Well, when you look at all the engines out there, they nom all the CPU leaving few room for the actual game. I've never seen a game made for these engines.

What do you mean "all the engines out there" ?

What do you mean 'What do you mean "all the engines out there" ?' ?
Even just you have at least 4 engines
(like full Axe, full ASM, full vertices and full faces or something)

I don't think a 3D engine like what's being made for console and PC games is something that should be done on calcs for more than trying to push them to their limits etc. Rather, I agree with Runer that a hybrid engine optimized for a game in particular is better.

Well, I'm pretty sure that actual 3D games on calculators are possible. You do indeed use a lot of CPU on the 3D, but so does grayscale, and there are some very good grayscale games out there.
Besides, the resolution of the calculator is a big help for this as well. The low resolution improves the speed of the vector graphics (since not a lot of pixels need to be drawn then), and the monocrome graphics make it possible to cheat with the visibility in ways that just wouldn't work well with colors.

A few tricks to speed up the rendering:
 - You can avoid a lot of Z-ordering by dividing your level in the correct segments and rendering them in the correct order depending on which sector you're in (which can be predefined instead of calculated on the fly) You can even completely skip the sectors that are invisible (read: behind walls) if you do this.
 - You should not fill polygons that don't have anything behind them (or if they will only be drawn on something that has a plain white background). Just draw the outlines and you're fine. In combination with the previous technique, you also don't have to fill objects that only have sectors behind them that are hidden from your current point of view)
 - You can further avoid filling and Z-ordering for objects using a wireframe model by checking the camera position relative to the model and only draw the sides of the model that are facing the camera.
 - Finally, limit the complexity. Complex levels with lots of vertices and edges are quite slow to render, and doing collision checking on them can be a nightmare. Besides, because of the low resolution, a simple level looks much cleaner and clearer anyway. Also, limit the textures. While textures can look nice,they slow down the rendering a lot, and level can also look good with only a few textures (see the nostromo screenshot above). Besides, having a lot of textures can make it hard to see stuff in front of it (I often have this problem with raycasters).
I don't really have enough stuff yet to test the first technique, but I've tested the final two in testcases, and they seem to work really well.
The collision library I'm working on will probably showcase those three techniques as well.
Even though you're right that 3D for calculators always has to be optimized a bit for each game. If you just want to feed the engine a big, unoptimized world and expect it to do everything for you, it has to be a huge engine that will probably be quite slow as well.
And I think this is what made a lot of 3D projects die: While the calculator is able to handle it well, when you want to do anything more complicated than a 3D tunnel game, the level design can be a real nightmare, especially compared to a simple tilemap. This immediately makes most 3D projects rather big projects, and unfortunately, in the calculator community, big projects tend to easily die.

Quote from: Matrefeytontias on April 29, 2014, 02:52:35 pm

What do you mean "all the engines out there" ?

What do you mean 'What do you mean "all the engines out there" ?' ?
Even just you have at least 4 engines
(like full Axe, full ASM, full vertices and full faces or something)

Hum it's quite a compliment from you to call these "engines" (Vertex3Dlib, ThreeDee, AxeJh3D and AxVectors respectively). They are more like sets of functions (actually like the original Juha3D).

You've just been pwned.

Ooooow yeah, dat useful post.

ben_g : what I wondered a lot was : "is detecting occlusion slower than the actual stupid drawing ?" and it appeared to be a good question.

Actually what I was saying is that instead of trying to make a full fledged engine, a per game optimized engine is better because smaller and faster since it only has the features you need and it's part of your code, not a library.

I agree.

Not to hijack this thread but 3D games are possible on calc. I have a few demos of my own that have a fair bit of stuff in them like basic AI and collisions etc:





Not sure if you can tell whats going on, but it just flying around shooting the objects. Only the xwing moves in the interactive demo, but thats just because the others are being told to stay still.

Aether3D was possibly the best engine performance wise, it could render complex objects at very good frame rates.

But ben is right, you need to be considerate with level design. Thats why i chose a spacesim since you dont need an environment beside some stars and planet sprites. Not saying that i will guarantee that ill finish, but i planned on having a max of 6 objects (like a broken freighter to protect, 1 wingman and waves of 3 enemies to destroy for example).

Yay! tr1p1ea hasn't forgotten about the xwing game!

I wonder if tr1p1ea will finish the xwing game