GZDoomBuilder-Bugfix, a maintenance fork of GZDB

[DnB-Freak]

This is not a bug, certainly not with GZDBBF when you present a corrupted image to the editor.
As to the conversion in Slade3, to convert to a flat image the image must be between F_ markers.

I used Slade3.1.2 to convert it to an opaque flat.
The flat itself was exactly 4096 Bytes in size, where does the corruption go? In Slade3?
I've tried to save it as an 24-bit PNG from several different programs, imported it and converted it so it's for sure nothing wrong with the PNG.
It worked fine in Slade3, it was displayed as a normal 64x64 flat and nothing else.

In GZDBBF all the other flats was normal except of this one and Yes, my flats ARE between the F_markers(even pre-conversion).

Instead of disclaiming it's a bug, analyze it.
On my PC in GZDB I see a 1x1 black square instead of a 64x64 flat.
What would you do?

• Save METALF24.PNG
• temporary import it into a wad
• put it between F_markers and convert it to an opaque flat
• save the wad, run GZDBBF and open any map
• Select linedef or sector and view textures

A:
Finally if you find that currently imported flat as an 1x1 black square, it got to be a bug/glitch in GZDBBF.

B:
If not, you see the flat properly then it's certainly something wrong with SLADE3 or GZDBBF that are on my PC.
Almost unimaginable every graphics software on my PC is corrupt.

[ZZYZX]

Can you send me the exact minimal WAD that has this reproduced (that only has this flat)? I tried to convert manually but seems to be working...

[DnB-Freak]

Here we go:

[ZZYZX]

My SLADE (v3.1.1.4) just hangs up trying to open that file. I doubt it's related though
Opened with XWE, things seem correct. Will try to understand what happens.

Anyway, I think I found the cause. MaxED is fucking genius.
Your lump begins with the following hex bytes:

Code: Select all • Expand view

02 00 00 08 02 00 00 00 00 08 02 EF 02 02 EF 02 08

Apparently this triggers the function that's commented as follows

Code: Select all • Expand view

            //mxd. TGA is VERY special in that it doesn't have a proper signature...
            if(CheckTgaSignature(data)) return new FileImageReader(DevilImageType.IL_TGA);

I'm probably going to throw this function out move it a bit lower or make flat detection go first. Or look at how GZDoom does it. But the current way is very wrong.

Anyway, commented step-by-step algorithm reproduction under spoiler

---

Code: Select all • Expand view

      private static bool CheckTgaSignature(Stream data)
      {
         // TGA header is 18 bytes long
         if(data.Length < 18) return false; // 4096 is larger than 18, so this passes
         
         // Rewind the data first
         data.Seek(0, SeekOrigin.Begin);

         // Read TGA header
         int idlength = data.ReadByte(); // Can be 0 or the length of ID string, whatever that is
         // [ZZ] : first byte is 0x02
         int colormap = data.ReadByte(); // Can be 0 or 1
         // [ZZ] : second byte is 0x00. this passes
         if(colormap != 0 && colormap != 1) return false;

         int imagetype = data.ReadByte(); // Can be 0, 1, 2, 3, 9, 10, 11
         // [ZZ] : third byte is 0x00. this passes
         if((imagetype > 3 && imagetype < 9) || imagetype > 11) return false;

         data.Position += 9; // Skip some stuff... // [ZZ] : here it just ignores a lot of bytes. next relevant chunk begins at 0x0C hex.

         // [ZZ] : due to following bytes being 02 02 EF 02, width and height are read as 514x751

         int width = data.ReadByte() + (data.ReadByte() << 8);
         if(width < 0 || width > 8192) return false;

         int height = data.ReadByte() + (data.ReadByte() << 8);
         if(height < 0 || height > 8192) return false;

         int bitsperpixel = data.ReadByte();  // Can be 8, 16, 24, 32
         // [ZZ] : and then this byte is 0x08. so it also passes the "TGA check"
         return (bitsperpixel == 8 || bitsperpixel == 16 || bitsperpixel == 24 || bitsperpixel == 32);
      }

Updated the build, this should be fixed as of R3008.

Among other good news:
The auto-updating error should be gone now thanks to Rachael.
Also, since I opened Visual Studio anyway, blood's bug is fixed now. (this one)

Bad news is that I still can't make myself look into the issue with assigning DoomEdNums from another archive >_>

[DnB-Freak]

Thank you, ZZYZX.

I've tried one thing btw...

---

Tried to read lump manually with PS...

Exporting the Flat Lump
Opening it as 8bit 64x64 raw in PS
Set Image type to Indexed and import the doom palette assigning it to the image

It looked identical so I:
Saved it via PS as TGA (Type 1) (no RLE-compression)
Opened it in a HexEditor and found the structure of the flat lump just after the palette index at offset 786,
but as the palette was in reverse order I had to "Flip" each byte polarity...

in pascal programming language it's done similar to this way (not the best code, anyhow) abstract:

Code: Select all • Expand view

for I:=786 to StreamA.size do
begin
  A := StreamA.Read(I, 1);
  B := 255 - A;
  StreamB.Write(B, 1);
end;

I know Flats got no headers, but what I dunno certainly understand yet is that the FileImageReader detected the first bytes of the flat as a signature of a TGA?

[ZZYZX]

TGA doesn't have a signature either. So GZDB just detects TGA by "starting bytes kinda look like TGA", so bytes in certain range will detect as TGA if you're (not) lucky enough.
Basically according to TGA's detection algorithm in GZDB, if first few bytes are zero, bytes from 0x0C to 0x10 are not zero (and read to reasonable size values), and byte at 0x11 is 8, 16, 24 or 32, then your file is a TGA.

[abbuw]

Scrolling a vertex slope sector up and down in visual mode with enhanced rendering effects disabled pops up this error.

Code: Select all • Expand view

***********SYSTEM INFO***********
OS: Microsoft Windows 10 Home
GPU: Intel(R) HD Graphics 5500
GZDB: R3009

********EXCEPTION DETAILS********
Index was outside the bounds of the array.
   at CodeImp.DoomBuilder.BuilderModes.BaseVisualVertex.GetSectorHeight() in w:\dev\GZDoom-Builder\Source\Plugins\BuilderModes\VisualModes\BaseVisualVertex.cs:line 98
   at CodeImp.DoomBuilder.BuilderModes.BaseVisualVertex.Update() in w:\dev\GZDoom-Builder\Source\Plugins\BuilderModes\VisualModes\BaseVisualVertex.cs:line 66
   at CodeImp.DoomBuilder.BuilderModes.BaseVisualVertex..ctor(BaseVisualMode mode, Vertex v, Boolean ceilingVertex) in w:\dev\GZDoom-Builder\Source\Plugins\BuilderModes\VisualModes\BaseVisualVertex.cs:line 51
   at CodeImp.DoomBuilder.BuilderModes.BaseVisualMode.GetVisualVertex(Vertex v, Boolean floor) in w:\dev\GZDoom-Builder\Source\Plugins\BuilderModes\VisualModes\BaseVisualMode.cs:line 730
   at CodeImp.DoomBuilder.BuilderModes.VisualFloor.ChangeVertexHeight(Int32 amount) in w:\dev\GZDoom-Builder\Source\Plugins\BuilderModes\VisualModes\VisualFloor.cs:line 373
   at CodeImp.DoomBuilder.BuilderModes.VisualFloor.ChangeHeight(Int32 amount) in w:\dev\GZDoom-Builder\Source\Plugins\BuilderModes\VisualModes\VisualFloor.cs:line 348
   at CodeImp.DoomBuilder.BuilderModes.BaseVisualGeometrySector.OnChangeTargetHeight(Int32 amount) in w:\dev\GZDoom-Builder\Source\Plugins\BuilderModes\VisualModes\BaseVisualGeometrySector.cs:line 789
   at CodeImp.DoomBuilder.BuilderModes.VisualFloor.OnChangeTargetHeight(Int32 amount) in w:\dev\GZDoom-Builder\Source\Plugins\BuilderModes\VisualModes\VisualFloor.cs:line 333
   at CodeImp.DoomBuilder.BuilderModes.BaseVisualMode.RaiseSector8() in w:\dev\GZDoom-Builder\Source\Plugins\BuilderModes\VisualModes\BaseVisualMode.cs:line 2095
   at CodeImp.DoomBuilder.Actions.Action.Begin() in w:\dev\GZDoom-Builder\Source\Core\Actions\Action.cs:line 266
   at CodeImp.DoomBuilder.Actions.ActionManager.BeginActionByKey(Int32 key, Boolean repeated) in w:\dev\GZDoom-Builder\Source\Core\Actions\ActionManager.cs:line 576
   at CodeImp.DoomBuilder.Actions.ActionManager.KeyPressed(Int32 key) in w:\dev\GZDoom-Builder\Source\Core\Actions\ActionManager.cs:line 515
   at CodeImp.DoomBuilder.Windows.MainForm.OnMouseWheel(MouseEventArgs e) in w:\dev\GZDoom-Builder\Source\Core\Windows\MainForm.cs:line 1342
   at System.Windows.Forms.Control.WmMouseWheel(Message& m)
   at System.Windows.Forms.Control.WndProc(Message& m)
   at System.Windows.Forms.ScrollableControl.WndProc(Message& m)
   at System.Windows.Forms.ContainerControl.WndProc(Message& m)
   at System.Windows.Forms.Form.WndProc(Message& m)
   at CodeImp.DoomBuilder.Windows.MainForm.WndProc(Message& m) in w:\dev\GZDoom-Builder\Source\Core\Windows\MainForm.cs:line 4146
   at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
   at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
   at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)

[Wiw]

I keep getting this error:

"Unable to make file image. AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt."

Is there some way of remedying this? How did it come about?

[Galathrax]

So I'm new here, and I just registered to ask some questions, this is a pretty long thread so I hope I'm not asking something that's been answered a few times already. Is there a comprehensive guide to using the latest version of gzdoom builder somewhere? I downloaded builder because it seems to be the most up to date edition, but I checked the main post and didn't see anything about guides for how to use the program, what resources are, how to use them, etc. Basic stuff on getting started. Hope someone can help me.

[Kappes Buur]

So I'm new here, ...... Hope someone can help me.

Welcome to the world of DOOM map creation.

Maybe my guide will help you or at least point you in the right direction.

[Galathrax]

So I'm new here, ...... Hope someone can help me.

Welcome to the world of DOOM map creation.

Maybe my guide will help you or at least point you in the right direction.

Thank you very much! Glad to have gotten a quick reply, any resource at all to help is appreciated.

[ZZYZX]

I keep getting this error:

"Unable to make file image. AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt."

Is there some way of remedying this? How did it come about?

Full stack trace please.

Also, I'd really like to suggest everyone who doesn't do it yet to actually use the GitHub issues. Every time a new issue is created, I get an email notification, which then shows up on my Android once I open it So it's a lot harder to miss something there. I know I could subscribe to this thread but since it has a lot of other talk... (and either way issues are cleaner)

[ZZYZX]

Breaking news people! GZDB now supports a native 64-bit binary, which means it can now use 2k HD textures on a regular basis without going out of memory

As one of consequences of this, the .NET version requirement was bumped up to .NET 4.6.x. Most users aren't going to notice this, but if you do — update please.
If you have really ancient OS like Windows XP, you may as well consider switching to Doom Builder X, as it has lower system requirements too :Р

Note that due to historical reasons (notably possible 64-32 plugin incompatibility) it will NOT update to 64-bit automatically.
You can grab the latest 64-bit version here: https://devbuilds.drdteam.org/gzdbbf/

[Kinsie]

The latest build appears to crash on startup, at least on both my machine and Batandy's.

[ZZYZX]

It seems in this case installing it into a clean directory should work. Apparently this happens if you have old plugins, these are not compatible. (at least for whatever reason my local installation of r28-something autoupdated just fine)