Over the last week or so, I've thrown together a 3D renderer in assembly. Right now the points must be hard-coded, and it doesn't draw lines between them yet (cough Mateo cough) but it is certainly usable. Right now, the arrow keys move the player, [Del] and [Stat] move the player up and down respectively, and the number pad is used for rotation ([4] = left, [6] = right, [8] = up, [2] = down, [7] = roll left, and [9] = roll right). I went for a first-person-style control scheme, so if you look directly down and press forward you will move in the direction that forward would be if you were not looking directly down. (I hope that makes sense?)

Enough text, here's an image!


As you can see, this renderer is pretty smooth. (The GIF looks a little choppy, but the real version isn't.)

Download (source included; updated 2018-12-27)

Huge thanks to Kerm, Mateo, Jacobly, Runer, and a bunch of others who helped me with some of the routines and debugging. I have no major plans for this in the future, but I'm hoping someone will pick this up, optimize it, and possibly turn it into a C library! Pretty simple 3D games have been made for the monochrome calculators, (ex. TI-Doom) and I'm sure the CE has lots of potential. A 3D graphics library could be extremely empowering to C and assembly coders alike.

What do you think?

P.S. It also has an icon when launched from Cesium.

It looks nice and it's fast! (I might want to start learning C Edit: and ASM now.)

This is really exciting, Hactar. It's been fun watching you hone your ez80 assembly skills while you work on this, and I'm sure the work including getting fixed-point routines working will come in handy for many people. I certainly will want to ask to use them for Graph3DE when I get to work on it. Eightx84: This is ASM, not C.

Very nice! I hope there will be some 3D engine created in near future that will be smooth. When I'll learn ez80asm better I will experiment with 3d too.

I was actually I little bit disappointed while using this in the emulator that it seemed to only run at about 20-30 FPS, but on a real calculator it is significantly better. Of course, I have absolutely no knowledge of some of the other complex aspects of 3D rendering, such as drawing faces. (I understand about breaking things up into triangles, and only drawing the triangles from one side, but how does one ensure that the triangles are drawn in the correct Z-order? And what about drawing triangles where 1-2 points are behind the camera, but the third is in front?) Anyway, I too definitely hope that this will be optimized further and evolve into a usable game engine. The CE has a lot of potential, and the more people get involved the more of that potential will be unearthed and explored!

G3DCE HYPE

CEmu running on "100%" is slower than the calculator at the moment (quote below from Mateo taken from here). I've been running it on 120-130% to get something closer to actual calculator speed.

Once I was into programming in batch on windows and I really liked making games in pure batch. Although it is all in console window people were finding millions of solutions to do stuff like games, 1x1 pixel graphics, more than one color at once, etc. So I made once a simple 3d engine in pure batch and I have some experience. When I will have better knowledge od the eZ80Asm I will definitely try to pick up on this and make some 3d functions to it.

Say, do you know anything about polygon filling and/or raycasting...?

Hactar: What do you need to know?

Well, eventually I will need to be able to draw solid structures. Mateo's line routine will work for wireframe models, but actually drawing solid objects will become necessary for this to be practical in any games. I have a general idea of how to manage to data for keeping track of this, so that's no issue. (Per-pixel) raycasting seems like it may be a bit too slow, so I'll need a way to both draw an arbitrary triangle on the screen and a way to do proper Z-ordering. Both of these sound rather challenging.

You definitely will want to look into scanline rendering (the algorithm I'm implementing). It's fairly complex, but if you only need polygons and not lines, it's not as bad as the full blown version I'm implementing. It's by far the most efficient way to do full 3D arbitrary shapes without a GPU.

Well drawing lines and polygons is not as complex as implementing 3D math routines so it should be a pretty straight-forward exercise.

There are already several line routines for the CE available.

If you are only going to be drawing 3 sided polygons (triangles) then it's simpler also. I think the standard approach is to think of a rasterized triangle as a stack of horizontal line slices where each end-point changes in slope with each slice. If that makes sense?

Will this be a true 3D engine, or will it have some support for taking a 2D map and rendering it 3D if the right data is given to it?

My hope is to implement some form of ray-casting which would indeed allow (relatively simple) 3D games. I'm not sure quite what you mean by "rendering a 2D map in 3D." If you are talking about applying textures to faces, that is certainly something that may come in the future, but right now everything is tentative. (By the way, if anyone else wants to optimize/expand upon what I already have, PLEASE do so! I might not be coming back to this project for a little while, and it seems there are several others here who have much greater knowledge than I do of what techniques will work best.)

The link seems to be down, so I'm wondering how long ago this was. I may be interested in reviving the topic of a 3d engine. Does this use the OP registers? It seems it. If there was source, I'd be easy to extend it, but it seems gone.

At the top right of each post, the date of the post is shown.
The last post was written on Feb 17 2016 at 05:48:33 pm.

99.99% He's not.

I'm assuming based on this that they used custom fixed-point math instead.

I would love to convert this to ICE

I moved some files around in my Dropbox, which broke the link. Here's a new link that should work in the future. (I've updated the original post as well.)

Indeed, this program uses custom fixed-point math (16.8 if I remember correctly), with no OS math routines. Addition and subtraction are trivial, and I remember multiplication just being a bunch of register juggling and mlt instructions. I think I took the square root from and based my division on code in this "eZ80 Optimized Routines" thread.

Angles are represented in increments of 1.40625 degrees so that a single byte holds an angle between 0 and 360 degrees. I used spreadsheet software to make a lookup table for trigonometric functions.



Lines are pretty easy, yes. I originally left them out of this because I was waiting on a line-drawing routine from Mateo, which has now probably been incorporated into the C graphics libraries. Polygons also aren't too bad, but rendering textures has got to be pretty difficult (or at least moderately slow). Even though this program runs at an acceptable rate, this is the bare minimum of rendering eight points. Hopefully many of the algorithms could be optimized, and maybe some time could be gained by using a custom GetKey routine instead of a thin wrapper for TI-OS's _GetCSC. Even though I mostly made this as a learning opportunity (and that it was!), I'd love to see someone make something fun or useful with it if that's possible.