Demon
Register | User Profile | Member List | F.A.Q | Privacy Policy | New Blog | Search Forums | Forums Home
Doomworld Forums : Powered by vBulletin version 2.2.5 Doomworld Forums > Classic Doom > Source Ports > Doomsday 1.9.0 betas
 
Author
All times are GMT. The time now is 01:59. Post New Thread    Post A Reply
DaniJ
Senior Member


Posts: 1740
Registered: 08-03
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
Old Post 01-16-06 19:01 #
DaniJ is offline Profile || Blog || PM || Search || Add Buddy IP || Edit/Delete || Quote
entryway
Forum Staple


Posts: 2587
Registered: 01-04
DaniJ said:

As of 1.9.0 ALL ...
...for 1.9.1
Doomsday 1.8.6 | Last updated on Jan 18 2005
Old Post 01-16-06 19:51 #
entryway is offline Profile || Blog || PM || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
DaniJ
Senior Member


Posts: 1740
Registered: 08-03
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).
Old Post 01-16-06 19:58 #
DaniJ is offline Profile || Blog || PM || Search || Add Buddy IP || Edit/Delete || Quote
DaniJ
Senior Member


Posts: 1740
Registered: 08-03
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.

Last edited by DaniJ on 01-17-06 at 08:01
Old Post 01-17-06 07:51 #
DaniJ is offline Profile || Blog || PM || Search || Add Buddy IP || Edit/Delete || Quote
DaniJ
Senior Member


Posts: 1740
Registered: 08-03
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.
Old Post 01-18-06 00:09 #
DaniJ is offline Profile || Blog || PM || Search || Add Buddy IP || Edit/Delete || Quote
Graf Zahl
Why don't I have a custom title by now?!


Posts: 7130
Registered: 01-03
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.

Last edited by Graf Zahl on 01-18-06 at 00:32
Old Post 01-18-06 00:21 #
Graf Zahl is offline Profile || Blog || PM || Email || Search || Add Buddy IP || Edit/Delete || Quote
DaniJ
Senior Member


Posts: 1740
Registered: 08-03
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)

Last edited by DaniJ on 01-18-06 at 00:45
Old Post 01-18-06 00:37 #
DaniJ is offline Profile || Blog || PM || Search || Add Buddy IP || Edit/Delete || Quote
Graf Zahl
Why don't I have a custom title by now?!


Posts: 7130
Registered: 01-03
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.
Old Post 01-18-06 01:02 #
Graf Zahl is offline Profile || Blog || PM || Email || Search || Add Buddy IP || Edit/Delete || Quote
DaniJ
Senior Member


Posts: 1740
Registered: 08-03
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...
Old Post 01-18-06 01:16 #
DaniJ is offline Profile || Blog || PM || Search || Add Buddy IP || Edit/Delete || Quote
Graf Zahl
Why don't I have a custom title by now?!


Posts: 7130
Registered: 01-03
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.
Old Post 01-18-06 01:25 #
Graf Zahl is offline Profile || Blog || PM || Email || Search || Add Buddy IP || Edit/Delete || Quote
DaniJ
Senior Member


Posts: 1740
Registered: 08-03
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.]
Old Post 01-18-06 01:35 #
DaniJ is offline Profile || Blog || PM || Search || Add Buddy IP || Edit/Delete || Quote
All times are GMT. The time now is 01:59. Post New Thread    Post A Reply
 
Doomworld Forums : Powered by vBulletin version 2.2.5 Doomworld Forums > Classic Doom > Source Ports > Doomsday 1.9.0 betas

Show Printable Version | Email this Page | Subscribe to this Thread

 

Forum Rules:
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts 		HTML code is OFF
vB code is ON
Smilies are OFF
[IMG] code is ON
 

< Contact Us - Doomworld >

Powered by: vBulletin Version 2.2.5
Copyright ©2000, 2001, Jelsoft Enterprises Limited.

Forums Directory