GP2X 3d Engine Demonstration Challenge

[timbobsteve]

Is there any word on that sdgl or Vincel GL ?

I am pretty new to programming and it would be nice to have a library to work with if I am going to try 3D stuff.

Anyways... I love that there are people working on 3D. For now I might try and just finish a single 2D game

 

[Dzz]

Despite friendly rivalries, I think we can talk about what techniques are likely to be good ideas. Which do you guys think is a better approach: sorting polygons back-to-front and drawing them in the proper order or using a z-buffer?

Is there some other better way to make sure that the right pixels get drawn when polygons overlap?

 

[rixed]

Which do you guys think is a better approach: sorting polygons back-to-front and drawing them in the proper order or using a z-buffer?

Is there some other better way to make sure that the right pixels get drawn when polygons overlap?

Depends on what you plan to do.
The problem with rendering engine is that you can not target all types of 3d scenes.

For a purely general renderer, there are no alternative to zbuffer (the variant that is seldom used and which is called s-buffer(*), can be a good replacement but certainly not for the general case). Anyway, such a purely general renderer would be very slow.

The other familly of techniques, are the variants of the painter algorithm. But sorting facets is not enought in the general case : what you consider to be the center of a given facet can be below the center of another, yet some of its pixels beeing above. Another aproach that I like is to divide all the geometry into convex objects, and then sort those.

The third familly of techniques is of course BSP/portals algorithms. Priceless for simple geometry with a lot of occlusion, they are not very usefull to handle small and complex objects.

The idea that Im trying to push is that there is no good technique but the combination of all, for distinct part of the rendering. Large surfaces with BSP, complex objects rendered from the farthest to the closest, single detailed object with a zbuffer to avoid visual oddities...


(*): The idea behind the s-buffer is to represent each scan-line by a sorted list of intercrossing segments.

 

[slygamer]

Which do you guys think is a better approach: sorting polygons back-to-front and drawing them in the proper order or using a z-buffer?

Is there some other better way to make sure that the right pixels get drawn when polygons overlap?

Using a z-buffer could incur many cache misses if the z-buffer was in cached memory since the 940T has a small cache and the pixels you may be testing against could anywhere within that z-buffer for each polygon drawn.

I think the painter's algorithm would work best as a general solution. Ideally you would have to make sure that no polygons intersect to avoid rendering artifacts.

 

[rixed]

Actually, many times when polygons intersect they should not, and that's an inconvenient of the z-buffer that such intersections become visible. With a painter-algorithm, no matter if the hand of your main character ends behind the wall : you won't see its fingers clipped by the wall, which is better for the eyes.

Approximations in the rendering stage can hide approximations of the computing stage.

 

[Dzz]

Ok, it doesn't really count because it's not texture mapped yet but I had to get my hat in the ring.

http://gp2xgamer.com/demo3d1.gpe

You can zoom with the volume +/- keys. It's just flat shaded so far but it's a start!

 

[MadDog]

Ok at it doesn't really count because it's not texture mapped yet but I had to get my hat in the ring.

http://gp2xgamer.com/demo3d1.gpe

You can zoom with the volume +/- keys. It's just flat shaded so far but it's a start!

Nice, and the exec is so small, something I need to deal with in mine. I got mine running the the 940 over the weekend but the 3d is bust. I was going to do the T&L on the 940 as well but decided that it may simplify/load balance things better if the T&L is on the 920 and the 940 is just a raster monkey.

Is any of this on the 940? If so, are you waiting for the vsync on the 940?

 

[Dzz]

Ok at it doesn't really count because it's not texture mapped yet but I had to get my hat in the ring.

http://gp2xgamer.com/demo3d1.gpe

You can zoom with the volume +/- keys. It's just flat shaded so far but it's a start!

Nice, and the exec is so small, something I need to deal with in mine. I got mine running the the 940 over the weekend but the 3d is bust. I was going to do the T&L on the 940 as well but decided that it may simplify/load balance things better if the T&L is on the 920 and the 940 is just a raster monkey.

Is any of this on the 940? If so, are you waiting for the vsync on the 940?

No, I am not using the 940 (yet). I am not certain which tasks to give it yet. I am leaning toward doing the T&L and rasterizer setup stuff on the 940. I am concerned that the smaller cache on the 940 will impact texture mapping performance in the rasterizer but want to do some measurements to see.

 

[satacoy]

Very slick! Is the time shown in 10ths of milliseconds like your demo coding examples? If so, that's impressively fast!

 

[Dzz]

Very slick! Is the time shown in 10ths of milliseconds like your demo coding examples? If so, that's impressively fast!

Yes, the time is in tenths of milliseconds but only for the 3D-related stuff (the geometry transformations and rendering). I decided not to include the time for clearing the screen, drawing debugging text, and so on, since it isn't relevant to the code I'm working on. With only about 5 or 6 triangles typically showing up in this demo the time for the geometry is barely noticeable. It is also very fast to render solid-color polygons. Interpolating the texture coordinates and then accessing the texture memory (possibly incurring a cache miss) will really slow things down.

 

[MadDog]

Very slick! Is the time shown in 10ths of milliseconds like your demo coding examples? If so, that's impressively fast!

Yes, the time is in tenths of milliseconds but only for the 3D-related stuff (the geometry transformations and rendering). I decided not to include the time for clearing the screen, drawing debugging text, and so on, since it isn't relevant to the code I'm working on. With only about 5 or 6 triangles typically showing up in this demo the time for the geometry is barely noticeable. It is also very fast to render solid-color polygons. Interpolating the texture coordinates and then accessing the texture memory (possibly incurring a cache miss) will really slow things down.

Have you thought about tiling the screen memory and texture memory? I have thought about it a bit, but yet to try it out. Some of the arm instructions look like they will help in generating the addresses, the shift option on the last param is real cool. But I don't know enough about the chip yet, could turn out the odd address calculation will negate any benifits. Four dwords (one cache line) would be a 4x4 screen block (for pallatised screen mode) and so is very attractive, what do you think Dzz?

 

[Dzz]

Have you thought about tiling the screen memory and texture memory? I have thought about it a bit, but yet to try it out. Some of the arm instructions look like they will help in generating the addresses, the shift option on the last param is real cool. But I don't know enough about the chip yet, could turn out the odd address calculation will negate any benifits. Four dwords (one cache line) would be a 4x4 screen block (for pallatised screen mode) and so is very attractive, what do you think Dzz?

Hmm, that's a really intriguing idea; my head hurts just thinking about whether it would be a net win. I think only testing will determine that for sure. I'm just starting to think about texture mapping myself so it will be a while before I consider trying such tricky things. My next task is to get the ability to import objects from some third party application. The ascii output from a program called Milkshape 3D looks pretty easy to parse. I got that program because it is cheap.

One thing I am convinced will help a LOT with performance is well-implemented mipmapping to help make sure that texture references during rasterization are "nearby" in the texture memory.

 

[Tobriand]

Out of interest (and from a non-coder's point of view) how much faster/slower would it be to make an engine that did not use textured but instead relied on high-poly models, with detail done with extra polys each of one colour, or a simple gradient, or some such?

Obvious examples... FF7 character models, and, possibly, the models in Warcraft III (not sure, but I got the impression that they didn't have much in the way of textures, just well designed models).

 

[MadDog]

Out of interest (and from a non-coder's point of view) how much faster/slower would it be to make an engine that did not use textured but instead relied on high-poly models, with detail done with extra polys each of one colour, or a simple gradient, or some such?

Obvious examples... FF7 character models, and, possibly, the models in Warcraft III (not sure, but I got the impression that they didn't have much in the way of textures, just well designed models).

Thats something i've thought about for a few years on many platforms. The main thing is the divide thats needed, I don't know too much about textured rendering, the code I have I 'nicked' of the net although I understand the idea behind it. If gouraud or other shading methods can be done with no divide then I can't see why not.
But then there maybe short cuts that would reduce the divide cost. But even then your still cutting down the memory bandwidth.

Would be a good test to see how many polys would == a 100 poly textured shape.

 

[rixed]

Out of interest (and from a non-coder's point of view) how much faster/slower would it be to make an engine that did not use textured but instead relied on high-poly models, with detail done with extra polys each of one colour, or a simple gradient, or some such?

This is not easy to compare both rendering : what tesselation is needed to have a gouraud shading looks as nice as a texture mapping ?

Also, this depends on what is rendered : some models badly needs textures (land, for exemple), while others do not (vehicules or other mechanical models).

I think a good strategy is to mix both technics (better a car with a flat round surface than a cube with car textures, on a plannar well textured road).

 

[MadDog]

Out of interest (and from a non-coder's point of view) how much faster/slower would it be to make an engine that did not use textured but instead relied on high-poly models, with detail done with extra polys each of one colour, or a simple gradient, or some such?

This is not easy to compare both rendering : what tesselation is needed to have a gouraud shading looks as nice as a texture mapping ?

Also, this depends on what is rendered : some models badly needs textures (land, for exemple), while others do not (vehicules or other mechanical models).

I think a good strategy is to mix both technics (better a car with a flat round surface than a cube with car textures, on a plannar well textured road).

Its funny but i've had this conversation so may times over the years, what you say is correct. I just think that it would be an intresting thing to try. Most all non textured 3d games that i've seen were on the old 16bit systems.
And a few on the old spectrum!!! But (ok going off topic) with a modern PC 3d card you could really crank up the high def.

There was a really good PC flight sim, had the A10 tank buster in it. That was almost all untextured and the higher screen res in software worked really well.

 

[hmw]

Have you thought about tiling the screen memory and texture memory? I have thought about it a bit, but yet to try it out. Some of the arm instructions look like they will help in generating the addresses, the shift option on the last param is real cool. But I don't know enough about the chip yet, could turn out the odd address calculation will negate any benifits. Four dwords (one cache line) would be a 4x4 screen block (for pallatised screen mode) and so is very attractive, what do you think Dzz?

Hmm, that's a really intriguing idea; my head hurts just thinking about whether it would be a net win. I think only testing will determine that for sure. I'm just starting to think about texture mapping myself so it will be a while before I consider trying such tricky things. My next task is to get the ability to import objects from some third party application. The ascii output from a program called Milkshape 3D looks pretty easy to parse. I got that program because it is cheap.

One thing I am convinced will help a LOT with performance is well-implemented mipmapping to help make sure that texture references during rasterization are "nearby" in the texture memory.

For Pocket PCs, there is a discussion on swizzling in this thread.

- hm

 

[Dzz]

For Pocket PCs at there is a discussion on swizzling in this thread.

- hm

Thanks for the reference! I'll spend some time tonight reading up on "swizzling".

I got a basic object reader done so I don't have to code test pyramids by hand any more. Here's another demo (I hope nobody minds a continual stream of links to demos, I think they're fun). In this case at the default zoom it's rendering about 470 of 1280 triangles, about 25,000 pixels.

http://www.gp2xgamer.com/demo3d2.gpe

The transformation+rendering time is horrific though -- about 9 milliseconds. I think I need to take a closer look at optimization of what I've got so far. I think most of it is in triangle setup for the rasterizer and that's only going to get worse when I start interpolating texture coordinates.

 

[MadDog]

Dzz, do you know if the display width value register has to be the same as the physical width or if its a stride? If its a stride value then your be able give your self a gardband cutting down on required clipping, not sure if that would help. Also do you know the cost of a memory exception? You could setup the protection unit to stop the rendering of the current tri on the bottom edge, removing a clip plane you need to worry about. Just some crazy ideas of the top of my head.

 

[Squidge]

I already use a similar technique, although via the blitter...

Draw to an off-screen buffer which is larger than the display (the visible display typically sits in the middle), not worry about clipping, and then use the blitter to actually copy the visible part directly to the frame buffer.

I've used this method in a couple of emus too so I don't have to bother clipping sprites