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.

Announcements And Comments > Something that bothers me about the compo

#26843 - tomer - Mon Sep 27, 2004 9:31 am

I have read the next compo rules, and one thing that bothers me
is the rule, that commands us to send the source code of the project.
Why is that?
I can compile my own engines myself, and send the compiled ROM.
what's wrong with that Simon?

And two more things:
1) Simon, I think it would be really cool, if you open a new page
on the site about the compo, and every potential competitor will
send his screenshots, and describe a bit about his project, so we could
all be anxious, and of-course guide each other(if wanted)

2) I've been keeping up with DS development, and it seems, that
no software could easily emulate the 3D chip features.
I've heard that hardware box will do that.
so, what exectly can you tell us, that we might not know?
any developers licked info? or maybe homebrew projects?
anyway i'm excited to see it in action, although I am quite
sad, that no software rendering will live these years (shame, cause
I spent alot of time learning the core functions by software). But,
I guess, that now good programmers will be measured by other
3D algorithms (VSD, HSR, Quality etc..).

3) and I demand you to keep GBADEV.ORG alive no matter what
happens in the potable gaming industry. these little GBA machines
are like the best thing, that fell in my hands. Unlike most of
GBA programmers, I'm developing 3D for the GBA, and I hope,
that soon enough I will release a mega 3D project for all of you.

Thanx in Advance, you are all great
Cheers, Tomer!

#26855 - bahnhof - Mon Sep 27, 2004 4:41 pm

Hardware rendering isn't necessarily easier than software rendering. The more complex things in 3D engine development are still there. Writing polyfillers and camera math is pretty easy but it's the engine structure which needs a lot of thought. With hardware accelleration that part is still there. Additionally, 3D engines have become far more advanced since we can program our own shaders now.
I think most good 3D engines for next generation consoles or PC are many times more complex than any GBA software rasterizer one could write since there are less boundaries. 3D engines on Gameboy Advance require a lot of dirty/smart hacks/tricks but that doesn't make someone a good programmer. There's more to explore in hardware acceleration right now, there are already many documents on software rendering and the most amazing things have been pulled off on the amiga for instance.

I may have misunderstood your point ^_ ^

#26856 - SimonB - Mon Sep 27, 2004 5:18 pm

tomer wrote:
one thing that bothers me is the rule, that commands us to send the source code of the project. Why is that?


Compo Rules wrote:
Entries selected to be on the cartridge must be prepared to submit all source/scripts/graphics etc


The rules doesnt command you to send the source code of the project. Only if your game is selected to be on the cartridge must you be prepared to send in the source in case we ask for it.
It is possible that we will not ask anyone to send in their source code but if it will help in the integration of the games we just might. Also, if we suspect theft or if we need the source for any other unknown reason we put it in the rules.

tomer wrote:
I can compile my own engines myself, and send the compiled ROM.
what's wrong with that Simon?

There isnt anything wrong with that and nor have I said so. its exactly how you should do it. You compile the game and send it to us.

tomer wrote:
1) Simon, I think it would be really cool, if you open a new page
on the site about the compo, and every potential competitor will
send his screenshots, and describe a bit about his project, so we could
all be anxious, and of-course guide each other(if wanted)

Thats a good idea. At least we need to get up a proper site for the competition and your idea wouldnt be hard to implement at all.

tomer wrote:
2) I've been keeping up with DS development, and it seems, that
no software could easily emulate the 3D chip features.
I've heard that hardware box will do that.
so, what exectly can you tell us, that we might not know?
any developers licked info? or maybe homebrew projects?
anyway i'm excited to see it in action, although I am quite
sad, that no software rendering will live these years (shame, cause
I spent alot of time learning the core functions by software). But,
I guess, that now good programmers will be measured by other
3D algorithms (VSD, HSR, Quality etc..).

I cant tell you anything because I dont know. I dont sit on a ds dev kit or any ds documents or info.

tomer wrote:
3) and I demand you to keep GBADEV.ORG alive no matter what
happens in the potable gaming industry. these little GBA machines
are like the best thing, that fell in my hands. Unlike most of
GBA programmers, I'm developing 3D for the GBA, and I hope,
that soon enough I will release a mega 3D project for all of you.

Well OK, I wont shut it down, but only because you demanded it ;)

Simon

#26876 - tepples - Tue Sep 28, 2004 1:28 am

In practice, integration will probably require only the game's object code (as one or more .o or .a files) and a license to use it in a commercial project.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#26998 - Jagos - Fri Oct 01, 2004 12:05 pm

Actually is not necessary any .o files. Just like we are used to compile any project with a starting address of 0x08000000 the only requirement to make a multigame cart would be to compile every game with starting addresses of 4Mbit space between them, i.e.

menu 0x080000000
game1 0x080080000
game2 0x080100000
game3 0x080180000
... ...

Next you create the rom using something like
copy/b menu.bin+game1.bin+game2.bin+... multigame.gba
(of course every rom has to be 512kb in size)

And the menu code must only jump to the code of a game with something like "b 0x0800xx0000" to execute a game when is selected.