Sign in to follow this  
Followers 0

A couple of apparent bugs

The first goes like this: I save a lump of a graphic to disk, lets say M_LSLEFT to m_lsleft.lmp, I open the lump with XWE and edit the alignment. I close it, open it, and the lump seems corrupt, as it is not identified as a graphic, and only displays raw data. But if I delete the lump and rename the backup (m_lsleft.lmp.001.tmp) to m_lsleft.lmp it reveals the graphic properly with the new alignment. If things were working correctly, the file itself wouldn't be mangled, and the backup would retain the old alignment.

The second is a visual glitch, where if I change the zoom of a graphic, it becomes all back. I haven't seen that glitch anywhere but in XWE (SLumpEd doesn't display the problem when zooming, for example). Plus it doesn't happen always, just most of the time, occasionally I can change the zoom factor and the graphics display properly.

I'm on Windows 98 and my graphics card is a 32 MB SiS.

Share this post


Link to post

I can't reproduce either. What I don't get about the first one, is why the extension changes to LMP. When you export an image, it's automatically saved as a BMP. I can open it, and even rename it to an LMP and open it - no problems. Did you change the extension manually?

The second one never happens for me either... If you can consistently reproduce it with an image, let me know.

Share this post


Link to post

Csabo said:
What I don't get about the first one, is why the extension changes to LMP.

Yeah, sorry, I forgot to mention how I do that. I choose View raw data in the Entry menu and then save it. My intent is to save it to disk in its native DOOM lump format (so I can then load Doom with whatever lumps I'm testing independently of any others). Once I do that the lump is openable with XWE (you added independent lump support not long ago), and it looks fine, but what I described happens if I change the offsets of the pic. Maybe its doing something to the lump file that it should only be doing to a wad?

The second one never happens for me either... If you can consistently reproduce it with an image, let me know.

This one affects all the graphics. When it happens, any graphics viewed with a zoom factor that's not 2 go black, but they still bear their natural outline. Like, you get the black silhouette of the imp's A1 frame over the cyan background if you increase the zoom factor (or decrease it to 1). As I type this post its not happening, but if I were to restart my computer it might.

Share this post


Link to post

Not that I really have just a lot of idea what's going on between XWE and your drivers, but I can note quickly that the SiS graphics chips have always been notorious for introducing bizarre and reproducible bugs in imaging software, and may be the root of the problem here. I know my old 64MB SiS 315 I used for awhile would corrupt webpages that used Flash all the time.

Share this post


Link to post

Katarhyne said:
SiS graphics chips have always been notorious for introducing bizarre and reproducible bugs in imaging software, and may be the root of the problem here.

Sounds likely; for example, they (since it was on two different SiS cards) do also somehow improperly read GLBoom's sky rendering, producing small stacking copies of the sky instead of one large sky graphic.

Share this post


Link to post

Hey myk,

Sorry for the delay. I looked at this again. I saved the lump as RAW, and re-opened it, adjusted the alignment, closed the file, then opened it again, and it looks fine. I tried it with several lumps, and also with the "Auto apply image offsets" on/off, but it all worked fine. I also stepped through the code, from the looks of it everything is right. (BTW, I think a Save as RAW data menu item would be useful.)

I can't figure out what we are doing differently... Maybe could you send me the lump after it got corrupted? It might help if I see what got written in to the file.

As for the other error, it sounds more and more likely that it's not a coding error, but something on your end. (I mean if it works fine sometimes...)

Share this post


Link to post

I sent the files by email; it seems to be adding the PWAD header at the top and the lump name at the end (I see this in "Veiw as Ascii" under Raw). As you'll see, the included backup is fine, with the new alignment (23 instead of 3).

I did something else to test; I saved another copy of the lump as raw, opened it, used the "apply alignment" option without even changing the offsets, and the lump was also PWADized.

And if these are renamed to *.WAD, they work... (as a wad with the lump in it).

Share this post


Link to post

Your description is accurate, what happens is the file gets rewritten as a regular valid WAD, with only one entry in it. The file you sent confirms it. I just don't understand why, but I suspect it's the cleanup function.

Please grab the latest beta. First of all I added the "Save as... (raw data)" menu item, I think this is a lot easier than switching to raw and back. I also added a small extra info after any file is opened, it lists the "file type". Just a number, which is the internal id for XWE, all we care about is 0 = WAD, anything else is non-WAD. Cleanup will not be performed unless the file is a WAD file.

If you run the last beta from the command line with "-debug" parameter, it will create a small text file called xwedebug.txt. That file will contain some info about your last session, so save it right after the file gets corrupted - if it still does, and email it to me or just post it here.

Share this post


Link to post

I tried it; this beta doesn't mangle the LMP file. When I reopened the lump after modifying it, it was fine and kept the new alignment.

Csabo said:
Just a number, which is the internal id for XWE, all we care about is 0 = WAD, anything else is non-WAD. Cleanup will not be performed unless the file is a WAD file.

Right, I see it says "File type 8" in the status bar for the one I used for testing (a Gfx), and it didn't create a backup, as expected.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0