Doomsday 1.9.0 betas

and also that it should work in jDoom (if/when the appropriate limits are extended)

As of 1.9.0 ALL the hardcoded Doom map limits have been extended inline with other limit removing ports, including generation of new blockmap data when necessary. V3&V5 glnodes are supported as well. Also missing textures are no longer a problem (a MISSING image is drawn instead).

I'm also well on the way to making jDoom BOOM compatible and hope to have the bulk of the support in place for 1.9.1

DaniJ said:

As of 1.9.0 ALL ...
...for 1.9.1

Doomsday 1.8.6 | Last updated on Jan 18 2005

Yeah...

We decided to jump straight to 1.9.0 due to the anormity and resonance of the changes. For example the games can't even SEE the map structures anymore as they exist entirely engine-side and are manipulated via an API (the DMU). Another example is the completely new (optional) BIAS lighting model (full vertex lighting).

Grazza said:

DaniJ: I tried DV map05 in jDoom 1.9.0-beta3, but couldn't get it to work whether I built the nodes externally (using glbsp 2.20) or left it to the internal node builder. Is there a way to get it to work at present, or does it require an as-yet unreleased version?

Yeah you won't be able to run it in 1.9.0-beta3, you'll have to sit tight till the next beta which includes all the new limit extending code merged into the CVS from my local source copy.

Which also btw has seen maploader.dll updated to glBSP 2.20 (so you won't need to build the nodes seperately).

PWADs like Phobos: Anomaly Reborn can also be loaded in beta4 but due to most of the BOOM support not having been implemented yet - it isn't really playable.

entryway said:

How about frame rate on par.wad\e1m6?

I can't tell you atm since I can't compile a working version of beta4 currently. I don't expect it to be very quick though, as to be honest we haven't spent any time on optimising, as we haven't yet finished the implementation.

Furthermore, most of the optimizations we could implement would be completely redundant due to work planned for 1.9.1 so we arn't too worried about speed atm. As if skyjake's early test code is anything to go by - rendering in 1.9.1 will be a LOT quicker.

This map works much more slowly in risen3d (with all graphics features switched off) than in gzdom or glboom+.

Thats quite understandable given the differences internally. For example GZDoom doesn't sort sprites and masked walls "correctly" using a Z-buffer hence it (and glboom+) are bound to be much faster than Risen3D on that map.

DaniJ said:

For example GZDoom doesn't sort sprites and masked walls "correctly" using a Z-buffer hence it (and glboom+) are bound to be much faster than Risen3D on that map.

Why waste time sorting them when making sure that there are no translucent edges gives such a performance boost? I never liked that effect anyway.

BTW, this only makes 10% of the overall rendering time.

In the opening cave of E1M6 of P:AR the difference is on my system:

45 fps Quality/Sprite sorting on
51 fps Quality/Sprite sorting off
55 fps Speed/Sprite sorting on
61 fps Speed/Sprite sorting off.

Rendering walls as entire linedefs as opposed to segs gives even more speed. But unfortunately that only works on NVidia cards. On ATI it causes ugly seams.

Why waste time sorting them when making sure that there are no translucent edges gives such a significant performance boost? I never liked that effect anyway.

I myself would prefer some kind oh hybrid solution as I don't like the hard edges... perhaps only sorting them "properly" if they are in the block or neighbouring blockmap blocks to that of the current viewer and then use the ones with the translucent edges. So that sprites/masked walls in the distance will be drawn (quickly) using the hard edged versions. Of course it would mean keeping two sets of alpha data around for each masked graphic though...

When you've got models & particles around it pays to use a Z-buffer.

I was just using it as an example. I'm sure there are other (more) significant differences in the pipelines of each gl port.

Only 10%? Thats pretty significant in my book. Fakeradio for example currently costs about 18%... (it'll be pretty much free in 1.9.1 though)

DaniJ said:

I myself would prefer some kind oh hybrid solution as I don't like the hard edges... perhaps only sorting them "properly" if they are in the block or neighbouring blockmap blocks to that of the current viewer and then use the ones with the translucent edges. So that sprites/masked walls in the distance will be drawn (quickly) using the hard edged versions. Of course it would mean keeping two sets of alpha data around for each masked graphic though...

Thanks for the tip! ;) That way I can add the option without too much of a performance penalty. BTW, you don't need 2 sets of sprites. You can create the normal one and render it with (GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA) with translucent edges and with (GL_ONE, GL_ZERO) without them.

I was just using it as an example. I'm sure there are other (more) significant differences in the pipelines of each gl port.

Of course there are.

Only 10%? Thats pretty significant in my book. Fakeradio for example currently costs about 18%... (it'll be pretty much free in 1.9.1 though)

There's a lot of objects in that particular scene. That's why I like to use it for such comparisons. Since it is entirely CPU bound any additional processing becomes immediately apparent. Maybe some of the overhead comes from the complicated sorting algorithm I use that tries very hard to avoid overlaps. But it has the definite advantage that all lines in the scene will be sorted properly in any conceivable circumstance.

Thanks for the tip! ;)

No problem. I kept meaning to post a suggestion at your forums... which reminds me to suggest it to Skyjake also ;)

BTW, you don't need 2 sets of sprites. You can create the normal one and render it with (GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA) with translucent edges and with (GL_ONE, GL_ZERO) without them.

DOH! Yeah of course. I'm too tired...

DaniJ said:

No problem. I kept meaning to post a suggestion at your forums... which reminds me to suggest it to Skyjake also ;)

If it helps, I used a distance of 256 map units from the camera as the threshold between translucent and non-translucent. With a distance of 128 you can see the change at 1280x1024 quite well.

Cheers.

I think the value for distance threshold used should track to the resolution automatically though.

I'm wondering if there is a way to modulate them as per multitexturing so there is no noticeable transition...

Apologies to entryway as we've kinda hijacked his thread. [Edit by Grazza: I've split it off into its own thread.]