Sylvester

if you already have a buffer where you mark whether a pixel belongs to a floor you could also store an ID of that floor in it and based on that decide whether or not that floor should clip a sprite.

I see, my bad. So the engine clips each polyobject to every subsector it crosses and builds a separate BSP for every subsector for sorting all the polyobject lines it contains?

With „confined to a subsector“ I meant that each polyobject is limited in that it is only able to move within a single subsector and if I understand the miniBSP approach correctly this is still the case here. Compare this to Build where a group of sectors could freely move inside a concave sector, e.g. vehicles in Shadow Warrior like the tank. This would be a pretty big loss for me personally as I really prefer the way sprites are sunk into the floor in those engines. Otherwise I think the 3D model approach would probably be a good solution for rendering moving geometry but you would have to write completely separate collision detection code. Apart from that I would be really interested if there was a clean way to render the moving geometry the same way as all the other sectors without the disadvantages of the other methods.

Hi, this post is pretty technical, I hope this is the correct subforum for this topic. Please feel free to move it somewhere else if this is not the case. Imagine, you would have to create a new sector based software rendered engine (like the Doom, Build, Jedi engines) for a completely new game where backwards compatibility to existing levels and tools would not be an issue. Imagine, one of the requirements would be that some doors/platforms/etc. could move, like polyobjects in Hexen or everything in Build. What algorithms would you choose for hidden-surface determination? The two existing solutions in similar engines are as I previously mentioned polyobjects (BSP with moving lines inside convex subsector like in Hexen) and portals with sorting done at runtime (Build). The disadvantage of polyobjects is that the system is relatively limited in how the moving lines are all confined to a single convex subsector. Build‘s portals with runtime sorting don‘t have that limitation but instead you have the extreme overhead of having to do VSD at runtime which slows down everything else and limits the complexity of levels you can do overall, just for a few moving lines. I don‘t think Quake‘s system of rendering the world using a BSP and writing to a z-buffer first then rendering moving objects using the z-buffer wouldn‘t work with the way the world is drawn in Doom/Build as the floors and ceilings are drawn using a floodfill-like algorithm that requires everything to be drawn in the right order, so filling in the moving walls/sectors later wouldn‘t work. Maybe this could be done if one would project the floors and ceilings on screen and draw them as polygons instead? Do you have any other ideas or thoughts on this?

I have l known that WAD stands for „Where‘s All the Data“ since like forever but since I‘m not a native English speaker I never knew that „wad“ is a word in and of itself until a few days ago (like in „a wad of tobacco“). Now id‘s choice to name a WAD‘s components „lumps“ makes more sense as well.

You're probably right, that seems to be the case. Interestingly, when not opening the map directly but instead first opening another one from the same IWAD and then switching to MAP17 with ctrl+shift+o this garbage collection is not performed and the sector is "correctly" labeled as sector 122. At least that's the case when I do it in Ultimate Doom Builder R3925.

I wrote a WAD map importer for my own game engine for testing purposes and stumbled upon a strange issue regarding some sector references in plutonia.wad which I don't understand, maybe someone here can explain it to me? The importer works perfectly for all maps in doom.wad and doom2.wad but when I try loading MAP17 of plutonia.wad it fails. This is because sector 19 apparently has no linedefs associated with it so I checked the map in Doom Builder and there it shows that sector 19 has four linedefs: 1195, 1203, 1205 and 1206. After seeing this I looked up the data directly in SLADE and there those four linedefs have sidedefs (1782, 1795, 1796 and 1797) that reference a sector 122 (instead of 19) which isn't shown at all in Doom Builder (here there are only sectors 0 up to 121). I searched all sidedefs in the map data and not a single one references sector 19 so why does Doom Builder associate those that reference sector 122 with sector 19 and why doesn't sector 122 exist there at all? There are a two more sectors that are also referenced in the data but do not exist in Doom Builder, namely 123 and 124. SLADE's map editor and the Doom engine itself all have the same behaviour, so it must be correct but i don't understand how the connection is made between those linedefs and sector 19.

Thanks, changing the file extension to .wad worked! I even tried doing that while experimenting around with Prboom+ before I changed PWAD to IWAD in the hex editor but still got the "CheckIWAD: IWAD tag not present" error message so I gave up on that idea too early.

I just bought REKKR: Sunken Land on Steam and since I'm not a big fan of GZDoom (which is included with the Steam download) I tried to launch the .iwad and .deh files on my source port of choice, Woof v8.1.0.0. This results in the error message "W_GetNumForName: PNAMES not found!", I checked the contents of the wad file in SLADE and it contains a PNAMES lump, so why can't Woof find it? I tried launching the application with "-iwad rekkrsl.iwad -deh rekkrsl.deh" and also with "-iwad doom.wad -file rekkrsl.iwad -deh rekkrsl.deh", both didn't work. So then I tried launching the wad on my second source port of choice, Prboom+ v2.5.1.4, which resulted in the error message "CheckIWAD: IWAD tag D:\Program Files\PrBoom-Plus/rekkrsl.iwad not present" (launch arguments "-iwad rekkrsl.iwad -deh rekkrsl.deh"). I checked rekkrsl.iwad in a hex editor and saw that the first four characters are "PWAD" so i tried changing them to "IWAD" and see what happens. This changed nothing for Woof and resulted in Prboom+ giving me the same error message as Woof ("W_GetNumForName: PNAMES not found!"). Is there any way to play the game with one of those source ports? I played the original free version of REKKR with both of them and that worked flawlessly!