Page 1 of 22

Progress Thread - New demo - Cobra Mk III (18-May-08)

Posted: Thu 01 Dec, 2005 9:25 am
by qarnos
Hello everyone!

After posting some of this stuff to the A83 mailing list I received an e-mail from one of your members asking me to get involved in this forum.

I have been working on a realtime 3D engine for Z80-based systems, mainly targeted at the Z80-based TI calculators, but designed to be easily adapted to almost any system.

I started this project originally in 2001, but then had a few years off from the Z80, only to resurrect it whilst browsing through my old files a few months ago (I caught the bug again!).

The aim of the project is twofold. First, I wanted a "real" 3D engine with support for all the basic tools required to make a useful game. Second, it needed to be very fast, with a goal of rendering a useful amount of objects at 15-20 fps. As a result, the engine always trades off size and accuracy for speed.

As it stands right now, the engine currently supports:
* arbitrary rendering windows of any size and position on screen.
* 7-bit 3x3 matrix transformations, with optional 16-bit translations to allow objects to exist in a 16-bit worldspace.
* some basic quaternion routines, which really need some work.
* 3D clipping support for line / wireframe objects. It can be used for polygons but the results aren't correct in some situations.
* Patterned polygon rendering, which is actually not as slow as I thought it would be.
* A whole slew of mathematical support routines, mainly covering a variety of fast (130 T-States) 8-bit multiplication routines and some reasonably fast 8 & 16 bit division.

At the moment it can render a solid 3D cube at ~25 fps and a medium-level wireframe (~20 points and lines) at ~28 fps.

I have a recent-ish demo (source only) available at http://home.iprimus.com.au/qarnos/aldemo.zip, but it was written for the TI-83+ with ION/MirageOS ONLY. I have since modified it to natively support the TI-86.

Anyway, like I keep telling everyone, I'm not going to garuntee I will every actually finish it (I started it in 2001!) but I would appreciate comments/feedback.

I finish work for the year in just over 2 weeks, so hopefully I can dedicate some time to it over the Christmas break.

Posted: Thu 01 Dec, 2005 9:52 am
by kv83
Sounds very, very nice. How 'bout a nice PTI Screenshot :D

Or a 8xp would be appreciated aswell (man... I'm sooooo lazy) :)

Posted: Thu 01 Dec, 2005 10:09 am
by CoBB
It runs quite smoothly.

http://www.hszk.bme.hu/~pg429/misc/cube83p.gif

By the way, TASM gives two errors, because the strings 'Invalid screen co-ordinates' and 'clipping overflow' are too long.

Posted: Thu 01 Dec, 2005 10:11 am
by BetaSword
Question: Does it require lots of painful math to create something, or do you have another sort of setup to create models and such?

Posted: Thu 01 Dec, 2005 10:32 am
by qarnos
CoBB wrote:It runs quite smoothly.

http://www.hszk.bme.hu/~pg429/misc/cube83p.gif

By the way, TASM gives two errors, because the strings 'Invalid screen co-ordinates' and 'clipping overflow' are too long.
Thanks for that. I must have some kind of error checking disabled, since I don't get those. But I had noticed that the 15th character in each string was missing when displayed. Now I know why.

Posted: Thu 01 Dec, 2005 10:36 am
by qarnos
BetaSword wrote:Question: Does it require lots of painful math to create something, or do you have another sort of setup to create models and such?
Nah, it's really quite simple. You just define an abject as a series of XYZ points, such as:

.db -64, -64, 0 ; define a square
.db -64, 64, 0
.db 64, 64, 0
.db 64, -64, 0

The range of each XYZ value is limited to -64..+64 due to the multiplication method used by the matrix routines, but it is fast - the raw multiplication time is 38 T-States.

Lines and polygons are defined in a similar way. For instance, the square above could be defined as a polygon using:

.db 0, 1, 2, 3

Which basically says, connect point 0 to point 1, point 1 to point 2, point 2 to point 3 and point 3 loops back to point 0.

The exact method you use depends on how you utilise the engine, but you get the general idea.

Posted: Thu 01 Dec, 2005 11:24 am
by benryves
Best of luck with this project... nice to see polygon filling now :)

EDIT: How are you dealing with depth-ordering pixels? A square is usually a nasty shape to draw if you only sort the entire polygon's depth... and I'd have thought per-pixel to be too slow/memory intensive.

Posted: Thu 01 Dec, 2005 12:04 pm
by tr1p1ea
Hey qarnos, welcome to the forums! (it was me who emailed you :)).

You seem like quite an accomplished coder, this is a very impressive project. Do you have any cool game ideas in mind?

Posted: Thu 01 Dec, 2005 1:25 pm
by dysfunction
This is extremely impressive! I love when great coders just show up, and suddenly the community has another excellent coder out of the blue!

Posted: Thu 01 Dec, 2005 3:29 pm
by Timendus
Pretty impressive... I'm curious how it will run a real map though.

Posted: Thu 01 Dec, 2005 8:10 pm
by axcho
How does it store and draw the patterns? Are they bitmaps? Could you make it use cellular automata to generate textures also?

Posted: Thu 01 Dec, 2005 8:19 pm
by qarnos
benryves wrote:Best of luck with this project... nice to see polygon filling now :)

EDIT: How are you dealing with depth-ordering pixels? A square is usually a nasty shape to draw if you only sort the entire polygon's depth... and I'd have thought per-pixel to be too slow/memory intensive.
Thanks, Ben. Although I didn't end up using your triangle code, it did set off a spark in my head about how to do polygons.

As for depth sorting, the engine doesn't do that yet. The cube demo just using back-face culling. It turns out that for closed convex polyhedra, such as a cube, back-face culling is sufficient, since the remaining polygons can't possibly overlap/intersect. If you take a look at an old 3D game such as Elite, you will notice that all the spacecraft are also closed and convex. It just makes life easier!

I would like to add some kind of depth sorting. I have been thinking of trying to implement some kind of BSP tree type system. There are several ways I could simplify it in order to make it workable on a Z80, it's just a question of whether the simplified version would actually be useful.

It will definitely be an interesting challenge!

Posted: Thu 01 Dec, 2005 8:46 pm
by threefingeredguy
What kind of buffering would you use? Z buffering? 1/z buffering? Painter's Algorithm? Visible-pixel buffering?

Posted: Thu 01 Dec, 2005 9:50 pm
by CoBB
I'm inclined to think that at the amounts you can render at a decent speed even a plain bubble sort could perform fairly well.

Posted: Thu 01 Dec, 2005 10:04 pm
by Timendus
I guess it's time for a sorting contest judged by speed :)

Why do I feel like I really need to brush up on 3D rendering techniques every time I read one of these topics? :P