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 11471 times)

0 Members and 1 Guest are viewing this topic.
Re: GBA Minish Cap Coding
« Reply #20 on: August 27, 2012, 06:14:31 pm »
  • *
  • Reputation: +8/-0
  • Offline Offline
  • Gender: Male
  • Posts: 6583
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.
Logged

noseblunt3

Woodman is awesome
Re: GBA Minish Cap Coding
« Reply #21 on: August 27, 2012, 10:09:15 pm »
  • *
  • Reputation: +2/-0
  • Offline Offline
  • Gender: Male
  • Posts: 132
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.
Logged
Rome wasn't built in a day, but they didn't waste time by sitting around doing nothing either!
Re: GBA Minish Cap Coding
« Reply #22 on: August 27, 2012, 11:10:44 pm »
  • *
  • Reputation: +8/-0
  • Offline Offline
  • Gender: Male
  • Posts: 6583
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.
Logged

Antidote

>.>
Re: GBA Minish Cap Coding
« Reply #23 on: August 28, 2012, 12:18:01 am »
  • In all seriousness who's serious?
  • *
  • Reputation: +0/-0
  • Offline Offline
  • Gender: Male
  • Posts: 1485
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
Logged
  • Axiomatic Data Laboratories

thestig

Re: GBA Minish Cap Coding
« Reply #24 on: August 28, 2012, 01:21:24 am »
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.
Logged
Re: GBA Minish Cap Coding
« Reply #25 on: August 28, 2012, 02:28:13 am »
  • *
  • Reputation: +8/-0
  • Offline Offline
  • Gender: Male
  • Posts: 6583
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.
Logged

noseblunt3

Woodman is awesome
Re: GBA Minish Cap Coding
« Reply #26 on: August 28, 2012, 02:54:00 am »
  • *
  • Reputation: +2/-0
  • Offline Offline
  • Gender: Male
  • Posts: 132
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.

Quote
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.
Logged
Rome wasn't built in a day, but they didn't waste time by sitting around doing nothing either!
Re: GBA Minish Cap Coding
« Reply #27 on: August 28, 2012, 02:57:13 am »
  • Yeah, I don't even...
  • *
  • Reputation: +11/-4
  • Offline Offline
  • Gender: Female
  • Posts: 1008
You shouldn't be limited by space though since theres no physical "cartridge" for the memory/data to be saved on.
Logged

thestig

Re: GBA Minish Cap Coding
« Reply #28 on: August 28, 2012, 03:29:58 am »
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
Logged
Re: GBA Minish Cap Coding
« Reply #29 on: August 28, 2012, 03:35:15 am »
  • *
  • Reputation: +8/-0
  • Offline Offline
  • Gender: Male
  • Posts: 6583
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.
« Last Edit: August 28, 2012, 04:08:11 am by Diminish »
Logged

Antidote

>.>
Re: GBA Minish Cap Coding
« Reply #30 on: August 28, 2012, 06:05:02 am »
  • In all seriousness who's serious?
  • *
  • Reputation: +0/-0
  • Offline Offline
  • Gender: Male
  • Posts: 1485
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.

Quote
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.
Logged
  • Axiomatic Data Laboratories
Re: GBA Minish Cap Coding
« Reply #31 on: August 28, 2012, 06:15:40 am »
  • *
  • Reputation: +8/-0
  • Offline Offline
  • Gender: Male
  • Posts: 6583
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).
« Last Edit: August 28, 2012, 06:24:05 am by Diminish »
Logged

Antidote

>.>
Re: GBA Minish Cap Coding
« Reply #32 on: August 28, 2012, 11:56:40 am »
  • In all seriousness who's serious?
  • *
  • Reputation: +0/-0
  • Offline Offline
  • Gender: Male
  • Posts: 1485
Then what noseblunt said doesn't apply ^.^ carry on merrily :P
Logged
  • Axiomatic Data Laboratories

thestig

Re: GBA Minish Cap Coding
« Reply #33 on: August 28, 2012, 01:06:31 pm »
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.
« Last Edit: August 28, 2012, 01:10:13 pm by gm112 »
Logged
Re: GBA Minish Cap Coding
« Reply #34 on: August 28, 2012, 02:22:57 pm »
  • *
  • Reputation: +8/-0
  • Offline Offline
  • Gender: Male
  • Posts: 6583
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.
Logged

Antidote

>.>
Re: GBA Minish Cap Coding
« Reply #35 on: August 28, 2012, 03:32:47 pm »
  • In all seriousness who's serious?
  • *
  • Reputation: +0/-0
  • Offline Offline
  • Gender: Male
  • Posts: 1485
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
Logged
  • Axiomatic Data Laboratories

noseblunt3

Woodman is awesome
Re: GBA Minish Cap Coding
« Reply #36 on: August 29, 2012, 03:31:06 am »
  • *
  • Reputation: +2/-0
  • Offline Offline
  • Gender: Male
  • Posts: 132

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://blea.ch/wiki/index.php/Nitrofs

They're both for ds development, but the same logic should apply for the gba.
Logged
Rome wasn't built in a day, but they didn't waste time by sitting around doing nothing either!

Antidote

>.>
Re: GBA Minish Cap Coding
« Reply #37 on: August 29, 2012, 03:41:57 am »
  • In all seriousness who's serious?
  • *
  • Reputation: +0/-0
  • Offline Offline
  • Gender: Male
  • Posts: 1485
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.
« Last Edit: August 29, 2012, 03:45:35 am by Antidote »
Logged
  • Axiomatic Data Laboratories

thestig

Re: GBA Minish Cap Coding
« Reply #38 on: August 29, 2012, 03:51:36 am »

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://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!
Logged
Re: GBA Minish Cap Coding
« Reply #39 on: August 29, 2012, 04:33:20 am »
  • w00t
  • *
  • Reputation: +0/-0
  • Offline Offline
  • Gender: Male
  • Posts: 1979

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://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.
« Last Edit: August 29, 2012, 05:06:16 am by DanTheMan »
Logged
What do you mean I need a life?  =P  Hm... Lives... Isn't that something that you get in Super Mario Bros?  You know, those green mushrooms?  That's a life, right?



My one and only fangame, Link Maze, may be viewed at http://www.zfgc.com/forum/index.php?topic=82.0
  • Link Maze - Zelda mini fangame
Pages: 1 [2] 3   Go Up

 


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



Page created in 0.075 seconds with 57 queries.