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

0 Members and 1 Guest are viewing this topic.
Re: GBA Minish Cap Coding
« Reply #40 on: September 01, 2012, 02:48:16 am »
  • *
  • Reputation: +0/-0
  • Offline Offline
  • Posts: 57
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.
Logged

thestig

Re: GBA Minish Cap Coding
« Reply #41 on: September 01, 2012, 03:28:36 am »
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...
Logged
Re: GBA Minish Cap Coding
« Reply #42 on: September 01, 2012, 03:49:04 am »
  • *
  • Reputation: +0/-0
  • Offline Offline
  • Posts: 57
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.


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

Quote
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.
« Last Edit: September 01, 2012, 03:53:14 am by shongshui »
Logged

Diminish

4Sword
Re: GBA Minish Cap Coding
« Reply #43 on: September 01, 2012, 04:12:23 am »
  • *
  • Reputation: +8/-0
  • Offline Offline
  • Gender: Male
  • Posts: 6584
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.
Logged

thestig

Re: GBA Minish Cap Coding
« Reply #44 on: September 01, 2012, 04:24:47 am »
Quote
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.
Logged
Re: GBA Minish Cap Coding
« Reply #45 on: September 01, 2012, 03:54:51 pm »
  • *
  • Reputation: +0/-0
  • Offline Offline
  • Posts: 57
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?
Logged

Diminish

4Sword
Re: GBA Minish Cap Coding
« Reply #46 on: September 01, 2012, 04:25:23 pm »
  • *
  • Reputation: +8/-0
  • Offline Offline
  • Gender: Male
  • Posts: 6584
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).

Code: [Select]
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.
Logged

Antidote

>.>
Re: GBA Minish Cap Coding
« Reply #47 on: September 01, 2012, 05:16:01 pm »
  • In all seriousness who's serious?
  • *
  • Reputation: +0/-0
  • Offline Offline
  • Gender: Male
  • Posts: 1484
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
« Last Edit: September 01, 2012, 05:19:59 pm by Antidote »
Logged
  • Axiomatic Data Laboratories

thestig

Re: GBA Minish Cap Coding
« Reply #48 on: September 01, 2012, 05:54:39 pm »
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?
Logged

Antidote

>.>
Re: GBA Minish Cap Coding
« Reply #49 on: September 01, 2012, 06:31:08 pm »
  • In all seriousness who's serious?
  • *
  • Reputation: +0/-0
  • Offline Offline
  • Gender: Male
  • Posts: 1484
It's not actually a variant, it's similar to the Z80 however.

http://marc.rawer.de/Gameboy/Docs/GBCPUman.pdf
Logged
  • Axiomatic Data Laboratories

thestig

Re: GBA Minish Cap Coding
« Reply #50 on: September 01, 2012, 07:02:18 pm »
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.
Logged

Diminish

4Sword
Re: GBA Minish Cap Coding
« Reply #51 on: September 04, 2012, 04:07:30 am »
  • *
  • Reputation: +8/-0
  • Offline Offline
  • Gender: Male
  • Posts: 6584


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.
Logged
Re: GBA Minish Cap Coding
« Reply #52 on: November 18, 2012, 05:07:07 am »
  • w00t
  • *
  • Reputation: +0/-0
  • Offline Offline
  • Gender: Male
  • Posts: 1979
*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.
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

Diminish

4Sword
Re: GBA Minish Cap Coding
« Reply #53 on: December 12, 2012, 12:51:13 am »
  • *
  • Reputation: +8/-0
  • Offline Offline
  • Gender: Male
  • Posts: 6584
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
Logged

Diminish

4Sword
Re: GBA Minish Cap Coding
« Reply #54 on: February 04, 2017, 08:09:56 am »
  • *
  • Reputation: +8/-0
  • Offline Offline
  • Gender: Male
  • Posts: 6584
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.



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.
« Last Edit: February 28, 2017, 04:09:29 am by Diminish »
Logged
Pages: 1 2 [3]   Go Up

 


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



Page created in 0.045 seconds with 45 queries.

anything