Omnimaga
Calculator Community => TI Calculators => ASM => Topic started by: Matrefeytontias on April 27, 2014, 08:16:43 pm
-
So yeah. I was wandering in WikiTI's Experiments page, section 3D engine, and went trough different links to see which ones included source (you know, documentation and all). I had heard about qarnos's Aether3D but in some way I never got my hand on it or anything related to it.
Until I found an actual download (http://darrencubitt.googlepages.com/release-2008-06-01.zip). The zip doesn't contain the lib's source unfortunately, but the lib itself has been compiled into a flash app accessible via the same mecanism that I use with PageSwap (mapping the app to bank A and stuff). Taking a look at the readme (an amazing readme, you should see it), I realized how awesome it was, and how close to OpenGL it actually was O.O (scaled down to z80 calcs of course).
So it has pretty much anything one could expect from a 3D engine : rotations, camera handling, matrices, quaternions, model-loading automagic, arbitrary polygon-filling (any number of points), proper 3D clipping, all that stuff.
So I'm not doing it right now since it's 2:15 am, but I'm pretty sure it would be worth it to dive into it a bit (the zip includes an example and some models to play with), but I guess it'll be hard since the latest (understand : 2008) source is non-available.
Just pointing out.
-
Oh wow I remember that engine. It was a shame that it was never completed. He posted a vid on Youtube and when I asked if it was dead he said he felt the community was dying and he wasn't very motivated to work on it.
The only thing: When he said that in 2010-11 I don't think he was aware that calc sites other than MaxCoderz and Ticalc.org actually existed, since back then Omni had record high activity. Had he known back then, maybe he would have still worked on it?
-
Well I don't know for sure. I read in the MaxCoderz thread that he worked on it since 2001 (which is a pretty long time if you ask me) ; so I guess the only thing we can really do is send him an email asking for the source (I would like to at least, because I'm quite fascinated by this piece of work). Though I have a bad experience of asking insistantly for a source code (sorry about that calc84maniac ._. ).
-
It is an amazing engine and i do think that qarnos did leave a copy of some source code with maxcoderz ... However i dont think its the source to the app lib, but code to some earlier tests. I used to talk regularly with qarnos about 3D when i was making my own engine.
He also has a really nice 2D library as well.
-
Wow, that sounds amazing!
-
Wow O.O how I missed that...
-
Well, probably because it has been started 13 years ago and abandonned 5 years ago.
-
I wouldnt say that it was missed, this project obviously generated a large amount of attention when it was active. The only issue is that so many 3D projects end up being abandoned :(.
-
I guess that's because of the many difficulties due to working with 3D at all. Having tried, I think of 3D as a powerful but extremely hard-to-use tool when it comes to calculator programming <_<
-
I guess that's because of the many difficulties due to working with 3D at all. Having tried, I think of 3D as a powerful but an underpowered and extremely hard-to-use tool when it comes to calculator programming <_<
FTFY.
At least, it's the unfortunate truth when it comes to polygon 3D. Pseudo-3D rendering techniques like raycasting, and perhaps mode 7, have potential.
-
Hum.
(http://www.benryves.com/images/nostromo/bsp/2010.11.28/Walkthrough.gif)
I call that powerful, even if it's Nostromo by benryves and not Aether3D by qarnos.
-
Hum.
(http://www.benryves.com/images/nostromo/bsp/2010.11.28/Walkthrough.gif)
I call that powerful, even if it's Nostromo by benryves and not Aether3D by qarnos.
That's definitely one of the best examples of 3D quality/performance on an 83+/84+, and I think it had huge potential to become a full game. Although more complex than raycasting and mode 7, it still uses shortcuts to avoid full polygon 3D. And comparing it to any platform that isn't a calculator, the truth is it's awfully plain and slow. I don't have much faith in a full polygon 3D game for the 83+/84+, but I still believe in the capability of engines like this that take intelligent shortcuts.
-
Hum.
(http://www.benryves.com/images/nostromo/bsp/2010.11.28/Walkthrough.gif)
I call that powerful, even if it's Nostromo by benryves and not Aether3D by qarnos.
Wow, that is pretty awesome O.O
-
So many of these 3D engines for the z80 calcs are not completed, and are mostly dead. So sad.
-
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, in my opinion that's pretty much everything that can achieve decent speed, I mean an engine unusable outside of its particular context. But it can be done.
-
Well, when you look at all the engines out there, they nom all the CPU leaving few room for the actual game. :P I've never seen a game made for these engines.
-
What do you mean "all the engines out there" ?
-
What do you mean "all the engines out there" ?
What do you mean 'What do you mean "all the engines out there" ?' ? :P
Even just you have at least 4 engines :P
(like full Axe, full ASM, full vertices and full faces or something)
-
You've just been pwned. :P
-
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 (http://www.omnimaga.org/ti-z80-calculator-projects/(axe)-glib-tuto/msg371822/#msg371822), 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.
-
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.
-
What do you mean "all the engines out there" ?
What do you mean 'What do you mean "all the engines out there" ?' ? :P
Even just you have at least 4 engines :P
(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. :P
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.
-
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.
Or make a library which only include basic function, and let the user do what he wants to do. (Cause some function must be there, like projection or such).
-
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:
(http://img.ourl.ca/polytest50.gif)
(http://img.ourl.ca/sfdemo1.gif)
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).
-
Does that use gray scale ? O.O It looks totally awesome. :D
-
Yay! tr1p1ea hasn't forgotten about the xwing game!
-
I wonder if a 3D remake of Illusiat 3 would be possible? Dungeons were pretty simple in the original version.
-
I wonder if tr1p1ea will finish the xwing game
-
IIRC he still plans to finish what he posted above, but for now he is working on xLIBC features and I believe he also had a Mode 7 engine for the CSE.
-
Any progress on your engine?
-
Not so far. I've been working mostly on Worms and nKaruga these days, but I use to alternate every now and then.