ZDoom 2.1.7

Evolution · Post by **Evolution** » Sat Nov 18, 2006 5:45 am

Great work Randy! Only 3 more!

Post by **Ryan Cordell** » Sat Nov 18, 2006 8:44 am

You're forgetting 2.1.7a, 2.1.7g..

HotWax · Post by **HotWax** » Sat Nov 18, 2006 9:05 am

For the last time, the next version after 2.1.9 is 2.1.10, not 2.2.0.

Post by **Graf Zahl** » Sat Nov 18, 2006 9:20 am

Depends on added features. Randy once said that 2.2.0 will add custom states.
So if this were true the next one should be 2.2.0, not 2.1.8.

But I really don't think that the current changes justify bumping the minor version already.

Post by **Nash** » Sat Nov 18, 2006 10:36 am

I think it's safe to assume that 2.1.8 will already officially support custom states because the code is already in.

So no need to wait for 2.2.0.

Post by **Graf Zahl** » Sat Nov 18, 2006 11:06 am

I think you should try to understand what I was writing...

jallamann · Post by **jallamann** » Sun Nov 19, 2006 10:53 am

Nash: Release version numbers don't have to follow any pattern except that a later version number should be higher than a previous version.

Lemonzest · Post by **Lemonzest** » Sun Nov 19, 2006 3:23 pm

Added a new D3DFB class that should be more compatible with modern systems
than the 8-bit paletted DDrawFB.
Pros:
- Much cleaner code.
- No performance penalty when running in a window.
- Slightly faster fullscreen performance on Geforce 6 and 7 cards.
- Vista ought to love it.
Cons:
- Requires Pixel Shader 1.4 or better.
- Fullscreen on an ATI Mobility x300 is a little slower (but still faster
than DirectDraw in a window).
Note that this is not hardware accelerated rendering. The screen is still
drawn as before by the CPU to an 8-bit paletted surface. The difference is
in how that surface makes its way to the visible display. Here, the surface
is copied to an 8-bit texture, and a pixel shader converts it to RGB when
drawing it.

just seen that in the change log, does that FINELY mean that the messed up colours when alt+tab is used are over? (windows loses the pallete)

Post by **Graf Zahl** » Sun Nov 19, 2006 3:27 pm

If it works, yes. The new code draws to a True Color display and does all the palette to color conversions internally.

Post by **Nash** » Mon Nov 20, 2006 4:17 am

What about software-mode translucency? Any performance gains?

(I have been very busy with work lately so I haven't been able to compile the latest version to see it for myself)

RazTK · Post by **RazTK** » Mon Nov 20, 2006 5:33 am

Oddly, the release build of r383 crashes at startup (no matter the IWAD).
The debug build works fine so I can't get any more information.

Reminds me the MaxVisPlanes bug randy has been working on back in 1998.
I'm hoping he won't get nightmares!

HotWax · Post by **HotWax** » Mon Nov 20, 2006 8:15 am

Nash wrote:What about software-mode translucency? Any performance gains?

Since it clearly states that it won't affect the renderer, my guess is no.

Post by **randi** » Mon Nov 20, 2006 5:37 pm

Translucency is still 100% C code, so there's probably room for some improvement if it was written in assembly.

QBasicer · Post by **QBasicer** » Mon Nov 20, 2006 10:22 pm

Would the speed difference really be worth the hassle? I mean, if you use the optimizer, it usually produces pretty fast code to begin with.