The status of ZDoom 2.0.97

DaniJ · Post by **DaniJ** » Sun Mar 20, 2005 4:26 am

Are you abstracting using macros to implement your new floating point math?

From a coders POV it would be nice to have the option of fixed/floating (considering your spending the time to go through and change all this), so that if at some point in the future you/someone else wanted to port Zdoom to compile on say an ARM processor it wouldn't be a royal pain in the ass to convert it back again.

Post by **Graf Zahl** » Sun Mar 20, 2005 5:02 am

My guess is that it's too late for that. ZDoom already uses a lot of floating point for internal calculations even in 2.0.96.

AgentSpork · Post by **AgentSpork** » Sun Mar 20, 2005 5:04 am

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

May I ask what exactly that is of?

Post by **Graf Zahl** » Sun Mar 20, 2005 5:55 am

The base for a new renderer!

Post by **Chris** » Sun Mar 20, 2005 6:18 am

Graf Zahl wrote: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. ;)

True that. In my experience, on anything semi-modern, changing math-heavy fixed-point (ie, multiplications, divisions, etc) to floating point is generally good. Fixed point is good at having a fixed accuracy, int<->fixed conversions, and areas where bitwise operations help a lot, however (an example of the latter, I had a good, working 2d distance calculation function that didn't use any branching or sqrt's.. not 100% accurate, but close enough for most uses).

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

Even so, an on-chip opcode is bound to be better than an external implementation.

Tormentor667 · Post by **Tormentor667** » Sun Mar 20, 2005 6:55 am

timmie wrote:
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?

...what is it?!

Post by **Kirby** » Sun Mar 20, 2005 9:59 am

Randy, you rock my world

Tormentor667 · Post by **Tormentor667** » Sun Mar 20, 2005 10:54 am

Graf Zahl wrote:The base for a new renderer!

This means, no more Doom-Port-Limits?

QBasicer · Post by **QBasicer** » Sun Mar 20, 2005 12:42 pm

If we're goin with a new renderer, 32 bit textures...maybe...please?

skadoomer · Post by **skadoomer** » Sun Mar 20, 2005 1:42 pm

Tormentor667 wrote:
timmie wrote:
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?
...what is it?!

A new system to render space. Hopefully this will eliminate the "Fish eye" effect when you try to look too far up or down in a map. If i had to venture a guess on what this would mean, i'd say this would allow for true 360 degrees of mlook like in gl ports. Then again, thats just my own observation basted on the way the shots are constructed.

RabidZombie · Post by **RabidZombie** » Sun Mar 20, 2005 1:55 pm

Im sure that freedom of any angle for the look has been talked about before in the polymost beifits thread

And anyway, i was right about that 'Fake' screeny being something:
ah, cant be bothered to find the link

Sphagne · Post by **Sphagne** » Sun Mar 20, 2005 11:37 pm

Great news, and the next step? A fully GL renderer?

Grubber · Post by **Grubber** » Mon Mar 21, 2005 1:18 am

What about releasing ZDoom .96 with Graf's DECORATE additions, something like .96a, so people don't have to wait for it to be official (Randy?)

rpeter · Post by **rpeter** » Mon Mar 21, 2005 1:47 am

Optimizing for speed is not just the compiler's territory. Ken used precalculated tables for almost everything: power, sqrt, sin, cosin, angles. Some were static tables in the code, the bigger ones were loaded from the grp file. Sure, you won't find many floats in Build, probably none in the Duke's game code, but with a fixed precision float lookup tables can also be created.

I still cannot imagine that those bird-brain piggies could be fitted with an AI that can slow down ZDoom noticably...

Post by **Chris** » Mon Mar 21, 2005 2:31 am

Ken used precalculated tables for almost everything

Tables aren't always faster. Depending on the precision you need, the tables could be too large to easilly fit in the CPU cache. Also if you're using floats, converting to and from int is hard on the CPU as well.