gbadev.org forum archive

Hi, I am Tomer, and I know alot about 3D engines.
these are some pics of the 3D engine, that I have written, plus a little
MD2 Demo with 3RD person camera, Cheers
If you have questions about 3D graphics, I'll be more then happy
to share knowledge.

NOTE: You will have to save the images and the demo in order to
view them- Right clivk on the mouse ("save target as"). else
you won't see them

[Images not permitted - Click here to view it]
[Images not permitted - Click here to view it]
[Images not permitted - Click here to view it]
[Images not permitted - Click here to view it]
[Images not permitted - Click here to view it]

And Here is a very little demo:

http://www.geocities.com/carmatomer/3d.zip[color=darkred]

You should get better webspace...

I find it a nice idea to use mode3 for 3D stuff, but i am afraid you would need more colors for real games to get a decent output...
_________________
Team Pokeme
My blog and PM ASM tutorials

some nice pics :)

btw: i hate geocities

tomer wrote:

Hi, I am Tomer, and I know alot about 3D engines. If you have questions about 3D graphics, I'll be more then happy
to share knowledge.

<nogba>
Okay I'm a 2d programmer who likes 3d only for its effects and powerful hardware. I'm using Direct3D 9 for 2d demos and games, and I don't like the format of textures or texels which screws my head.
Still I live in a world of 3d demos and 3d games so I'm forced to use it, and it may pay off someday... Came 4th place at a demo party in PC demo with my crappy 3d to 2d engine.

I have a question about how I can get a 3d image to show up as a 2d image (pixel aspect!) and still be able to have 3d primitives in the front of and in the background of the 2d image. What do I need to think about when doing this? (No spec about DX or openGL. Just how to think in 3d space)
</nogba>

Okay, that was question and information that doesn't belong in this forum, and I'm sorry for bringing it up :(

Well, if I understood correctly, you want to make a 2D scene with
3D primitives respectively in the background.
Well, if that you meant, then the answer is very simple.
your 2D engine will have a static 3D Camera - don't apply camera
prespective, instead just put your 3D primitives in a fixed distance
with the ability to make them move - to change their own coordinates.
that's about it, and don't forget, that you must disable the camera,
and to make a seperate 2D renderer, and a 3D renderer.
Cheers

tomer wrote:

Well, if I understood correctly, you want to make a 2D scene with
3D primitives respectively in the background.
Well, if that you meant, then the answer is very simple.
your 2D engine will have a static 3D Camera - don't apply camera
prespective, instead just put your 3D primitives in a fixed distance
with the ability to make them move - to change their own coordinates.
that's about it, and don't forget, that you must disable the camera,
and to make a seperate 2D renderer, and a 3D renderer.
Cheers

Thanks :)

Seems quite good. Any development since the first post?

I've never done any 3D programming before besides a bit of OpenGL for the computer. What would be the best approch to learn 3d on the GBA? If you could write up a post that would help newbies like me who know not too much about 3D programming I think a lot of us would really appreciate it. If you don't have time then don't worry about it.

Thanks,
Eric

3D for GBA is more something you invent than learn; getting good-looking 3d that's fast enough to be practical for a game is very difficuly.

tomer, I'm currious as I've been playing with something similar, what kind of frame rate are you getting right now with a full scene like the ones in the screenshots?

Will
_________________
"Only two things are infinite: the universe, and human stupidity. The first is debatable." -Albert Einstein

I want to develop something 3D too :)

I had some problems finding out how to transform a vector correctly (by setting up a camera and world transformation and then somehow transform the coordinates of the vector). Maybe i should look into it again... I guess you can find a lot of info on non-gba related sites (also on PC 3D dev sites).
_________________
Team Pokeme
My blog and PM ASM tutorials

It is true that there's no much document for creating 3d in software rendering. Many good docs were written in '95-'97.
Basically on gba, it's just about finding the right algorithms first, after that it's pure programming. Like vector transforming, of course it's the same way you learned from maths lesson, just optimizing some bits.

My short tips would be:
1) Get a working engine on PC, because it's fast
2) When you know how to do 3d, then move it to GBA

Then alot of math optimizing:
1) NEVER EVER use floats. Instead, use fixed point, but 32bit signed int:s, like 15 bits for the number and 16bits for decimal (using shifting, ALOT of faster).
2) NEVER EVER divide anything as it's right meaning; instead, generate dividing table for numbers from 0 to 65536 for example. Dividing table is fixed point table, which is simply generated as for(i to 65k) divtable[i]=65536/i. Then just use it like: "number=(80*divtable[7])>>16
3) This is also obvious, but always table sines and cosines.
4) Hmm, the most basic ones, try to live with them :)

Edit: oh yes, MUL is quite fast :)

Quote:

It is true that there's no much document for creating 3d in software rendering. Many good docs were written in '95-'97.

Recently a new book by laMothe was published called "Tricks of the 3D game programming gurus" and altough I'm not a big fan of laMothe's work, this one's actually pretty good.

It goes in depth into the details of making yourself a 3D software rasterizer, from the basic and advanced math (very good chapter) to actual optimization of code. Ofcourse the code in the book was written for Windows (x86) but I guess when you've read the whole book and programmed your own 3D engine for PC, it shouldn't be so difficult to port it to GBA.

- Pan

shadez, i consider myself a "quite good" programmer, but at the other hand i think that i am a looser at maths :(

Well, the problem is with the algorithms you mentioned, i found a good tutorial now but the most complicated part for me seems to be proper projection and clipping of polygons with screen edges (cant we just clip the polygons by just not drawing the invisible parts and interpolate to the visible parts of the poly?). I took a look at some polygon drawing examples and they seem to scan the poly first and then draw it, isn't drawing it in one go better? I think that is done this way because it might be easier when interpolating from left to right (to find out the left or right edge).

Btw, i really like your demo :)
_________________
Team Pokeme
My blog and PM ASM tutorials

Scanning is done to allow the poly to be drawn in horizontal strips. Fill time on Polys - especially textured - is what kills performance on a well optimized renderer. Here:

Lets assume we want to draw a poly without scanning it. How exactly do we fill it? Here's a couple ways (assuming triangles as any poly can be broken down into a group of triangles and it makes the algorithms much simpler).

Draw, the edges with a good line drawing routine and use a flood fill alogrithm to complete it (works only for solid polys - gourand or textued would need more work in the floodfill.) Alas, floodfill tends to be pretty slow and stack intensive as most implementations are recursive (it also needs to do a read before every write which makes it even worse).

Pick 2 vertices. Get how fast the slope decreases over time as we approach the third. Draw progressively smaller lines as we approach the 3rd vertice. This works pretty well, but again every line drawn in the fill must use a line drawing algorithm which while fairly efficient, isn't gonna give great performance. Also, a bunch of pixels will be double or tripple drawn on acute angles which will throw off textuing and such.

Add your own routine here.

Anyways, now assume we're scanning in the edge (into RAM) and creating an edge draw list. This at the cost of 3 lines. Now, we just horizontal fill across the face of the poly using very efficient word writes for solid or slower interpolate between 2 colors for gourand, or skip over read from the texture for textured. As the main fill routine is writing horizontally, it uses the hardware to its best ability and gets the best performance possible for filling.

Even with the best possible filling routines, on larger polys (say greater than roughly 6 pixels in width), the fill time is still the bottleneck.

Hope this helps.

Just thinking out loud, but let's say you need to draw a couple of polygons (flat).

The main speed killer is the actual filling right?
How about using hblanks to draw 128 sprites per horizontal screenline?

You would calculate which polygons are visible, and go forth from that list.
Then, you would create a buffer which looks like this:

Sprite buffer[160][128];

In the 160-228 scanline period you would have time to calculate this buffer:
for each line of the screen (160 lines), you would calculate the x,y (w,h by using zoom?) of the "polygon-sprite-lines", in such a way, that it would fit in sprite oam.
Then when the actual hblank interrupt occurs, you would simply DMA all 128 sprites for that current vertical screenline.

Just my innovative .02 cents :)

Interesting. But - Interrupts are now free CPU time. If you interrupt on every scanline on the screen, you've eaten ovef half of the available CPU time for the rest of the game. Plus I'm not 100% sure you could DMA 128 sprites (256 bytes) of info in time when you consider setup and entrance/exit code. Still, an innovative idea that I'll think about a bit more :)

I have a 'text writer' that uses this technique. Always updates 100 sprites per frame, I haven't been able to reach 128 though. But perhaps my other IRQ's and music process is interfering for DMA'ing 128 sprites on time.

-- And about eating half of the available CPU time:

Hblank's duration is about 10-20% of the scanline cycle usage?
This is what will be eaten, and that means you still have around 80% left of the scanline during the actual drawing (good for calculating the next buffer).

Miked, i once created a function to draw a poly in one go by using horizontal fills. You just have to sort the points, calculate the slope on the left/right edge (calculate the change in X when Y changes by 1) and then interpolate along the edges and fill everything in between. I think i wrote it like a half year ago and i was not really getting into it any more (the code was crappy, but the idea worked).
_________________
Team Pokeme
My blog and PM ASM tutorials

MeiM0D - were you sitting inside the interrupt the whole time or were you exiting and re-interrupting per scanline? I tend to stay in interrupt time when doing complicated multi-line things because that was the best way to do it on GBC. You lose a bunch of time to entrance/exit overhead so while 10-20% for hblank time may be correct (I don't have the specs in front of me), you lose a bunch more getting through CRT0 and teh BIOD crap. BTW, we have to have a fairly complex interrupt handler do to multiple interrupt support and such so that's why I always assume big overhead getting in and out...

Lupin - Yep, that's the basics of an edge list poly filler. The only other wrinkle you don't mention is that the slope will change once along one of the 2 edges when it passes the middle vertice (middle being middle in Y position) so you need to re-calculate the slope at that point. But you are correct in stating that edges don't need to be stored in RAM and re-read if you are clever with register usage. Hmm lets see what we'd need
r0 - r3 work registers for math and horizontal filling
r4 poly Y height count
r5 left slope value
r6 right slope value
r7 fill value (to be passed into one of r0-r3)
r8 video pointer
r9 left slope accumulator
r10 right slope accumulator
r11 top/bottom mid point tracker (may not be needed)

leaving r12 and r14 for stuff I missed so yeah a end point list isn't really needed. I have a feeling that most poly fillers are from people like me who are used to x86 limited register space. Cool - I may go give this a try :)

Yeah, you could get a flat filler really fast like that. Actually GBA has enough regs to do textured without any extra loading/storing in the inner loop at all (for mine, one ldrb from the texture, one ldr from the palette (would be ldrh, but needs a shift) and one strh to the screen). I don't know if it would be possible in mode 4 though, since you would need extra regs to do 2 pixels at a time. With 8-bit fixed uv coords and a max texture size of 256, and a bit of cleverness, you could put the u in the lower 16 bits of a reg and v in the upper, saving one reg, and then you only need one for both increments, saving another (as well as a cycle for adding them). Since you need to mask to the texture size anyway, you get the separation for 'free', and since you have to shift v to multiply by the tex size, that's no extra time either.
I wish I had time to write it^^
Although even more, I want to write a different 3D system I came up with that uses an S-buffer, and draws the whole screen in fixed-size strips using stmias. I scribbled the renderer down on paper, but never actually wrote it. Could be fun to see if it would really be fast enough.
_________________
___________
The best optimization is to do nothing at all.
Therefore a fully optimized program doesn't exist.
-Deku

Miked0801 wrote:

MeiM0D - were you sitting inside the interrupt the whole time or were you exiting and re-interrupting per scanline? I tend to stay in interrupt time when doing complicated multi-line things because that was the best way to do it on GBC. You lose a bunch of time to entrance/exit overhead so while 10-20% for hblank time may be correct (I don't have the specs in front of me), you lose a bunch more getting through CRT0 and teh BIOD crap. BTW, we have to have a fairly complex interrupt handler do to multiple interrupt support and such so that's why I always assume big overhead getting in and out...

I enter and exit interrupt per scanline.. the bios+irqhandler stuff is only a couple of cycles each scanline, not more than 1% total cpu each frame.

I did a demo with my mod player running + a 9 line (each line is 8 pixels in height) textwriter shooting 100 sprites for each line using this technique + 2x3d stars with flatshaded polygons taking up mostly 70% of the mode5 screen area... and that seemed to run at 60fps :).

We will only know if it works until somebody actually tries it!

Hi everybody...alright, aside from raycasting, are there any other viable options on the gba that would allow a custom map environment, i.e. something better than squares as walls, floors, ceilings, etc.?

Would creating a huge 3d array (is that even possible on gba?), or many many 2d arrays to simulate a 3d array, and then using a custom made library to define FOV, location, etc. be a viable option? I'm trying to stay away from raycasting since it limits your actual 3D options (too many rays in 3D) I would just raytrace the center of the FOV to see exactly where the character is looking (eventually want to turn it into a first person shooter) or aiming, and modify the FOV based on the movements of the player.

Tieing into the below, my biggest problem is that I want to create a truly 3D game that is not raycasting. Raycasting isn't truly 3D because the character would never need to aim up/down.

Aside from the engine trouble, I've been thinking about the control layout on the gba and how it would best suit the game I would like to make.

Strafing left/right would be the problem due to the design of just one control pad...so here's what I came up with:

Up/down - move forward/backward

Right/left - strafe right/left, but where the player would be aiming at would actually never change, theoretically in a wide enough space a character would revolve around the fixed point at which he was aiming, moving in a giant circle (good for moving back and forth to evade fire while being able to center your fire on the enemy...could have repercussions such as making the game too easy if the enemy didn't move enough)

B - many different uses (switch weapons, reload)

A - jump

R - shoot

L - hold to move aiming reticle across the screen without moving, or possibly to move while turning quickly...maybe...

The biggest problem that I have would be to aim somewhere while moving in a totally different direction. Unfortuanately, the design makes this very hard to implement and I was wondering if there were any suggestions on this or references to threads that I missed in my searches.
_________________
I would kill the sexiest person alive, but suicide is a crime.

Step 1 - get your engine running above 2 FPS...

Miked0801 wrote:

Step 1 - get your engine running above 2 FPS...

I think that is more like step 2. Step one would be: "Get a working engine".

Who knows you may even get to step 3: "Make your engine worth looking at and playing"
_________________
Little kids and Playstation 2's don't mix. :(

Would programming it in all ARM be worth the speed increase? I actually prefer assembly to C/C++ because I first learned how to program on a calculator (you know, making games to play in class) and to make any sort of decent game on the calc you have to program it all in assembly and so I feel more comfortable with regs instead of C++ which I haven't actually learned all that much of as of now (can do basics...the bare basics).

Idea for increasing the speed of the program: it only loads cubes of the total map data. It would make the map seem cubical (is that even a word?), in other words having like a different area here, connected to an area here...(see below)

___________ ____________
| | | |
| |_______| |____
| _______ _____
| | | |
|___________| |____ _____|
| |
| |

Please excuse the crudity of the drawing, the underscores and spaces don't line up exactly. But each room would be loaded seperately, and since we're working of a cart instead of a disc, there is a much shorter load time...I dunno, just toying around with ideas on how to get a true 3D game on the GBA.

Quick question:
Can I create 3D matrices on the GBA?
What do console games use instead of raycasting to show POV, FOV, whatever?
_________________
I would kill the sexiest person alive, but suicide is a crime.

A 3D array of voxels (volume texture elements) would take up too much ROM space.

Various 3D games use different techniques such as height-mapping (like raycasting but each map square contains a height value rather than just filled/not filled, roughly like a run-length coded version of your 3D voxel array, as seen in Comanche), portal-casting (like raycasting but using arbitrary polygons instead of squares), height-mapped portal-casting (the method Marathon uses, which achieves the same result as Doom), even more advanced portal-casting (as seen in Serious Sam), etc. A competing technique used in the Doom and Quake engines involves building worlds out of BSPs of polygon meshes.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

I'm not trying to smash your hopes but:

GBA 16Mhz ARM CPU
32K of real memory
256K of slower
4Megs of ROM
No 3D Hardware support
No FPU
No Hardware Integer Divide
16-bit Bus to VRAM

First PCs that ran DOOM at roughly 30Hz (not wolfenstein)

486 DX 33 (Roughly equiviolent to the GBA CPU due to registers starvation)
8Megs of RAM slower RAM
20Megs of Very Slow R/W RAM (HDD)
Cacheof 64K or 256k (equivilent roughly to IWRAM)
No 3D HW support, but VGA HW tricks to write many bytes at the same time (remember mode X?)
Slow FPU
Built in Integer Divide
32-Bit Bus to VRAM (VESA Local Bus :) )

So that PC had roughly 100x the Memory (cached!), slightly more CPU horsepower, a built in HW divide (This is big!), and either a 32-bit bus to VRAM or 4xwrite mode. It takes a really, really, careful approach to even get psuedo 3D graphics working on a GBA. To get anything at all up to speed will require extensive ARM assembly optimizations and a thorough knowledge of the hardware. This is where my previous comment came from. Advice, do a few side scrollers and puzzle games first on the target before attempting to open this Pandora's box.

Miked0801 wrote:

I'm not trying to smash your hopes but:

GBA 16Mhz ARM CPU
32K of real memory
256K of slower
4Megs of ROM
No 3D Hardware support
No FPU
No Hardware Integer Divide
16-bit Bus to VRAM

First PCs that ran DOOM at roughly 30Hz (not wolfenstein)

486 DX 33 (Roughly equiviolent to the GBA CPU due to registers starvation)
8Megs of RAM slower RAM
20Megs of Very Slow R/W RAM (HDD)
Cacheof 64K or 256k (equivilent roughly to IWRAM)
No 3D HW support, but VGA HW tricks to write many bytes at the same time (remember mode X?)
Slow FPU
Built in Integer Divide
32-Bit Bus to VRAM (VESA Local Bus :) )

So that PC had roughly 100x the Memory (cached!), slightly more CPU horsepower, a built in HW divide (This is big!), and either a 32-bit bus to VRAM or 4xwrite mode. It takes a really, really, careful approach to even get psuedo 3D graphics working on a GBA. To get anything at all up to speed will require extensive ARM assembly optimizations and a thorough knowledge of the hardware. This is where my previous comment came from. Advice, do a few side scrollers and puzzle games first on the target before attempting to open this Pandora's box.

I think this is one box left closed. If someone really wants 3D, tehy should wait for the DS. By the time they have created this "super-uber 3D engine" for the GBA, the DS will have put it to shame.... :)
_________________
Little kids and Playstation 2's don't mix. :(

Don't worry about smashing my hopes, I knew it was farfetched when I proposed it because I figured if it was even somewhat feasible, someone would have attempted it already, but oh well.

Hm...maybe I should just learn C++ and either OpenGL or DirectX and work on a game for the PC...but you gotta admit, it WOULD be fun to play a portable version of CounterStrike or Halo 2...and while I'm on this "wishing" streak, here's another one: I wish for a DS SDK.

Anyway, thanks for the info, I might try a 2D real time fantasy game (like the current day Sword of Mana, or for those of you who remember the original Final Fantasy Adventure) with semi-3D effects. Is there anything like CGI on the GBA? Or should I go back to my old "movie" standby and create each individual frame?
_________________
I would kill the sexiest person alive, but suicide is a crime.

awindrose wrote:

I wish for a DS SDK.

I wish for one too!

awindrose wrote:

Anyway, thanks for the info, I might try a 2D real time fantasy game (like the current day Sword of Mana, or for those of you who remember the original Final Fantasy Adventure) with semi-3D effects. Is there anything like CGI on the GBA? Or should I go back to my old "movie" standby and create each individual frame?

We'll see after Kingdom Hearts: Chain of Memories comes out. The CGI sequences are supposed to be "on par with the PS2 scenes". I wonder if it will be true...
_________________
Little kids and Playstation 2's don't mix. :(

I don't know if this will help anyone, but here's a link to a site full of 3D engine specs and source code.

http://www.3dengines.net
_________________
my dev/business site:

http://codebytesdev.afraid.org

Mr. GBA wrote:

I don't know if this will help anyone, but here's a link to a site full of 3D engine specs and source code.

http://www.3dengines.net

Eh, funny (at least for me) : the two GBA engines listed in 3dengines.net are Yeti3D (to which I contributed a bit), and GBA3DS, which is my first attempt of a 3D engine :)

Anyway, you should have a look at Yeti3D. It's well written, has a not-too-bad framerate, a world editor... There's a GPL version which is a bit old, a v2 that should be released under GPL too, and a "Pro" version.
Derek sometimes reads these forum. You can also contact him if you want to contribute, he's a very nice person.
_________________
GBA,GC,NGPC,GP32,FPGA,DS stuff at http://torlus.com/

Torlus wrote:

Eh, funny (at least for me) : the two GBA engines listed in 3dengines.net are Yeti3D (to which I contributed a bit), and GBA3DS, which is my first attempt of a 3D engine :)

Well..when I said "a site full of 3D engines..." I meant that there is a multitude of 3D engines on that site, which could easily be ported over to the GBA.

Anyway Torlus, I've played with Yeti3D and GBA3DS and I much prefer your GBA3DS. In particular, it's the 3D animation that has drawn me towards it. I was wondering if you could point me in the direction of some tutorials that helped you make GBA3DS?

Thanks in Advance.
_________________
my dev/business site:

http://codebytesdev.afraid.org

Well, most of the information I used was found in gamedev.net's articles. And Half-Life smd format is human-readable, that's why I chose it at first.
Yeti3D is much more complete than GBA3DS, and can use MD2 models. Well it would be an idea to add skeletal animation support in Yeti3D, as most of the code is done is GBA3DS... But I'm currently working on other projects at the moment :) Maybe later...
_________________
GBA,GC,NGPC,GP32,FPGA,DS stuff at http://torlus.com/

gbadev.org forum archive

Graphics > GBA 3D Engine

#18702 - tomer - Thu Apr 01, 2004 11:41 am

#18703 - Lupin - Thu Apr 01, 2004 11:47 am

#18712 - NoMis - Thu Apr 01, 2004 1:21 pm

#18714 - LOst? - Thu Apr 01, 2004 2:22 pm

#18716 - tomer - Thu Apr 01, 2004 2:36 pm

#18719 - LOst? - Thu Apr 01, 2004 3:33 pm

#20113 - shadez - Sun May 02, 2004 10:05 am

#20125 - zazery - Sun May 02, 2004 6:42 pm

#20128 - Gopher - Sun May 02, 2004 7:26 pm

#20131 - Lupin - Sun May 02, 2004 7:59 pm

#20196 - shadez - Tue May 04, 2004 4:28 pm

#20280 - pan69 - Thu May 06, 2004 7:21 am

#20282 - Lupin - Thu May 06, 2004 12:38 pm

#20296 - Miked0801 - Thu May 06, 2004 6:56 pm

#20302 - NEiM0D - Thu May 06, 2004 7:43 pm

#20311 - Miked0801 - Thu May 06, 2004 10:17 pm

#20314 - NEiM0D - Thu May 06, 2004 11:05 pm

#20330 - Lupin - Fri May 07, 2004 1:54 pm

#20336 - Miked0801 - Fri May 07, 2004 6:46 pm

#20338 - DekuTree64 - Fri May 07, 2004 9:04 pm

#21488 - NEiM0D - Sat May 29, 2004 11:54 pm

#23371 - awindrose - Sun Jul 11, 2004 4:49 am

#23385 - Miked0801 - Sun Jul 11, 2004 3:45 pm

#23390 - dagamer34 - Sun Jul 11, 2004 6:26 pm

#23395 - awindrose - Sun Jul 11, 2004 9:49 pm

#23404 - tepples - Mon Jul 12, 2004 3:37 am

#23430 - Miked0801 - Mon Jul 12, 2004 6:00 pm

#23435 - dagamer34 - Mon Jul 12, 2004 11:52 pm

#23440 - awindrose - Tue Jul 13, 2004 1:22 am

#23442 - dagamer34 - Tue Jul 13, 2004 1:29 am

#23532 - Mr. GBA - Wed Jul 14, 2004 7:31 pm

#23562 - Torlus - Thu Jul 15, 2004 9:12 am

#23594 - Mr. GBA - Thu Jul 15, 2004 11:19 pm

#23616 - Torlus - Fri Jul 16, 2004 7:58 am