ZDoom

I'm sure a lot of people are anxious for Graf Zahl's custom weapons support to be an official feature of ZDoom. So why isn't it ready yet? I have decided to convert from fixed point to floating point numbers and add a vector math class. Since there are thousands of lines of code that need to be changed to accomodate this, it takes some time.

For players, this change should be transparent. For programmers, it will be readily apparent. Here's just one example of how things have changed. The following code is responsible for making a Lost Soul fly at its target.

Before: After: Eight lines of code were reduced to just one. Although this change really doesn't add anything of value right now, it should prove useful later on, so I wanted to get it out of the way.

And that's why you can't play with custom weapons in ZDoom just yet. If you dig in the forum thread I linked to above, you can find an unofficial build that supports them and play with that in the meantime.

If you want something else ZDoom-related to play with, Skull Tag 0.96b was released yesterday, with all-new bot support plus lots more.

And here are three screenshots of something I've been toying with:

Hehe, that's cool. I've been wondering why it's taking so long, but it makes sense now. Heh, I'm glad to know that you are still working on it and everything.

And those screenshots look pretty cool. I wonder what maps those are from...

Awesome Just Awesome

Keep going randy!

Wow xaser, you even got randy to join us! Woo!

Anyways, what in the hell are those screen shots?

randy wrote: Since there are thousands of lines of code that need to be changed to accomodate this, it takes some time.

Sounds like a bigger overhaul then strife. You certinly are a patient one.

Although this change really doesn't add anything of value right now, it should prove useful later on, so I wanted to get it out of the way.

The devine plan of zdoom i presume....
From what i've gathered, you seem to be interested in the ken silverman route in 2.5 (or 2.75) dimensional rendering. You wouldn't be planning on supporting a certin other game would you?

skadoomer wrote:You wouldn't be planning on supporting a certin other game would you?

No, the game code is too different.

Eight lines of code were reduced to just one.

But of course, that doesn't necesarilly mean less compiled code, or even more efficient compiled code. Though switching from fixed point to floating point should be a nice improvement.

What I'm looking forward to is GCC 4.0. According to sources I've heard, it's supposed to compile C++ much better and produce significantly faster code. Too bad it's still beta.

What are the screenshots of? I mean they sorta look like very old DoomCAD 3d-preview mode (which was vastly inferior to DB's). Is this a "ZLevelEdit" program or something?

OMG, this is really insane! Aside from better readybility, what exactly are the benefits? Right now this looks like a huge change purely for cosmetics.

Chris wrote:

Eight lines of code were reduced to just one.

But of course, that doesn't necesarilly mean less compiled code, or even more efficient compiled code. Though switching from fixed point to floating point should be a nice improvement.

No. If you look closely you will see a call to a member function called 'Unit'. Considering how the length of a vector is calculated this is either a wrapper for an sqrt call or for something that works like P_AproxDistance, depending whether speed or accuracy is more important.
But the one thing it definitely gets rid of is the huge amount of FixedMul calls which make the code quite unreadable and prone to programming errors. But i'd still like to know how the game should benefit from it.

POLYMOST !

Graf Zahl wrote:OMG, this is really insane! Aside from better readybility, what exactly are the benefits? Right now this looks like a huge change purely for cosmetics.

Are you kidding? You said it yourself how terrible the physics were, numerous times. Now extending them will be a breeze

I've always thought that Zdoom was solid as a rock internally, now this just confirms my belief to the power of ten. Thats what makes it so beautiful to behold....

Chilvence wrote:POLYMOST !

Graf Zahl wrote:OMG, this is really insane! Aside from better readybility, what exactly are the benefits? Right now this looks like a huge change purely for cosmetics.

Are you kidding? You said it yourself how terrible the physics were, numerous times. Now extending them will be a breeze

Physics calculations don't get better from changing the numerical representations of the values. It's the algorithms that suck and they will most likely stay the same with floating point math.

Maybe I'm using the wrong terminoligy for what I am trying to say. I am a bit of an uneducated slob...

I am assuming that velocity is a vector. How many times easier are vectors easier to understand than doom's bizzare, half 2d, and seperated momx/y/z thingies?

randy wrote: After:

Code: Select all

self->Velocity = (dest->Origin - self->Origin).Unit() * SKULLSPEED;

Look at that. Now you dont need a degree in Carmackology to understand what is going on in the movement code

If you look closely you will see a call to a member function called 'Unit'.

Not only that, but the Origin subtraction is not only a function call, but creates a temporary 'Origin' object. If such things were defined in the class definition however, all that could be inlined and optimized away, leaving just some floating point math.

Considering how the length of a vector is calculated this is either a wrapper for an sqrt call or for something that works like P_AproxDistance, depending whether speed or accuracy is more important.

Don't forget to consider that modern CPUs actually have sqrt opcodes. And sqrt isn't really that bad, unless you go overboard with it.

MartinHowe wrote:What are the screenshots of? I mean they sorta look like very old DoomCAD 3d-preview mode (which was vastly inferior to DB's). Is this a "ZLevelEdit" program or something?

Maybe just the polymost renderer as it stands now without any texture mapping yet with the flats and walls set to different colors?

Chris wrote:

If you look closely you will see a call to a member function called 'Unit'.

Not only that, but the Origin subtraction is not only a function call, but creates a temporary 'Origin' object. If such things were defined in the class definition however, all that could be inlined and optimized away, leaving just some floating point math.

Right. That as well. And since I know VC's optimizer quite well I can say that this does not create optimal code. On the other hand, P_AproxDistance was also a function call and the FixedMul calls, although inlined created some code overhead.

Considering how the length of a vector is calculated this is either a wrapper for an sqrt call or for something that works like P_AproxDistance, depending whether speed or accuracy is more important.

Don't forget to consider that modern CPUs actually have sqrt opcodes. And sqrt isn't really that bad, unless you go overboard with it.

The last time I checked an sqrt opcode still needed 10 times as much time as a multiplication (but that was some time ago...)