ZFGC
Resources => Coding => Topic started by: 4Sword on May 30, 2012, 05:19:47 am
-
Minish Cap GBA Programming using C/ASM though Tonc
(http://i8.photobucket.com/albums/a13/4Sword/minishGBA_screenSept3.png)
I am currently working on trying to understand how to program in C/ASM using Tonc to make games on the GameBoy Advance. This topic is to keep track of my progress in learning how to do that and to share my code with those who might find that useful. Eventually I plan on including documentation and tutorials on what I did, but this will be released after I reach and refine aspects of the coded features.
Updates
06/25/2012 (http://zfgc.com/forum/index.php?topic=39479.msg432347#msg432347) - simple sprites, background graphics, framework for having more than one room
07/08/2012 (http://zfgc.com/forum/index.php?topic=39479.msg433076#msg433076) - palette changing, having rooms larger than the screen size
08/27/2012 (http://zfgc.com/forum/index.php?topic=39479.msg436048#msg436048) - simple animation, Link's standing and walking graphics converted
09/03/2012 (http://zfgc.com/forum/index.php?topic=39479.msg436275#msg436275) - improved and irregular animation rates, movement added back in
02/03/2017 (http://zfgc.com/forum/index.php?topic=39479.msg453135#msg453135) - redone various improvements
-
Not exactly a bump of sorts but I thought I should say that I have been working on programming my Minish Cap code on the GBA by using the C programming languange and the tonc library/tutorials. I have some of the code done for diagonal movement at a reduced speed but mainly what I have done is a sprite system that puts together the sprites from pieces - just like the GBA does.
I was going to post my code for what I had so far for that, but it dawned on me that I could also get a rudimentary room and collision system implemented soon and that would make a more complete release. Otherwise though, I am wondering if the Game Maker stuff I posted is of any use to people or if you guys would like it better if I continued GBA stuff and put that out (and in so doing, trying to make the C stuff in such a way that someone who understands Game Maker can follow it)?
-
Always liked the MC Engine project. Keep it up, I would like to see you continue the GM version, as I think it would have more value here. But I understand it's probably more convenient to code the C version.
-
If time wasn't an issue, I'd recommend doing both.
-
Thanks. In some ways I want to still do both but I do get busy with work. I think what I will try to do is release unique features in Game Maker and focus on the plain and simple right now for C programming on the GBA. Oddly enough while I did take programming classes in C++, there are aspects of C programming which are somewhat initially confusing at first (bit-shifting, doing things not object-oriented, arrays of function pointers, etc.). Well really without tonc's (http://www.coranac.com/tonc/text/toc.htm) notes I wouldn't have made nearly any progress - it also doesn't help when the tools referenced in other GBA programming tutorials are either outdated or give the wrong output. Anyway:
(http://i8.photobucket.com/albums/a13/4Sword/minishGBA_screenA.png)
The demo doesn't show it off, by changing the room_index Link would be able to go to another room. I know I said I would have collisions implemented but I thought having some amount of background drawing would make it look a lot better first.
Current Features:
- putting together Link graphics from 8x8 size pieces, piece flipping
- being able to have more than one room
- C-style "object-oriented" alternative
- background graphics
- moving at a reduced diagonal rate (had to use hex value offset equivalents for precision like a boss)
The download is attached, if there is anything anyone wants explained I will try to answer as best I can - really, it would be cool if other people could program for the GBA too. I should also mention that the code is easier to understand if you view it through Programmer's Notepad.
-
If were programming GBA, would we have to keep in mind the file size limit, or since it being on the computer, it wouldn't matter.
-
I have not really thought about the file size limit of the GBA, but I know that graphics take up the bulk of the file size limit of any game. The GBA is able to do image flipping and palette shifting so if I was doing just Link movement on Game Maker I would need sprites for both facing left and right, and if I wanted to do all the tunics I would have to have redundant copies. The actual Minish Cap game appears to be about 16,384 KB and right now I am only at 10 KB so I should be fine.
That all being said, the GBA is really old so while it may be possible to run the stuff I am doing on an actual GBA - if it only works on an emulator that is fine too.
-
Wouldn't it be better to simply use SDL and compile a game rather than running it as a GBA game? I can see trouble when pirates start putting the ROM on cartridges and start selling it on eBay. Plus, doesn't it go slower because the ROM is interpreted rather than being a standalone executable?
-
Right on all points, Spirit. He could use anything other than <x>. But I don't know, I guess it's the novelty's sake for writing games on the GBA. Either way, it would be interesting to see what comes of this.
-
It would probably run faster if I did it with SDL (I have some knowledge of that or am familiar enough with the lazyfoo tutorials to where I could adapt what I had to use that too without the things like the 8x8 image piece restrictions), but that is mainly because computers that would run it have more resources available to them compared to the GBA. Heck, the reason I had to do treat 1.000 and 1.414 as something like 1000 and 1414 and then convert those numbers to hex was to get around the fact that the GBA can't handle floating point numbers nearly at all and I wanted to keep the precision (this is to say that the GBA can't do floating point stuff well like modern computers can).
But yeah, I don't think it is interpretted too much? Before it is compiled the code is very close to the Assembler level, and after it gets compiled it is in binary that the GBA understands. I guess it has to be interpreted by the emulator because it is not the actual hardware, but even so then the emulator takes advantage of the computer's processing ability. Speed-wise, it should be fine or comparable/better than Game Maker speed (which slows down based on the more you have).
I like programming on the GBA because it is a good way to have to constantly think about not making the program bloated by managing resources poorly. It also has built in sprite rotation and palette shifting which Game Maker either doesn't have or requires the professional edition. As for pirates, I plan on just releasing my code as an engine.
-
But yeah, I don't think it is interpretted too much? Before it is compiled the code is very close to the Assembler level, and after it gets compiled it is in binary that the GBA understands. I guess it has to be interpreted by the emulator because it is not the actual hardware, but even so then the emulator takes advantage of the computer's processing ability. Speed-wise, it should be fine or comparable/better than Game Maker speed (which slows down based on the more you have).
That is definitely not how emulation works. Every call is interpreted, so you have extra overhead for each CPU cycle that goes into the ROM. It doesn't matter if it's compiled down to the absolute binary that ARM7 requires. And whether or not your computer has the AVX instruction set or not, doesn't reap the benefits for how much processing power your software needs. The point of the matter is, you still have an extra layer of abstraction going on. You still are doing binary translation. The SDL version would still outperform the GBA emulated version by a large margin because it is simple computer science. It's like saying running an x86 binary on my core i7 would run faster on Windows XP than it would running the binary by itself(no OS). Which, if MOST cases, would be untrue.
Emulators whether you like it or not, will always run slower than native binaries. Not even javascript or any other languages that are compiled at runtime can outperform their native counterparts for the same reason. These days, however, there's been a trend in recompiling them the interpreted binaries against the native platform anyways. So that there just proved your argument wrong.
I like programming on the GBA because it is a good way to have to constantly think about not making the program bloated by managing resources poorly. It also has built in sprite rotation and palette shifting which Game Maker either doesn't have or requires the professional edition. As for pirates, I plan on just releasing my code as an engine.
You could do palette shifting just as easily on the computer. We have shader programs. Also, it's very possible to do it with the CPU but.. meh. GBA programming *is* fun. I was just saying, that it is a neat novelty to have a homebrew project running on the GBA. And that's not necessarily a bad thing? I didn't mean to sound so negative when I said that. More people should try console programming every once in awhile, imo. It has a lot to offer in regards to teaching someone about programming since you don't have the OS standing in the way of you and your hardware.
-
I am doing a poor job of explaining - I am thinking of this in relation to Game Maker and how it acts when you go to run a game or what a Game Maker executable is like. I know that the emulator has to process the GBA file and be a middleman between the computer and the GBA file, but the speed of the computer makes it so this is not too noticeable (and the GBA is about 10 years old, more recent computers shouldn't have speed issues with emulating it). In referring to C and Assembler I mean mainly that compared to Game Maker, I am not including a lot of the bloat of the stuff I am not using too.
But yeah, I get that SDL has image abilities that too I just wanted to give GBA a shot. I don't have to worry about recompiling everything so that the GBA file will work on other operating systems - the person with the other operating system just has to have a compatible emulator. And also programming for the GBA has been a childhood dream deferred, lol.
-
but the speed of the computer makes it so this is not too noticeable (and the GBA is about 10 years old, more recent computers shouldn't have speed issues with emulating it).
It'll be noticable side-by-side against the native SDL-based binary.
But yeah, I get that SDL has image abilities that too I just wanted to give GBA a shot. I don't have to worry about recompiling everything so that the GBA file will work on other operating systems - the person with the other operating system just has to have a compatible emulator. And also programming for the GBA has been a childhood dream deferred, lol.
Yeah like I said, GBA programming is fun. It's like writing code for the SNES, but rather than using assembler for a platform that has rather retarded design choices, you have the awesomeness of the SNES put into a platform that is less retarded with some of its design slapped ontop of a higher level language. That's why the GBA is so cool to write code on. It's by far the easiest 2D-Based console to write code on.
-
(http://i8.photobucket.com/albums/a13/4Sword/minishGBA_screenB.png)
Update(s)
- Added palette shifting (not "bounded" use equivalent of L and R to shift)
- Added views for rooms larger than the screen size
I'll post the code later once I make some refinements to the sprite system in how it gets loaded into memory and so that it handles animations. Otherwise though having rooms larger than the screen size was tricky to figure out. Essentially one of the smallest background units is 256 x 256 pixels. The screen size is only 240 x 160 pixels so you load more than you need, but if you have a large room getting as much background data as you can is important (so you don't have to reload the background as often).
The GBA file is attached which shows the progress.
-
You should look into how the various BG modes work in the GBA. I think mode 1 would be best for tiling, if my memory serves correctly. Mind you, it's been over 6 years since I've done any GBA coding. I remember pulling off some sweet mosaic effect though, using BG Mode 2 and some programming trickery. ;p
Good luck on this project.
-
I used Mode 0 because it seemed to be used in the Minish Cap to do the normal tiling. I saw that Mode 1 was used in the barrel inside the Deepwood Shrine but I haven't paid enough attention to see if it used elsewhere. I think that I deviated from the Minish Cap a little bit in terms of loading the background data though, when looking through Map Viewer on VisualBoyAdvance the amount of background loaded into memory appeared to be just 256 x 184. I figured it was more convenient to just use all 256 x 256.
I have read a little about mosaic effects but what I would really like to figure out is how to make everything on the screen fade to white and fade to black; I know where I would put it in my code and it would complete the effect of doing room transitions.
Thanks for the luck too.
-
Hah see, I really hadn't touched GBA hardware in 6 years so my brain's really not remembering everything properly. As far as debuggers go, I think no$gba has the best debugger around, even though that emulator's not seen an update in ages. They might've improved the debugger in VBA-M, but I can't be sure.
-
The tonc library that I am using has built-in functions to work with no$gba's debugger, but I haven't had time to use it yet. Otherwise I debug manually to some degree by writing the math out on paper and drawing diagrams - tweaking the code a little bit to see what changes and recompiling also helps. I plan on eventually buying a used GBA off of Amazon and the rest of the equipment required to test my code on actual hardware though too.
Anyway, I was going to try and clean up the code before releasing the source of the previous update, but it is probably not necessary. Basically the view is constricted to the room dimensions and the background loads based on the view. On the condition you get to the bottom of the room, the full dimensions of the map may be outside the room dimensions. This is alright though in that the view is constricted (which also means that when looking for the background data, it code should never seek to retrieve anything outside the background array). It could be further coded though so that when something like this happens it re-positions the map so that, for example, when going down to the bottom of the room and then going back up again there is the most free space towards the top of the loaded background region.
Eventually I will have enough features and the code cleaned up enough to where I will rerelease this as a tutorial and walkthrough of what I did.
The source code for the previous update is attached.
-
Update
(http://i8.photobucket.com/albums/a13/4Sword/minishGBA_2.png)
I have been busy but I was able to create a working sprite system that can do palette changing, animate at different speeds, flip the animation horizontally without having duplicate sprite data, stores the image pieces it needs into memory instead of putting everything into memory, has images made up of a variable amount of pieces, etc. But mainly it handles animations effectively. The code structure is somewhat reminiscent of how Game Maker Lite draws sprites but has the potential to be a lot more versatile.
The code in this update is just the sprite system. I am looking through what I have already done and redoing things to be more efficient.
The source code and GBA file are attached.
Edit: In sprConv.c, Piece p_LinkWalkL_3[2][2] should be {392, 8,{0x0010,0x0010,0x014A,0}}, it doesn't change anything other than a piece in tile memory being further out then it needs to be.
-
Man, thts too cool!
-
Thanks! It's really fun to code actually once you understand the method to its madness. In regard to the sprite system, the current animation system uses powers of 2 in determining what image to draw - currently the animation rate for Link walking is a little slow but going up a power of 2 makes it too fast. I am going to try rewriting parts of it so that it also is compatible with multiples of 3 but that might take a while. Also, I have to add special animation functions for sprites which don't give the same amount of "weight" to displaying images or just display images in a pattern (like blinking).
Also, for the people downloading the source cod, feedback or questions on how its coded would help me make it better - I'd be willing to help you understand what it does if you would just ask about it.
-
I saw that you include the sprites directly in the executable.
With so few RAM available, you're gonna be out of ressource very quickly.
Maybe it's because it's a simple test, but you should probably use some kind of filesystem library.
I don't know much about tonc, but I know devkitARM include libfat.
Other than that, good job! This project actually made me start programming for the ds(in C++ though).
Thanks for giving me the idea.
-
Thanks for the feedback and cool beans about the DS development. It would be helpful to myself and others if you would post your code sometime - it'd be neat to see what you have accomplished and helpful in how it likely covers a different set of coding challenges.
I do not know what you mean about including sprites in the executable - not sure which version of my code you were looking at. In the first demo I put out I put all of Link's standing sprites into tile memory but in the latest demo I loaded in only what was needed to display Link (I knew I would run out of room in tile memory eventually and that the tutorial examples just had it where you loaded everything into tile memory).
I have heard about something like the GBFS but thought that it was something used more mainly for convenience and ease of development - but I'll look into it and other file systems more since you have found them useful.
-
Diminish, I don't understand what he's talking about either, first he talks about running out of RAM then he goes immediately to ROM, the two are completely isolated. Don't worry about running out of space, as long as you watch your memory usage and use KISS you'll be fine.
GBA Filesystems are for convenience only you don't really need them, and they don't really save any space, in most cases the complexity of a filesystem can be a detriment rather than a help
-
I saw that you include the sprites directly in the executable.
With so few RAM available, you're gonna be out of ressource very quickly.
Viewport culling can solve memory issues fairly easily. But even then, the GBA has plentiful resources for a 2D game. I mean hell, even full blown 3D games have been written for the GBA on stock! If a developer isn't competent enough to handle console programming, then they shouldn't be doing it at all.
-
Ah, alright. It is good though that we are all vigilant about making code more efficient and having better resource management. Also over the next few days I will try to edit my first post to include the most recent information as well as a log of the previous updates so that what is going on in the topic is more understandable.
In terms of what I said I was going to go through and make more efficient, I am looking into better use of the screenblocks for doing backgrounds to reduce the amount of times the background has to be loaded. One of my last demos managed to not have to do it too often but use of multiple screenblocks would reduce this further and provide better stopping points for future object activation/deactivation.
-
I was talking about the lastest version of the project.
Here's what I meant:
- In your project, all the sprite data is stored in the files "sprRaw.h" and "sprRaw.s"
- In "minish.c", you add the sprite data in the executable (#include "include/sprRaw.h")
This increase the size of the executable.
- The executable is gonna be loaded in RAM, that means you're limited in terms of data.
- The GBA has 256kb of RAM and 96kb of VRAM, not a whole lot.
A GBA cartridge has a max size 32mb, plenty of space to store data (sound, gfx, ...).
- To allow more diversity in ressource, you only load what you need, when you need it.
You do this by fetching data from the cartridge and transfering it into RAM, freeing memory
when you dont need it anymore.
example: the hero goes from the overworld to a dungeon.
-step 1: freeing the overworld tileset and map from RAM.
-step 2: loading the dungeon tileset and map from the cartidge
I hope that I explained my point well this time.
I could be wrong though, I don't pretend to be an expert.
Thanks for the feedback and cool beans about the DS development. It would be helpful to myself and others if you would post your code sometime - it'd be neat to see what you have accomplished and helpful in how it likely covers a different set of coding challenges.
I was actually thinking about doing a tutorial. I'll probably post something when the project has more meat to it.
-
You shouldn't be limited by space though since theres no physical "cartridge" for the memory/data to be saved on.
-
My apologies, noseblunt, I was responding to your post in context of the GBA Hardware in general to 2D Game Devleopment, not 4Sword's implementation. In that case yeah, your explanation would've been nice initially. ;p
-
The "sprRaw.h" file that minish.c includes is just to have a reference to the externally defined array of sprites. I could probably just not include "sprRaw.h" though in minish.c considering I only needed references to the default palette and the shadow tiles - and I could make it so there is no "sprRaw.h" since the only time I would need to reference raw graphics is for when I was to put pieces into memory in advance (the shadow pieces because they are so commonly used) and then have extern statements individually only where I need them.
After minish.c knows where to get the graphics from it puts them into VRAM which works like a stratch pad. When I have Link animate I do a memcpy32 statement to overwrite tile memory starting at tile-id 320 and then build OAM pieces using that new information. I didn't think you could change the length of any of that, just that you had a confined space to work within. When looking at actual game stuff I remember seeing pieces of the title screen still in memory even after I had played for a while so I don't think it gets cleaned up either.
Beyond that, I am still confused because some of the techniques I used sort of already did what you are suggesting (e.g. Link animations and how I don't just load all of the tiles in VRAM but select the pieces I need from the source array in PAK ROM and copy it to tile memory VRAM).
I was actually thinking about doing a tutorial. I'll probably post something when the project has more meat to it.
Great, I'm looking forward to learning from it.
You shouldn't be limited by space though since theres no physical "cartridge" for the memory/data to be saved on.
Well yeah, but I am trying to avoid bloat if I can - I don't want to do things a sloppy and easy way just because I have the room to. If I can do things in a more efficient way then I can look at my code and not be ashamed of it.
My apologies, noseblunt, I was responding to your post in context of the GBA Hardware in general to 2D Game Devleopment, not 4Sword's implementation. In that case yeah, your explanation would've been nice initially. ;p
I know you're busy with other stuff too but it would be cool as well to maybe see some of your GBA code in the future if you still have it.
-
I was talking about the lastest version of the project.
Here's what I meant:
- In your project, all the sprite data is stored in the files "sprRaw.h" and "sprRaw.s"
- In "minish.c", you add the sprite data in the executable (#include "include/sprRaw.h")
This increase the size of the executable.
- The executable is gonna be loaded in RAM, that means you're limited in terms of data.
- The GBA has 256kb of RAM and 96kb of VRAM, not a whole lot.
A GBA cartridge has a max size 32mb, plenty of space to store data (sound, gfx, ...).
- To allow more diversity in ressource, you only load what you need, when you need it.
You do this by fetching data from the cartridge and transfering it into RAM, freeing memory
when you dont need it anymore.
example: the hero goes from the overworld to a dungeon.
-step 1: freeing the overworld tileset and map from RAM.
-step 2: loading the dungeon tileset and map from the cartidge
I hope that I explained my point well this time.
I could be wrong though, I don't pretend to be an expert.
Thanks for the feedback and cool beans about the DS development. It would be helpful to myself and others if you would post your code sometime - it'd be neat to see what you have accomplished and helpful in how it likely covers a different set of coding challenges.
I was actually thinking about doing a tutorial. I'll probably post something when the project has more meat to it.
Noseblunt, you've got it wrong, the executable isn't going to be loaded into ram unless it is a stub app for a multiboot cart, and i doubt he's using a multiboot cable (i could be way off base though).
http://www.coranac.com/tonc/text/first.htm Read the multiboot section.
-
When coding I mainly test it on the Visual Boy Advance (to see if it works) but otherwise I have actually tested it on the original Nintendo DS hardware through a GBA flashcart (for the coolness factor and to actually be sure it works on hardware).
-
Then what noseblunt said doesn't apply ^.^ carry on merrily :P
-
Lol, well so you're not going to test this engine on real hardware 4Sword? More than likely you won't have to really worry about much since you don't plan on doing fancy stuff, but even then.. just curious.
EDIT: Also how in the hell did I miss that part about the exe being loaded into ram. O_o There would be no need for that in the gba environment. Honestly I don't understand why memory's such an issue here. You don't have anything else allocating resources to the system memory and the developer has complete control over how things get allocated. Or unless 4Sword would be doing something ridiculously stupid, memory can't be an issue. And given that he's spending a little time learning the hardware and how it works, it's highly unlikely he would be.
-
I thought that I was testing this engine on real hardware, the Nintendo DS and it having GBA compatibility. Otherwise I did buy a AGB-001 Glacier GBA that I plan to do testing on but the flash cart I got was incompatible with that (it works on the DS though, I have another model of flashcart which I am looking to buy though that should work). In terms of what I make needing to be hardware compatible, I realize that playing GBA games now is done mainly via some form of emulation - so mainly getting it to work on actual hardware on the actual original GBA is just fun for the sake of it being fun.
-
And you need no more reason than that. Getting things running on lowmem environments can be a PITA, but the satisfaction is SOOO worth it :3
-
Noseblunt, you've got it wrong, the executable isn't going to be loaded into ram unless it is a stub app for a multiboot cart, and i doubt he's using a multiboot cable (i could be way off base though).
http://www.coranac.com/tonc/text/first.htm Read the multiboot section.
I may indeed have misunderstood the concept, but I still think you should check these links:
http://double.co.nz/nintendo_ds/nds_develop6.html (http://double.co.nz/nintendo_ds/nds_develop6.html)
http://blea.ch/wiki/index.php/Nitrofs (http://blea.ch/wiki/index.php/Nitrofs)
They're both for ds development, but the same logic should apply for the gba.
-
No it doesn't, the NDS and GBA are two entirely different pieces of hardware. They both use ARM processors sure, but so does the Wii, and many, MANY phones.
The complexity of a Filesystem, while convenient, isn't really conducive on a platform with as little memory as the GBA, if you look at official games, they don't use Filesystems, and neither should we.
-
Noseblunt, you've got it wrong, the executable isn't going to be loaded into ram unless it is a stub app for a multiboot cart, and i doubt he's using a multiboot cable (i could be way off base though).
http://www.coranac.com/tonc/text/first.htm Read the multiboot section.
I may indeed have misunderstood the concept, but I still think you should check these links:
http://double.co.nz/nintendo_ds/nds_develop6.html (http://double.co.nz/nintendo_ds/nds_develop6.html)
http://blea.ch/wiki/index.php/Nitrofs (http://blea.ch/wiki/index.php/Nitrofs)
They're both for ds development, but the same logic should apply for the gba.
If you read in, you'll note that this is talking about flashcarts which is logical that the programs would have to be allocated in RAM space somewhere for access speed purposes, this doesn't apply to regular carts that have just a stock ROM. Note the MechAssault game for the DS that's 128MiB in size. The DS has nowhere near the amount of RAM to sustain a game that big at a given time. Use some logic here.
Also, Antidote's pretty right. The underlaying architecture for ARMv7 versus ARMv9 are significant and the configuration of the DS is way different than the GBA. Not only do you have the ARM7 binary to worry about, but you have a second ARM9 binary talking too. That's just in the CPU alone, we're not even talking about how its address space works or how the graphics-bound hardware works.
Anyhow if you feel the need to continue this debate over ROM size affecting the amount of free RAM there is, go start another topic for it. Leave 4sword's topic alone god dammit!
-
Noseblunt, you've got it wrong, the executable isn't going to be loaded into ram unless it is a stub app for a multiboot cart, and i doubt he's using a multiboot cable (i could be way off base though).
http://www.coranac.com/tonc/text/first.htm Read the multiboot section.
I may indeed have misunderstood the concept, but I still think you should check these links:
http://double.co.nz/nintendo_ds/nds_develop6.html (http://double.co.nz/nintendo_ds/nds_develop6.html)
http://blea.ch/wiki/index.php/Nitrofs (http://blea.ch/wiki/index.php/Nitrofs)
They're both for ds development, but the same logic should apply for the gba.
I do think you've misunderstood the concept. It boils down to the way in which code is executed. On the GBA, code is executed directly from the ROM cartridge, not needing any RAM to do so (which is why GBA flash carts have to have extremely high response times, far higher than SD cards can provide). The 256 KB of RAM is for holding variables, sprite data, etc. On the DS, code is loaded from ROM into RAM before being executed, and that's why they needed to have the 4 MB of RAM available for it. It is impossible to execute code directly from a DS cartridge in the same way that it can be done from a GBA cartridge. As Antidote stated, the only time that GBA code is executed directly from RAM is when the program is small enough to fit into the 256 KB of RAM and is defined as a "multiboot" file.
I leave the following few links to help you understand the differences in coding:
http://www.pocketheaven.com/ph/wiki/index.php?title=Multiboot
http://www.pocketheaven.com/ph/wiki/Block_device
http://www.pocketheaven.com/ph/wiki/index.php?title=NAND_and_NOR
Basically, when coding for the GBA you embed your resources within the *.gba file itself since there's a 32 MByte limit. On the DS, you reach out to the internal filesystem as much as possible since it's now a 4 MB RAM limit. GBA-wise, there is GBFS ("Game Boy File System"), but that came rather late in the GBA homebrew scene, and I've mostly only seen it used with GBA GSM Player and a few other programs.
Diminish, keep up the good work! I only took one semester of a coding class that used GBA coding as our basis, but I'd be happy to help out in any small way I can
EDIT: I've just been informed that Diminish is 4Sword. How are ya dude? It's been quite a while since we last spoke face-to-face.
-
Hey this is pretty neat! This type of code is actually pretty relevant to my troubles currently. As of yet, currently I am trying to learn how to code games in C++, but am looking to move into programming C for VBA. This code would be really helpful as a starting point to learn from, so it couldn't have come at a better time XD (but don't worry I won't hardcopy it).
I just wanna ask some questions though, is it possible to write GB games as well using the tonc library? And also how different is it to program C from C++? I know there are certain limitations that C lacks (such as the lack of classes), but I am not entirely sure how different it is.
-
For the GBA, you would probably be better off sticking with C rather than C++ itself. But the semantics between C++ <-> C are very different. But I'm just going to save you a paragraphs worth of reading and just leave it at that.
GB.. as in retro GameBoy? You COULD write games for the GB in C, but it'll run very slow. Z80 assembler will be needed in that case. Also Dimminish, will you be releasing some form of documentation for your engine? It would be a good idea to maybe start running a tutorial series on this as you go along deving this, haha. Like "Tutorial Series Part 1: Setting up Project", etc...
-
For the GBA, you would probably be better off sticking with C rather than C++ itself. But the semantics between C++ <-> C are very different. But I'm just going to save you a paragraphs worth of reading and just leave it at that.
I figured that it would be. I'll probably consult some tutorials if they are available for help, but I just hope that understanding C++ would be a good prerequisite.
GB.. as in retro GameBoy? You COULD write games for the GB in C, but it'll run very slow. Z80 assembler will be needed in that case.
Very slow in that language? Is that what you mean? As far as I am concerned, GB (more specifically GBC, but not GBA) games are normally programmed in C, and just as long as I can match that quality, then I am fine with it. I am not sure what you mean by the assembler, but since I still have much to learn so I won't bug you.
Oh yeah, just to clarify, I am looking to make a GBC game, and not a classic GB game. Sorry about that.
Also Dimminish, will you be releasing some form of documentation for your engine? It would be a good idea to maybe start running a tutorial series on this as you go along deving this, haha. Like "Tutorial Series Part 1: Setting up Project", etc...
That would be nice, but I don't think that many apart from people like myself would be interested. And I am only interested because I am lookng into making a specific game for a specific project.
-
Hey this is pretty neat! This type of code is actually pretty relevant to my troubles currently. As of yet, currently I am trying to learn how to code games in C++, but am looking to move into programming C for VBA. This code would be really helpful as a starting point to learn from, so it couldn't have come at a better time XD (but don't worry I won't hardcopy it).
I just wanna ask some questions though, is it possible to write GB games as well using the tonc library? And also how different is it to program C from C++? I know there are certain limitations that C lacks (such as the lack of classes), but I am not entirely sure how different it is.
The tonc libraries are built around the GBA but there is something called GBDK uses C/ASM for making GB games. I've looked into it a little bit but it seems a little more difficult to pick up and learn because of the loss of documentation and examples for using it. The GB and GBA screen sizes are both clean multiples of 8 though, so in terms of getting past the some of the initial confusion of getting usable sprites to the screen, using GB graphics can be helpful. Things like GB animations are easy to as the frames all fit cleanly within 8x8 bounds.
Tonc supports writing your game in C++, but you'll have to change the makefile to refer to the C++ compiler instead of the C one. Personally I did my code in C because the tutorials were in C. I thought the C not having classes would be challenging too, but then I discovered how to use function pointers. For example, I could have an array of monster structs, iterate through it, and dereference the function pointer to call functions which draw the monsters. Of which, the function pointers could refer to entirely different functions which draw different kinds of monsters. In C++ this would be like having a parent object with children each defining a draw method differently.
Also Dimminish, will you be releasing some form of documentation for your engine? It would be a good idea to maybe start running a tutorial series on this as you go along deving this, haha. Like "Tutorial Series Part 1: Setting up Project", etc...
My code is a little difficult to document in its early stages due to having to redefine aspects of it as I go. But in terms of putting out a tutorial series, I am planning on releasing a cleaned up version of the sprite system code with a section on how I converted the graphics into a usable GBA format. I'm still thinking out the further pacing for later features, but the graphics seem like the biggest initial hurdle to wanting to code for the GBA so I'll start there.
-
GB.. as in retro GameBoy? You COULD write games for the GB in C, but it'll run very slow. Z80 assembler will be needed in that case.
Very slow in that language? Is that what you mean? As far as I am concerned, GB (more specifically GBC, but not GBA) games are normally programmed in C, and just as long as I can match that quality, then I am fine with it. I am not sure what you mean by the assembler, but since I still have much to learn so I won't bug you.
Oh yeah, just to clarify, I am looking to make a GBC game, and not a classic GB game. Sorry about that.
Don't know where you heard that from.. that's just not true. GB/C titles are mostly written in assembler. This is evidenced by code dumps of LADX where references to the toolchain have been found. Also, just look at the odd bugs in the Pokemon games. ;p A high level language would help programmers avoid silly errors like that or unless Nintendo/GameFreak were employing some of the most terrible programmers.
EDIT: Also that's good to hear. I can't wait to see a tutorial come out of this project.
-
Personally I did my code in C because the tutorials were in C. I thought the C not having classes would be challenging too, but then I discovered how to use function pointers. For example, I could have an array of monster structs, iterate through it, and dereference the function pointer to call functions which draw the monsters. Of which, the function pointers could refer to entirely different functions which draw different kinds of monsters. In C++ this would be like having a parent object with children each defining a draw method differently.
You mean a separate function that takes in a struct as a parameter? That sounds fine, but is there also an alternative way for inheritance to work with structs (like can we have a struct inherit properties of a base struct just as we do classes?).
Don't know where you heard that from.. that's just not true. GB/C titles are mostly written in assembler. This is evidenced by code dumps of LADX where references to the toolchain have been found. Also, just look at the odd bugs in the Pokemon games. ;p A high level language would help programmers avoid silly errors like that or unless Nintendo/GameFreak were employing some of the most terrible programmers.
What do you mean by assembler? Is it like a separate language? Do you have a link that can help me learn about it some more? I have gathered most of my knowledge from this site: http://www.loirak.com/gameboy/gbprog.php, which I am planning to learn more from. It does mention assemblers as well, but also encourages you to learn C.
Also does Z80 work just as well for GBC games as GB games?
-
In my current code the reason I have an Object struct is to be common elements needed to handle collisions and movement. I can later test for collisions with all objects by running through an array of all of the objects. I haven't tested this out at all the syntax and my use of references could be wrong but this is the general idea of what I was getting at (it shows a way to have different types of monsters, I probably won't use this way of doing things but I could).
typedef struct Monster{
Object obj;
(void *) stepFunc(Monster *);
(void *) drawFunc(Monster *);
} Monster;
Monster Octorok0;
Monster Tektite0;
Monster Keaton0;
Monster_Init(&Octorok0,&Octorok_Step,&Octorok_Draw);
Monster_Init(&Tektite0,&Tektite_Step,&Tektite_Draw);
Monster_Init(&Keaton0,&Keaton_Step,&Keaton_Draw);
Monster * allMonsters[3] = {
&Octorok0,
&Tektite0,
&Keaton0
}
int i;
for (i = 0; i < 3; i++){
*allMonsters[i].stepFunc(allMonsters[i]);
*allMonsters[i].drawFunc(allMonsters[i]);
}
The Octorok_Step and the like are functions. So a Monster struct can move and be drawn in many different ways by making the Monster struct refer to different functions.
-
Also does Z80 work just as well for GBC games as GB games?
The GBC and GB are virtually identical, the only differences between the two is that the GBC has a color screen, more VRAM, and some instructions specific to it, there may be more differences, but i can't be arsed to remember atm.
The Z80 is just a processor from Zilog, http://en.wikipedia.org/wiki/Zilog_Z80
-
The Z80 is just a processor from Zilog, http://en.wikipedia.org/wiki/Zilog_Z80
Thought the GB used a variant of a Z80 CPU?
-
It's not actually a variant, it's similar to the Z80 however.
http://marc.rawer.de/Gameboy/Docs/GBCPUman.pdf
-
It's not actually a variant, it's similar to the Z80 however.
http://marc.rawer.de/Gameboy/Docs/GBCPUman.pdf
Ah, well even then the same concept applies. It's too slow to run C code. ;p Sorry for derailing your topic, I'm gonna stop talking now lol.
-
(http://i8.photobucket.com/albums/a13/4Sword/minishGBA_screenSept3.png)
I haven't started writing up a tutorial for the sprite system implementation I am using, mainly because recent progress has redefined aspects of that system. As mentioned in an earlier post, I wanted the animation rate to be slightly slower as well as for there to be irregular animation patterns like blinking. This small recent update does that - and thus fully encapsulates the Link normal state of walking and standing. Link now blinks after some time has gone by (instead of all the time) and animates at a closer rate compared to the GBA (using multiples of 24 so that image incrementing can be done at rates of 1, 2, 3, 4, 6, 12, and 24). I also separated out animation graphical elements from the object struct - this will be useful when wanting to have something like an animating shadow)
There are many things that still need to be added to the sprite system like multiple object graphic memory support, simple sprite scaling, and translucency.
But yeah, the attached source code contains the improved and irregular animation rates (with a non-black background so that it's easier to see). I added back the ability for Link to move around and change palette with L and R so that the .gba is like a quick walking engine but meh, still working towards backgrounds and reapplying the view code.
-
*is 3 months late*
I tried the demo, and it's quite good! Especially when coded in pure C. The best I ever did was https://dl.dropbox.com/u/59972490/GBAandDS/Update2.gba and https://dl.dropbox.com/u/59972490/GBAandDS/Update1.gba , all of which using modes 3 and 4 without even attempting to work with the GBA's sprite/background capabilities.
-
What is up you all? I have been busy with work to where I haven't had much time to work on this, and it doesn't help I took a detour and decided to do a little web-design for a related site for it. I still have to figure out some of the PHP, SQL, and Javascript/jQuery stuff to go with it as well as redesigning SMF elements to be more appealing (not to mention fixing gradients to be more dithered and less banded) - but I like what I have going so far. Eventually I plan on creating some tutorials/templates and having a resource system that would help beginners with learning how to code for the GB/GBC/GBA. It's a long-term project that should gives me something to practice web development and a lot of C programming.
The below preview image is just a prototype in progress but I intend to get further with it:
http://i8.photobucket.com/albums/a13/4Sword/gbgThemeX.png
-
It has been a while since I have done anything with this but I cleaned up some of my code. I would have liked to fully flesh out the "depth" system so that it works more similarly to Game Maker depth-setting but this likely requires building the OBJ_ATTR all_pieces array I have via a sorting algorithm. Additionally though, I "simplified" the sprite animation such that I no longer separate out what I considered normal animations (e.g., 1 image displaying for 4 frames, next image displaying for 4 frames) and special animations (e.g., 1 image displaying for 4 frames, next image displaying for 48 frames) - instead they are all handled as special animations (it uses more space but functionally it should be faster). I also broke up non-loaded images (basically sprites that are preloaded into memory) from sprites to avoid checking on each draw if the image was preloaded or not. The sprite system also only initializes the pieces which had been used previously instead of reinitializing every piece.
(http://i8.photobucket.com/albums/a13/4Sword/gbgZelda_Screenshot_zpsvpgdig8d.png)
Major changes:
- beginnings of a room system
- a palette swapping system
- an object system with dynamic memory allocation
- a more efficient sprite system
- some fancy bit-manipulations
code is attached!
Edit: I've removed the source code attachment due to it getting downloaded at least 16 times by other people with no feedback or thank you comment whatsoever - considering the same with my Pokemon Engine for the same reason. I'm still working on aspects of this (namely collision detections and HUD currently) and will post that at some point later.