MaxCoderz

calcul831415 wrote:Will you be able to rotate the screen around the 3D model?

Are you talking about being able to view a 3D world fom any particilar viewpoint? If so, then yes. I just need to write the code to create a "camera matrix", which is a matrix which allows you to transform a 3D world to how it would look from any point of view. It's not that hard to write - I'm just getting lazy!

currahee wrote:I wonder though if it can handle more geometry or a true 3D environment, not like Gemini but y'know like Quake.

Well, it is "true 3D", since it allows a full 6 degrees of freedom. But if you are looking for Quake83, well... I wont say it is impossible, but you would be struggling for a decent framerate. This engine is designed for 3D space/aircraft & perhaps car racing kinda stuff.

coelurus wrote:With software rendering, overdraw should be extremely low. I would like to hear your ideas about your simplified version.

Well, the simpification wasn't in the algorithm itself, but the implementation.

My idea was to restrict the BSP planes to running either along, or diagonally across the X, Y & Z planes of the 3D world. That way, I could reduce each plane test to a comparison of X, Y & Z co-ordinates, instead of doing a dot-product. The dot-product code is fairly fast (around 300 T-Sates IIRC), but I wouldn't want to use it as intensively as in a BSP tree algorithm.

Kozak wrote:The speed at which it applies polygon filling looks impressive. I am looking forward to see more extensive screenfilling performed by your engine qarnos.

Thanks. The polygon code isn't perfect (ie: the polygons aren't quite "correct"), but I have been toying with a new idea which should eliminate these flaws and result in an improvement in polygon rendering speed, but a slight time penalty for anyone who was thinking of attempting grayscale polygons (it involves shifting some of the code from the edge tracing routine in to the actual drawing routine).

I will probably go ahead with the idea, since grayscale isn't one of my prime objectives.

Restricting planes in a BSP to be axis aligned is a major modification to the algorithm It becomes more of a loose octree (or ABT) which is polygon- instead of space-based.

Anyway, my main interest for a Z80 3D game has always been a Descent clone (an idea I have kinda dropped), the questions in my last post was biased towards that. A Space Dementia clone is more than possible on TI83s, I personally wonder why the high-range calcs haven't gone any further.

Good thing you skip grayscale, 3D involves a lot of moving pixels and grayscale would make things real fuzzy.

hmmm...compared to something like fat on the 68ks...how well would this lend its self to ease of game making

The less difference you want between games, the easier it can be made...

This and FAT is entirely different. That's an "apples to oranges" comparison. This is 3D rendering and FAT is raycasting.

Do you think 3D multi-calc first person shooters are possible with this? or would it just be too slow?

I know their diffrent...I was talking about speed and number of posible images/objects at a time...

or in other words...could I make a shooter out of this, and if so, how easily

A question regarding the speed: I know that there are ways for ASM programs to take advantage of the SE's 15 mhz (I remember the 15 mhz version of Gemini that ran almost too fast). Would that make any difference in the speed of this, possibly allowing for more complex scenes at better framerates?

necro wrote:I know their diffrent...I was talking about speed and number of posible images/objects at a time...

or in other words...could I make a shooter out of this, and if so, how easily

calcul831415 wrote:Do you think 3D multi-calc first person shooters are possible with this? or would it just be too slow?

I wouldn't really want to be the one to try to make an FPS out of this. It isn't really designed for that purpose. It would certainly be slow, but that's only one of the problems you would have to ovecome!

BetaSword wrote:A question regarding the speed: I know that there are ways for ASM programs to take advantage of the SE's 15 mhz (I remember the 15 mhz version of Gemini that ran almost too fast). Would that make any difference in the speed of this, possibly allowing for more complex scenes at better framerates?

Extra clock speed will always help. One big bottleneck on the 83 is the LCD driver - it is very slow. In the cube demo, over 25% of the time spent on each frame is spent sending data to the LCD. I'm not sure what the deal is with the LCD driver on the SE calcs, so it may be a limitng factor.

But if the LCD driver also runs at a higher speed, then it would not be unreasonable to expect a framerate 2 - 2.5 times higher on the SE for any given scene.

I have made a couple of minor improvements to the engine and thought I'd put out the classic "bouncing cubes" demo.

The framerate is still reasonable enough given the increase in complexity.

TI-83+ version: http://home.iprimus.com.au/qarnos/democube.8xp
TI-86 version: http://home.iprimus.com.au/qarnos/democube.86p

The 83+ version requires ION/MirageOS. The 86 version requires no shell. My experience with the 86 is limited, so standard disclaimers apply. Also, the 86 version has no framerate counter. It runs quite a bit faster though thanks to the memory mapped LCD.

Could someone make a screenshot of that again? I'm at my parent's place and my laptop crashed at home, so I can't access it anymore Which means no compiler, no emulator, and no files at my disposal untill I get back home...

This is very impressive! You have easily surpassed the monocromatic 2 demo already. I'm looking forward to seeing polygon clipping, something essential to making this engine really useful.

There you are:

Wow!

Sweet! That'd make a great screensaver

Watch out ticalc!