#101283 - cppdungeon - Mon Sep 04, 2006 6:20 am
how exactly do you make 3d stuff with a gba?
_________________
"in Soviet Russia, car pimps you!"
#101286 - sajiimori - Mon Sep 04, 2006 6:54 am
The GBA does not have 3D hardware. There's "Mode 7," and there's software renderers. The former has tutorials on this site; the latter is a very large subject.
http://en.wikipedia.org/wiki/Software_rendering
#101309 - keldon - Mon Sep 04, 2006 9:53 am
Bear with me for a minute because if my diary is as clear as I believe, I might write my tutorials in the gba wiki. Starting off with linear integration, to line drawing and perspective correct/affine texture mapping.
In short you will have to code every part of the 3d engine yourself. I would start off with the rendering part - the bits that draw lines, polygons and texture maps.
The 3d engine itself can be simple or complex depending on how you look at it. The engine works via a pipeline. So you start off with your original model representation that might say, "the printer is located in the corner of the room, it is 12x8x6 feet rotated 45 degrees on the x-plane; the camera is here facing there tilted like this. You then go through a couple of stages:
- converting from models co-ordinates to the co-ordinates of the world; so that london is no longer positioned relative to England, but in relation to the entire world
- you then convert the world co-ordinates to the camera's co-ordinates, so that london is no-longer relative to the world, but to the camera
- you can then draw these polygons to the screen after clipping the polygons and converting their co-ordinates to the screen's system.
Rendering pipeline links
1 >> http://www.willamette.edu/~gorr/classes/GeneralGraphics/Pipeline/geometry.htm
2 >> http://video-animation.com/flash3d_008.shtml
#101335 - tepples - Mon Sep 04, 2006 3:14 pm
Do you mean actual 3D, or just partly 3D as seen in Mario Kart Super Circuit?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#101356 - keldon - Mon Sep 04, 2006 6:46 pm
Or "wolfenstein 3d" and doom ... or even duke nukem 3d. And in case you didn't know, they all used ray casting, and duke nukem just got clever with it. It wasn't until quake that you got *real* 3d graphics.
#101374 - sajiimori - Mon Sep 04, 2006 7:51 pm
Contrary to popular belief, Quake was not the first game with full 3D graphics. It wasn't even the first full 3D FPS -- Future Shock came out a year earlier.
#101384 - keldon - Mon Sep 04, 2006 9:40 pm
Wikipedia >> http://en.wikipedia.org/wiki/Terminator:_Future_Shock
Playable demo >> http://uk.gamespot.com/pc/action/terminatorfutureshock/index.html
Wow, I wonder why it is never mentioned. There is also that space shooter thing I have a playable demo of somewhere with "6 degrees of movement" or something. But I'm not sure when that came out or what technology is behind it.
#101386 - sajiimori - Mon Sep 04, 2006 9:49 pm
Are you talking about Descent? That was a very popular game that came out in 1994. The source is available now.
#101387 - keldon - Mon Sep 04, 2006 10:15 pm
Yes that's the one.
#101391 - cppdungeon - Mon Sep 04, 2006 11:39 pm
all i really want, is the apperance of 3d, so any information on this ray casting thing would be much appreciated (like in doom).
thanks!
_________________
"in Soviet Russia, car pimps you!"
#101396 - sajiimori - Tue Sep 05, 2006 1:27 am
The Doom source is available, as are lots of tutorials on ray casting. A quick search yields plenty of results.
If you get stuck somewhere, feel free to post specific questions. :)
#102188 - thegamefreak0134 - Mon Sep 11, 2006 5:27 pm
OK, while we\'re on the subject, I have a quick question. In a \"true 3D\" engine on the GBA, how does one go about quickly filling polygons? I am working on just such an engine (in mode 4, cause that\'s just easier) and for some odd reason even using DMA to do the fills my line drawing for drawing the polygons themselves takes way too long. (Oddly enough, it does about 1 polygon per frame. Not good.) Any ideas on how to fix this?
I wanted to know if there is a way to draw the screen pixel by pixel, instead of line by line. I don\'t know if this is possible or possibly faster, as I have never dealt with the subject before. Can someone offer possibly a few links on the subject? Thanks.
-gamefreak
_________________
What if the hokey-pokey really is what it's all about?
[url=http:/www.darknovagames.com/index.php?action=recruit&clanid=1]Support Zeta on DarkNova![/url]
#102196 - sajiimori - Mon Sep 11, 2006 6:57 pm
Render a polygon at a time. While rendering a polygon, render a line at a time.
There are threads here about quickly filling memory with a specific value. In short, fill several registers with the value and use the stm instruction.
Fast polygon rasterizing has been talked to death for 15+ years. Mike Abrash went over it pretty well in his black book, which can be downloaded in PDF format.
#102197 - kusma - Mon Sep 11, 2006 6:58 pm
| thegamefreak0134 wrote: |
OK, while we\'re on the subject, I have a quick question. In a \"true 3D\" engine on the GBA, how does one go about quickly filling polygons? I am working on just such an engine (in mode 4, cause that\'s just easier) and for some odd reason even using DMA to do the fills my line drawing for drawing the polygons themselves takes way too long. (Oddly enough, it does about 1 polygon per frame. Not good.) Any ideas on how to fix this?
|
There's many ways of doing "true 3d" (gosh, I *hate* those kinds of terms) on the gba, but the most common way is indeed scan-converting the polygons and drawing a span at the time. this is fairly efficient, and can be unrolled quite well. don't expect to be running fullscreen scenes in 60fps though.
fatmap2.txt is a quite good documentation of how to write efficient fillers, as is the chris hecker tutorials.
that being said, i really love renderers that work in completely different ways. http://www.pouet.net/prod.php?which=5235 and http://www.pouet.net/prod.php?which=18299 are some good examples imo. another (and way cooler) example will be availible in some time from the shitfaced clowns.
#102198 - kusma - Mon Sep 11, 2006 7:01 pm
| sajiimori wrote: |
| Fast polygon rasterizing has been talked to death for 15+ years. |
...and still, it's nowhere near where it should be :)
#102214 - thegamefreak0134 - Mon Sep 11, 2006 9:07 pm
OK, I\'m not even tlking about texture mapping, I\'d be happy with a solid color at this point. Perhaps is doing a 3D engine of any kind in C out of the question? I was really trying to steer clear of asm coding...
Anywho, I\'m not quite sure I follow on the points mentioned. I\'ll look into some tutorials mentioned and see if I can make anything of it, but being a little un-familiar with the terminolagy doesn\'t help much, as I am very new to 3D coding in general.
Thanks guys!
-thegamefreak
_________________
What if the hokey-pokey really is what it's all about?
[url=http:/www.darknovagames.com/index.php?action=recruit&clanid=1]Support Zeta on DarkNova![/url]
#102221 - sajiimori - Mon Sep 11, 2006 10:46 pm
I bet you could get a reasonable framerate for simple scenes of solid-filled polys using only C. However, I'd recommend at least stealing someone's optimized memory filling code.
#102408 - thegamefreak0134 - Wed Sep 13, 2006 8:42 pm
I have. I\'m using TONC\'s memset routine. OK, what is a \"reasonable\" ammount of polygons to have filled in a frame? I wouldn\'t think 1 would be that much... I\'m already checking for backface culling and such, and it\'s still doing it real slow-like. Of course, there are a couple of other concerns...
I figured that perhaps my problem isn\'t in the line drawing routine so much as in the triangle point sorting-stuff required to make the polygon fill itself work. (I\'m using a fairly common method of running down the triangle drawing a single line from side A to side B.) I\'ll post my code tommorrow and maybe you can tell me if there\'s something I\'m doing insanely wrong. I\'ll comment it heavily of course. Note that I know little of optimizing 3D operations, and also note that I could not use the 9 multiplication matrix for transformations because it wouldn\'t work, so I\'m stuck with the 12-ulti version.
I\'m having issues...
-thegamefreak
_________________
What if the hokey-pokey really is what it's all about?
[url=http:/www.darknovagames.com/index.php?action=recruit&clanid=1]Support Zeta on DarkNova![/url]
#106453 - Yare - Thu Oct 19, 2006 8:01 am
These tips might help you if you're a newbie programmer:
Avoid putting conditionals in your loops.
Avoid function calls in loops if you can, because jumping around in memory essentially invalidates the cache.
Any time you have a loop, precompute any constants with respect to the loop and pull them out so they aren't being recomputed needlessly...
Whenever you're doing scan-conversion, derive an incremental algorithm for it. At each step the most work you should be doing to find your new position is a single increment.
Avoid casting real values to discrete values until you absolutely have to -and if you have to, try and make sure you do it outside of as many loops as you can.
Hope some of that helps =/
#106465 - kusma - Thu Oct 19, 2006 10:28 am
| Yare wrote: |
These tips might help you if you're a newbie programmer:
Avoid putting conditionals in your loops.
|
Conditionals aren't that bad on ARM CPUs, as you have condition-codes on most instructions. But hey, less instructions usually perform faster.
| Quote: |
Avoid function calls in loops if you can, because jumping around in memory essentially invalidates the cache.
|
The GBA has no caches, so this doesn't apply here.
| Quote: |
Any time you have a loop, precompute any constants with respect to the loop and pull them out so they aren't being recomputed needlessly...
|
Most modern compilers detect such cases when optimizations are turned on. But it's a very valid point for code readability, since you show better what is done.
| Quote: |
Avoid casting real values to discrete values until you absolutely have to -and if you have to, try and make sure you do it outside of as many loops as you can.
|
This sounds like you're used to x86 where you need to change the FPU rounding mode etc if you want IEEE-compliance in your float to int-casts. As the gba has no FPU this is hardly an issue since you should try to avoid using plain floats anyway.
#106480 - Yare - Thu Oct 19, 2006 4:15 pm
Yes, I've done all of my graphics programming on x86 CPUs. I've programmed PIC microcontrollers for robitics applications but I've not programmed a microcontroller for graphics yet.
When using a software floating point solution on the PIC, conversions from float to int still take quite a few instructions. I guess the overall point of my post was that a programmer should strive to do the minimum amount of work possible in a loop.
The point about compiler optimization is a good one, but I think it's important to teach good programming practices to the new generation rather than tell them to rely on a feature that isn't part of the language standard.
As for the cache, I was under the impression that most microcontrollers did have a small instruction cache. Is this an ARM-specific missing feature?
-Yare
#106482 - poslundc - Thu Oct 19, 2006 4:48 pm
| Yare wrote: |
| The point about compiler optimization is a good one, but I think it's important to teach good programming practices to the new generation rather than tell them to rely on a feature that isn't part of the language standard. |
Of course, one of the best standards in any language is not to prematurely optimize away your code's readability, verifiability and maintainability in exchange for performance.
| Quote: |
| As for the cache, I was under the impression that most microcontrollers did have a small instruction cache. Is this an ARM-specific missing feature? |
ARM is a CPU, not a microcontroller, and doesn't assume a memory system, so a cache is optional. The GBA doesn't have a cache, but has a single-instruction prefetch. Branches will invalidate the prefetch (as well as flush the CPU's three-stage pipeline), but conditional execution won't.
Dan.
#106483 - kusma - Thu Oct 19, 2006 4:52 pm
| Yare wrote: |
The point about compiler optimization is a good one, but I think it's important to teach good programming practices to the new generation rather than tell them to rely on a feature that isn't part of the language standard.
|
Also remember that your compiler is a mighty tool. It can generate better code in microseconds than you can do in hours, and it doesn't differ between inner- or outer-loops (and therefore optimizes everywhere). Use it for all it's worth, be lazy on it's behalf - you'll save a lot of development-time that way.
| Yare wrote: |
As for the cache, I was under the impression that most microcontrollers did have a small instruction cache. Is this an ARM-specific missing feature?
|
No, most ARMs are configured with both an instruction- and data-cache. But not the one on the GBA. A cache would not help much, because of the low clock frequency / high-speed memory configuration chosen in the GBA.
To try to pull my nit-picking back on track, I'd like to give away my best optimization-trick:
Never ever optimize before profiling. Know that you're working on a bottle-neck, know that your time is spent at the code with the most potential speed increase. That way, you'll not only work efficiently - you'll also stay motivated.
#108695 - Ant6n - Sat Nov 11, 2006 10:38 am
if you wanna fool with 3d, try abrash's black book
http://www.gamedev.net/reference/articles/article1698.asp
chapter 39?
anton