#311 - KholdFuzion - Mon Jan 06, 2003 4:38 am
Im currently in the progress of making a 3D engine for the gba, as i design it, im focusing on a 3d rpg (like final fantasy 7-9), but it shouldnt be to hard for it to be switched to a different style game, like a fps. Because of hardware limitations, im ganna start w/ shaded models in a textured world, like ff7, but if i can make a fast enough algorithm, it will also have textured models. Fell free to offer any advice, comments, help, anything u want, im open to all suggestions.
#319 - KholdFuzion - Mon Jan 06, 2003 5:55 am
as i get parts of the engine done, i will be releasing it as opensource, till then, im looking around for a fast and efficient method for the engine. ive been browsing around and saw that Bluerose (http://www.raylight.it/Blueroses3dagb/blueroses.htm) has a working 3d engine w/ textured models (its commercial tho) if anybody has any good ways of doing this on a gba, let me know
#323 - Lord Graga - Mon Jan 06, 2003 9:29 am
Hmm....If the Bluerose engine is going to run totaly smooth (60 fps), then it is going to have a maximum of 266 polygons.
It says:
Up to 16000 polygons per second.
I.E with a framerate of 60, 16000/60 = 266.666
#352 - sketcher - Mon Jan 06, 2003 8:08 pm
So you can have 4 characters with 50 polys each on screen no problem! That leaves you with an extra 66 polys to spare for the portion of the world on screen. Oooh, this is exciting the game boy advance really is meant for 3D!
_________________
"Oh yeah, so what kind of warrior are you? A code warrior? HAHAHA!"
#496 - jaymzjulian - Wed Jan 08, 2003 4:28 am
it depends on the comprimises you're willing to make - I can only speak for what I'm achieving with t-mapping, which is around 15fps with 300ish t-mapped lit polys onscreen (http://artificial-stupidity.net/~alih/lfengine/twilight2.png), However, it should be noted that I am not really a very good coder, and in fact I'm almost geometry starved, right now (40% is spent in geom and polysort, 60% is spent in drawTextureTriangle).
FWIW, the big places of loss in my code, right now, is reading the texture bits from ROM - I'm using 128x128 textures, which means that caching them into iwram is not an option, since they're 16kbytes each. If you were, however, willing to use 32x32 textures, then they would be 1kbyte each, and then you could set up an LRU cache or something in 8k of iwram, and this would make your t-mapper significantly faster.
There are similar comprimises which can be made in geometry... my geometry data is in fact way too large right now (96 bytes/vertex, all of which need to be read from rom), and my code is far from optimial.
Also, it should be noted, that "triangles per second" is a bullshit measure - when the house object in that picture is in the distance, the frame rate shoots up significantly, even tho the number of visible triangles hasn't changed. gee, look ma, I can fake benchmarks! ghee!
There are other things you can do to be fast. For example, if you half the horizontal resolution to 120x160, as many have chosen to do, then your t-mapper will be significantly faster. If you have no lighting, of course, your geometry will be faster, and so on. There are many things you can do in teh name of speed :-p.
Oh, yeah, don't trust VBA for framerates - it's usually around 20% over, in my engine's case, and I've heard different figures for others (the screenshot above, btw, has the FPS calculator adjusted to compensate for this :-p)
- jj
#498 - jaymzjulian - Wed Jan 08, 2003 4:33 am
the blueroses engine looks *really* impressive
#504 - KholdFuzion - Wed Jan 08, 2003 5:34 am
the truth is, im actually fairly new to 3d graphics, everything i know, im converting to the gba, and the rest im learning and applying to the gba (my 'teachers' site is http://coelurus.thorntwig.tk, hes giving me personal lessons 'cross aim) your engine looks nice so far, lighting isnt really a issue, im gonna mimic the ff7 engine as much as possible, so probably the only 'shadows' on characters will be via texture or gradiant shading. 32x32 is actually enough for this style engine, character textures will be hella small, world textures can be small, but use different variants to keep it interesting, like 2-3 grass, 2 'mountain', 2 water, several for the occasional building, u get the idea
#557 - coelurus - Wed Jan 08, 2003 8:22 pm
For an FF-style game, I'd recommend to use 3D characters and static backgrounds. 3D-characters are quite low-poly and very small on-screen, since you mostly see the entire model. Both factors mean you don't really have to worry about the speed for objects.
The only reason for using 3D environments would be to save some mem (textures are often smaller than backgrops), but I think some simple compression can help there. 3D environs also need to be clipped properly against models :p
Try to skip any form of perspective correct texture mapping or filtering. It sure gives very pleasing results, and can be accelerated with subdivision, either by scanline or by area. BUT, I'd prefer fluid gfx to beautiful gfx. Looking at a small screen that jerks is not fun...
EDIT: Flag for grouraud or texture mapping! An example would be clothes, they could use plain colors, but the face and perhaps the belly and chest could need some texturing. Gouraud shading only is lots faster than texturing, keep that in mind.
No shadows! You could try to make a software implementation of Shadow Volumes, but that'd just be ridiculous :) Projected ground-shadows or just a little dark blob below the feet might help to make the visual better.
Lambert-shading is enough to make the models look good, no specular with phong or anything.
Do you really need Z-buffering for models? I don't know whether face-sorting or a Z-buffer is the fastest method, but in any case, I think face-sorting is enough (if you can get away without intersecting tris).
ANOTHER EDIT: Normal-storage can be saved really simple, by using a trick in most ID-titles: to have a bunch of normals (256 for a byte) and let each vertex (or entire face) have a byte pointing to a predefined normal. To save even more, one could use bit 7 for the gouraud-texture flag and the rest for the normal-index... Just some ideas :)
#580 - lordmetroid - Wed Jan 08, 2003 9:47 pm
I'm going to get my hands on a 3d Engine for my next project so I like to ask this question in advance...
I want to support FF like battles in my engine, and if I make the enviorment of polys. Would that go slower as I have to draw a big part of the screen of polys?
I also wonder can one use sprites in a bitmap mode, as I assume one uses
a bitmap mode usually when drawing polys?
Perhaps it could go faster if you only rendered certain parts by polys like those who actually are haveing a 3d proportions like craters and stuff, and make the floor of a mode 7 effect...
And to even optimize it more use Golden Sun kind of sprites that are able to be seen from very many angles so they would be able to spin around a sprite...
perhaps there is a way to have a bunch of "3D"sprites and have a 3d Skeleton and pose each arm/leg/body/etc-sprite where it should be to make it look even more 3D, what do you think?
_________________
*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...
#609 - PeterP - Wed Jan 08, 2003 11:40 pm
Hi,
I read somewhere about some technique called "swizzling" textures. I think it means that you hack up the texture in small rectangular chunks that fit in the cache and then texture the part of the triangle that use the chunk in the cache. Then you move on to the next chunk / part of the triangle until you've rendered the whole triangle.
E.g. if the texture is 128x128 and only 32x32 can fit inside the cache, then you'd end up with 16 chunks (0..31, 0..31), (32..64, 0..31), (65..95, 0..31), (96..127, 0..31), (0..31, 32..64) etc...
I haven't tried to implement it myself, but I'm planning on trying it later.
/pete
#627 - jaymzjulian - Thu Jan 09, 2003 3:37 am
| PeterP wrote: |
Hi,
I read somewhere about some technique called "swizzling" textures. I think it means that you hack up the texture in small rectangular chunks that fit in the cache and then texture the part of the triangle that use the chunk in the cache. Then you move on to the next chunk / part of the triangle until you've rendered the whole triangle.
|
If anyone is interested, I have some code here that I wrote over christmas to rotate/scale a sprite into a triangle, and tesselate the triangle into two when it's too large (i.e. greater than spriteSize*2)
However.
I threw this out, because by the time I was managing sprite ram (which you quickly find is very limited for this particular case - in bitmap mode, there is only enough room for data for 4 64x64 sprites!)
anyhow, if anyone wants the code in question, tell me, and i'll send.
- jj
#649 - coelurus - Thu Jan 09, 2003 12:02 pm
I don't think you need 128x128 textures for an FF-style game. In any way, the rez of the GBA-display is too low, so 32x32, or even 16x16 might be sufficient (you can t-map the eyes and mouth only). This might of course take more space than usual (just having a flat face ;) ), but you'll probably gain more since the t-maps are smaller.
I think it's best you start coding on the engine and see what happens. Experimenting is the best way to figure things out.
#655 - mithris - Thu Jan 09, 2003 2:03 pm
When i wrote my 3D-engine for the GBA i noticed that the rotation/translation
was the biggest problem, and since that the RAM is very limited some things
can be hard to do.
Sorting polygones is never a good idea.
But i got a 500-something polygone envmapped object run in about 20fps
atleast, and anyone less lazy than me could probably get it running faster.
So basically what i noticed was that the fillrate is not the biggest problem.
/Bjorn
_________________
codito ergo sum
#658 - jaymzjulian - Thu Jan 09, 2003 2:23 pm
| mithris wrote: |
Sorting polygones is never a good idea.
So basically what i noticed was that the fillrate is not the biggest problem.
|
I've noticed this somewhat too, although you can optimize this out a LOT, whereas optimizing out the fillrate is harder.
I'm interested to hear your justification that sorting poly's is never a good idea, however... i've found polysorting to be faster than using a z-buffer.
- jj
#659 - mithris - Thu Jan 09, 2003 2:34 pm
Poly sorting is probaly lots and lots faster, but you have to calculate a value
to sort on for every poly and you probably want to do this before you do
the backface culling.
So if you will go for radix sort (as i did since it O(n)), you will need
2 buffers containing the values to be sorted.
But all that is just the small problem..:D
The big problem and why i think sorting is a bad idea is that you cannot sort
all polygones correctly, a sphere works just fine but for more advanced
meshes the sorting will screw up some polygones making them flicker and
generally beahve in a bad way.
You can tweak this, finding a good sorting value for each object perhaps,
i guess the most commonly used is Z at the center of the polygone,
but even this causes problems with big vs small polygones close to each other.
/Bjorn
_________________
codito ergo sum
#707 - PeterP - Thu Jan 09, 2003 10:16 pm
Ok, if sorting results in flickering and errors and span buffering is too slow, then perhaps a hierarchial z buffer would be an alternative?
i.e mip mapping the depth buffer. That way you could potentially cull an entire triangle with one depth test.
Anyone tried this?
And a question: Is there any benefit in using triangles instead of (convex) polygons?
#708 - mithris - Thu Jan 09, 2003 10:32 pm
Hmm.. a triangle is a convex polygone?
Well, a hierarchial z buffer would still take to much mem, since you don't want to put it in EWRAM.
hierarchial z-buffers also gives other interresting possibilities, since you
can if you do some sorting create somekind of occlusion culling.
And i don't think s-buffers is to slow, but there is not enough memory for it.
Perhaps one could do some kind of tweaking, rendering only parts of the
screen or smth.
/Bjorn
_________________
codito ergo sum
#709 - PeterP - Thu Jan 09, 2003 10:43 pm
| mithris wrote: |
| Hmm.. a triangle is a convex polygone? |
What I meant was: Should I triangulate my meshes or should I keep them as n-sided convex polygons?
I currently take whatever I get out of Maya, even if it's 8 sided polygons.
The way I've coded things, I found it slower to render the world as triangles instead of polygons, but I was wondering if others have experiences that differ and if I should reconsider.
#710 - mithris - Thu Jan 09, 2003 10:45 pm
As far as i know everyone is using triangles, mainly because they are
really easy and fast to draw, but i guess any convex polygone quicky
could be splitted into triangles.
/Bjorn
_________________
codito ergo sum
#712 - PeterP - Thu Jan 09, 2003 10:49 pm
| mithris wrote: |
As far as i know everyone is using triangles, mainly because they are
really easy and fast to draw, but i guess any convex polygone quicky
could be splitted into triangles.
/Bjorn |
Why are they faster?
#716 - mithris - Thu Jan 09, 2003 11:01 pm
| Quote: |
| Why are they faster? |
I have no idea if they are faster, but i belive it's simpler to have a
tri-filler and triangulate the n-gones.
/Bjorn
_________________
codito ergo sum
#728 - Nessie - Fri Jan 10, 2003 12:17 am
When I wrote a rasterizer some time back, I found that rendering n-gons was slightly faster than triangles, at least using the algorithm that I came up with. Stilll, if I were doing it today, I would only support triangles for any number of reasons.
Aside from reasons already mentioned, I wouldn't care to deal with data structures that could support n-gons. Not that it's hard to do--it just seems like it's unnecessary.
#733 - squeakytoy - Fri Jan 10, 2003 1:04 am
| PeterP wrote: |
| Why are they faster? |
It's much easier (ie simpler and less code) to fill them than more complicated concave polygons.
#788 - PeterP - Fri Jan 10, 2003 6:06 pm
| squeakytoy wrote: |
| PeterP wrote: | | Why are they faster? |
It's much easier (ie simpler and less code) to fill them than more complicated concave polygons. |
Ok, I see, but the reasons I use n-gons are:
- Backface culling, faster to cull one 4 sided polygon than 2 triangles. (both when using the normal and triangle area checks).
- Clipping a triangle usually produces n-sided polygons and I won't have to triangulate the clip result.
- I do the scan conversion and rasterizing in a separate functions anyway, so rasterizing is the same for both triangles and n-gons.
But I agree that using triangles means easier data structures... I'm going to do some tests and see which is faster in my game.
#1130 - sketcher - Tue Jan 14, 2003 9:32 pm
PeterP,
Swizzling is a generic term talking about taking something that uses a certain number of bits and adjusting it to fit into a smaller number of bits. Like adjusting 32 bit color to fit into 16 bit color.
_________________
"Oh yeah, so what kind of warrior are you? A code warrior? HAHAHA!"