Textures are always a big deal with calculator 3D engines, because they require a loooot of processing power. As far as I know, the only engine that's fast enough to provide textured polygons is nGL on the TI-Nspire because this calc has a lot of processing power actually./me points to (http://img.removedfromgame.com/imgs/screenie3.png) :P
Textures are always a big deal with calculator 3D engines, because they require a loooot of processing power. As far as I know, the only engine that's fast enough to provide textured polygons is nGL on the TI-Nspire because this calc has a lot of processing power actually.
If you have problems handling bigger levels, then it's ofthen best to divide them into a few sections. Then for every one of those sections, you have a small list which indicates which other sections are visible from that section. Then you only render the section you're in and the sections visible from there.
You'll have to put a bit more work in your levels to do this, but it makes it possible to have much bigger levels with minor overhead.
I've used this trick a few times in some unreleased test projects of mine, to render environements that are too big for the 84+ to render, like entire race tracks.
For a calculator, you shouldn't have to do perspective corrected texture mapping. You get almost as good results from affine texture mapping if the textures aren't stretched too much. And calculation-wise, textured triangles were about 2-3 times as heavy as the solid ones (Though I have to admit: both the solid and the textured triangle drawing routines were terribly optimized). So, depending on the complexity of the textures you use and how efficiently your engine does the 3D to 2D conversion, a bitmap could sometimes be faster.
Bitmap textures are indeed very expensive to draw; even if I could get it to work, the engine already requires significant CPU power for the other stages of the rendering pipelines (rotating, projecting, 2D clipping, 3D clipping, etc). However, my engine is geared towards drawing/clipping lines and polygons, so the "textures" are not bitmaps, but a series of 3D lines and polygons that are "attached" to the wall (i.e. vector graphics). Suppose that I wanted to draw "Hello" on a wall. Instead of drawing the pixels that make up the 'H', I could instead store the 3D lines that make it. Then, it's easy and fast to draw because it's just a bunch of lines instead of having to do perspective-correct texture mapping. While this does limit the type of "textures" you can create, I think it's better than having all blank walls.
For a calculator, you shouldn't have to do perspective corrected texture mapping. You get almost as good results from affine texture mapping if the textures aren't stretched too much.That's correct, nGL doesn't use the Z coordinate for texture interpolation. It simply maps the triangle edges to screen edges and interpolates linearly.
Suppose that I wanted to draw "Hello" on a wall. Instead of drawing the pixels that make up the 'H', I could instead store the 3D lines that make it.How well does that scale? I assume you're not using a z-buffer, but sort the faces before drawing. (Surprisingly, a z-buffer is faster than sorting faces on the nspire, even for moderately low-poly scenes)
Interestingly enough, X3D doesn't draw any triangles whatsoever. Instead, it exploits a few properties of the level design. First, all of the cubes can be rotated/stretched/skewed, but they have to remain convex. This means that for a given cube, (with backface culling) we can draw the sides in any order without a Z-buffer or depth-sort. Second, a cube can be connected to another cube by having them share a face. I then just set the clipping region to be the shared face before drawing the child and clip the lines of the child's polygons against it. Since the calculator renders in monochrome and there is zero overdraw because of the clipping region, there is actually no need to clear any triangles; I just clear the screen before rendering and draw the outlines of the polygons.QuoteSuppose that I wanted to draw "Hello" on a wall. Instead of drawing the pixels that make up the 'H', I could instead store the 3D lines that make it.How well does that scale? I assume you're not using a z-buffer, but sort the faces before drawing. (Surprisingly, a z-buffer is faster than sorting faces on the nspire, even for moderately low-poly scenes)
For a calculator, you shouldn't have to do perspective corrected texture mapping. You get almost as good results from affine texture mapping if the textures aren't stretched too much. And calculation-wise, textured triangles were about 2-3 times as heavy as the solid ones (Though I have to admit: both the solid and the textured triangle drawing routines were terribly optimized). So, depending on the complexity of the textures you use and how efficiently your engine does the 3D to 2D conversion, a bitmap could sometimes be faster.Since I'm not clearing any triangles, if I want to draw the vector wall graphics, all I have to do is throw them at the polygon clipper. If they want a filled white polygon that's outlined, the wall is already white so we only have to draw the outline. If, on the other hand, they want a black filled polygon, we just once again clip it and draw some black-filled triangles. There's no need to even draw the outline in that case! Perhaps I will upload an image to clarify what I mean by this.
I just love it! :DThank you!!! This is the most ambitious project I've ever taken on (with a codebase around ~10,000 lines), but somehow it seems to work :P
This is by far one of the coolest things I've ever seen on the 68k series. Question: do you use tigcc or gcc4ti for programming this?:D I am currently using TIGCC... should I be using GCC4TI?
10,000 lines !? O.O dang, and I thought nKaruga was big with 6658 lines of actual code (not including images).Of course, I'm including the number of lines for the level converter, among other things ;)
This is really impressive. I'm a bit confused, though: If it's based on descent, why are the screenshots focused on walking around? The Descent I remember had zero-G flying everywhere!So originally I started out by wanting to just create Descent, but now my goal is to create a general 3D engine that would be able to run other games and, perhaps one day, Descent. The levels of Descent are very complex, however; my engine can render a level, but it does so at <1 FPS. The gravity was added so I had a working demo for my class project.
In any case, great job on the engine. It might actually give me a reason to use my recently acquired TI-89.Thanks! :D With any luck we can revive the 68k community ;)
Just starred the source. Can't wait to see more!Thanks! I have followers! :D
Textures are always a big deal with calculator 3D engines, because they require a loooot of processing power. As far as I know, the only engine that's fast enough to provide textured polygons is nGL on the TI-Nspire because this calc has a lot of processing power actually.
Since it's a portal renderer, if the portal isn't visible, whatever's on the other side isn't either. [...] I wonder if there's a way to efficiently programmatically determine potential visible sets...
I think I scared him :(Don't worry, you didn't scare me! haha I've just had some health issues that have prevented me from using my hands much this last month (arthritis and the like). I'll be back soon though! :)