Hello Guest, please login or register.
Did you miss your activation email?
Login with username, password and session length.

Pages: [1] 2 3   Go Down

Author Topic: GBA Minish Cap Coding  (Read 22876 times)

0 Members and 1 Guest are viewing this topic.
GBA Minish Cap Coding
« on: May 30, 2012, 05:19:47 am »
  • *
  • Reputation: +8/-0
  • Offline Offline
  • Gender: Male
  • Posts: 6603
Minish Cap GBA Programming using C/ASM though Tonc



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 - simple sprites, background graphics, framework for having more than one room
07/08/2012 - palette changing, having rooms larger than the screen size
08/27/2012 - simple animation, Link's standing and walking graphics converted
09/03/2012 - improved and irregular animation rates, movement added back in
02/03/2017 - redone various improvements
« Last Edit: February 04, 2017, 10:40:37 pm by 4Sword »
Logged
Re: Minish Cap Stuff
« Reply #1 on: June 22, 2012, 11:53:00 pm »
  • *
  • Reputation: +8/-0
  • Offline Offline
  • Gender: Male
  • Posts: 6603
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)?
« Last Edit: June 23, 2012, 12:17:43 am by Diminish »
Logged
Re: Minish Cap Stuff
« Reply #2 on: June 24, 2012, 10:56:58 pm »
  • *
  • Reputation: +9/-0
  • Offline Offline
  • Posts: 728
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.
Logged
  • Pyxosoft
Re: Minish Cap Stuff
« Reply #3 on: June 24, 2012, 11:05:38 pm »
  • Yeah, I don't even...
  • *
  • Reputation: +11/-4
  • Offline Offline
  • Gender: Female
  • Posts: 1008
If time wasn't an issue, I'd recommend doing both.
Logged
Re: Minish Cap Stuff
« Reply #4 on: June 26, 2012, 02:51:59 am »
  • *
  • Reputation: +8/-0
  • Offline Offline
  • Gender: Male
  • Posts: 6603
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 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:



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.
« Last Edit: June 26, 2012, 02:54:08 am by Diminish »
Logged
Re: Minish Cap Stuff
« Reply #5 on: June 26, 2012, 02:56:21 am »
  • Yeah, I don't even...
  • *
  • Reputation: +11/-4
  • Offline Offline
  • Gender: Female
  • Posts: 1008
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.
« Last Edit: June 26, 2012, 02:57:56 am by zdude684 »
Logged
Re: Minish Cap Stuff (GBA Code)
« Reply #6 on: June 26, 2012, 03:11:55 am »
  • *
  • Reputation: +8/-0
  • Offline Offline
  • Gender: Male
  • Posts: 6603
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.
« Last Edit: June 26, 2012, 03:22:19 am by Diminish »
Logged

DaSpirit

The Quiet
Re: Minish Cap Stuff
« Reply #7 on: June 26, 2012, 03:02:54 pm »
  • The Mad Programmer.
  • *
  • Reputation: +1/-0
  • Offline Offline
  • Gender: Male
  • Posts: 87
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?
Logged
I support:

thestig
Re: Minish Cap Stuff
« Reply #8 on: June 26, 2012, 03:08:28 pm »
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.
Logged
Re: Minish Cap Stuff
« Reply #9 on: June 26, 2012, 04:08:24 pm »
  • *
  • Reputation: +8/-0
  • Offline Offline
  • Gender: Male
  • Posts: 6603
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.
Logged

thestig
Re: Minish Cap Stuff
« Reply #10 on: June 26, 2012, 04:25:57 pm »
Quote from: Diminish on June 26, 2012, 04:08:24 pm
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.

Quote
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.
Logged
Re: Minish Cap Stuff
« Reply #11 on: June 26, 2012, 06:11:00 pm »
  • *
  • Reputation: +8/-0
  • Offline Offline
  • Gender: Male
  • Posts: 6603
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.
Logged

thestig
Re: Minish Cap Stuff
« Reply #12 on: June 27, 2012, 04:13:19 am »
Quote from: Diminish on June 26, 2012, 06:11:00 pm
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.

Quote
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.
Logged
Re: Minish Cap Stuff
« Reply #13 on: July 08, 2012, 09:30:20 pm »
  • *
  • Reputation: +8/-0
  • Offline Offline
  • Gender: Male
  • Posts: 6603


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.
Logged

thestig
Re: Minish Cap Stuff
« Reply #14 on: July 08, 2012, 11:13:36 pm »
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.
Logged
Re: Minish Cap Stuff
« Reply #15 on: July 09, 2012, 03:50:11 am »
  • *
  • Reputation: +8/-0
  • Offline Offline
  • Gender: Male
  • Posts: 6603
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.
Logged

thestig
Re: Minish Cap Stuff
« Reply #16 on: July 10, 2012, 02:08:13 am »
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.
Logged
Re: Minish Cap Stuff
« Reply #17 on: July 10, 2012, 02:25:57 am »
  • *
  • Reputation: +8/-0
  • Offline Offline
  • Gender: Male
  • Posts: 6603
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.
Logged
GBA Minish Cap Coding
« Reply #18 on: August 27, 2012, 06:02:09 am »
  • *
  • Reputation: +8/-0
  • Offline Offline
  • Gender: Male
  • Posts: 6603
Update



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.
« Last Edit: August 28, 2012, 05:07:59 am by Diminish »
Logged
Re: GBA Minish Cap Coding
« Reply #19 on: August 27, 2012, 06:16:56 am »
  • *
  • Reputation: +12/-0
  • Offline Offline
  • Gender: Male
  • Posts: 497
Man, thts too cool!
Logged
Pages: [1] 2 3   Go Up
« previous next »

 


Contact Us | Legal | Advertise Here
2013 © ZFGC, All Rights Reserved


Page created in 0.024 seconds with 73 queries.

anything