gbadev.org forum archive

This is a read-only mirror of the content originally found on forum.gbadev.org (now offline), salvaged from Wayback machine copies. A new forum can be found here.

Coding > This guy seems to know his math, I don't get it though!

#24977 - lordmetroid - Sat Aug 14, 2004 8:16 am

My post on flipcode got me an interesting answer... However I can't understand how it would work...
Could you guys please help me out with it?
_________________
*Spam*
Open Solutions for an open mind, www.areta.org

Areta is an organization of coders codeing mostly open source project, but there is alot of sections like GBA dev, Language learning communities, RPG communities, etc...

#24978 - lordmetroid - Sat Aug 14, 2004 8:47 am

Don't bother... darn me, just thinking in wrong directions...
I didn't consider what the dot product would really make out of my world...
_________________
*Spam*
Open Solutions for an open mind, www.areta.org

Areta is an organization of coders codeing mostly open source project, but there is alot of sections like GBA dev, Language learning communities, RPG communities, etc...

#24992 - DekuTree64 - Sat Aug 14, 2004 6:56 pm

Hmm, I'm not quite sure what that other guy meant either, but I am a little curious as to how your CZ-buffer idea would work. I tried a C-buffer once, but it was significantly slower than just throwing triangles at the screen. It was written in C though (compared to a C brute force filler), so I can't say how an ASM version would compare to an ASM brute force routine.
I have a feeling though that on GBA, you're not going to GET enough triangles on the screen for any overdraw reduction to help much.
What kind of worlds do you have in mind to render with it? I know you said only Y axis rotation, and that helps a lot, but you'll probably have to do some serious optimizing based on what sort of environments you'll be in, like indoor, outdoor, small corridors, lots of open space, hills and trees, or more square things like buildings.
_________________
___________
The best optimization is to do nothing at all.
Therefore a fully optimized program doesn't exist.
-Deku

#25047 - lordmetroid - Sun Aug 15, 2004 10:41 pm

It doesn't matter what environment I am in...
I make use of a old trick to save both memory and in this case also cpu power...
Tilemaps!
Though the tile does contain polygon information rather then pixel information this time...
I then make the frustum cull with a tech my coder associate and teacher invented or whatever, he told me about it anyway...
The frustum is culled by a Shockwave tech, the shockwave is a LUT specifying how the tiles should be tested when culling. At the same time as the frustum cull the tiles get a shade value.
Then the polygons inside the frustum is backface culled and at the same time their angle checked against the camera and an additional shade value is added upon the first one.
Now we got flatshading for free.

The C-buffer will handle clipping automaticly so I gain some speed their and it's necessary as I make use of mode2 for rendering and so using segments eases my work with my objects!
The Z in CZ-buffer is a Z buffer combined with a C-buffer, the Z-buffer is used for my objects and checked pixel for pixel against the segment of the world.
If their is no segment occupying a tile the mapdata is assigned tile0.
This makes reseting the buffer really much a fast thing and I only need to write to VRAM the tiles currently occupied by some 3D data.
The background is scaled to only show half the background at once, and using the other as a dbl-buffer. This will make the rendering area a 128x64pixels/buffer, not much indeed!
I also doesn't have any floor out of polygons but rather use the second layer for that!

With all these abuses of the system and some more like the rotation only around Y-axis I think I will gain some cpu power I wouldn't be having if I didn't make use of all these evil cheats
_________________
*Spam*
Open Solutions for an open mind, www.areta.org

Areta is an organization of coders codeing mostly open source project, but there is alot of sections like GBA dev, Language learning communities, RPG communities, etc...

#25052 - DekuTree64 - Sun Aug 15, 2004 11:19 pm

Hmm, sounds like a right fine plan, actually.
Here's what I'd do to sort of eliminate the frustum culling altogether. Your tiles are just flat on the 'ground' (X/Z) plane, right? So you only have to test against lines, rather than 3D planes, because the Y, or height from the ground, is ignored.
Instead of checking each map tile against those frustum lines, just look at the frustum as a 2D polygon layed out on the 2D ground. Either a 4 sided polygon, or to simplify things even more, ignore the near clipping plane, and it becomes a triangle. And what do you do when you have a triangle on a grid? You interpolate along the edges and draw it, of course. Just 'draw' the frustum triangle like a regular polygon, except instead of plotting pixels, do your 'I found a tile inside the frustum' code. Heck, you could even get free Z sorting by starting at the vertex closest/farthest from the camera.

..at least I think it would work. What do you think? Should I draw a picture to explain it a little better?
_________________
___________
The best optimization is to do nothing at all.
Therefore a fully optimized program doesn't exist.
-Deku

#25054 - lordmetroid - Sun Aug 15, 2004 11:40 pm

That is what the shockwave does... start with the tiles nearest the camera and make a .product test with the view angles' normals defining the frustum...
And as each stage of the shockwave spawns next stage I store what tiles is nearest the camera... that way I get a general polygon sorting, and segments near the camera can occupy large amount of the screen meaning I test those first and then don't need to overwrite any segments I previously done...
_________________
*Spam*
Open Solutions for an open mind, www.areta.org

Areta is an organization of coders codeing mostly open source project, but there is alot of sections like GBA dev, Language learning communities, RPG communities, etc...