Color bug

[ibm5155]

I've tested my mod with Gzdoom and, some colors are quite broken, and the engine just freeze when I look around O_o
Testing wad: http://www.mediafire.com/download/o4k80 ... AND_v5.pk7

In software to opengl it actually Works, but all the colours are crazy O_o

and using 256 color mode makes things even more weird O_o
In case you guy wonder, here's how the map should look:

LINK

And here is how it looks for now:

[Rachael]

I probably should've asked this in the other thread but I spaced it - but what does this look like in plain old ZDoom?

[ibm5155]

ehm, with zdoom 2.8 it gives the right color for the arrow, but there are some garbage on screen (blue dots), + if I move around the game just crash
EDIT: screenshot time:
*Note: the arrow key under the screen shots Always changes the color, so that's why all the screenshots doesnt have the ame color (but it should be a single color each tic for all the arrow)
Zdoom 2.8

Gzdoom
Qzdoom: Opengl/DIRECT3D Truecolor OFF/ON , opengl Accelerated:

Qzdoom: Direct3d Truecolor off , Doom software renderer:

Qzdoom: Direct3d Truecolor ON , Doom software renderer:

Qzdoom: OpengGL Truecolor ON , Doom software renderer:

Qzdoom: OpengGL Truecolor OFF , Doom software renderer:


All the modes that shows some kind of glitch Always freeze (not crash) when looking around, but not in the case of using the zdoom true color off and software render with direct3d/opengl

edit2: HMMM there's even a skybox glitch in opengl mode render O_o (gzdoom mode) I dont remember of seeing such black trangles on sky :O

edit3: finally a crash message with qzdoom:
Execution could not continue.

Fatal drawer error: DrawSpanLLVMCommand
x1 = 494, x2 = 517, y = 269, flags = 3

...
Just go opening the doors in front of you in the start with idkfa and boom

[Rachael]

So yeah, I dunno what kind of funky stuff you managed to put into this map, but it's a wonder it even runs at all.

[ibm5155]

idk why the door is broken, maybe it's related to the fact that I'm using 1x1 textures?

EDIT2: The fatal errors under "zdoom mode" is related to the map size that's huge, the truecolor implementation does something that fixes that, but it's not 100% stable

[Rachael]

Could be. The map runs fine on OpenGL for some reason, but in Software there are read violations everywhere. This match glitches the hell out of ZDoom, too.

[ibm5155]

Could be. The map runs fine on OpenGL for some reason, but in Software there are read violations everywhere. This match glitches the hell out of ZDoom, too.

the LLVM is related to some point to the skybox where in this case is a "dynamic skybox" (where the skybox câmera pos moves based on the player position)
EDIT: Or maybe not, the crash is quite random with the LLVM
is there some kind of debug console?

[Rachael]

The problem is the 1x1 textures. The drawspan functions read beyond the 1x texture expecting there to be more data - but there's not. The reason this works in OpenGL is because OpenGL can read those textures exactly as-is.

What's attached is not a fix, but it at least gets it working. This is a bug in what I suspect the original Doom code that ZDoom inherited, meaning it likely affects all source ports. This bug should be reported at the ZDoom forum but you can link this topic.

GLITCHLAND_v5_new.pk7

(66.52 KiB) Downloaded 442 times

[ibm5155]

hmm now it's working in software 256 color mode (looks cool actually), but in truecolor mode there's still some kind of LLVM error :s.
But yes I'll repor this case to zdoom either.

[Rachael]

Have you tried the newest QZDoom? Probably against the advice of every programmer ever in existence (and oddly, it's convenient and I like it for some reason), it will run after getting drawer access violations, but if you see the error it still should be reported.

[ibm5155]

I had tested the latest build from this morning (the one from day 27), I tested new one and it looks ok, you shouldn't crash a game just because something isn't being rendered right...
And it has been created: http://forum.zdoom.org/viewtopic.php?f=2&t=53997

EDIT: Well, at least now the glitchland has a special cool looking in software emode with true color

LINK

[Rachael]

Alright. There's actually a very good reason to crash the game - access violations are a programming error that need to be fixed - but an end user is not concerned about those. Access violations can cause memory corruption and even more programming glitches down the line which become harder to track down later.

I think the reason why dpJudas put in the code he did is because of exactly that - he wants to still be able to track those, but he doesn't want to stop people from playing just because they occur. They're just as serious an issue, none the less, but at least they're only read errors which do not cause the kind of problems write errors can.

[dpJudas]

Eruanna is exactly right about my reasoning for not crashing the game with read access violations. Partly also because the multithreaded nature of the renderer means that when a read access violation occurs, the "crime" was committed eons away from the crash point.

Ideally I'd like to make it so that no matter what calculations stuff like R_DrawMaskedColumn does, the texture coordinates fed into the drawers can never go out of bounds. Kind of how OpenGL never crashes no matter how garbage texture coordinates gzdoom might feed it. We are not fully there yet, but at least this gets it a little bit closer to that.

[Rachael]

Randi fixed this.

[ibm5155]

And randi saves the day