Calculator Community > TI 68K

Descent 68k/X3D

<< < (2/6) > >>

TIfanx1999:
This looks quite nice! I'll have to put it on my calc and give it a try. :)

catastropher:
Thanks @Art_of_camelot! So, I wanted to give a status update. Here are the features I have worked on implementing since my last post:

* Several optimizations and bugfixes
* The ability to import a Descent I level (registered or shareware)
* Gravity
* Better collision detection and ramps!While the engine *can* import an official Descent level, it unfortunately has numerous rendering problems and renders at <1 FPS :( So, in the meantime, I'm using the official level editors as an editor to create simple test levels. Here is a screenshot of one in the editor:
Spoiler For Spoiler:
Here's an animated screenshot of the level in action (though it still has some rendering glitches):
Spoiler For Spoiler:
I present the project on Wednesday, and after I clean up the code a bit, I'll be publicly releasing it. I will probably be rewriting the engine as a long-term goal to have a better level structure and overall design. In the meantime, however, I want to implement the following features:

* Vector graphics (i.e. "texture"/wall decorations made of lines/simple filled polygons)
* Switches
* Doors
* Elevators
* A simple weapon
* Facing spritesYou may be wondering if this will still be a game of Descent. The answer is, I'm not sure. Certainly it will turn into a 3D game engine (much like FAT but with true 3D), but I'm not sure if the calculator will be able to handle a full level. I've thought of a way to simplify the geometry into convex regions (instead of just cubes), but this will require an engine rewrite. We will see though :)

As always, thank you for your continued interest in X3D! I look forward to posting my progress in the future!

Matrefeytontias:
Wow that looks very cool !

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.

ben_g:

--- Quote from: Matrefeytontias on April 06, 2015, 04:10:42 am ---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.

--- End quote ---
* Ben_g  points to :P
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.

catastropher:
Hey guys, thanks for the input!


--- Quote from: Matrefeytontias on April 06, 2015, 04:10:42 am ---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.

--- End quote ---

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.


--- Quote from: ben_g on April 06, 2015, 07:26:16 am ---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.

--- End quote ---

In a way, this what the engine currently does. Since it's a portal renderer, if the portal isn't visible, whatever's on the other side isn't either. The levels themselves are made up of interconnected cubes; when two cubes are connected, the face that they share is the portal. It works by starting at the cube you're currently in and recursively rendering neighboring cubes until it hits the recursion limit or there's nothing left to render. However, this means that you still have to consider each potentially visible portal and send it through the polygon clipper, even if it turns out it isn't visible (which sadly is an n^2 algorithm :(). I do like this idea though because it may really cut down on the number of cubes the renderer has to consider. I wonder if there's a way to efficiently programmatically determine potential visible sets...

Navigation

[0] Message Index

[#] Next page

[*] Previous page