Calculator Community > TI 68K

Descent 68k/X3D

(1/6) > >>

catastropher:
Edit: I updated the binaries to use the new improvements. Download link at the bottom of the post!

Way back in 2011, my step mom found her old TI92+, which she generously gave to me. I was in 10th grade at the time and had only done Z80 ASM programming, so naturally I really really wanted to learn to program the 68k calculators. Can you guess what the first program I tried to make was? Descent! Being totally inexperienced in 3D programming however, my first few attempts failed miserably. Since I did post-secondary and started college full time in 11th grade, I naturally decided that programming the calculator was my top priority; thus I invested significant time during my freshmen year into learning it! ;D

The result of my first 3D attempt in 2011 wasn't that impressive, but I got a 3D wireframe cube of triangles to spin:



Over the next few years, I experimented quite a bit with 3D programming. In sophomore year, I managed to implement a segment buffer for hidden surface removal. In junior year, I finally began to understand 3D math. I began work on X3D, a knock up engine that rendered 3D graphics as if it were rendering on a TI83+.

Let's flash forward to last month. Since I'm a senior, I had to pick a capstone project for my Senior Seminar class. At first I wasn't going to do anything calculator related because, quite honestly, I hadn't even turned my TI92+ on in several months. But then, when I was teaching my little brother some programming, he noticed my calculator in my desk drawer and I was hit with a wave a nostalgia - I knew that I wanted to start working on X3D-68k again. That night in February, I stayed up into the wee hours of the night and managed to produce this from scratch:



So, I got thinking: if I could look at the cubes from the outside, wouldn't flipping the normals let me view the cube from the inside? While this did totally work, the calculator just could not cope with drawing grayscale triangles that filled the whole screen, even after clipping (the framerate dropped to under 6 fps). Unfortunately, because of this, I had no choice but to rewrite the engine to do monochrome rendering  :(

So, I did indeed rewrite it. My first approach was to draw white triangles and outline them. However, I got thinking again: levels in Descent are made out of interconnected "cubes" (really convex octahedrons) that share a single face. In portal rendering, this is know as a "portal". Thus, the only way to see the cube on the other side is through that portal. If I just set the clipping region to be that shared face, I can draw the level polygons in any order since the cubes are convex! Even better, because there is zero overdraw, I don't need to actually rasterize the triangles, just draw the outline of them (since it's monochrome)!

Two weeks ago, I found out that too much speed coding and not enough code maintenance was starting to catch up with me. Worse, it turns out that when you do 2D portal rendering, you start getting singularities and weird geometry when part of the portal is off screen. Thus, I rewrote the engine for the final time to have a well maintained code base, and a 3D polygon clipper/view frustum clipping. As of today (well really yesterday since I'm writing this at 4:00 AM here), I finally fixed all weird clipping issues that I've been running into! After three years, I feel like I finally have something that shows some actual progress!  :)

So, here are features of X3D so far:

* Levels made of interconnected cubes. They can be stretched, skewed, rotated, etc. so long as they remain convex.
* 3D portal rendering. If the portal isn't visible, nothing on the other side of the portal can be visible so it's culled.
* 2D/3D clipping to the viewing frustum.
* Collision detection with the level cubes.
* Two axes of rotation (you can look up, down, left, and right). The camera moves in the direction you're facing.
Here are some screenshots of the rendering output. Note that even though the engine supports more complex shapes than actual cubes, I was lazy so I threw a quick, small level together out of them:







So, the "Line count" tells you the number of lines the render had to draw in a given frame. Woah, that number is ridiculously high! Every cube has 12 edges, and each edge is shared between two faces. Since the renderer currently works by drawing individual faces, an edge will wind up being drawn twice. Worse, if two cubes are connected, they share 4 edges - each one of those edges will then wind up getting draw 4 times! Also, this leads to some lines looking thicker than others: if one of the edges is off by even a pixel the lines will diverge slightly. Luckily, I have already devised an algorithm to prevent this and am working on implementing it now. So, until then, the engine runs a bit slow because in worst case, it's doing 4 times as much work than it needs to This issue has now been fixed!

Anyway, since this is a school project, I can't release the source code until after I present it at the senior symposium (sometime in April). I can, however, release the binaries for you to try! Disclaimer: there is a very high chance of this crashing your calculator! I am not responsible for any damage caused by running it! That aside, there shouldn't be too many problems while running it, though visual artifacts are likely because I'm still debugging it. If it crashes with an error message, please pm/email me with the error message! Thanks! Note that I only have a TI92+; I tried it on a TI89 Titanium using TiEmu and it seemed to work just fine, but I have no way to verify if it works on a real calc yet. Here are the keys:

Up/down: turn up and down
Left/right: turn left and right
F1/F2: move forward/backward
F3/F4: straife left/right
Hold enter: display position, angles, and current cube
Esc: quit

If I can get the renderer working fast enough, I most certainly want to turn this into a game of Descent (though this may take quite a while until completion). Thanks for reading and I'll post any progress that I make!

Sorunome:
Wha, that is some quite big post! All I can say that 3D development has always amazed me, and you definitely managed to get some nice things running! Also it's good to see some 68k development again!
I wish you good luck with your project and hope it turns out to become a complete game! :D

catastropher:
@Sorunome, thank you so much for the kind words! :) And yeah, it's quite a big post! haha I've really wanted to do this for a long time, so hopefully I'll be able to turn it into a full game. I just hope there will be at least a few people who still have a 68k calc left to play it!

pimathbrainiac:
I finally have a reason to find my 89Ti again! This looks amazing. Keep it up.

catastropher:
@pimathbrainiac, thanks! :D I really appreciate the support!

So, over the past day I did a number of things:

* Fixed the x4 overdraw problem
* Added backface culling
* Removed redundant edges so walls look more realistic and feel more solid
* Expanded the level
* Reduced the stack usage in my recursive render_cube() function, which was causing a stack overflowWith these improvements, the engine runs at 3-4 times the previous framerate! There are still several optimizations that I can do, however, so over the next few weeks I'll work on implementing them. Also, there are several bugs in the renderer, such as the one that can cause the screen to blank at certain locations in the map... I must look into this...  I will edit the first post soon with the new binaries as soon as I fix a few more bugs.

Anyway, here is an animated screenshot of me "flying" through the test level. Note that the fps on the emulator is ~2 fps slower than on the real calc for some reason.

Spoiler For X3D walkthrough:

Navigation

[0] Message Index

[#] Next page