Playing big, modern maps on old machines

[pineapple2664]

37 minutes ago, Woolie Wool said:

Set your resolution to 320x200 (4:3) or 426x200 (16:9) in prboom-plus, it is an older port than Woof and might give you better performance. However, don't expect an old computer to play just any map. On my single-core Athlon XP rig there are many maps I cannot play, and I have the advantage on the Athlon of being able to use native 320x200 with a CRT under a legacy prboom version that has much, much less overhead than modern ports--the code that lets low resolutions display on modern-ish displays and GPUs has a performance cost. Things like "Kythraessos" from Legacy of Heroes or "God Machine" from Sunlust are still unplayable unless I switch to my modern Ryzen rig. I would strongly consider getting a better computer, even a used laptop that is a few years younger would be a significant improvement and will cost much, much less than a new computer.

 

E: in general (though there are of course exceptions) older versions of source ports will generally give you better performance. Features add overhead, and overhead is the enemy of low-spec computers. If that means you have to live without modern amenities like HRTF audio or rewinds or other newfangled features, and miss out on MBF21 wads, so be it.

Interesting point on Woof; using the example of God Machine, I find that Prboom-plus struggles with God Machine unless I play on a low resolution. On the other hand, Woof works with minimal lag at 1600x900 given that I turn off High Resolution in the settings. Hell, even Combat Shock map 5 is playable on my computer with Woof, despite having triple the monsters of GM on HNTR.

 

In all honesty, the massive lag I get when playing maps is pretty rare, limited to some Sunder maps and the big maps mentioned above. I don't really want to go through the trouble of compiling another source port, so sad as it might be, I nowadays just avoid those maps.

[Professor Hastig]

11 hours ago, Woolie Wool said:

E: in general (though there are of course exceptions) older versions of source ports will generally give you better performance. Features add overhead, and overhead is the enemy of low-spec computers. If that means you have to live without modern amenities like HRTF audio or rewinds or other newfangled features, and miss out on MBF21 wads, so be it.

 

I wouldn't blame it on the features. It's just that hardware changes and what is performant on old systems can be slow on modern ones, and the optimizations needed to make it fast on modern systems will hit older ones quite badly often.

Granted, with software rendering this is much less than with hardware rendering, but just comparing the code being generated by compilers 10 years ago with today's is often interesting. Being targeted to very different CPUs this can show some pronounced differences with unexpected results.

 

And that's really the biggest problem with old systems as they get left behind. On the flip side if you got your "highly optimized assembly" (TM, term originally coined by the ZDoom devs) it may not be so optimized anymore if CPU architecture changes, in ZDoom's case exemplified by being replaced with faster C code - faster on more recent systems only, of course.

 

Edited September 18, 2023 by Professor Hastig

[Shepardus]

10 hours ago, pineapple2664 said:

Interesting point on Woof; using the example of God Machine, I find that Prboom-plus struggles with God Machine unless I play on a low resolution. On the other hand, Woof works with minimal lag at 1600x900 given that I turn off High Resolution in the settings. Hell, even Combat Shock map 5 is playable on my computer with Woof, despite having triple the monsters of GM on HNTR.

The resolution of your display is irrelevant for Woof, it always runs at 640x400 resolution (or the widescreen equivalent) internally, or 320x200 if you turn off high resolution. PrBoom+ has actual high resolution rendering. The performance of the software renderer highly depends on the resolution, so for a fair comparison you should run PrBoom+ at a similar resolution.

[pineapple2664]

A late update, but on the point about hardware, my Probook runs Map 18 (for example) at a minimum of 200 fps on DSDA-Doom using OpenGL. In the end, I suppose the best answer to my query really was “use better hardware”.

Edited October 17, 2023 by pineapple2664

[Dark Pulse]

3 hours ago, pineapple2664 said:

A late update, but on the point about hardware, my Probook runs Map 18 (for example) at a minimum of 200 fps on DSDA-Doom using OpenGL. In the end, I suppose the best answer to my query really was “use better hardware”.

In general, that is always a solution to anything being too slow. :P

[wesleyjohnson]

I have kept DoomLegacy compatible with older hardware, especially with software-rendering.

I prefer to play large maps using direct 32bit draw in DoomLegacy as it looks better than GL, and is FAST.

There is also a setting to handle large numbers of monsters.  It will only draw the closest monsters, according to your selection.

I had trouble with nuts.wad until I put that in.   Now it will handle nuts on any machine.
Most of that was developed on a single core Athlon, using Linux.

The windows version got tested on an old WIn98 machine for a long time, but now is tested on an old WinXP machine.

 

800x600 is generally a good screen size for large maps.  It is what I generally use.

 

Can also play MBF wads.

 

DoomLegacy does have some optional assembly routines, but they are currently disabled because the latest compilers produce code that is just as good, and does not need to be update manually every time I touch that particular code.

 

Edited October 24, 2023 by wesleyjohnson

[fabian]

14 hours ago, wesleyjohnson said:

There is also a setting to handle large numbers of monsters.  It will only draw the closest monsters, according to your selection.

I had trouble with nuts.wad until I put that in.   Now it will handle nuts on any machine.

 

I would have guessed that sorting the sprites by scaling factor would be the bottleneck, not the actual drawing. But you need them sorted to decide which ones are close and which are far away, right?

[wesleyjohnson]

The code puts them into a sorted list at sprite creation, each frame.  Some of them get discarded immediately if the list has gotten long enough.

I use an insert sort that is much faster than the draw.

A single draw of a nearby sprite would be on the order of 65K operations.

A draw of a more distant sprite is on the order of 1500 operations.

The sprite list is never allowed to get longer than twice the selected limit.  If the limit is set to 100 sprites, then insert is in the order of 400 operations, and that is only after the list has grown to full size.  The rejection tests come first and after the size reaches the limit they prune out the losers early.  Pruned sprites do not have to get drawn at all, and there is much saved in not calling any draw functions for them (cache fighting is reduced by never referencing their data).

 

What also helps is a randomized pruning.  It is not a fair pruning, as it must be fast.  This makes the sprites that are on the edge of the display area, only get drawn ever few frames.  As the player only sees them every few frames they appear to flicker, which is an interesting distance effect.

This allows the existence of the more distant sprites to be seen by the player without slowing the frame rate to a crawl.

On any map where you have sprites being treated this way, there are literally a quite a few closer monsters that are more important threat and have your attention.

In any case the sprites sorted by distance is needed for software draw anyway.

 

If the user has selected a draw limit of 100 sprites, then the closest 100 sprites get drawn normally.  There will be an additional 100 sprites that get drawn conditionally, selected by distance and randomized pruning.  The sprite sort list will never exceed 200 sprites, even if there are 1000 sprites visible on the map.

 

I used a wad with a very large number of monsters during the development.

Before, I would get a frame rate of 1 frame every 3 seconds.

Now, any frame rate slowdowns are not even noticed.

 

Edited October 25, 2023 by wesleyjohnson

[fabian]

Does this mean the farthest rows of enemies flicker in the start view of nuts.wad?