rpeter

I got burnt by STL vector. I substituted the TArrays with vectors in zdbsp, it worked on smaller maps, but on bigger ones crashed. Like stl::vector had some upper size limit, it just wouldn't grow any larger. With GCC and VC2008 too.

Excellent thread, not that I understand every word of it. I feel justified that I removed the LUTs years ago in my pet project. I have no idea why some ports still insist on them, probably some demo compatibility consideration? As for the thinker/mobj stuff I separated some specials out of the thinker list to see what happens. Each special type has its own list and deferred deleting mechanism, so far no problem.

I thought about demo desyncing, no problem for me, removed all demo code ages ago: don't care about demos. I want to dissect that thinker stuff to pieces, because I have problems following all the casting, union, void* parameter hackage. I'm not a pro, just a hobby coder, cannot argue with compiler makers.

As a weekend hobby coder I don't dig too deep into compiler science, but I do hate all the new warnings and errors with every major gcc release. I've already run into that strict aliasing warning, I might try RjY's solution. I haven't a problem with Zone, I converted PrBoom's functions into a C++ class long time ago. I'm trying to do the opposit. At first glance I could create separate lists for the different thinker types and run their functions separately. Not sure about the consequences, I'll be wiser a month later.

Are there UDMF maps out there with vanilla features only? I presume there are some new ones for ZDoom/GZDoom, but that could be all.

I would gladly see a float rewrite of Doom only to see whether the code gets simpler at all.

The same goes for anim_t in p_spec.c: boolean istexture is not a bool value at all.

Why don't you just skip steps to see the effect? Like measure the duration of a single frame and omit something like rendering flats or skydome or light calculation to see the effect. I don't know what you call outdated hardware but a GF6600GT made almost no difference wether I shoved it commands and polygons or commented those lines out. Inefficient storage of polygons (I used linked lists instead of arrays) however did make even the automap choppy with large and detailed wads. Anyway, do you render the scene while traversing the bsp (like GLBoom) or traverse the bsp, collect what needs rendering and render them as a separate step (like GZDoom)?

Well, I render the scene in my pet Boom port (not GL, but D3D, no difference though) this way: 1. traverse the bsp and collect stuff to render into separate render lists, handle sw hacks. 2. render the different render lists in the following order: -skydomes -skymasks -walls (masked and unmasked together) -flats -anti-hacks (missing flats, walls) -sprites -spectres -coronas (halos) -translucent walls -dynlights -player sprites (the weapon in hand) -HUD colormap (picking up bonuses, taking damage). Before rendering I sort the walls (just to prevent Z-fighting) without splitting, the translucent walls (a must, see boomedit.wad) the sprites, spectres and coronas. So far I haven't run into wads where I needed to split polygons to sort properly. I only detect masked textures to disable dynlights on them, I'm quite happy with the edges, by I will definietly try the above mentioned SmoothEdges algorithm. Had a lot of trouble with sprite edges, had to disable 3D filtering on them completely. I've borrowed the scaling functions from Doomsday, they filter the sprites just well, at least they don't look too blurry, still retaining a little of the blockiness of the original renderer. I see if I can improve them by smoothing out the edges as well.

DOS Doom still remains the etalon, see the argument above. But you don't have to map for it, don't have to play with it. I could imagine Chocolate-Doom with a menu item: ORIGINAL/LIMITLESS.

Those limits are usually lifted in popular ports. You can even hack the original Doom.exe to up some limits. Map authors usually indicate if they wad needs a limitless engine to play. Another question is whether such ports offer full backward compatibility with or without the demo stuff.

But port authors do understand every bit in the source code, so they know those limits just don't always work the way you described. Just think of array overflows: the C language does not have a mechanism to detect them. In the original Doom under DOS most overruns went unnoticed, the engine simply used some garbage from memory. Under current operating systems the crash is however imminent. Up the limit: no more crash, however demos recorded under DOS go out of sync now. Another kind of limit is in the collision code: sometimes you shoot through enemies (and vica versa). Fix it: you're also hit more often by fire and the spiderdemon gets weaker against rockets. Which case do you prefer? How about this bug: mancubi fireballs sometimes hit you through the wall. Fix it: there goes demo compatibility again. Even bounding box checking is broken in the original Doom. Fix it: God knows how it affects things. True, a lot of those limits only affect demo compatibility. However, for some demo compatibility is paramount.

I think porting or recreating Doom cannot be lossless. Todays compilers work differently than the NextGen one used, operating systems work differently, buggy code ported to other programming languge works differently. I think consideration should be made before deciding to port about how much the loss would be. Like removing Doom's limit would ruin all the demos, speedruns and some (I think small number) of wads. I admire the heroic efforts some port authors make to even try to emulate the bugs in the original game. Other port authors decided the loss of demo compatibility is acceptable, some even removed demo support altogether. The gamers and map designers have the choice which port to choose. Its a free world, right?

Oh, I don't share your view. The user profile, the computer management console, the registry, etc. are all aimed at managing dekstops in a corporate environment. I happened to administer such network with 3000 desktop computers and boy how much these hated things help things organized. Since MS didn't bother to release a substantially different OS for home usage we happen to play on a system aimed at large companies.

I do not even use cfg files, just keep config data for my apps in the registry.