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

[Spengo]

Wowz, 9-20 fps! that ain't half bad at all. Filled polygons and everything. Very well done.

[benryves]

Wow, this looks fantastic

Full BSP, you say? Even better. I can't wait to test on hardware.

[qarnos]

Wow, that works blazing fast on my 84+SE, absolutely incredible!

The sorting and object intersection is probably the most impressive aspect of this engine so far. I also noticed that the polygon clipping still doesnt always clip right at the edge, but i guess its no big deal.

Thanks! You're all too kind!

The intersecting cross thing is actually 3 polygons. From the initial orientation, the horizontal one is one poly, but the verticle one is two polys split by the horizontal one. This is the way BSP trees handle it and the only way to draw that kind of object when doing a painters draw.

As for the clipping, there is nothing I can really do about that when the polygons are intersecting the near plane (which is the main problem). The edges of the screen are sometimes out by 1 or 2 pixels - I might be able to fix that but it would more than likely result in trying to draw off the screen and general badness will quickly follow.

[tr1p1ea]

Eh like i said its no big deal, and now that i re-read earlier posts you're right about it not being noticable anyways.

[CompWiz]

I also got a bug...after exiting the program Mirage was telling me that all my programs were 0 bytes big. Once you leave mirage and return everything is back to normal.

Hmm, well maybe if you were using a better Shell... [cough]crunchy[/cough]

Wow, that looks great. I can't wait to try it out on my 84+SE and 83+. In fact, maybe if I install the link cable I have with me on my work computer, I could try it out right now(of course, I always have my 84+SE along, and my 83+ is in my backpack, next to me). Good think I hacked myself admin status a little while ago.

[chickendude]

Why is CrunchyOS so much better? Or even, what's different about it? Isn't it also created by Detached Solutions crew?

[coelurus]

CrunchyOS, by our own DWedit.

Good stuff, simply put

What makes me surprised is that I figured I have always erronously and strictly regarded BSPs to be too much for the calc... I thought it once and it stuck (I happen to be very stubborn and lazy). Ah well, I hope now you're gonna try a 2D BSP for Nostromo Ben

[CompWiz]

CrunchyOS is a shell that can run Mirage, Ion, Asm, and basic games. It also supports compressed games, so you can fit more games into your calculator's memory, and use them normally with CrunchyOS. Also, unlike Mirage, Crunchy does not move the program out of the archive and into the ram, and then back, every time you run the program. Instead, it makes a copy of the program in the ram, and when you exit, it puts any changes(savegames, highscores) back into the archived program with patches. The archive has a limited lifespan, a certain number of reads and writes it can do before it stops working. CrunchyOS's method of running programs causes a lot less wear and tear on the archive. Also, it requires far fewer garbage collects. Back when I was using Mirage, programs sometimes had to garbage collect every time they ran, and sometimes didn't even fit back into the archive. Now that I have CrunchyOS, I don't even remember the last garbage collect that I've had to do. Another nice benifit from this, is that since the original program is still in the archive while you are running it, it is safe. If it crashes, the program is safe from harm in the archive, and will not be corrupted. I remember back when I used mirage, ztris would commonly get corrupted.

Since you are new to the forum, you haven't seen that I am a staunch supporter of Crunchy. In fact, once someone asked me to stop promoting it so much. But, since you asked so nicely...

[qarnos]

CrunchyOS, by our own DWedit.

Good stuff, simply put

What makes me surprised is that I figured I have always erronously and strictly regarded BSPs to be too much for the calc... I thought it once and it stuck (I happen to be very stubborn and lazy). Ah well, I hope now you're gonna try a 2D BSP for Nostromo Ben

The BSP code surprised me, too. I investigated a whole lot of ways of shortcutting it before I decided to just do the real thing, and I'm very happy with it.

The key is in how I solve the plane equation. I can do very fast multiplication of 0.6 fixed point numbers, so I like to use that whenever possible. The plane normal is 0.6 to begin with but, unfortunately, the vector to the camera from object space is 16 bits.

I got around this by shifting the camera vector until it was 6 bits and then diving the D component of the plane equation by the same amount (actually, I calculate a reciprocal and then multiply by that).

So when I get to each BSP node I have the camera vector as a 0.6 fixed point and the reciprocal. Then I just do a dot product, multiply D by the reciprocal, subtract it and viola!

I haven't count the T-States, but the time spent on each BSP node (not counting the rendering) would not be much more than about 450 T-States. That's ~13000 nodes per second at 6Mhz and ~33000 at 15Mhz.

You could argue that a plain old bubble-sort of the polygon Z values would be faster in most situations but, as you probably are aware, Z sorting is not always the most reliable solution.

Anyway, one of the big changes is this demo, which isn't obvious, is I have shifted to a generic model structure for the rendering (the cubes were hard-coded).

I am still trying to finalize a few things - I would like to be able to specify several objects of different detail levels and have the engine select the appropriate one based on Z distance - but I have a reasonable idea of where I am going.

If anyone would be interested in writing a program to convert some of the more popular 3D formats to this format, that would be a huge help. If there is any interested I will write up the format and post it withing the next week or so.

[coelurus]

Z-sorting is bad, yes. What I don't like with BSP trees though are the splits, they will introduce quite a lot of data with larger objects (such as entire maps).

Unless anybody else wants to write a converter, I might. I'm _very_ busy, but I need some variation in my programming life
Do you have support for tri-fans/-strips?

[tr1p1ea]

DXF files are extremely easy to parse, i worte a converter so i could import them into Flash. Shouldnt be too hard to modify.

[qarnos]

Z-sorting is bad, yes. What I don't like with BSP trees though are the splits, they will introduce quite a lot of data with larger objects (such as entire maps).

The number of splits depends on how balaned you want the tree. In the demo, the tree is highly unbalanced - almost all nodes branch to the left with nothing on the right - but this allows only one split instead of three.

There is quite a bit of overhead when rendering polygons, in calculating the edge gradients, so keeping splits to a minimum is much more vital than having a balanced tree. There is no real time penalty for unbalanced trees, but it means the recursion will run deeper, so for a complex object there might be a chance of stack overflow, but I doubt that objects of such complexity would actually be used in this engine.

And, as I have said before, this engine isn't really designed for an FPS. It might be possible on an 83+SE/84+ in high speed mode, but I don't really care for FPSs anyway, so I'm not worrying about it

Unless anybody else wants to write a converter, I might. I'm _very_ busy, but I need some variation in my programming life Smile
Do you have support for tri-fans/-strips?

No, I am keeping it simple. A plain vertex list with connectivity information for lines/polygons.

DXF files are extremely easy to parse, i worte a converter so i could import them into Flash. Shouldnt be too hard to modify.

I haven't really looked at too many formats. .ASC files from 3D studio seem to be fairly standard, but they also seem to only deal in triangles (what is everybodys fascination with triangles?). Wavefront .OBJ files are also very simple, as I have recently discovered. I have been impressed by Wings 3D, so one of the export formats it supports would be a good starting point.

What I may do is create a program to generate all the required data for the 3D engine from a specified input format, and then others can write converters for whichever format I choose as the input format.

If you use piping to send data from one program to another, it would an elegant solution.

The main pain in the butt will be the BSP trees. The code to produce an optimal tree for my engine would be fairly complex, and it would be silly to reproduce that in every converter, which is why I am leaning towards that solution.

I have one question for you, though, which has been bugging me... How do you pronounce "tr1p1ea"?

[coelurus]

Fans/strips could be used to cache filling information, for example the expensive gradients. But ok, you wanted to keep it simple, for now...
Obj is a good choice for a general format, since pretty much any modeler can export to that.
Triangles are good because they are always planar. It's harder (impossible really) to determine how to split non-planar n-gons, n > 3, to give the effect artists want, while it is not impossible to merge adjacent planar tris.

As the plugin-junkie I am, what about making a master program and write plugins that parses data to some independent storage?

[anykey]

I feel stupid that I look at this thread to see if anybody has put any new screens up
good work.

[benryves]

Writing output plugins for Milkshape 3D (super-cheap low-poly model editor) is trivial, and it supports a bazillion (rough estimate) input formats. I've used it in the past for converting Quake 3 and DOOM3 meshes to one of my own 'custom' formats. Might be worth a gander?

I finally tried the demo program on my calculator - it's obscene how fast it runs, even on my crummy old 83+. Well done!