Since I have a 3D engine working on the prizm, I have been trying to think of a game that would work on it without stressing it. I have been either trying to find an existing game what wouldn't have issues cloning or designing one myself. The limit is this: this engine is not optimized for heavy fps stuff from what I have seen. It gets very slow when it comes down to a screenfull of pixels since the fragment shader must calculate pixel color per every pixel. So far my ideas:

• Block dude in 3D
  
• 3D Tetris-like game
  
• 3D Tanks game (Oblit, but 3D)

So far these are my limits on designs:

• 3D rendering takes up a lot of time. Large game code in between each frame will not work well. Block dude works and tetris works as I do calculations once, then do a series of renderings.
  
• Texture mapping has no performance loss, and may actually be faster than per-vertex coloring
  
• Colored lighting works, but each light requires more matrix math. Light shines through walls, preventing that would kill FPS.
  
• shadows would kill the fps, end of story. You could make a game with a cube and a ground plane, that might render ok. Add more polygons, fps drop.
  
• (Character) animations: Loads of matrix math can make everything terribly slow.
  
• High poly models will both look bad on low res rendering (But accurate) and will take a while to render.
  
• Artwork and models must be doable (I can make stuff, but not awesome stuff)

I plan on releasing a source tarball in a while after I test more of the engine, change up some stuff, and make easy to build (Engine is completely in C++, for a good reason. Prizm headers and the lack of libc++ and such require extra patchwork). [/list]

I'd love to create some simple 3D games with that engine you've ported/made any firm benchmarks on speed versus number of polygons/textures/lighting effects?

Not yet. I am hoping to thoroughly test the speed with an actual game. Also note that the fps depends on how much is drawn to the LCD. The less drawn on the LCD, the faster. One large triangle will be slower than a whole bunch of tiny triangles.

A tanks game would definitely stress it. I might make that.

Checkers will be the game of choice here. Just decided to mention it here as well as.

I found an open-source checkers engine that should work on the prizm, so woo!

By the way, I love the idea of some version of Blockdude in 3D after the checkers game. Blockdude was a great TI-83+ game, and the Nspire guys seemed thrilled to get a nice Lua version working in 2D. A color 3D version on the Prizm would be quite the interesting breakthrough, imho.

1) A 4D Rubiks hypercube/tesserract would be awesome (Find a tutorial video about it).

2) A 3D maze, but REALLY 3D (e.g. inside a cube, with each room being a cube with up to 6 directions to move; not just a flat maze with a 3D view). As for rendering, you could do it recursively by rendering just the adjacent rooms, which are rendered in turn by first rendering THEIR adjacent rooms, etc. For each room, you'd keep track of "direction", so that if you can see into the room to the "left", then you only render the rooms branch off of it to the (every direction except to the right). At each level, you eliminate directions, so that if you are rendering a room which was "above" the room to your "left", then you never look at rooms "below" from that point. Etc. This will work no matter what the view angle, and will quickly only render rooms that you might be able to "see". ... If you are ambitious, you can later think of a 4D version which only shows 3D cross-sections at a time, but allows you to rotate around all 4 axiis

3) Make a program which connects locationless rooms to each other and renders them (using a similar recursive technique to the one I mentioned for the 3D maze) AS IF they were adjacent. Rooms would be connected by storing a list per room, such that if there is no connecting room, draw a wall; else render the room referred to through where the wall WOULD be. You can connect rooms in way that are geometrically impossible, but visually seamless ... I did something like that here: PolygonMap.jar (if it doesn't work, try running it again until it does ... sometimes it gets an erroneous setup to start with. Use the number keys or SPACE to get a new room. I can tell you how to input numbers directly to create a new map on the fly if you like. This program uses polygonal rooms for ease).

Descent. I would love you forever (once I got a Prizm).

1) I thought about that but not a 4D cube. I will look at what it is later.

2) I don't quite follow. Do you have an example (image,vid, etc.) of this?

3) If you mean make Portal for the Prizm, I can do that RTT isn't hard. The hard part would be making that happen as a game. (I know what you are saying, portals are basically what the effect will be)

Be aware that anything that draws full screen will render slowly. This is because the Fragment Shader calls plot(x,y,color); on every point on a triangle. If you look at the texture example, stuff starts to slow down when I get close to the texture as there are a lot of points changing. Doing stuff in a room will get very slow as this engine isn't optimized for that. Sure, I can make those close-up textures very low quality and speed it up, but that would be sketchy.

I second this, by the way. I can think of a number of rather fun games that should require minimal polygon counts yet still look moderately impressive.

What would you see as a fair test? Make a cube at 1/2 screen size, then subsurf it to find out the relation of triangles to fps?

Here is an image of the checkers game rendering at full quality and 260 triangles, somewhat low fps, but not an issue as it is just waiting on key input. Shouldn't subtract at all from playability.



Yes, I notice that the board's texture is messed up. I have the texture wrapping around 8 times and it loses precision. Also, the blue square in the cursor. A green square will be the selected tile.

Neat! How long of a framerate? The board is one poly; the 260 are from the checkers, right? It looks like the pieces are octagons, so that should be 2 triangles per edge for 8 edges, 8 per face, for 8+8+16=32 per checker. I count 24 checkers, which is 768 triangles. What did I miss?

This engine renders only in triangles, lines, and dots. The board is 2, there were 32 chips (not in that screenie), each having 8 triangles, plus the selection square, 2 = 260. I don't know what you have 2 triangles per edge unless you want double sided chips, which I don't do.

Also, the framerate is about 3 FPS. And thanks!

Edit: I have tile selection drawing done as well as spinning the board at the end of turn. Now to actually add in checkers game code.

Very impressive! This is really neat stuff!

Can't wait for it to come out. As a suggestion how about seeing if you could have controls to spin it during your turn so you can get an idea to what the opponent might do if you move somewhere.

Will do!

Awsome!! I thought of the idea because of some 3d chess games have it so you can twist it to look at different perspectives.

It would be cool to have a Pocket Tanks game(some is 3D).

I am keeping this thread open for more talk on 3D games for the prizm. For the Checkers game, see this topic.

*subliminal messenging: Descent* The original ran on a 386 (33MHz) or 486 (66MHz) with a fully 3d software renderer.

Descent II also ran on a 486, and both are now open source.

Correct me if I am wrong, but doesn't the 3/486 have an FPU?