Hi,

As some of you might know, I am working on a 3D engine. But the engine only runs at a reasonable speed on 15MHz mode, especially when using textures. But the main problem with the 3D engine is that, because it uses 8.8 fixed-points, it quickly runs into accuracy problems. For example rendering a room correctely is, even when it's split up into several wall models, impossible while you are inside it.

So actually to make the engine more useful, it would need a full recode , and I would like to create a full game with it too.

I'm especially looking for someone who can help me with fast math routines and writing optimized code. If someone wants to join for doing something else, that's good too.

For the game, I would prefer an fps, but that can still change. Also, I hope no one would have problems with it being open-source.

Maybe, with the help of the community, this can become a great project.

Hi ben_g! I have never managed to make a working 3D engine, but I have worked on most of the components, code-wise and I have a large collection of routines that I have been optimising more and more over the years. I cannot promise full-time help, but I wouldn't mind having some code to work on in my spare time. For example, if you asked me to write a 16.16 FP multiplication routine, it might take me a while to work through optimising as far as I can (I have a rather dismal stock of FP routines and most of them are rather new, so they haven't had the same years of optimising) Also, high precision trig routines sound rather scary. The fastest and most accurate I've ever done is a signed 8-bit routine using a 64-byte LUT.

Anyways, if you have some routines that you want worked on, feel free to email me or post them. If I see a few I can do right away or if any particularly intrigue me, I'll help

I have a bunch of fast trig routines as well, and I would be happy to contribute any other routines I have or could write relatively quickly. I regret that I won't have the time to be a more substantive partner in the project. I hope you do find people, though!

To be honest, I don't fully know which routines I need yet. For the 3D part, it needs to be signed. And 8.8 was too small because I got overflows. 8 bits of decimal accuracy is enough, so 16.16 might be a bit of overkill.

So I'll have to choose between 16.8 fixed-points or 16-bit floating points. Does anyone know what would be the best for this project? (I do not know anything about the speed of small floating points).

If it helps to make the desision, here's a list of the math that is done in the 3D engine:

-addition
-substraction
-multiplication
-division
-sine (In the current version, I used that together with some math to do cosine and tangent as well)
- square root

All routines accept for the square root have to be signed.

Also, my fixed-point triangle drawing routine looks quite inefficient. Could anyone help with a very fast one based on how lines are drawn? Also, it should have support for full signed 16-bit coordinates.

And thanks to everyone who wants to help.

You're almost definitely best served using fixed-point numbers for a project like this. If 8.8 fixed-point is insufficient, then go for 16.8 fixed-point, I suppose. What sort of overflows were you getting with 8.8 that made it infeasible?

when models ware drawn very big (when you're close), stuff suddenly start to glitch and lines are being drawn incorrectely , drawing to the wrong points or drawing to random locations (only some lines, other parts of the model , which are further away and smaller, were drawn correctely). I can make a screenshot of this if you want.

EDIT to avoid a double-post:
So I decided to go with 16.8 fixed-points. I already have addition and addition:
add hl, de \ adc a, c ;to add cde to ahl
and subtraction:
sub c \ sbc hl, de ;to subtract cde from ahl

I'm not fully sure if they would work with signed numbers too, but I think they will.

Now I still need a signed 16.8 multiplication routine, a signed 16.8 division routine and a 16.8 square root routine. I already have an 8.8 sine routine and it shouldn't be too hard to make it 16.8.
All math routines can have LUT's, as long as I still have around 2Kb RAM free for variables and the engine.

I'm going to try the multiplication, so I was wondering how you wanted to deal with overflow? Maybe return a specific flag if there was overflow, set the result as the highest it can go, or just return it somewhere?

I basically switched to 16.8 to avoid overflows, so if it's the easiest for you, you can just ignore it. But if you like to handle it differently, setting it to the highest sounds like the best option.

oh, okay, I see. I think I will add that in just as an extra precaution.

EDIT: What about using shadow registers? Are you using interrupts?

I'm not using interrupts. I might add some later which will be used to move the player and other objects, so that everything keeps updating at the same speed interdependently of at which speed the engine runs. This would only be done once every X interrupts (I don't know the exact number), so it shouldn't matter if I miss a few.

So if I would once use interrupts, i could just add some DI's and EI's.

I am not sure if this will work for you:

Code:


Since you are using 16.8 format, you will want the EAH part. Overflow on the integer end will be in CD, so you can check for overflow. You can add this before the "ret" to get the result in ELH

Code:

Now the result is in ELH and if there was overflow, it goes with FFFFFF as the result.

(At least, that is how I expect it to work. Hopefully somebody can come along and optimise/fix this up)

*cough* Runer

Thank you for the multiplication routine.

I just completed the sine routine:

Code:

Ben_g. I'm terrible at math routines, but if you need a beta/alpha tester at any point, you can count me in.

As requested in IRC, negating ahl:

Code:


I welcome any optimizations or functional corrections.

I alse needed a negCDE routine, so I wrote this one based on your code:

Code:

Will it work?

EDIT: @ACagliano, Once this reaches a playable state, you can be one of the first who will test it, to get rid of most bugs.

Nope, that's still not it. You're incrementing c, but c is the MSB and e is the LSB. To do two's-complement negation, you first flip all bits, then add 1. It would look something like this:


Code:


I think.

Thank you. Now, will this work as a signed multiplication?

Code:


It's basically xeda's routine with some code added at the start and end.

The code at the start to make sure both numbers are positive and save the sign:

Code:


And the code at the end to put the result in ahl and negate if nessicary:

Code:

Yep, that looks right, but I can see a slight optimisation:

Code:

This can be changed to just:

Code:

This is because the "xor c" will have bit 7 (the sign bit) set if only one value was negative, and if that bit is set after a math operation, the plus/minus flag is set.

Okay, couldn't resist on the NegCDE.

Code:

And I was just going to post the NegAHL:

Code:

I hope I didn't make any mistakes :/