Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Attack of the Glitches

edited 2006 Mar 12 in Developers
<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?

Comments

  • This does sound a little extreme but at least on Windows - the only glitch I experience is the sector light levels wrapping with sector lighting specials.

    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.
  • Thinking about these glitches and endianness...

    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).
  • More glitches:
    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.
  • <blockquote>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?</blockquote> But aren't Data/Graphics/DLight.png and the one in Doomsday.pk3 the same image? They should be, if they aren't at the moment. (So that Doomsday.pk3 can be compiled out of the files in the repository's Data directory.) The DLight.png in the repository has an appropriate alpha channel, so LGM_NORMAL is the correct loading mode.
  • <blockquote>I've just noticed that jHexen's p_setup.h did not have the latest DAM constant list and have updated it to the correct values (in SVN).</blockquote>Shouldn't those be in dd_share.h?
  • <blockquote>But aren't Data/Graphics/DLight.png and the one in Doomsday.pk3 the same image? They should be, if they aren't at the moment.</blockquote>
    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> 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.</blockquote> Ah, I see. Since you know which changes you've made in the Data dir, could you make sure all the files are correctly up to date? 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>Can you give jDoom a try on MacOS. I would be interested to hear how you get on.</blockquote>Running jDoom on the Mac: I'm getting identical missing upper/lower wall segments and clipping problems. This would suggest it's an endianness problem in some of your new p_arch code. 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>there is an issue with the spawn height of mobjs.</blockquote> Does this happen any more? I fixed a case of P_GetInt() that was used for storing heights into floorz/ceilingz, which are fixed_t. For me the spawn heights look just about correct now, but some mobjs are still invisible in jHexen (e.g., wall torches, enemies).
  • 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>Ah, I see. Since you know which changes you've made in the Data dir, could you make sure all the files are correctly up to date?</blockquote>Yes, I will.
    <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.
  • <blockquote>Does this happen any more? I fixed a case of P_GetInt() that was used for storing heights into floorz/ceilingz, which are fixed_t. For me the spawn heights look just about correct now, but some mobjs are still invisible in jHexen (e.g., wall torches, enemies).</blockquote>
    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.
  • <blockquote>Yes that is incorrect behaviour and would definetly suggest there is an endianess problem in Src/p_arch.c - ReadValue()</blockquote> The breakpoints are not reached because the HEXEN lump format specification only defines fields for texture offset x/y and the front sector. The textures are apparently read via P_LoadSideDefTextures(), outside of the other processing. (Should be fixed?)

    At least the upper and lower wall texture indices seem to be initialized properly in P_LoadSideDefTextures().
  • It appears Rend_RenderWallSeg() never draws the upper and lower segments because seg->backsector is always NULL. Now, where is that initialized...
  • I'm getting lines without ML_TWOSIDED, even though they have a front and a back sector (in P_ProcessSegs). This at least is one cause for null seg->backsectors.
  • I believe I've got this just about figured now. It comes back to DAMpropertyTypes. DAM_FLAGS is specified as DDVT_INT, even though segs use a byte for flags and sides and lines use a short. The endianness comes into play, and the flags are written outside the member variable.

    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>The breakpoints are not reached because the HEXEN lump format specification only defines fields for texture offset x/y and the front sector. The textures are apparently read via P_LoadSideDefTextures(), outside of the other processing. (Should be fixed?</blockquote>That is correct. The reason being that textures need to be read at a latter point in the read process to allow the line's special to be referenced in the game's (BOOM support).
    <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).
  • <blockquote>I believe I've got this just about figured now. It comes back to DAMpropertyTypes. DAM_FLAGS is specified as DDVT_INT, even though segs use a byte for flags and sides and lines use a short. The endianness comes into play, and the flags are written outside the member variable.</blockquote>
    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).
  • Now I've got the upper and lower wall segments rendered correctly, but enemies and some of the mobjs are still missing. Also, have you modified the way sector lightlevels are determined? Map01 in jHexen seems a little brighter than I remember...
  • <blockquote>Also, have you modified the way sector lightlevels are determined? Map01 in jHexen seems a little brighter than I remember...</blockquote>
    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...
  • Ok I've now updated the defaults for the relevant variables.

    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)).
  • <blockquote> 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)).</blockquote> Is this intended for official use, too? I would've assumed that the default makes things a bit darker? Doomsday has always been somewhat lighter than the original games, since the lightness isn't reduced by distance as radically as in the original Doom renderer.
  • <blockquote>Is this intended for official use, too?</blockquote>
    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.
  • <blockquote>Can you check how I'm binding the MISSING resource in Src/rend_main.c - Rend_PrepareTextureForPoly(), I'm getting some weird behaviour for any surfaces drawn using that texture.</blockquote> Seems OK to me. What kind of weird behaviour are you seeing?
  • <blockquote>Seems OK to me. What kind of weird behaviour are you seeing?</blockquote>Thanks for checking.

    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.
  • <blockquote>Any surfaces using that texture are replaced with a moire static depending on view angle...</blockquote> This isn't necessarily a problem with your video card. I've seen this kind of thing before. At least on one occasion it was due to the curtex variable, which was preventing the binding of a texture because curtex and the currently bound texture had gotten out of sync -- Doomsday didn't think it needed to bind the texture even though it really should've. So, keep digging...

    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>This isn't necessarily a problem with your video card. I've seen this kind of thing before. At least on one occasion it was due to the curtex variable, which was preventing the binding of a texture because curtex and the currently bound texture had gotten out of sync — Doomsday didn't think it needed to bind the texture even though it really should've. So, keep digging...</blockquote>I've just quickly swapped in my old videocard and the problem does seem to have disappeared... however given what you've said I'll experiment further with that to see if I can see anything.
    <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.
  • <blockquote>About the black lightning: there was an instance of SetFixed used with DMU_LIGHT_LEVEL, which of course resulted in very low lightlevels.</blockquote>There was a couple of instances of the same in jDoom & jHeretic. I've replaced them with SetInt and as expected the light wrapping is now fixed (or not <i>fixed</i> depending on how you look at it :) )
  • I think we could do with a quick stock take of what doesn't work correctly atm.

    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?
Sign In or Register to comment.