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

General Discussion
1

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!)

2

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)

3

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?

4

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:

5

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?

6

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:

SAVE_FILES = USER_DIR + "/Saves/"

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.

7

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: