"Texture.write" doesn't work under Windows?

This is odd, and I’m honestly not sure of whether it’s a bug, or something that I’m doing wrong (a missing dependency, perhaps). o_0

In short, in a Windows distributable build (created sometime yesterday, I think that it was), a call to “Texture.write(Filename())” fails. Under Ubuntu, whether in a distributable build (made today, admittedly) or in the SDK, it seems to work as expected.

Directly before this call, I’m also writing out a text-file via my “GameSaver” module; this seems to work on either platform, and uses the same base file-path string. (It doesn’t, however, use a “Filename” object, I believe.)

No errors or notifications seem to be printed out, even with sys.stdout and sys.stderr redirected, and notify-output set. The call seems to simply do nothing.

The texture appears in-game (it’s displayed on-screen) before attempting writing, so I imagine the the texture itself is fine as far as that goes.

In case it’s relevant, the texture was created via a call to “DisplayRegion.getScreenshot()”.

(I haven’t rebuilt this for Windows since yesterday, I don’t think. If changes have been made recently that may affect this, I can create a new build and double-check that the issue persists, I daresay!)

Some cases I know Texture.write() fails on windows:
-texture has no ram image if its a texture buffer or suchlike (need to use extractTextureData)
-the directory you’re trying to write doesn’t exist
-permission problems (when game is in ‘program files’ and not run as an administrator)

Hmm… The latter two issues don’t seem likely in this case: I’m writing two other files to the same location directly before the attempted texture-save; they’re text-files, not images, but it still seems to indicate that the directory is present and that I have permission to write there. (The directory in question is in a relevant user-data directory–“C:\Users<user-name>\AppData\Local<game-name>\Saves”, to be specific–I believe.)

So, does an image produced by “DisplayRegion.getScreenshot()” usually have a RAM-image?

I imagine it should. A simple test is to print the texture if it says ‘no ram image’ then there’s no ram image.

I did a quick test and I can write a texture under windows using: base.win.getDisplayRegion(0).getScreenshot().write(‘some.jpg’) and a texture I got from getScreenshot() is totally valid and has a ram image, so I don’t think this is your problem :blush:

Are you using a Unix-style path? So, /c/path/to/file.png instead of C:\path\to\file.txt (otherwise you need to use Filenam.fromOsSpecific.) And what is the return value of the write() call?

Ah, sorry for the delay in response–I somehow missed your reply! ^^;

Ah, that might be the problem. Looking at my code, I see that I determine the user-directory to be:

USER_DIR = Filename(Filename.getUserAppdataDirectory(), "ADoorToTheMists").toOsSpecific()

My save-file directory is then specified to be:


So not only does the save-file directory use an OS-specific directory, it then mixes the styles. :confused:

So, what I should perhaps do is leave the user-directory in the default format, and convert to OS-specific when called for.

I think that I’ll create a new build with this in mind (as well as printing out the result of the “write” command, just in case), and report back.

Indeed, that seems to have been the problem!

(It’s a bit of an awkward one to fix at this point, to my annoyance–but so it goes. I’m currently at least partway through dealing with it, I believe.)

Thank you very much for the aid! :slight_smile: