Color bug

Moderators: Rachael, dpJudas

Locked
ibm5155
Posts: 152
Joined: Tue Oct 25, 2011 13:05

Color bug

Post by 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: And here is how it looks for now:
Image
Attachments
startuplog.txt
(1.51 KiB) Downloaded 88 times
User avatar
Rachael
Developer
Developer
Posts: 3640
Joined: Sat May 13, 2006 10:30

Re: Color bug

Post by 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
Posts: 152
Joined: Tue Oct 25, 2011 13:05

Re: Color bug

Post by 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
Image
Gzdoom
Qzdoom: Opengl/DIRECT3D Truecolor OFF/ON , opengl Accelerated:
Image
Qzdoom: Direct3d Truecolor off , Doom software renderer:
Image
Qzdoom: Direct3d Truecolor ON , Doom software renderer:
Image
Qzdoom: OpengGL Truecolor ON , Doom software renderer:
Image
Qzdoom: OpengGL Truecolor OFF , Doom software renderer:
Image

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
User avatar
Rachael
Developer
Developer
Posts: 3640
Joined: Sat May 13, 2006 10:30

Re: Color bug

Post by 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
Posts: 152
Joined: Tue Oct 25, 2011 13:05

Re: Color bug

Post by 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
Last edited by ibm5155 on Sat Oct 29, 2016 15:50, edited 1 time in total.
User avatar
Rachael
Developer
Developer
Posts: 3640
Joined: Sat May 13, 2006 10:30

Re: Color bug

Post by 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
Posts: 152
Joined: Tue Oct 25, 2011 13:05

Re: Color bug

Post by ibm5155 »

Eruanna wrote: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?
Last edited by ibm5155 on Sat Oct 29, 2016 15:59, edited 1 time in total.
User avatar
Rachael
Developer
Developer
Posts: 3640
Joined: Sat May 13, 2006 10:30

Re: Color bug

Post by 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 200 times
ibm5155
Posts: 152
Joined: Tue Oct 25, 2011 13:05

Re: Color bug

Post by 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.
Last edited by ibm5155 on Sat Oct 29, 2016 16:15, edited 1 time in total.
User avatar
Rachael
Developer
Developer
Posts: 3640
Joined: Sat May 13, 2006 10:30

Re: Color bug

Post by 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
Posts: 152
Joined: Tue Oct 25, 2011 13:05

Re: Color bug

Post by 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 :mrgreen:
Last edited by ibm5155 on Sat Oct 29, 2016 16:38, edited 2 times in total.
User avatar
Rachael
Developer
Developer
Posts: 3640
Joined: Sat May 13, 2006 10:30

Re: Color bug

Post by 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
Developer
Developer
Posts: 798
Joined: Sat Jul 23, 2016 7:53

Re: Color bug

Post by 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.
User avatar
Rachael
Developer
Developer
Posts: 3640
Joined: Sat May 13, 2006 10:30

Re: Color bug

Post by Rachael »

ibm5155
Posts: 152
Joined: Tue Oct 25, 2011 13:05

Re: Color bug

Post by ibm5155 »

Image
And randi saves the day :D
Locked

Return to “Closed Bugs”