As some of you may know, I am currently developping for the ez80 calculator line a port (read: a full rewrite) of my previous engine on monochrome calculator. Thanks to the increase power and the color screen, it can finally output something 'usefull'.
Here is current status screen :


(model are based from tomb raider III game on PS1/PC)
For now, I stick with a full screen 320x240@8bpp vsynced rendering (this is obviously an area in which we could gain some speed !) The screenshot above run between 3 and 6 fps (which is quite good for such heavy models, ~900 triangles + 600 triangles for the walking model)

There was a lot of thing done :

▪general 3D math (vector&matrix)
▪flat & textured shading
▪lightning (per polygon, also work for texture)
▪depthsorting
▪bone animation
▪animated texture through part texture copy
▪easy way to support vertex and pixel shader
▪(buggy) clipping

I obviously still have a lot of thing to do, especially optimizing stuff (because, well who want a slow engine ? )
There is also some stuff I would pretty much search/implement/do, such as :

▪mipmapping (which may definitly improve visual quality, with the low-res screen)
▪better occlusion routines
▪fix bugs around
▪Estimate if we could convert it to a C library too

Wow this is amazing!

This is crazy awesome!!!

x-post from CW

I have a render request.

You should come up with a gLib logo, with a lot of poly, and use it as a benchmark.

I also want to see a render of a CE rendering a CE.

I'm interested in your depth resolution.

What sort algorithm are you using? Are you caching the results? It seems like using a single pass of a bubble sort each frame would probably be sufficient since the sort results frame to frame won't change much.

Any plan to support per vertex light mapping? That's the fastest lighting method around that I know of.

Great work!

Incredible! I look forward to seeing this develop!

Amazing! I'm stunned how you got the person to look like an actual person without making her look like Steve.
A few questions:
If you make the textures less complex, how much would that speed it up?
How easy will it be for others to use this engine?
what FPS do you think you'll achieve with ideal optimization?

Unrelated: If we got Geek Bench or AnTuTu on the calculator, what score do you think it'd give?

As JamesV said, I look forward to seeing this develop!

Awesome work as always, and finally the cross post!

The screenshots are amazing .

Actually I am not so happy with my sorting algorithm. I use some sort of constant time radix sort with average Z rebuild each time (at about 1200cc per triangle). I did at first try to use temporal coherency for sorting but my very first algorithm was very slow - so I guess I will need to experiment more in this area. You'll need to keep in mind that the actual rendered list of triangle can if fact greatly change from frame to frame due to agressive culling.

The lightning is actually computed at vertex level and then propagated at polygon level due to animation stuff. Shading is done per polygons though.

To answer texture question, the texture size is independent from shading speed. On the opposite fixing the texture size at a single 256x256 page did speed up the rendering.

Targeted fps would really be about 8fps for the above screen, but I think I am dreaming too much

The engine in itself is quite easy to use if you know the generality of 3d rendering - if you know opengl pr directx using the engine will be pretty simple. However you still need to know assembly

Mhhhh I strictly dont know how point the calculator would have, but I doubt it will be much

Is the map a kind of BSP, or is it just a big 3D model?

There is no acceleration structure or whatsoever, it just plain 3D models. An another possible way to gain speed indeed

Yeah you could just crawl a BSP back to front and render as you go and not sort the environment at all. Would have to resolve that with the dynamic mesh data though.

Altough resolving node will take quite some CPU time, as you'll need some dot product in 16bits and given that the BSP may be quite huge, sorting might be faster. Some other structure such as octree could be quite interesting, especially for culling though.

So, the code is available on github : https://github.com/TheMachine02/Virtual3D
It isn't the final (at least a v1.0 version), but it is still kinda usable. I haven't written a proper documentation *yet* though, but at least basic example should be quite straightforward, and should allow you to test your own model out of the box

Awesome, I will check it out when I get the chance to. You're amazing

For a moment, I had been putting some brain-cycles in thinking about porting or cloning the legendary Ken Silverman's Voxlap engine. But that sorcery is written in C with parts in x86 ASM, with some parts containing SSE and 3DNow!.

So, I added a bit more eyes candy





If some asm guru want to take a look at the code for optimisation, well he is welcome (even if I still haven't really finished the base, and well, early optimisation is bad. At least, some right now should be pretty much harmless )

One place of optimisation is texturing obviously, which is in lib/shader/vxPixelShader.inc for inner loop, and lib/vxRasterInterpolation.ez80. If one want more explanation, I will be delighted to give it (it is just since it is lengthy, I don't want to write it right now ). I think however trying a totally different approach/algorithm to test for speed my be worth it (even if the actual inner loop might not be so much different, cause well, there isn't 36000 way to do texturing !)

Not sure how I didn't see this update?!

Yep, that is pretty much the most awesome thing I've ever seen on a calculator .

Looks fancy! How fast can you go if you have a model with like 20-30 polygons? Keep up the excellent work!

wow, this is awesome