[UPDATED] ZDoom32 2.8.6a (ZDoom is undead)

Game Engines like EDGE, LZDoom, QZDoom, ECWolf, and others, go in this forum
Forum rules
The Projects forums are ONLY for YOUR PROJECTS! If you are asking questions about a project, either find that project's thread, or start a thread in the General section instead.

Got a cool project idea but nothing else? Put it in the project ideas thread instead!

Projects for any Doom-based engine are perfectly acceptable here too.

Please read the full rules for more details.
dpJudas
 
 
Posts: 3037
Joined: Sat May 28, 2016 1:01 pm

Re: [RELEASED] ZDoom32 2.8.2 (ZDoom is undead)

Post by dpJudas »

It is essentially the same problem again. It only stores one of the columns. Change it to:

Code: Select all

   // Top solid color:
   for (int index = 0; index < start_fadetop_y; index++)
   {
      dest[0] = solid_top_fill;
      dest[1] = solid_top_fill;
      dest[2] = solid_top_fill;
      dest[3] = solid_top_fill;
      dest += pitch;
      for (int col = 0; col < 4; col++)
         frac[col] += fracstep[col];
   }
And the same thing for the bottom solid color fill.
User avatar
drfrag
Vintage GZDoom Developer
Posts: 3141
Joined: Fri Apr 23, 2004 3:51 am
Location: Spain
Contact:

Re: [RELEASED] ZDoom32 2.8.2 (ZDoom is undead)

Post by drfrag »

Thanks, now it's working but with the wrong solid color (the sky is red). With the old RGB32k.RGB lines it's the same.
Commenting the following lines with the "solid_top_fill << " and "solid_bottom_fill << " has no effect either.
Edit: it's fixed but i don't know why, using solid_top and solid_bottom directly.
Edit2: it's up @ https://github.com/drfrag666/gzdoom/commits/tccapsky
User avatar
drfrag
Vintage GZDoom Developer
Posts: 3141
Joined: Fri Apr 23, 2004 3:51 am
Location: Spain
Contact:

Re: [RELEASED] ZDoom32 2.8.2 (ZDoom is undead)

Post by drfrag »

@dpJudas:
I've changed loads and stores to be aligned, it works with Randi's original code. The other time i went nuts with those changes, this time i've just replaced occurrences in r_draw_rgba.cpp and r_drawt_rgba_sse.h. Your version of DSimpleCanvas::Resize didn't compile with gcc since std::aligned_alloc is C++17.
Unfortunately performance is exactly the same both in my athlon64 and the p4 2.4, at the start of map01 even @1152 (still old crt monitor here). So it's not worth changing it, anyway i've uploaded the changes in case you want to check them.

https://github.com/drfrag666/gzdoom/commits/gzdoom32

Edit: capped skies don't work in Heretic and Hexen but it doesn't matter that much.
User avatar
drfrag
Vintage GZDoom Developer
Posts: 3141
Joined: Fri Apr 23, 2004 3:51 am
Location: Spain
Contact:

Re: [RELEASED] ZDoom32 2.8.2 (ZDoom is undead)

Post by drfrag »

I've tested the last GZDoom SVN and capped skies still don't work in Heretic and Hexen with the classic renderer, moreover stretched and normal skies don't work properly either. The sky is tiled (when you look up you see the bottom of the sky), i don't know if i should post a bug report.

On aligned load and stores i assume everything is right (doesn't crash) so i will not revert it at least for now.

This is unrelated but now i'm trying to add a 3x3 low detail mode, unfortunately my half-assed implementation is a disaster.
User avatar
drfrag
Vintage GZDoom Developer
Posts: 3141
Joined: Fri Apr 23, 2004 3:51 am
Location: Spain
Contact:

Re: [RELEASED] ZDoom32 2.8.2 (ZDoom is undead)

Post by drfrag »

I've released a new version. This release mainly adds the truecolor capped sky drawers and a couple of new low detail modes and fixes some crashes (large textures on old cards and SSE2 executable with voxels). See first post.
I've changed version numbering as well (still it's very conservative). I've updated ZDoom LE and Classic as well.
User avatar
drfrag
Vintage GZDoom Developer
Posts: 3141
Joined: Fri Apr 23, 2004 3:51 am
Location: Spain
Contact:

Re: [RELEASED] ZDoom32 2.8.2 (ZDoom is undead)

Post by drfrag »

Well, this is embarrassing. :oops: I've just released a new version since i've found a nasty bug with broken savegames on maps with dynamic lights (i've flagged it as critical). Somehow i missed a bugfix by Graf after porting his GZDoom adjustments for the new savegame code, i usually don't read the entire description for all commits. The problem was already in the previous release after the merge with the old GZDoom but it's not a bad merge. I know i said the last one was a solid release but hey this time is for real i promise. :) I know this comes after the gcc crash with voxels for the SSE2 version but it was also unfortunate and that doesn't mean this is not a solid product. 8-) Some testing would be welcome.

On the bad rendering of 3D Floors in TC mode (missing textures shown as white) it's the same as in QZDoom 0.0 alpha. I don't know how to fix them (not skilled enough of course) nor where to look at. I don't know how to port LLVM code to C++ or if that's even possible. May be it's an easy fix or may be it's over-complicated.
@dpJudas: I'm asking for your help again :3: , what do you think of this? Is there a viable and easy solution for fixing them on this poor man's QZDoom? (this engine is faster on old machines and has lower requirements so it would be nice to have them working).
dpJudas
 
 
Posts: 3037
Joined: Sat May 28, 2016 1:01 pm

Re: [RELEASED] ZDoom32 2.8.2 (ZDoom is undead)

Post by dpJudas »

I'm not really sure what causes the bug you're referring to. There are too many changes since then for me to say. If you know which drawer is failing and can tell me what is supposed to happen when the texture is missing, maybe I can come up with a theory for what is going wrong.
User avatar
drfrag
Vintage GZDoom Developer
Posts: 3141
Joined: Fri Apr 23, 2004 3:51 am
Location: Spain
Contact:

Re: [RELEASED] ZDoom32 2.8.2 (ZDoom is undead)

Post by drfrag »

Thanks very much again, sadly i've got no idea of what's wrong. The texture (flat) is applied but it's mostly not shown only a few squares with the wrong color. The problem was in q0.0 alpha (from 09/26) and not in q0.1 (from 10/18) so i've reviewed your commits in QZDoom master between those dates but there's nothing there, seems like it's fine right out of the box with the LLVM drawers.
Sometimes both the upper and lower flats for the 3d floor are bad and sometimes only one of them (as in the example) or both of them are mostly right with only a few white stripes for wall textures.
Do you remember such a problem? I've tested with staircase3b2.wad (see screenshot) and 3D_BLDG7e.wad mostly.
It can be reproduced with any 3d floor and in ZDoom32 i renamed the swtruecolor CVAR to r_truecolor.
Screenshot_Doom_20171121_112610.jpg
Just in case wads here:
viewtopic.php?f=3&t=37508
And engine here:
https://github.com/drfrag666/gzdoom/rel ... 2_282b.zip
dpJudas
 
 
Posts: 3037
Joined: Sat May 28, 2016 1:01 pm

Re: [RELEASED] ZDoom32 2.8.2 (ZDoom is undead)

Post by dpJudas »

Not really sure what happens there, sorry. The pixels at the edge vertically could look like sampling bugs. The errors to the side could be a broken 1 column drawer where the 4 column version works. It could be a light level that is just way too high somehow (since its so white but yet not entirely). Not really seeing any pattern in it.

I can't recall having seen something like this.
User avatar
drfrag
Vintage GZDoom Developer
Posts: 3141
Joined: Fri Apr 23, 2004 3:51 am
Location: Spain
Contact:

Re: [RELEASED] ZDoom32 2.8.2 (ZDoom is undead)

Post by drfrag »

Thanks, the main problem there is (obviously) the ceiling flat mostly shown as white. The output with QZDoom 0.0 alpha is exactly the same as with ZDoom32 (i downloaded it from a doomworld thread). In the original truecolor thread nobody complained about 3d floors so may be the problem was introduced later, i don't know if it could be related to the removal of premultiplied alpha (it doesn't seem so). Did you try 3d floors back then at some point with the C++ drawers?

So no idea but i'd really like to fix this since i find this old renderer very interesting for legacy hardware. To illustrate it on my old athon64 3500+ comparing ZDoom32 with Rachael's test build from 05/21 i get (NOSSE2 / SSE2) 38 / 55 fps vs 19 / 33 @1024. Now that ZDoom32 is a mature port i think it's worth fixing this (IMHO) for people with old hardware but unfortunately i can't do it myself. It happens only with 3d floors but i don't know where to look and my skills are quite limited. Any help would be greatly appreciated.
:wub:
Also i'd like to try your old test build in zdoom-truecolor2.zip, do you still have a copy lying around by any chance? Thanks again.

Edit: the screenshots are actually from q0.0 alpha. Here's another one with 3D_BLDG7e.WAD.
Screenshot_Doom_20171123_214430.jpg
User avatar
Kappes Buur
 
 
Posts: 4114
Joined: Thu Jul 17, 2003 12:19 am
Graphics Processor: nVidia (Legacy GZDoom)
Location: British Columbia, Canada
Contact:

Re: [RELEASED] ZDoom32 2.8.2 (ZDoom is undead)

Post by Kappes Buur »

I downloaded the engine from viewtopic.php?f=44&t=57087&start=45#p1028078
and ran those two pwads with the default settings
Spoiler:
Specs
Spoiler:
User avatar
drfrag
Vintage GZDoom Developer
Posts: 3141
Joined: Fri Apr 23, 2004 3:51 am
Location: Spain
Contact:

Re: [RELEASED] ZDoom32 2.8.2 (ZDoom is undead)

Post by drfrag »

@Kappes Buur:
Thanks for testing it but the default is the classic paletted renderer since this is the sucessor to the good old ZDoom 2.8.1 (for old hardware and even win9x). You need to set r_truecolor to true or use the display menu option to switch to truecolor mode. The missing dome is normal since 3d floors are somewhat limited in software, they are fine with the GL renderer. Quite powerful hardware there BTW.

@dpJudas @Rachael:
Sorry but i need to insist. I known you're busy with more important and exciting stuff, great work with models BTW (at first i thought it was a Quake II screenshot). :D
I've done some research and i think the problem is related to a bad translation and alpha blending somehow and not in the drawers themselves. If so the problem was fixed in the commit '10/07 - Changed column drawers to use true color textures' and would be in RtTranslate1colRGBACommand (r_drawt.cpp). But of course may be i have no idea of what i'm talking about. That code was added in '06/07 - Changed rgba renderer to use a command queue system for its drawers'.
I don't know if 3d floors were rendered properly in the old june build (zdoom-truecolor2.zip). I'd like to test QZDoom 0.1 alpha from 10/08 as well (but i could only download the later beta).

I don't think this would be a quick and easy fix so what i'd like to do then is adding a hack for 3d floors in TC mode so at least flats are rendered properly but opaque by disabling alpha blending. That hack would be in the 3d floor code itself. Could you help with that, such a quick and dirty hack? Provided i'm not completely wrong of course. :)
User avatar
drfrag
Vintage GZDoom Developer
Posts: 3141
Joined: Fri Apr 23, 2004 3:51 am
Location: Spain
Contact:

Re: [UPDATED] ZDoom32 2.8.3 (ZDoom is undead)

Post by drfrag »

Well it's time to explain what happened to the project recently, i released another version on december due to a couple of new critical bugs i found, these were showstoppers actually.

Fist i had applied a patch by Graf which was supposed to enhance Doom turbo stairs using the Stairs_BuildUpDoomCrush special from Eternity but actually it prevented them from working, this was a game breaking bug and was fixed a few days later but somehow i missed the fix. This was pretty common and i usually check the next few days for commits after i apply a patch, well lesson learned. I've been applying the patches in waves and that's why it happened. :oops:

The another one was even worse, i ignored Graf's warning about an ASM routine being broken (R_DrawColumnHorizP_ASM after the floatification) so the engine crashed in software on really old CPUs (it crashed on P3 and even on P4). On more modern machines it worked fine so i assumed it would there, clearly i was wrong. :oops: My asm is very rusty and i don't think Randi would come back and fix it so it's disabled (but hey no performance difference at least on P4 cpus).

I don't think there are more problems now, i will review all the stuff from last year for the 2.9.0 release i'm planning to do. My intention is to port back as many features as i can such as DECORATE stuff (as far as modding capabilities the engine is one year old). I don't plan to add ZScript support since i think it would add some overhead and it was not production ready back when it was merged into ZDoom. It would require even more work anyway and for that there's GZDoom, i want this to be a lighter version for old machines.
I'm also going to at least limit the logfile CMD and consider to blacklist some MENUDEF CMDs as _mental_ suggested. The ACS patch will be in very soon as well (probably for LE too). As a side note i think i will also change the hqnx scaler for LE from google code (looks worse) to the _mental_ version.

The new ordering for the savegame list is there (by slot number as in original Doom and not alphabetically), the difference is that there are no empty savegames and you must create the slots first but then you can save wherever you want.

The old ZDoom32 branch without the GL renderer is still being maintained actually and i'm going to start the upgrade there.
A major roadblock for 2.9.0 it's that 3D floors are broken in truecolor and i've got no idea why (at least i had an interesting theory). The key could be in cortlong50's map (is really that a BIG download?). Not that it's a major thing but it's ugly. I've tested the LLVM renderer on a modern i7 CPU and yes it is clearly faster (138 vs 97 fps @1920) but the old renderer almost doubles its performance on 10 year old machines and it's still fast on modern CPUs.
I think very few people in the world could fix it and those are the ZDoom devs here. Of course Randi would also be welcome.
The renderer was properly merged but there's this nasty problem which also was in QZDoom alpha.

@_mental_: I hope you could have a look at this someday in the near future. Apparently cortlong50's map was rendered correctly so this could be related to the textures applied to the 3D floor (i know he sent you that map). Also as you can see i've added you to the credits section.
_mental_
 
 
Posts: 3812
Joined: Sun Aug 07, 2011 4:32 am

Re: [UPDATED] ZDoom32 2.8.3 (ZDoom is undead)

Post by _mental_ »

The hqNx implementation currently used in GZDoom isn't mine. I just replaced inline assembly with MMX/SSE intrinsics, so hqNx is available when building with all major compilers.

As for cortlong50's map I don't have. It's about this topic, right?
User avatar
drfrag
Vintage GZDoom Developer
Posts: 3141
Joined: Fri Apr 23, 2004 3:51 am
Location: Spain
Contact:

Re: [UPDATED] ZDoom32 2.8.3 (ZDoom is undead)

Post by drfrag »

I guess i didn't want to add the mmx requirement to LE but it's fine as long as it runs on a pentium ii, that google code implementation wasn't that bad after all and was used on a GZDoom beta.
Yes, i supposed he sent you the map. Then @cortlong50: could you please send me the map to check the 3D floors? I'm afraid i could not fix them myself tough but could do some investigation.

Another thing: Houston (_mental_), we've got a (another) problem. Do you remember the old bug with generalized Boom crushers not inflicting damage to the player? It made it into GZDoom 2.2 (and QZDoom 0.0 alpha, it was already there on 09/08) and was fixed in the next official release that was QZDoom 0.1 beta. I've revised the master branches of GZDoom and QZDoom between 09/26 and 10/18 and could not find anything. Which file am i supposed to track? The bug shouldn't be there since ZDoom32 is based on a later codebase, i suspect this could be a rare Git bad automerge since i don't see any conflict. I want to reapply that commit i can't find to fix it. I've discovered the bug playing map06 of d2dw-v1.wad. Could you please help? Thanks.
Post Reply

Return to “Game Engines”