Approaching Beta 4 (part 2)

edited 2006 May 26 in Developers
<i>This post was originally made by <b>skyjake</b> on the dengDevs blog. It was posted under the categories: Beta 4, Engine, Games, jDoom, jHeretic, jHexen, Releases, Version 1.9.</i>

The previous post on Beta 4 is getting quite long, so I thought it would be good to create an update post. Here is the to do list, with completed items removed:
<h3>To Do for Beta 4</h3>
<ul>
<li>Update release notes/change log.</li>
<li>There were reports of jHeretic savegame issues. Are they still occurring? I haven't been able to reproduce any yet.</li>
<li>XG: Still some noticeable problems here due to the existing DMU implementation being incomplete. Noteably dummy object handling - Doomsday isn't checking if an object is a dummy before calling P_Callback(p). Mostly fixed / still broken?</li>
<li>Doomsday: The background of the startup window is completely black in Windows. The text is visible and everything is else looks normal.</li>
<li>Map loading:
<ul>
<li>[FIXED in SVN 3225] DoomII MAP30 bug: Currently Doomsday will segfault when warping to MAP30 when it has been loaded once already.</li>
<li>[FIXED in SVN 3228] Slige maps bug: Currently when respawning on a map created by Slige Doomsday will exit with the error "W_GetNumForName: E1M1 not found!". I think somehow there is a mixup between whether the map lumps are loaded via the primary or auxilary lump cache (no BSP lumps are present in the PWAD but we use dpMapLoader to generate them at runtime). The first time the map is loaded the lumps are in the primary while subsequent attempts look to the auxliary cache.</li>
<li>[FIXED in SVN 3223] Currently if GL node buidling is disabled Doomsday segfaults during the load process. Doomsday's map polygonizer is broken?</li>
</ul>
</li>
<li>[FIXED in SVN 3208] jDoom: Line attack weapons are hitting planes with the skyflat and spawning PUFFs. Update; I've looked in to this and this bug only happens within a very particular set of circumstances and is VERY rare. I've not yet found the cause.
Update 2; I've found the problem. It's caused by the plane hit point algorithm in PTR_ShootTraverse returning an incorrect subsector as the contact point when the ceiling/floor on the front and back of the line is at the same height.</li>
<li>[FIXED in SVN 3212] jDoom: The stairs in the midle of the map dont raise up in DooMII Map07 once you have killed all the monsters. Most probably a dummy line/DMU issue.</li>
<li>[FIXED in SVN 3205] ictest.wad crash.</li>
</ul>
<h3>For Beta 5</h3>
<ul>
<li>Revise source directory hierarchy. Effect on runtime directory structure to be determined after Beta 4 has been released.</li>
<li>Current light range is reset when when changing sectors.</li>
<li>R_UpdateSector - Need to do something about the glow property update?</li>
<li>Sound and model decorations in addition to light decorations. (Does not affect the ABIs, so not really in any hurry but a really nice feature to have.)</li>
</ul>
Depending on how much of these can be addressed during the week, we could try to make a release next weekend.
«1

Comments

  • The stairs in the midle of the map dont raise up in DooMII Map07 once you have killed all the monsters
  • <blockquote>Depending on how much of these can be addressed during the week, we could try to make a release next weekend.</blockquote>
    I'll try any get as much done this week as possible. I seem to have more free time weekday evenings then weekends these days.

    I've not noticed any more problems with saves in any of the games.

    There are still a few problems with XG and DMU. I've found a few things which will instantly cause a seg violation.

    How about the yet to be implemented P_Copy/Swap(p) should that not be in for beta4? However we'd need that DMU constant to property conversion stuff.

    I've found a serious bug with the light grid with regard to DOOM.EXE hacks. Here is a map for debug (DOOMII MAP01) - <a rel="nofollow" href="http://www.daniel.ddsdesign.co.uk/Stuff/ictest.wad">ictest.wad</a&gt;
    Walk towards the red pillar and you'll hit an invisible wall (which SHOULD have a mid texture on it btw) and press use to open the midgrate door.
    The crash appears to be happening in LG_SectorChanged(), some debug code reveals:
    <blockquote>info->blockcount = 65535

    info->changedblockcount = 0</blockquote>
    That sounds wrong to me. Something is going wrong during the lightgrid init. Now the sector in question is unclosed so that might be throwing things completely off...

    Beta 5 - sound generators:

    It would be great if we could generalize the texture/flat decorations system so that potentially any object can be attached as well as lights.
  • <blockquote>That sounds wrong to me. Something is going wrong during the lightgrid init. Now the sector in question is unclosed so that might be throwing things completely off...</blockquote> My first guess would be that since the sector is not closed, the IsPointInSector test concludes that all points are within the sector, thus the sector is considered to affect all the blocks of the lgrid. In LG_Init, I would first make a quick test to see that all the sectors are closed, and then handle the open ones a bit differently.
  • <blockquote>There are still a few problems with XG and DMU. I've found a few things which will instantly cause a seg violation.</blockquote> Can you send me any test maps? (I have ictest.wad already.) Segfaults are usually pretty easy to fix once they can be caught in a debugger.

    <blockquote>How about the yet to be implemented P_Copy/Swap(p) should that not be in for beta4? However we'd need that DMU constant to property conversion stuff.</blockquote> I don't think we need to have those in Beta 4. The main idea is that all that has worked until now should still work, but the new stuff (bias lights, XG improvements et al.) is not as important.
  • <i>This comment was posted by dengDevs user <b>Melfice</b>.</i>

    When trying to load a saved game in Map12: Nightmare Depths. I get the error below and jDoom crashes (note: I can warp to the map no problem. It only crashes when I try to load a saved game that was in this map). I've been continuously able to reproduce this error. However, I tried saving a game in Map01, warping to a different map, and then loading that saved game, and it worked. Below is a copy of the out file:

    Maximum anisotropy: 8
    Multitexturing enabled (full).
    Con_StartupInit: Init startup screen.
    jDoom Version 1.15.0-beta3 Oct 16 2005 (Doomsday)
    DOOM 2: Hell on Earth
    P_Init: Init Playloop state.
    HU_Init: Setting up heads up display.
    ST_Init: Init status bar.
    MN_Init: Init miscellaneous info.
    SetupLevel: map01
    (GL data found)
    GL_VERT v2.0
    LG_Init: 165 x 138 grid (273240 bytes).

    The Desecrated Ruins

    Changing Level...
    SetupLevel: map12
    Opened PWAD file : bspcache\skill3 coop nomonst\MAP12-1290\MAP12.wad
    Reading 11 dir entries at 0xE0248

    Creating nodes using tunable factor of 7


    Building GL nodes on MAP12

    Loaded 5874 vertices, 1164 sectors, 10316 sides, 6297 lines, 575 things
    Map goes from (-1568,-3152) to (3136,1904)
    Creating Segs...
    Built 3750 NODES, 3751 SSECTORS, 18388 SEGS, 7530 VERTEXES
    Heights of left and right subtrees = (20,18)

    Saving WAD as bspcache\skill3 coop nomonst\MAP12-1290\MAP12.gwa

    Total serious warnings: 0
    Total minor warnings: 26

    All levels were built successfully.
    (GL data found)
    GL_VERT v2.0
    LG_Init: 152 x 164 grid (299136 bytes).

    Nightmare Depths
    Author: by Melfice

    Degreelessness Mode On
    SetupLevel: map12
    (GL data found)
    GL_VERT v2.0
    LG_Init: 152 x 164 grid (299136 bytes).

    Nightmare Depths
    Author: by Melfice

    R_TextureNumForName: not found!

    DG_Shutdown: Shutting down Direct3D...
  • <blockquote>My first guess would be that since the sector is not closed, the IsPointInSector test concludes that all points are within the sector, thus the sector is considered to affect all the blocks of the lgrid. In LG_Init, I would first make a quick test to see that all the sectors are closed, and then handle the open ones a bit differently.</blockquote>Sounds likely to me. How should we treat unclosed sectors with respect to the light grid? Note I have added a stub for checking for unclosed sectors earlier in the setup process and added a flag to sectorinfo_t. We just need an algorithm to drop in (maybe borrow one from glBSP?).
    <blockquote>Can you send me any test maps? (I have ictest.wad already.) Segfaults are usually pretty easy to fix once they can be caught in a debugger.</blockquote>Sure. I'm collect them up, write some notes for each and email them over to you.
    <blockquote>I don't think we need to have those in Beta 4. The main idea is that all that has worked until now should still work, but the new stuff (bias lights, XG improvements et al.) is not as important.</blockquote>Well, currently I had made use of P_Copy to do a few things in XG (eg mimic_sector) but they are easily replaced with a set of calls to P_Set(p).
  • <blockquote>When trying to load a saved game in Map12: Nightmare Depths. I get the error below and jDoom crashes</blockquote>Can you try something for me:
    Disable all your DEDs from TheExiled (ie don't load them) but DO load the PWAD. Then try to load your save game.

    I'll see if I can reproduce this in Beta-4.
  • <blockquote>When trying to load a saved game in Map12: Nightmare Depths. I get the error below and jDoom crashes (note: I can warp to the map no problem. It only crashes when I try to load a saved game that was in this map).</blockquote>I can see if I can get this to crash on my system.

    <blockquote>Well, currently I had made use of P_Copy to do a few things in XG (eg mimic_sector) but they are easily replaced with a set of calls to P_Set(p).</blockquote> Yes, I think it would be good to replace the P_Copy calls until we have a P_Copy that really works. :)

    <blockquote> How should we treat unclosed sectors with respect to the light grid? </blockquote> Why is the sector unclosed? Is it simply an error on the map author's part, or is it used in some hack?

    I'll see what happens in the debugger when running ictest.wad.
  • <blockquote>Yes, I think it would be good to replace the P_Copy calls until we have a P_Copy that really works. :)</blockquote>
    Will do.
    <blockquote>Why is the sector unclosed? Is it simply an error on the map author's part, or is it used in some hack?</blockquote>
    Yes it's left unclosed deliberately as part of a hack. There are supposed to be midtextures on the "invisible door" too but I simply haven't included the special case in Rend_RenderWallSeg to allow this hack to work (Note: they are already detected during map setup and a new flag in lineinfo_t denotes this. Rend_RenderWallSeg simply needs to check this flag in combination with a valid midtexture id).
  • <blockquote>Walk towards the red pillar and you'll hit an invisible wall (which SHOULD have a mid texture on it btw) and press use to open the midgrate door. The crash appears to be happening in LG_SectorChanged(), some debug code reveals:</blockquote>I am seeing the door (it is not invisible). Trying to open it causes a crash because the plane->sector pointers are initialized incorrectly (fix committed). The data from the sectorinfo is bogus because the sector pointer itself is bogus.

    <blockquote> When trying to load a saved game in Map12: Nightmare Depths. I get the error below and jDoom crashes (note: I can warp to the map no problem. It only crashes when I try to load a saved game that was in this map).</blockquote> I can't get any errors to occur. Must be something to do with the resources (I haven't got any of your custom stuff), Melfice. Is this the same map whose URL you posted a while ago?
  • <blockquote>My first guess would be that since the sector is not closed, the IsPointInSector test concludes that all points are within the sector, thus the sector is considered to affect all the blocks of the lgrid.</blockquote>Actually, R_IsPointInSector2 never lets this happen. The sector's vertices are always treated as a closed polygon.
  • <i>This comment was posted by dengDevs user <b>Melfice</b>.</i>

    <blockquote>Can you try something for me:
    Disable all your DEDs from TheExiled (ie don't load them) but DO load the PWAD. Then try to load your save game.

    I'll see if I can reproduce this in Beta-4. </blockquote>

    Surely.

    I made a new pk3 that only consisted of MAP12.wad an exiled_resources.wad, which has no .deds but the textures and flats used in the map (thus, without it, I'd get missing texture errors). After doing this, I tried loading the save game file and got the same error in my out file:

    Con_Init: Initializing the console.
    SW_Init: Startup message window opened.
    Executable: Version 1.9.0-beta3 Oct 16 2005 (DGL).
    Parsing configuration files.
    W_Init: Init WADfiles.
    W_AddFile: C:\Documents and Settings\Compaq_Owner\Desktop\Doom Stuff\The Exiled\Resource Wads\Doom2.wad
    IWAD identification: 00f36acb
    W_AddFile: C:\Documents and Settings\Compaq_Owner\Desktop\Doom Stuff\The Exiled\Resource Wads\Doom2.gwa
    W_AddFile: Data\Doomsday.wad
    W_AddFile: Data\jDoom\jDoom.wad
    IWAD identification: 00056533
    W_AddFile: Snowberry\addons\savetest.pk3
    W_AddFile: Data\jDoom\Auto\exiled_resources.wad
    W_AddFile: Data\jDoom\Auto\map12.wad
    Reading definition file: Defs\Doomsday.ded
    Reading definition file: Defs\jDoom\jDoom.ded
    138 sprite names
    974 states
    140 things
    8 lights
    112 sound effects
    68 songs
    359 text strings
    27 particle generators
    22 animation groups
    51 surface decorations
    69 map infos
    12 finales
    Sys_Init: Setting up machine state.
    Sys_Init: Initializing keyboard, mouse and joystick.
    Sys_InitTimer.
    Sfx_Init: Initializing DirectSound...
    DS_DSoundInit: EAX initialized.
    Sfx_InitChannels: 16 channels.
    DS_EAXSetdw (prop:11 value:2) failed. Result: 80004001.
    DS_EAXSetdw (prop:2 value:-10000) failed. Result: 80004001.
    DS_EAXSetf (prop:5 value:0.372500) failed. Result: 80004001.
    DS_EAXSetdw (prop:3 value:0) failed. Result: 80004001.
    DS_EAXSetf (prop:4 value:1.300000) failed. Result: 80004001.
    S_Init: OK.
    R_Init: Init the refresh daemon.
    R_InitModels: Initializing MD2 models.
    R_InitModels: Done in 0.00 seconds.
    Net_InitGame: Initializing game data.
    GL_Init: Initializing Doomsday Graphics Library.
    DG_Init: Direct3D 8.1.
    Direct3D information:
    Driver: nv4_disp.dll
    Description: NVIDIA GeForce FX 5500
    Texture units: 2
    Texture blending stages: 8
    Modulate2X: OK
    MultiplyAdd: OK
    BlendFactorAlpha: OK
    Maximum texture size: 4096 x 4096
    Maximum texture aspect ratio: 1:4096
    Maximum anisotropy: 8
    Multitexturing enabled (full).
    Con_StartupInit: Init startup screen.
    jDoom Version 1.15.0-beta3 Oct 16 2005 (Doomsday)
    DOOM 2: Hell on Earth
    P_Init: Init Playloop state.
    HU_Init: Setting up heads up display.
    ST_Init: Init status bar.
    MN_Init: Init miscellaneous info.
    SetupLevel: map01
    Opened PWAD file : bspcache\skill3 coop nomonst\DOOM2-9A81\MAP01.wad
    Reading 11 dir entries at 0xAFFC

    Creating nodes using tunable factor of 7


    Building GL nodes on MAP01

    Loaded 383 vertices, 59 sectors, 529 sides, 370 lines, 69 things
    Map goes from (-1304,-960) to (2072,2688)
    Creating Segs...
    Built 203 NODES, 204 SSECTORS, 1058 SEGS, 515 VERTEXES
    Heights of left and right subtrees = (14,12)

    Saving WAD as bspcache\skill3 coop nomonst\DOOM2-9A81\MAP01.gwa

    Total serious warnings: 0
    Total minor warnings: 0

    All levels were built successfully.
    (GL data found)
    GL_VERT v2.0
    LG_Init: 109 x 118 grid (154344 bytes).

    Level 1: Entryway
    Author: id Software

    Changing Level...
    SetupLevel: map12
    Opened PWAD file : bspcache\skill3 coop nomonst\MAP12-36B0\MAP12.wad
    Reading 11 dir entries at 0xE07B9

    Creating nodes using tunable factor of 7


    Building GL nodes on MAP12

    Loaded 5880 vertices, 1166 sectors, 10324 sides, 6304 lines, 574 things
    Map goes from (-1568,-3152) to (3136,1904)
    Creating Segs...
    Built 3752 NODES, 3753 SSECTORS, 18396 SEGS, 7536 VERTEXES
    Heights of left and right subtrees = (20,18)

    Saving WAD as bspcache\skill3 coop nomonst\MAP12-36B0\MAP12.gwa

    Total serious warnings: 0
    Total minor warnings: 26

    All levels were built successfully.
    (GL data found)
    GL_VERT v2.0
    LG_Init: 152 x 164 grid (299136 bytes).

    Level 12: The Factory
    Author: id Software

    SetupLevel: map12
    (GL data found)
    GL_VERT v2.0
    LG_Init: 152 x 164 grid (299136 bytes).

    Level 12: The Factory
    Author: id Software

    R_TextureNumForName: not found!

    DG_Shutdown: Shutting down Direct3D...
  • <blockquote>I am seeing the door (it is not invisible). Trying to open it causes a crash because the plane->sector pointers are initialized incorrectly (fix committed). The data from the sectorinfo is bogus because the sector pointer itself is bogus.</blockquote>
    I am too now. It's because of the recent reintroduction of the old HOM fix behaviour.

    As I mentioned earlier, I have rationalized this hack but I just need to update Rend_RenderWallSeg to be aware of them.
    <blockquote>Actually, R_IsPointInSector2 never lets this happen. The sector's vertices are always treated as a closed polygon.</blockquote>
    Oh. In that case it probably needs to be fixed. Consider a sector split into two disjoint polygons.
    <blockquote>I can't get any errors to occur. Must be something to do with the resources (I haven't got any of your custom stuff), Melfice. Is this the same map whose URL you posted a while ago?</blockquote>
    Neither can I.
    This is why I suggested to disable all your DEDs. I remember you sent me a DED with a MapInfo definition in it that had an unknown texture specified for the sky. The result was a "R_TextureNumForName: not found!" report at exactly the same point in the startup in your error report above.

    I reacted by including a check in the sky init code which prevents the sky being given an invalid texture and to dump an error message in the console for Beta4.
  • <i>This comment was posted by dengDevs user <b>Melfice</b>.</i>



    Actually, Dani, I hadn't given you any updated .deds for the map so that might explain why its not working for you. I overlooked you needing those. I actually fixed the sky in the maps.ded a while ago before I discovered this. What I find odd though is that if I just warp to the map with idclev, I get no errors whatsoever; Its only when I try to go to a saved game inside this map I get the error.

    At any right, below is a link to the updated .deds. Being that the map is for all intents and purposes ifnished, these shouldn't be having any changes made to them on my end. If they do, I will let you know:

    http://www.retetched.com/optix/theexiled/@Defs.rar
  • When using my hexen rain ded (I have just released)http://forums.jfiles.org/dload.php?action=file&file_id=80
    It works fine when you enter the level via "setmap 20"

    but when entering it via ethral travel(through those portals) the particle generator gets broken
  • <blockquote>but when entering it via ethral travel(through those portals) the particle generator gets broken</blockquote> Ethereal travel uses savegames to restore map state. Particle generators are not saved anywhere. This most likely causes the breakage. As Dani's earlier post elaborated, we need to revise the savegame system before the final 1.9.0 is released.
  • <blockquote>Can you send me any test maps? (I have ictest.wad already.) Segfaults are usually pretty easy to fix once they can be caught in a debugger.</blockquote>
    Ok, here are the maps I've tested that exhibit problems in Beta4:
    <a rel="nofollow" href="http://www.daniel.ddsdesign.co.uk/Stuff/STEEL.PK3">STEEL.PK3</a&gt; (DOOM2 - MAP01)
    Upon starting the level turn right at the first junction and go through the door to your left. Follow the wall on your right till you reach a lava pit with a few floating rocky boulders. Upon standing on the boulders they begin to sink but upon reaching the height of the surrounding lava I get a segmentation violation.

    I'll update this post if I find any more (other than those related to unimplemented stuff like P_Copy).
  • In SVN 3208:

    FIXED: "Line attack weapons are hitting planes with the skyflat and spawning PUFFs"

    This only happens when the subsector either side of the test linedef had the same floor/ceiling height. The linehit test was never initiated and as a result the trace was stepping forward into the next subsector.
  • All right, the reason for the crashes was that when the rock has descended into the lava, it's floorpic is set to zero, which is an invalid value. The rendering code was not expecting this, and tried to dereference a null pointer. The same problem occured in multiple places. However, this does not mean the map works correctly: floorpic zero means that the floor is not drawn and a HOM effect occurs.

    The sounds seem odd to me. The ambient sounds routinely override the "normal" sounds. Does this happen for you too?
  • <blockquote>All right, the reason for the crashes was that when the rock has descended into the lava, it's floorpic is set to zero, which is an invalid value. The rendering code was not expecting this, and tried to dereference a null pointer. The same problem occured in multiple places. However, this does not mean the map works correctly: floorpic zero means that the floor is not drawn and a HOM effect occurs.</blockquote>
    In that case, when an attempt is made to set the floorpic to zero it should instead be set to -1. This will make the renderer use the "MISSING" texture instead.

    However, I remember playing this map with 1.8.6 and the floor texture changed to the lava. Perhaps there is a mixup somewhere in the XG plane_move class.
    <blockquote>The sounds seem odd to me. The ambient sounds routinely override the "normal" sounds. Does this happen for you too?</blockquote>
    I hadn't noticed but then I always develop with the sound muted.

    I'll check...
  • <blockquote>The sounds seem odd to me. The ambient sounds routinely override the "normal" sounds. Does this happen for you too?</blockquote>
    Yes I get the same. Just to clarify: by "normal" you mean sector based sounds?
    I haven't checked how the ambient sounds are implemented but if they are sector based; isn't that normal DOOM behaviour though? I distinctly remember that sectors could only ever emit one sound at a time.

    See S_SectorSound in Src/jDoom/p_sound.c

    If this is changed it will need to have a compatibility option implemented.

    One thing I did notice that seemed wrong is that when using the DirectSound 8 driver - I have 3D sound enabled by default but when I first startup the in-game sounds are all distorted and fuzzy. If I go into the control panel and toggle the 3D sound button off then back on - the problem is solved but I need to do this each time I startup.
  • <i>This comment was posted by dengDevs user <b>PiCKleBro</b>.</i>

    When the sound generators are created (is that what you meant by 'decorations'?)the generator needs to be checked at the loading of every map (and/or gamesave to compensate for Hexen's ethereal travel) and if still playing stopped (and of course if neccessary, restarted).

    An issue has been noticed (by KuriKai) where using particle generators to create sound (eg jDAP) causes the sounds to continue playing even after a new map is loaded that doesn't contain the same sounds.
  • <i>This comment was posted by dengDevs user <b>PiCKleBro</b>.</i>

    Another thought: What if the 'sound generator' used the same in-game interface style as the bias-lighting does?

    You could then do a console command to save to a ded which would reference a sound (there would have to local or virtual directory rules about wav file locations of course)
  • <blockquote>An issue has been noticed (by KuriKai) where using particle generators to create sound (eg jDAP) causes the sounds to continue playing even after a new map is loaded that doesn't contain the same sounds.</blockquote>The sounds should stop when the level changes. Sounds like a bug to me.

    The other problem with this is that particle generators have never been saved AT ALL. This is one reason why we are moving the save games over to the engine (partially) so that stuff like this can be saved. This is one of the most important jobs to be done for Beta5.
    <blockquote>Another thought: What if the 'sound generator' used the same in-game interface style as the bias-lighting does?</blockquote>Yes, functionality along the lines of the in-game bias lighting editor would be ideal for placing map-specific sound and particle generator objects.

    Note, there are TWO types of sound generator being discussed here: <ul>
    <li>Sound generator "objects":
    Can be placed freely, anywhere in the map. These must be placed manually in each map.</li>
    <li>Sound generator "decorations":
    Are placed automatically by the engine attached to any surface using a texture/flat with a DED "Sound Decoration" definition. Will act similarly to the current light decorations.</li>
    </ul>

    What we really want is a generalised decoration system. That way we'd be able to decorate surfaces with lights, sounds, models and maybe more.
  • In SVN 3211:
    P_Copyp is not implemented yet, use P_Get/P_Set for now.

    Can you test this PWAD please skyjake:
    <a href="http://www.daniel.ddsdesign.co.uk/Stuff/mimic2.wad&quot; rel="nofollow">mimic2.wad</a> (DOOMII MAP01)

    Pulling the switch in the elevator results in:
    "Z_Free: attempt to free pointer without ZONEID"
  • <i>This comment was posted by dengDevs user <b>PiCKleBro</b>.</i>

    Generalised decoration tag....that would be awesome.

    Based on what I'm seeing in the decoration tag, all that would have to be added would be support for sound in the tag itself. As I'm sure you know (but I had to research) it has basically everything needed for lights already.

    One thought - Why not include particle generators to the decorations tag as well.

    That way there would be two consistent ways of adding *ANY* type of ambient enhancement to doomsday: The 'object' approach and the 'decoration' approach.

    Your thoughts?
  • <blockquote>Just to clarify: by "normal" you mean sector based sounds?</blockquote> I meant all other sounds: player weapon sounds, mobj-emitted sounds, sector sounds. The sound system probably needs to tune-up so that ambient/decoration sounds are played at a lower priority, or on a couple of reserved channels, where they cannot interfere with normal gameplay sounds.
  • In SVN 3212:

    FIXED: jDoom - "The stairs in the midle of the map dont raise up in DooMII Map07 once you have killed all the monsters. Most probably a dummy line/DMU issue".

    There were two bugs contributing to this.

    In jDoom - The use of the bossKilled variable prevented the DOOMII MAP07 667 special from ever activating (it assumed that only one 666/667 special existed per map).

    In jDoom and jHeretic - An incorrect DMU constant specified in EV_DoFloor when resolving the raisetotexture floor types.
  • <blockquote>Currently if GL node buidling is disabled Doomsday segfaults during the load process. Doomsday's map polygonizer is broken?</blockquote>
    I've found a fix for this problem but I don't know why the fix works. Skyjake - I'll provide the details here but could you investigate why this works please?

    Edit p_maptypes.h manually and change the datatype of children[2] to:
    unsigned short children[2];
    Edit p_arch.c and change the value types of DAM_CHILD_LEFT/RIGHT to DDVT_SHORT (lines 2501 & 2505).
  • <blockquote>ictest.wad problems in lgrid.c and invisible walls.</blockquote>I've just been looking into this a bit and decided to take a look at a couple of the other ports that handle this situation.

    I took a look at PrBoom-Plus-2.2.6.25 and was surprised to find Doomsday's map polygonizer and convex polygon clipper code. The code has since been enhanced to take into consideration unclosed sectors by the PrBoom team.

    Maybe we should look at implementing the same enhancements in Doomsday?
    Here is the src file in question: <a href="http://www.daniel.ddsdesign.co.uk/Stuff/gl_main.c&quot; rel="nofollow">gl_main.c</a>

    Dont you just love when people borrow your code, improve it and then don't tell you about the improvements so you can do the same.
Sign In or Register to comment.