#15159 - dagamer34 - Sun Jan 18, 2004 5:54 am
Does anybody know of a tutorial or a site that I can look at that will teach me how to render a triangle onto the screen? It doesn't have to be GBA-specific (i doubt you'll find any) but i am having trouble finding any. All i can find are sites that tell you how to draw a polygon with opengl or d3d.
Maybe give me some keywords i can search in google.
_________________
Little kids and Playstation 2's don't mix. :(
#15165 - tepples - Sun Jan 18, 2004 6:50 am
This book should help you greatly: ISBN 1571690042
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#15178 - poslundc - Sun Jan 18, 2004 4:55 pm
This site seems to have some good links. Keywords I used in google were "3d algorithm tutorial".
Dan.
#15198 - dagamer34 - Sun Jan 18, 2004 9:59 pm
So you draw polygons based on edge tables??? And i thought Direct3D and OpenGL was this big giant API that only master coders could understand...
However, realistically, the GBA is too slow to do any good 3D, right? That is if i am coding it.
_________________
Little kids and Playstation 2's don't mix. :(
#15199 - sajiimori - Sun Jan 18, 2004 10:14 pm
| Quote: |
So you draw polygons based on edge tables???
|
Draw them however you want.
| Quote: |
And i thought Direct3D and OpenGL was this big giant API that only master coders could understand...
|
You think they are small now?
| Quote: |
However, realistically, the GBA is too slow to do any good 3D, right?
|
The most technically advanced 3D stuff I've seen on GBA is Yeti3D. You can decide for yourself whether it matches your standards for "good 3D".
#15202 - DekuTree64 - Sun Jan 18, 2004 10:33 pm
You can either generate edge tables and draw from that, or just draw as you trace down the edges. That's how the tri-fillers in my 'Eternity' demo worked (you can get the source from my site at http://www.angelfire.com/wizard/deku/program.html), the triangle-related C files aren't actually used in the demo, I just left them there for such occasions as this, although the flat filler uses a C-buffer that I was trying out, so the inner loop looks confusing. You can still see how the edge tracing goes though. TriTexAffine.c is non-C-buffered, and not too much more complicated, so you could check that out too if you want.
If I was going to make a 3D game, I would probably go with edge tables. I was pondering on an S-buffer based system a while back, which had everything textured, and would just go through adding spans to the buffer, and then use a small, highly optimized loop to render the screen all in one go. I scribbled out the whole rendering loop on paper just to see if it would work, and I'm pretty sure it would. Then I started working on a convex polygon (as many sides as you want) scan converter for it, but I never got very far, because I'm not all that interested in 3D anyway.
Maybe next time I need a break from my RPG I'll go work on that some more. 3D really is fun to program, just not so much fun to play, if you ask me
_________________
___________
The best optimization is to do nothing at all.
Therefore a fully optimized program doesn't exist.
-Deku
#15264 - dagamer34 - Tue Jan 20, 2004 5:11 am
I said if I was the one to code it..
_________________
Little kids and Playstation 2's don't mix. :(
#15267 - sajiimori - Tue Jan 20, 2004 5:56 am
Then it makes even less sense to ask us.
#15276 - funkeejeffou - Tue Jan 20, 2004 9:28 am
The GBA can definetly do software 3D rendering. Look at Yeti3D evolution and if you still do not agree I think we can say that you're kind of idiot. Besides, Yeti3D demo does not only do 3D rendering but also has a IA engine (they're more like automates), collision detections... Quite a good job Derek Evans.
I coded before the BorderLine demo fo the compo. It was the fruit of 17 days of hard work in ASM. I so much thought that the GBA could'nt handle it that I messed up the resolution of the scenes to gain speed. I shouldn't have done that. I'm certainly gonna do another 3D engine for the GBA and I'll hope it will be better than the yeti3D, GBA can do great things by its 14 32-bitsregister, just wait.
Also, you might wanna look at bobeetec web site or agb one.
#15303 - Nessie - Tue Jan 20, 2004 5:55 pm
The question, 'Can the GBA do 3D?'...is pretty different from what I believe is a more suitable question, 'Can the GBA do 3D well?'.
The answer to the former is 'yes'...I think the answer to the latter is 'no'.
So I guess I'm an idiot.
Don't get me wrong, I was impressed with Yeti3D and I am in no way attempting to trounce on the work of the programmer. It's just that, perhaps depending on people's previous experience with 3D, the framerate and rendering quality may be considered sub-par.
Then again, any 3D Playstation games I played (which is admittedly not all of them) had unacceptable rendering issues (to me), and yet that didn't stop a whole lot of people from playing those games. I guess I had experienced N64 (and those frequent blurry textures, but otherwise solid rendering) and accelerated PC 3D graphics and so maybe I was a bit jaded at that point.
Still, it's cool to see people doing 3D graphics on the GBA, as a hobby and/or a technical exercise. I'm not really sure what kind of market would really be though....which only matters if you are trying to take the technology some where. That should not be a consideration in a 'doing it for fun project'.
#15317 - Miked0801 - Tue Jan 20, 2004 8:29 pm
Tony Hawk for GBA.
#15321 - sajiimori - Tue Jan 20, 2004 8:39 pm
| Quote: |
Then again, any 3D Playstation games I played (which is admittedly not all of them) had unacceptable rendering issues (to me), and yet that didn't stop a whole lot of people from playing those games. I guess I had experienced N64 (and those frequent blurry textures, but otherwise solid rendering) and accelerated PC 3D graphics and so maybe I was a bit jaded at that point.
|
You realize that Playstation was out years before N64 and decent consumer 3D acceleration on PC? I mean, you wouldn't go look at the original Star Wars arcade game and say, "Pffft! That rendering quality is just unacceptable."
#15325 - Nessie - Tue Jan 20, 2004 9:00 pm
What I'm saying is, I played N64 games and 3D accelerated PC games first. I later got a PSOne to play Symphony of the Night and rented various other games for the system.
So, what I've been saying all along is that my experience has been that PSOne quality 3D is generally very poor. Not even compared to any other system...just evalutating it based on my experiences.
And I feel the same about any 3D GBA work I've seen. (Yes I am expressing my own personal opinons) It may be good for the GBA, but that doesn't mean I think it's any good in it's own right.
Regarding Tony Hawk, if I recall, the games play on a pre-rendered (or drawn) scrolling backdrop and use a 3D modeled character.
If that's true, that hardly constitues a true, fully 3D environment.
#15330 - tepples - Tue Jan 20, 2004 9:47 pm
Is true 3D always necessary? Did the limitations of flat floors, walls, and ceilings of 2.5-D Doom or the lack of caves of height-mapped Comanche interfere with your enjoyment of those games?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#15332 - Nessie - Tue Jan 20, 2004 10:10 pm
I think you're missing the point. The question was not whether I prefer 2D or 3D.. One of the earliest questions in this thread was: | Quote: |
| However, realistically, the GBA is too slow to do any good 3D, right?... |
I am essentially agreeing..I don't generally think the GBA is a very good platform for trying to do 3D work, especially a fully 3D FPS environment.
There may be cases of hybrid systems (like Tony Hawk) where it works. And it may be a fun exercise to see how far you can push it....If something like Yeti3D is being done for fun, that's fantastic. It's a great piece of work and I can appreciate the amount of effort put into it.
But I doubt you'll get much sympathy trying to relase something like [insert 3D GBA demo here] on todays game market (if that's the intent)--the resolution and framerate are probably too low for gamers who may be used to Xbox, GCN, PS2, N64, Dreamcast, PC... quality 3D.
#15333 - sajiimori - Tue Jan 20, 2004 10:21 pm
I dunno... how did the GBA Doom games fare in sales? Do you feel that those compare well to the state of 3D on more powerful platforms?
#15348 - funkeejeffou - Wed Jan 21, 2004 5:02 am
The GBA is a 2D plattform dedicated console, it handles a lot of 2D functiuns in its hardware, and none for the 3D. Of course, it wasn't meant for doing 3D, but do you think that the old 386 or 486 were meant to do 3D in the early nineties?
No, but besides this fact, some game programmers began experimenting 3D software rendering and wanted to push the machines to there limits wich was really a big deal (the ideas they came up with back then where really great, like Fixed Point, precalculated div tabs, precalculated cos/sin tables...). 3D cards came as a consequence of it, and nowadays 3D coding = openGL or DirectX.
OpenGL and DirectX are fun but not as much as creating by hand line algorithms, texture mappers or lighting filling etc. I'm 23 years old and I've been coding for 2 years now, so I haven't lived this great period where coders would come up with any idea to win some CPU cycles or some bytes int he RAM. The GBA is a great opportunity to push our code skills as if it was a 486, and I think that's great for coders who like doing "complicated" stuff and who wants to test themselves.
This console is great, it is not a beast but it is not as hopeless as a Z80 for 3D rendering. It is really a cool technological toy.
#15349 - tepples - Wed Jan 21, 2004 5:55 am
Fact: The Z80 at 4 MHz did Faceball, a raycasted "3D" game (actually 2D in a uniformly extruded plane) that looked like somewhere between Battlezone and Wolfenstein. This gives ARM7 programmers hope to do more. "Because I can" is right. And who knows? The Yeti3D engine, the Payback engine, and other similar engines might actually have some practical use on GP32 or on a future overclocked GBA.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#15354 - bomberman - Wed Jan 21, 2004 11:12 am
Have a look at this:
http://www.nickm.launch.net.au/ProjectArchive/crasher.html
Wolfenstein style game done on a 20 years old computer, the Tandy Coco 3. It's not a Z80, but a 6809.
OK it's not like playing on a Dreamcast or a PS2, but still it exists...
#15406 - dagamer34 - Thu Jan 22, 2004 4:54 am
I didn't mean to start a debate here.
Anyway, back to my problem...
I don't know how to get the edges of a polygon. I was looking at one of the sites and it had a little bit of psuedocode in it yaustar was talking about. http://www.geocities.com/SiliconValley/Park/9784/otmpoly.txt
It says to determine which side is the longest and store it on the left side, and then put the other 2 sides on the right. Is that right? Just throw out code here if you want to. I won't complain.
_________________
Little kids and Playstation 2's don't mix. :(
#15407 - Miked0801 - Thu Jan 22, 2004 5:37 am
One way is to Breshenhiam <sp> the edges into a RAM buffer.
Take the long edge, use the line algo to trace your Left edge. Now do the same for your other two vertices for the right edge. By defintion, a triangle must be concave so therefore a horizontal (or vertical) line can be drawn from the left(top) edge to the bottom edge continously without exiting the poly. Just setup a loop of line starts and lengths then blit away. For extra credit, assign a color value to each vertice and linearly extrapolate it along the edges, then across each horizontal line Gourand shading.
#15557 - Cyberman - Sat Jan 24, 2004 8:57 pm
There have been rumors of Nintendo creating something like the super FX chip for the GBA, I personally would not be thrilled with that approach. Reason is the cost per game would be rather high (you pay $40 for the software and $10 for the additional hardware and packaging costs roughly). Perhaps they need to offer the 3d Advance instead?
Adding aceleration hardware isn't so bad if the hardware directly attaches to the GBA interface and the data ROM attaches to the hardware. I've actually gotten 1/4 the way through the design process on something like that, it just looses it's appeal quickly after a certain point due to API concerns (yes you need to have an API to go with that hardware .. EGL I suppose would be fine but you still need to design your hardware with the API in mind).
As for the original querry YEP it's possible to do.
YEP it's possible to make nice looking even.
NO it's not possible to make it fast and nice looking without some serious help.
I babble again :)
Cyb
_________________
If at first you don't succeed parachuting is NOT for you.
#15559 - sajiimori - Sat Jan 24, 2004 9:41 pm
Out of curiosity, what sorts of API concerns did you encounter that would make such a product lose appeal?
#15562 - dagamer34 - Sun Jan 25, 2004 12:43 am
How do you determine which side is the longest?
_________________
Little kids and Playstation 2's don't mix. :(
#15599 - Tim - Mon Jan 26, 2004 12:05 am
| dagamer34 wrote: |
| How do you determine which side is the longest? |
It's not the actual longest side of the tri you want, It's the side of the triangle which joins the highest and lowest point of the triangle on the y axis.
#15649 - Cyberman - Tue Jan 27, 2004 12:38 am
Making a complient API is a PITA, and I personally would not be able to do it in a timely manner. Even if I had full time from the day I started, it is a nine month project for one person, additionally there is the hardware realization. The engine was morphic however that is one could change the hardware as needed (think cheap FPGA and you have the idea down instantly). Cost for a hobby type device is not a big deal either.
Big costs of such an adventure:
Lo Power SDRAM 1.8 actually. (1 RAM 64M, 128M or 256M x32 device)
FPGA (1.8V also :) ).
Boot ROM
Regulator for the FPGA and SDRAM
The GBA itself programs the FPGA (no joke) for the 3d engine this reduces parts and cost but means start up will take a bit of time, thus a good time to have a those splash screens (this will take a couple of seconds to do so all the 'intro stuff' can happen while the FPGA is configured).
From that point comes the cost of IP, IE investing time in developing hardware suited for the chosen API. For simpleness, EGL was my choice (as opposed to making ones own or using something like DX API). EGL is a subset of OGL 1.3 spec.
Again the meat of the work is in the API. I suppose one could make a EGL complient API first in software then add the hardware features (works just as well).
And that is what the problem with the API is :)
Cyb
_________________
If at first you don't succeed parachuting is NOT for you.
#15762 - Derek - Thu Jan 29, 2004 5:05 pm
Excuse my lack of knowledge of FPGA's
So, does that mean you can programme a FPGA to render graphics? Im guessing it could also handle batch rotation of vertices.
For the GBA, EGL sounds a little bit of an overkill.
How hard would it be to support a PSONE style API? ie: Basic flat and non-perspective correct texture mapping?
Yeti3D has two bottle necks.
1) 8bit to 15bit lit Texture mapping.
2) Batch vertex rotations.
Both are handled by two simple functions. I doubt an entire OGL API would be required. The bulk of Yeti3D's speed comes from caching vertices.
RE: Yeti3D on the GBA.
Yep, sure. I agree. The demos are too slow for commercial games. I was hoping a 2X-3X faster GBA processor would be out by now. A Wolf3D/DOOM style world does run fast enough, but who wants limited worlds. GP32 runs this stuff at 25-35FPS at 320x240. The GBA has a lot of catchup todo.
The demos I release are designed to push the limits so I can measure bottle necks.
Luckily Yeti3D source isn't GBA/ARM based and there are a bunch of new devices comming out. So, the future is very bright.
Derek Evans - Yeti3D Author
http://www.theteahouse.com.au/gba/
#15927 - Cyberman - Wed Feb 04, 2004 5:19 pm
| Derek wrote: |
Excuse my lack of knowledge of FPGA's
So, does that mean you can programme a FPGA to render graphics? Im guessing it could also handle batch rotation of vertices.
|
The FPGA becomes a memory maped coprocessor. The 3d buffer is maped into the GBA's space. Since an FPGA is programable it's up to you what it can do (well also it'self but lets not get too far ahead). The idea was to queue a set of instructions for the simple engine and let them execute. Matrix multiplication etc is possible, but it's debatable which is more affective using the ARM to do that or the FPGA. You would have enough resources to do it either way. The FPGA was primarily slated for handling the shading and rendering of the graphics (which is an operation well suited for it). If you wish to do Vertex rotation and manipulation of 3d information, I suppose you could do that as well, I'm not sure how much of the FPGA the rendering engine would consume but the later would not be trivial. Fortunately most FPGA's these days have built in multipliers.
| Derek wrote: |
For the GBA, EGL sounds a little bit of an overkill.
|
There are reasons for standards, but it's something to shoot for, mostly the priciples of EGL, consider portability a BIG issue. The less work porting something the better in otherwords.
| Derek wrote: |
How hard would it be to support a PSONE style API? ie: Basic flat and non-perspective correct texture mapping?
Yeti3D has two bottle necks.
1) 8bit to 15bit lit Texture mapping.
2) Batch vertex rotations.
|
8->15 bit conversion would be eliminated since everything would be 15 bit color (DMA'd to the screen) when rendered. Textures are stored in the FPGA's SDRAM along with the current frame buffer. Rendering happens in the FPGA. 1 of 2 isn't bad is it? ;)
| Derek wrote: |
Both are handled by two simple functions. I doubt an entire OGL API would be required. The bulk of Yeti3D's speed comes from caching vertices.
RE: Yeti3D on the GBA.
|
Well often what appears to be simple in software has a different perspective in hardware.
I suppose I should write up a state engine and emulate that and see how it goes, good thing I have VBA source handy.
| Derek wrote: |
Yep, sure. I agree. The demos are too slow for commercial games. I was hoping a 2X-3X faster GBA processor would be out by now. A Wolf3D/DOOM style world does run fast enough, but who wants limited worlds. GP32 runs this stuff at 25-35FPS at 320x240. The GBA has a lot of catchup todo.
The demos I release are designed to push the limits so I can measure bottle necks.
Luckily Yeti3D source isn't GBA/ARM based and there are a bunch of new devices comming out. So, the future is very bright.
Derek Evans - Yeti3D Author
http://www.theteahouse.com.au/gba/ |
The processor on the GBA is an old ARM7thumb controller. If they upgraded it to an ARM9 thumb controller and choose a PLL that was programable adding in the ARM coprocessor for 3d graphics it's a no brainer. They could double IRAM and WRAM which would help as well. The problem nintendo is probably having is 'thinking like it was 2000' still. The aforementioned upgrades would keep the games compatible (speed wise etc.) and allow newer and superior games (perhaps doubling the video memory would be good too it's uncertain how to expand what they have by the way they set it up. <IMHO it was made to be like the SNES too much instead of leaving room for it to have a future beyond ported SNES games>).
Cyb
_________________
If at first you don't succeed parachuting is NOT for you.
#16028 - SmileyDude - Fri Feb 06, 2004 6:07 pm
I have a question regarding 3d on the GBA... how many triangles/sec should one expect from the GBA using a suitably coded renderer? I'm only talking flat triangles -- no texture shading or lighting at this point. Would rendering something like the Utah Teapot at 30fps be possible (someone estimated that's about a 1000 or so triangles. Since the only dataset I've found is in Bezier Patches, I can't confirm that)?
I'm only trying to get a rough idea here. Of course, there are a number of variables in this equation, like triangle size, graphics mode, etc, etc. I'm interested in hearing best case scenarios, and the tradeoffs involved with the using different modes (mode 4/5, rendering to a sprite/tileset, etc).
BTW -- how many triangles is the character in THPS? And what about Monkey Ball Jr? How many triangles would they be using to render the playing field? When I looked at it the other day, just the end goal appeared like it might be using close to a 100 triangles by itself (12 segments, each using 2 triangles per side == 96 triangles). Are they using real 3d for the board itself? Or, are they using a mode 7 trick to pull it off?
_________________
dennis
#16036 - Miked0801 - Fri Feb 06, 2004 10:56 pm
A good mode 4 engine should be able to pull off 3-4K flat shaded Triangle/Quads while running at 30Hz with a game (sound included) running in the background. That at least is what I've seen and experimented with. YMMV.
#16801 - KevinW - Wed Feb 25, 2004 4:55 am
I'd like point something else that might be missing from all this.
I see it as depending on what you are doing, one method might be better over the other. In terms of speed, and memory resources that is.
For instance an C/S/edge buffer type scheme might work better for your engine if there is a lot of overdraw. Because these algorithms save you big cycles where you are drawing large polygons.
Where as it is probably better not to use these algorithms and just sort and scan line draw your triangles when your scene consists of many small polygons. In this case the overhead (not to mention the added memory use) of managing so many small triangles might actually cause you more harm then good.
This applies to other parts of the 3D pipeline as well. For instance a BSP might be great for indoor ?room? type engines, but not so hot for large out door situations.
Plus the way 3D graphics might be used in a game can vary a lot. Like the prerendered background engines (see Nocturne (PC), etc) with 3D models drawn on top. Doom where you got restricted DOF; or like Unreal, or Quake where you got full DOF.
Nothing is to say you can?t even find new ways of combining various techniques for your own circumstances.
I even have this idea now where you could cache different routines in IWRAM depending on the fly to handle different situations.
Also take a look at the Quake 1 software rendering source code.
They draw the backgrounds in quads creating a Z-buffer at the same time.
Then they use this Z-buffer in drawing triangle models after.
Plus it might depend on how (if at all) you have any type of lighting, shading, transparency, filtering, texture rendering, etc.
So one must sit down and work out the limitations and do cleaver R&D (time permitting) on what works the best for thier given situation(s).
I?m not knocking anyone, nor saying one algorithm, is better then the next. Rather pointing to find the algorithms and perhaps go so far as inventing new ones that fit your particular project.
#16926 - rapso - Fri Feb 27, 2004 8:46 am
| Miked0801 wrote: |
| A good mode 4 engine should be able to pull off 3-4K flat shaded Triangle/Quads while running at 30Hz with a game (sound included) running in the background. That at least is what I've seen and experimented with. YMMV. |
3k-4k flatshades triangles per frame (with 30hz) or per second?
rapso
#17029 - Miked0801 - Sun Feb 29, 2004 7:37 am
30Hz meaning 90+K polys or so per second. Flat shading can be done real real fast. Divide this by about 3 for Gourand shading and by about 10 for textured (not corrected) polys. Even flat shaded, you should run into fill rate issues before anything else if you're really optimizing well. Mode 4 is nice though as it allows double fill rate :)
I forget what the inner loop speed was, but the cycle count per pixel was well in the single digits.
#17055 - rapso - Sun Feb 29, 2004 3:08 pm
| Miked0801 wrote: |
30Hz meaning 90+K polys or so per second. Flat shading can be done real real fast. Divide this by about 3 for Gourand shading and by about 10 for textured (not corrected) polys. Even flat shaded, you should run into fill rate issues before anything else if you're really optimizing well. Mode 4 is nice though as it allows double fill rate :)
I forget what the inner loop speed was, but the cycle count per pixel was well in the single digits. |
that's impressive, you're pushing 9k textured polys per second, the blue roses engine just pushes about 3k and myone 3024polys (without sound and logic), did you write the whole engine in assembler?
my blue-roses-source:
http://www.the-magicbox.com/game031302c.htm
greets
rapso