Attack of the Glitches
<i>This post was originally made by <b>skyjake</b> on the dengDevs blog. It was posted under the category: jHexen.</i>
I now have jHexen up and running on the Mac with the latest code, but I'm experiencing a number of odd glitches.
<ul>
<li>Most (or even all) upper and lower wall textures are missing. They are simply not rendered at all. Clipping seems to work normally, though.</li>
<li>Enemies are invisible. Other mobjs seem to appear normal (sprites; I don't know about 3D models).</li>
<li>Sector light levels are wrapping over to black. E.g., in the first Hexen map with the flashes of lightning, some sectors become black during the flash. Probably caused by a byte variable overflowing somewhere (DMU?).</li>
<li>In some places, like the hall of the first Hexen map, clipping prevents visibility from one subsector to others, so that the player only seems the subsector he's currently in.</li>
</ul>
I'm unsure how many of these are caused by endianness issues and how many are bugs of some other kind, like DMU misuse. Danij, can you see if these also happen when running in Windows?
I now have jHexen up and running on the Mac with the latest code, but I'm experiencing a number of odd glitches.
<ul>
<li>Most (or even all) upper and lower wall textures are missing. They are simply not rendered at all. Clipping seems to work normally, though.</li>
<li>Enemies are invisible. Other mobjs seem to appear normal (sprites; I don't know about 3D models).</li>
<li>Sector light levels are wrapping over to black. E.g., in the first Hexen map with the flashes of lightning, some sectors become black during the flash. Probably caused by a byte variable overflowing somewhere (DMU?).</li>
<li>In some places, like the hall of the first Hexen map, clipping prevents visibility from one subsector to others, so that the player only seems the subsector he's currently in.</li>
</ul>
I'm unsure how many of these are caused by endianness issues and how many are bugs of some other kind, like DMU misuse. Danij, can you see if these also happen when running in Windows?
Comments
The rest all works fine in Windows (at least with jDoom & jHeretic, I've not tried jHexen yet). I'll give jHexen a try this morning before I start working on the code.
Can you give jDoom a try on MacOS. I would be interested to hear how you get on.
There is one bug though that I've been unable to find yet - loading a map with GL Node building disabled will ALWAYS crash Doomsday some time around initializing the links. I've checked the map data and it appears to be reading it all correctly.
The only other known issue (to me at least) is that when BIAS lighting is enabled - mid textures on twosided lines arn't renderer correctly. Reason being that I didn't know how I should implement the surface colors into the BIAS lighting's affected surfaces store.
BTW - there seems to be an issue with the BIAS lighting in that upper and lower textures are being lit differently to mid textures. Its as if they have a different surface normal.
<blockquote>Sector light levels are wrapping over to black. E.g., in the first Hexen map with the flashes of lightning, some sectors become black during the flash. Probably caused by a byte variable overflowing somewhere (DMU?).</blockquote>
I would imagine so considering the same issue is present in all three games and on my machine also.
<blockquote>In some places, like the hall of the first Hexen map, clipping prevents visibility from one subsector to others, so that the player only seems the subsector he's currently in.</blockquote>
That sounds very odd indeed. Unless the geometry does something extremely weird in that area I can't see how that would happen unless you were in the "void" at the time.
Have a look at <tt>Src/p_arch.c - ReadValue()</tt> does that <em>look</em> right to you? It would seem it works correctly under Windows at least.
I've just tried jHexen:
All looks fine to me other than the sector light values are wrapping and there is an issue with the spawn height of mobjs.
Currently it bombs rather soon due to missing DMU, polyobject properties but that is to be expected.
EDIT:
Judging by the values you've just added to jHexen's debug cheat it would appear you suspect a mixup of the sector floorheight/ceilingheight floorpic/ceilingpic members?
I've just noticed that jHexen's <tt>p_setup.h</tt> did not have the latest DAM constant list and have updated it to the correct values (in SVN).
I see you changed the pixel format expressed when loading the DLIGHT resource - dynlights, object shadows etc no longer display correctly for me. Have you removed the graphic resources from Data/Graphics and replaced them with the Doomsday.PK3?
Can you check how I'm binding the MISSING resource in <tt>Src/rend_main.c - Rend_PrepareTextureForPoly()</tt>, I'm getting some weird behaviour for any surfaces drawn using that texture.
Not atm. I changed the format of the ones in Doomsday.pk3 I've improved the DLight resource present in Doomsday.PK3 but reverted to using a white on black pixel format without an alpha channel.
The various graphic resources in Doomsday.pk3 should be used to overwrite those in the repository's Data directory. The pixel format for the DLight resource specified in the call to LoadGraphics will need to be changed back too of course.
<blockquote>Shouldn't those be in dd_share.h?</blockquote>
Yes they should.
I had them in each game's include directory initialy due to the way game-specific properties were handled but there is no reason to have them there now.
<blockquote>It would be best if development could be done with the individual files in the Data directory, while the Doomsday.pk3 would be compiled automatically for releases as part of a build, in the build scripts.</blockquote>
I see. That makes better sense.
Yep thats now fixed. I had to make the same fixes for both jDoom & jHeretic too after updating to DMU so the original source code was probably to blame here. However I don't appear to get any invisible mobjs in Windows.
<blockquote>Interesting, it appears that breakpoints placed at DAM_TOP_TEXTURE and DAM_BOTTOM_TEXTURE in ReadMapProperty() are never reached when loading up jHexen map01. Surely this is incorrect behaviour?</blockquote>
Yes that is incorrect behaviour and would definetly suggest there is an endianess problem in <tt>Src/p_arch.c - ReadValue()</tt>
<blockquote>How about the changes you've made in the renderer? Perhaps the endianness swapping macros are used twice (or not at all) for some values? I'll need to look into that. (I already fixed one double-swapping a while ago.)</blockquote>
I would think it unlikely the changes I've made in the renderer would be the cause. Primarily due to the fact that I now understand how most of the code works and why it does so
The endianness issue you mention due to double usage of the high byte swapping macros was another instance where I simply didn't understand what the code was doing.
At least the upper and lower wall texture indices seem to be initialized properly in P_LoadSideDefTextures().
This is a problem with a global table of property types in general. It requires that all instances of the same property are of the same type. In this case, we can make all the flags properties integers, but I wonder if this is going to bite us in the ass sometime in the future?
<blockquote>At least the upper and lower wall texture indices seem to be initialized properly in P_LoadSideDefTextures().</blockquote>That is correct yes.
<blockquote>It appears Rend_RenderWallSeg() never draws the upper and lower segments because seg->backsector is always NULL. Now, where is that initialized...</blockquote>That is initialised in <tt>Src/p_arch.c - P_ProcessSegs()</tt>. Perhaps there is an endianness issue there?
At least under Windows - I don't have this problem with seg->backsector being NULL (hence why you're experiencing missing upper/lower textures under MacOS).
Ah yes. That makes perfect sense now.
<blockquote>This is a problem with a global table of property types in general. It requires that all instances of the same property are of the same type. In this case, we can make all the flags properties integers, but I wonder if this is going to bite us in the ass sometime in the future?</blockquote>
I believe I ran into this issue earlier but changed the data type of the member in question at the time to "fix" the problem.
It could indeed be a problem at a later date. I'm wondering if it would be better to maintain an array properties and set the data types there, per property instead of per constant (and store all the map object property values in the same place, including debug strings, DAM and DMU constants etc).
Sector lightlevels are determined in the same way but an offset is added to all values depending on the "light range" of the viewplayer. This light range picks an appropriate offset for the light value from the lightRangeModMatrix which is a pre-calculated array of values determined from the various CVARS that control the lighting (ambient light limit, light range compression etc, etc).
However. When the viewplayer's light range is at normal (the mid point in the lightRangeModMatrix) there should be no offset applied to the light values if both ambient light and range compression is turned off.
Set the CVAR <strong>rend-dev-light-modmatrix 1</strong> to view the light range matrix.
IMPORTANT: I still need to set the default light values used in the code to the values I've determined in-game (by changing the lightrange ramp, multiplier CVARS) to those in my local <tt>jDoom.cfg</tt>, so you might be getting decidedly different results than me...
Light range compression is the reason you're experiencing a much brighter jHexen. In the code I had the default set to 80% (which increases the lighting in dark sectors by this factor (note that the factor reduces expodentially in-line with the original light value. This means that eg, pitch black sectors are still pitch black)).
Yes, though I had intended to leave the final decision up to you. I find that a little bit of positive (around 10%) light compression coupled with increased light attenuation (black fog) looks closer to the original games on my machine.
You'll notice both positive and negative values work for light range compression (positive brightens dark sectors, while negative darkens light sectors.
The initial value of 80% was before I adjusted the range to go from -100% to +100% (and changed how the value is interpreted). Setting it to 0% should result in the same look as has been present in Doomsday previously.
It would appear that my videocard is knackered
I've tried updating drivers etc but no no-avail.
Any surfaces using that texture are replaced with a moire static depending on view angle...
I'll dig my old GFMX440 out and see if that fixes it.
About the black lightning: there was an instance of SetFixed used with DMU_LIGHT_LEVEL, which of course resulted in very low lightlevels. Are you seeing any other issues similar to this?
Also, another weird thing I'm now getting: In jHexen, I can punch invisible sector boundary lines. There is the sound effect and the little puff of dust and all. This is perhaps related to the flags issue, or something similar. Does this happen at all in Windows?
<blockquote>About the black lightning: there was an instance of SetFixed used with DMU_LIGHT_LEVEL, which of course resulted in very low lightlevels. Are you seeing any other issues similar to this?</blockquote>I've not noticed any other issues along those lines in jDoom & jHeretic up till now. I'll do a sweep of the games' code and look for any issues where lightlevel is treated as fixed_t.
<blockquote>Also, another weird thing I'm now getting: In jHexen, I can punch invisible sector boundary lines... Does this happen at all in Windows?</blockquote>Nope, though I can punch the stained glass windows at the start of MAP01 and although the glass shards are spawned and the sound played - the mid texture stays the same and the BLOCKED flag is not removed from the line.
Unfortunetly it would seem that the problems with binding the "MISSING" texture have not been resolved by changing videocards.
With the latest code in SVN, what happens is one in every twenty or so wallsegs renderered with this texture have glitches (interestingly it never happens with plane polys). The texture will disappear and be replaced by another texture/flat.
Skyjake - What issues remain, under MacOS?
What would you like to do about the global property type arrays used by DMU and DAM?
Stop answering to posts/reviving threads that are roughly 10 years or more old. That's quite annoying and unnecessary.
If you have something important to say, raise a new thread and make a references to old posts where necessary.