VOGONS


ZDoom LE (Legacy Edition)

Topic actions

Reply 20 of 63, by dondiego

User metadata
Rank Member
Rank
Member

Perhaps i should rename the cmd file then, i haven't received any crash reports on win7. Then is your graphic driver installed? Are you using the d3d renderer? Which video mode is crashing?

LZDoom, ZDoom32, ZDoom LE
RUDE (Doom)
Romero's Heresy II (Heretic)

Reply 21 of 63, by koverhbarc

User metadata
Rank Member
Rank
Member

The setup on the laptop is what it came with - Device Manager reports the video driver working. I had ZDoom still set to fullscreen ddraw, because I transferred it over on a USB stick as I usually do, and that crashed. With d3d it works, just as you imply for Windows 8. So this problem can happen on Windows 7 (and presumably Vista) as well; and again I got a bluescreen, the most serious type of crash as everything goes down. Obviously I would never knowing select DirectDraw on 7 unless D3D wasn't working (not sure if that's possible).

On XP, that problem can't happen but it can still be necessary to reset the video setting if you've put it into a bad video mode, as I've noted. The modes that cause this for me are 320x256, 400x256, (with some driver versions) 400x225. At least the last is presumably added by the game's logic to add widescreen modes 'for use letterboxed or in a window' as the source remarks (written before widescreen monitors were common). The 320x256 mode might seem appropriate for genuine 5:4 monitors i.e. the regrettably common 1280x1024 LCDs. However, after connecting one of those monitors and restarting, it still crashes; further, the intermediate 640x512 is not given. Anyway there's no way to prevent this unless you just don't offer those modes; I only just found out because I always play in a true 4:3 mode, and only recently decided to test every mode given.

[I really want to rant about those horrible 5:4 monitors, which constitute EVERY 17-19" fullscreen LCD ever made for PCs. They pretend to be 4:3 but instead stretch everything in 4:3 modes, which is easily noticeable, and makes the Windows desktop immediately look 'wrong'. No aspect-correct modes other than 1280x1024 are available to use.]

So, again, the batch file (I can use the command line directly, of course) needs to be run in these cases also, and you don't need to worry about the details because they are not in your control.

By the way I saw the new projects you've put out, and have been working on. However, I never liked Heretic, so can't say I am interested.

Reply 22 of 63, by koverhbarc

User metadata
Rank Member
Rank
Member

The last post was written in some haste and may have sounded a little rude, but I was just trying to answer your questions. I probably will download your Romero's Heresy mods, on which you probably placed more importance than this, just to test if nothing else; I imagine it doesn't really matter.

I don't want right now to try to bother you with a long post, but I do need to make one point: My Quake 2 comparison was meaningful, because I used the latter's software rendered mode, putting the load on the CPU no less than with ZDoom. The fact that it consists of completely different code, though, may mean it doesn't respond the CPU speed in the same way (and ZDoom itself might not depending on interpolation being on or off). I could give actual figures if you wanted.

Reply 23 of 63, by dondiego

User metadata
Rank Member
Rank
Member

Of course not, thanks for your report. I'll do something about it (probably updating the readme and renaming the cmd).
Doom with big limit-removing levels can run @1fps even on relatively modern machines.

On Heresy i didn't like Heretic very much either, that's why i made it. The old project was a patch for dos to convert the original Heretic levels to Doom. Heresy II is the new one and allows playing all Heretic levels with Doom and Heretic modified weapons and monsters, there are new weapons some from the Doom alphas and betas and several player classes. This one is a .pk3 for ZDoom based ports. Well, it's a very different animal than Heretic so you may actually like it, just watch the videos. 😀

LZDoom, ZDoom32, ZDoom LE
RUDE (Doom)
Romero's Heresy II (Heretic)

Reply 24 of 63, by koverhbarc

User metadata
Rank Member
Rank
Member
DonDiego wrote:

Doom with big limit-removing levels can run @1fps even on relatively modern machines.

Yes, ZDoom. This problem never happens in PrBoom+, and I have done some investigation of it.

ZDoom _abruptly_ slows from a playable framerate to 'slideshow' (~1 fps) when the amount of rendering complexity exceeds a certain amount, which is not much affected by resolution (I tested 320x200 to 1600x1200 - a factor of 30 in pixels drawn) and even less by sound and interpolation. The resolution (and CPU speed), though, do affect just how slow the 'slideshow' is.

For this test, I use a level called Planisphere 2, which while pretty lousy to play, demonstrates the capability of the Doom engine to render huge outdoor areas - but ZDoom falls down on it. PrBoom+ plays it perfectly (indeed the latest version was specifically fixed to do so), but Zdoom's software renderer always slideshows at any resolution, making it unplayable. Play it with -nomonsters and your highest resolution to see just how abrupt the transition is as you turn at certain points. In PrBoom those changes are still visible but not abrupt, and do not prevent normal play.

This seems like a problem that could be isolated to one point in the code and _perhaps_ fixed there. Without a profiler, though, which I've never used, it would take forever to find that one point. However it would be well worth it, especially but not only for old hardware.

As to the sound, all my timedemos have shown, comparing the result with and without -nosound, that the sound code always takes about 20% of the CPU time. I suppose this constancy is understandable, but the fact the the game is playable at all on a Pentium 1 (as you attest) shows that it could take fewer cycles than that. Also FMod _is_ always slightly faster for me, a result that's evidently machine-dependent.

Reply 25 of 63, by dondiego

User metadata
Rank Member
Rank
Member

Quadratic algos, the constant must be lower in prboom or may use some tricks. Also ZDoom is a more complex engine with more features. The slowdown also happens in opengl mode (GZDoom) so it's not a software renderer problem. I've tried nuts.wad in prboom and the slowdown is not so severe but it's there.

OpenAL is clearly faster on pentiums since FmodEX makes extensive use of floating point, and also OpenAL is compatible with win95.

LZDoom, ZDoom32, ZDoom LE
RUDE (Doom)
Romero's Heresy II (Heretic)

Reply 26 of 63, by dondiego

User metadata
Rank Member
Rank
Member

In case someone's interested i've fixed both of my repositories and now they are technically two gzdoom forks (two branches inside my gzdoom repo).

https://github.com/drfrag666/gzdoom/tree/zdoomle
https://github.com/drfrag666/gzdoom/tree/gzdoomcl

Also i've attempted a merge of GZDoom 1.8.3 (GL 1.2) into ZDoom LE but it's been a failure. Seems like the ZDoom data structures have changed too much in three years. The merge was pretty straightforward and after resolving a few conflicts i fixed the compiling errors due to the aforementioned changes but the renderer is not functional (more details follow). If someone with OpenGL and Doom source knowledge (such as leileilol) wants to contibute and fix it or do something interesting with it there's an experimental branch here.

https://github.com/drfrag666/gzdoom/tree/gzdoomle

drfrag wrote:

This GZFDoom (Franken) runs in software but in hardware the menus are fine however when i start a new game after the wipe nothing is rendered, i still see the menu and title pic and when i press ESC the menu appears on a yellow background.
I guess some data structures have changed, i've made only the minimal modifications to make this compile. I don't get any error messages. The ingame (GL?) stats are normal.

I've backtracked changes in some modules but without luck so i'm afraid Frankie is dead, i don't know up to which point the renderer is screwed may be it's just a silly minor issue but don't have the skills to fix this. So if someone wants to continue this task be my guest.

Link to the ZDoom forum thread:
https://forum.zdoom.org/viewtopic.php?f=4&t=56807

LZDoom, ZDoom32, ZDoom LE
RUDE (Doom)
Romero's Heresy II (Heretic)

Reply 27 of 63, by koverhbarc

User metadata
Rank Member
Rank
Member

I'm not sure what you mean by 'fixed your repositories' in the last post - anything that makes a substantive change?

In reply to the previous one, your 'quadratic algorithms' I assume you mean the mathematical definition of quadratic, i.e. O(n^2)? Actually, the BSP algorithm should have the advantage of being faster than quadratic, unlike the naive one used in Build which really is quadratic in potentially visible sectors. In any case nuts.wad shouldn't be used as an example here as its slowdown comes from number of monsters and not level geometry as in the interesting cases (remember it's a joke wad never intended to be playable).

What other levels did you have in mind as causing this severe slowdown? I could try the ones you recommend; for my part, Planisphere 2 is the only problematic level I know that's not ZDoom-specific (and hence can be used to compare with PrBoom+). I suggest you try it out as stated; really, under the ZDoom software renderer it happens that as you turn around slowly the framerate _instantly_ changes from ~20fps to ~1fps and back, which certainly seems faster than quadratic. I'd not be surprised if it happens also in GL, as the low dependence on resolution suggested it's not in the software renderer's particular loops.

I don't dispute that OpenAL is faster on some/most systems and ought to be included, I just want to report my results on my system.

Reply 28 of 63, by dondiego

User metadata
Rank Member
Rank
Member

What i said, being a proper fork instead of a repo created from scratch means it has a common history with ZDoom and you can cherry-pick commits and submit pull requests. However as codebases diverge more and more cherry-picking will be even worse than applying patches manually (the changes you're interested in) since a lot of conflicts appear.

AFAIK most Doom algos are O(n^2) and data structures are not efficient. Big and complex levels with a lot of stuff run slow here. In ZDoom 2.3 they introduced a garbage collector (fixed in 2.3.1) to increase performance and according to them the engine runs actually much faster. However i've only tried up to 2.2 on a pentium.

Independently of which sound backend you use 2.8.1 will be clearly slower on a pentium probably due to the overhead introduced with new features or may be it's that garbage collector or some variables changed to float. After the floatification (this doesn't affect LE) it would be surely even slower on pentiums.

LZDoom, ZDoom32, ZDoom LE
RUDE (Doom)
Romero's Heresy II (Heretic)

Reply 29 of 63, by koverhbarc

User metadata
Rank Member
Rank
Member

OK, I guess I understand what you meant about the repositories. Just how patches are added is not very interesting to me, but I'm sure you have the best solution here.

As far as the speed issues, it seems your answers boil down to "I don't know". Which is fine; I don't know either, which is why I'm asking and trying to figure things out. The BSP algorithm itself should be O(n log n) (I think; in any case O(n^2) would mean levels like Planisphere 2 could hardly be playable ever). Actually drawing the geometry should be essentially proportional to the number of pixels drawn, i.e. the resolution, and hence could not cause this kind of slowdown.

As I mentioned a compatible profiler would immediately tell me where to start looking; I searched, but couldn't find any that worked with CodeBlocks for Windows. I guess I should be looking for other people to ask.

I don't have any older hardware to test on, and I'm not sure what you have, but LE is supposed to improve the playing experience for such machines and this problem can affect even newer ones on some reasonable levels (not nuts.wad or its family). In any case I don't need it to find and investigate this problem, and Planisphere 2 proves that PrBoom+ is not affected by the same problem that ZDoom is (if you dispute that, test it yourself to see the difference). It is therefore potentially fixable and given how much content is ZDoom-specific, important.

Reply 30 of 63, by dondiego

User metadata
Rank Member
Rank
Member

The slowdowns depend on where you look at so it's rendering related, probably a poorly designed map with tons of two sided lines. I've tested with 2.2 and it's the same, also happens in hardware. I know prboom+ is faster. Check this:
https://forum.zdoom.org/viewtopic.php?f=4&t=56626

LZDoom, ZDoom32, ZDoom LE
RUDE (Doom)
Romero's Heresy II (Heretic)

Reply 31 of 63, by koverhbarc

User metadata
Rank Member
Rank
Member

I've read that already. Yes, Planisphere 2 is a map full of 2s lines; but that's not poor design, it's necessary to the level as you should know if you have tested it (since you can get on the tops of buildings converting any of the lines to 1s would give rendering issues). PrBoom+ is faster in general by up to 2x, yes, but on that map it's just _exponentially_ faster by not showing the non-linear 'slideshow' effect.

I have found the problem with the help of ZDoom's internal profiler. 2s lines are not themselves a big slowdown, at least if they don't have midtextures. The slowdown is actually in the sprite-drawing code - this accounts for almost all of it on Planisphere 2 and a majority on other maps. Each potentially visible sprite causes a loop through all the drawsegs from back to front (!). This will almost always find the sprite isn't visible, but not until going through almost all the drawsegs (which might be 50,000 in that map). The offending loop starts near line 2110 of r_things.cpp with the comment

// Scan drawsegs from end to start for obscuring segs.
// The first drawseg that is closer than the sprite is the clip seg.

Ugh. This procedure appears to be original but Zdoom has changed things so as to make the loop much slower and the inefficiency more obvious. The workaround (without rewriting the entire renderer) would seem to have to involve parsing the drawsegs in the opposite order, and I know that wouldn't be completely trivial.

Now I have to ask: are you open to the idea of fixing things like this for ZDoom/LE? I know GZ almost surely wouldn't accept it, and I can't talk to him anyway. But we should be able to make some changes that he would have rejected (such as the very idea of LE!).

Reply 32 of 63, by dondiego

User metadata
Rank Member
Rank
Member

But actually sprites are drawn back to front, that code is from id modified by Killough with some optimizations by Randi. It's been discussed in the past (obviously) and no one has come with a better solution.

https://www.doomworld.com/forum/topic/67244-h … play-from-afar/

LZDoom, ZDoom32, ZDoom LE
RUDE (Doom)
Romero's Heresy II (Heretic)

Reply 33 of 63, by koverhbarc

User metadata
Rank Member
Rank
Member

Please read what I actually wrote, and see the segment of code I pointed out (or take my word for it, as I've examined the issue closely). I did not mention the order in which sprites are drawn; which is anyway not a serious problem as shown by the fact that nuts.wad does not really slow down until the monsters are woken up.

What I did mentioned is the algorithm for each sprite determining its visibility, and the order in which drawsegs are stepped through for each sprite. The static limits in vanilla prevented this loop from ever being a serious time sink, but that is no longer true. As well as proving that this part was the cause of the slowdown, I created a version of this level eliminating all Things except the player start - and it showed no slowdown! The sprites for the things, even though almost all are _never drawn at all_, consume this massive amount of time, due to the said loop, which needs to be fixed.

Now can you answer the question?

Reply 34 of 63, by dondiego

User metadata
Rank Member
Rank
Member

Well, i assume that those guys knew what they were doing. I still don't see how changing the order would help but anyway if you came with a patch that works and increases performance for maps with lots of sprites i would accept it of course (same for the ddraw true color renderer). I think the devs of the mainline would accept this kind of patch as well, might contact them about this matter.

LZDoom, ZDoom32, ZDoom LE
RUDE (Doom)
Romero's Heresy II (Heretic)

Reply 35 of 63, by dondiego

User metadata
Rank Member
Rank
Member

The issue with sprite inefficiency was already being worked on by dpJudas and it's solved now in GZDoom, for the time being he implemented sprite culling with distance (as i suggested) and that's the fix i've backported to ZDoom32 (new project) and will to ZDoom LE as well.

https://forum.zdoom.org/viewtopic.php?f=4&t=57052#p1006298

LZDoom, ZDoom32, ZDoom LE
RUDE (Doom)
Romero's Heresy II (Heretic)

Reply 36 of 63, by koverhbarc

User metadata
Rank Member
Rank
Member

I didn't think of this because I didn't want to re-introduce any of the vanilla limits that had been so early fixed. I did work through the sprite code and it seems hard to improve given the rest of the renderer; it didn't seem easy there to reduce the length of that loop. So I temporarily gave up, also seeing that you were gone.

The other idea I had was to cull the drawseg list once for all before drawmasked by removing all segs that weren't drawn (have no visible surfaces) because they aren't needed to clip anything. This now seems to be the optimal solution; sure there could still be engine-breaking maps but as long the number of segs VISIBLE at one time didn't exceed a thousand or two it should still be fine on a P4. I don't see why this should not be possible but it would take more looking through the source to figure out.

However, this solution does work for the purpose and I have no complaint about its being available as an option, and it could coexist with the previous for even better performance on slow systems.

Reply 37 of 63, by dondiego

User metadata
Rank Member
Rank
Member

What i want to do now is culling of walls with distance (in ZDoom32 first), dpJudas has suggested an implementation:

https://forum.zdoom.org/viewtopic.php?f=4&t=5 … art=30#p1007641

LZDoom, ZDoom32, ZDoom LE
RUDE (Doom)
Romero's Heresy II (Heretic)

Reply 38 of 63, by koverhbarc

User metadata
Rank Member
Rank
Member

I have to discourage this. All levels that benefit significantly from it (and some that don't) are likely to see obvious visual anomalies from it. It's not like sprites, where no one really expects to see them from a distance where they'd be reduced to a few pixels.

The approach I suggested, if feasible, would be yet more efficient and cause no visual effects. I had planned to start looking at it as soon as possible.

Reply 39 of 63, by dondiego

User metadata
Rank Member
Rank
Member

That's why it would be disabled by default. It wouldn't be that bad, indoor big areas are even rarer than outdoor ones. In original Doom only 128 walls (later 256) were rendered at a time, i think i experienced it even on earlier doomlegacy versions. If low detail mode is acceptable this could be as well, like another kind of low detail mode.
But if you manage to get something better that would be fine, go ahead and try. I think dpJudas knows the engine well and knows what he talks about. And you know wall culling is the next big thing. 😎

LZDoom, ZDoom32, ZDoom LE
RUDE (Doom)
Romero's Heresy II (Heretic)