#3138 - linus - Tue Feb 18, 2003 10:31 pm
ok im a complete noob when it comes to gba programming, but im looking into it because ive been interested in making games for a while and have general idea of how to do it.
the basis for my engine is that there are 3 threads sound,graphics and main stuff. i was tryin to find some information on whether threadin on the gba was possible, are there any tutorials or anything out there?
#3141 - peebrain - Tue Feb 18, 2003 10:51 pm
Umm... kind of... Might want to check out information on interrupts :-).
Pern Project has a little section on it... www.thepernproject.com
~Sean
_________________
http://www.pbwhere.com
#3142 - tepples - Tue Feb 18, 2003 10:58 pm
It would probably be possible to write a preemptive scheduler that plays with interrupts and the stack, but I wouldn't recommend it for game applications on such a limited system, where everything is usually synchronized to vblank. Instead, put a cooperative scheduler in main() and call each thread's run() method, which should do a little bit of work and then return within a couple milliseconds. (Learn more: 1 | 2)
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#3147 - mbcook - Wed Feb 19, 2003 1:53 am
I agree with tepples. It could be done, but when you have so little resources in the first place, a scheduler will use up a long of important CPU time. It's better to just use a big loop or some such.
It doesn't make much sense in the first place anyway. The main use for threads for graphics (as far as I know, at least in the PC world) is to keep the game running smooth no matter how fast the PC is, so the framerate changes, but the game doesn't appear to slow down; since hard coded delays, etc don't work with different speed CPUs. But on a closed platform like the GBA, you can hard code delays and such so it's not a problem. As for sound, you can just use an interupt for that. So while it could be done, it's be a waste, I think.
_________________
--Michael
#3150 - CoolMan - Wed Feb 19, 2003 2:11 am
I was a n00bie at game engine theory just a year or so ago. As such, I came up with (what i think is) a fairly unique approach.
If you write all of your functions so that they process and return as quickly as possible, then you can have your main thread do all of the basics: (Sound work, button state checking, graphics refresh, etc.) Then comes the fun part...
You write all of your gameloop processes (game engine logic, pause menu logic, main menu logic, etc) so that they do all of their processing and return quickly.
You write a 'launcher' function for each of these processes, which (again, quickly) sets up the state of the process... (Where is the arrow in the pause menu, etc.) and pushes the process on a function stack in main.
Yes, a function stack. Game logic is running, if the user presses START, then push the pause menu on the stack. Pause menu polls the START button, and when it is pressed, pops the stack, and returns to the process under itself. (Gameloop)
Anyway, I've managed to explain my method very badly, and I doubt that I'll be explaining it any better anytime soon.
The gist is that I like threads very much, but have discovered the magic of single-thread game engine coding through a function pointer stack interface.
/me shuts up now.
_________________
Moron! You don't herd chickens with a shotgun!
--CoolMan
#3152 - mbcook - Wed Feb 19, 2003 3:23 am
You're right, that is a bad description; but it's a very interesting idea. I'll have to think about it.
_________________
--Michael
#3189 - Vortex - Wed Feb 19, 2003 5:14 pm
CoolMan,
This is an interesting approach. The only problem I see is how to implement any interractions between your scheduled tasks (the tasks pushed into the stack to be executed). The question of syncronisation is also open.
I think the discussion touches a more fundamental problem: how to represent a real-life process (which is parallel in nature) using sequential means (i.e. the good old game loop). What makes the problem even more challenging is the number of objects is usually not constant.
I was not able to find any good resource how to solve that problem in general.
#3191 - CoolMan - Wed Feb 19, 2003 6:00 pm
Well, the way that I have been doing communication between processes is through global function calls which modify private variables.
I don't do much (any) object oriented coding, but I suspect that oop would be very good at what i'm describing.
I have only implemented my 'process stack' game engine theory twice now, the first time use integers and a switch case instead of function pointers. :) So, I'm still developing the idea.
If you guys wanna check out source code, I'm releasing my GBA game as GPLware in the next few months. I'll keep this community posted when that happens.
> The question of syncronisation is also open.
-I assume that you're talking about syncing with hardware? On the GBA, I've been using a VBLANK inter, which releases the main thread via a 'floodgate' approach. (Semaphores would be better, but the world isn't perfect.) :)
> I think the discussion touches a more fundamental problem: how to represent a real-life process (which is parallel in nature) using sequential means (i.e. the good old game loop). What makes the problem even more challenging is the number of objects is usually not constant.
-Agreed. And the answer can be found by looking at any single-processor, multi-tasking environment... Speed. If you have a machine that can do things faster then the user can percieve them, then you can successfully maintain the illusion of things happening at once. Fortunately, the GBA is fast enough to do this. Unfortunately, the GBA is NOT fast enough to be wasteful with your CPU and still do it successfully.
There are those that complain about a lack of recent technology in console systems. (Myself included.) However, this very lack of representation of current technology is the only thing that seems to produce good coders anymore. (This out of a 16 year old...)
I am not a good coder by my own standards, but I do like to think that I will be someday, and that one of the main ways to achieve that goal is to restrict my availible resources. (By, say, programming for the GBA...)
Anyway, I guess that was a rant... Sorry :)
_________________
Moron! You don't herd chickens with a shotgun!
--CoolMan