#78824 - Fenderocker - Mon Apr 10, 2006 1:53 am
Is there a way to make a sprite change from one sprite to another without havenig to load them all into the OEM? What I mean is is there a way to change the file that a sprite is pointing to? you would probobly use the same thing for anamation because otherwise haveing all the frames loaded into OAM all the time would take up a lot of space.
P.S. Was that really confusing?
Last edited by Fenderocker on Mon Apr 17, 2006 11:25 pm; edited 1 time in total
#78825 - sajiimori - Mon Apr 10, 2006 2:09 am
I assume you mean "OAM". You do not store animation frames in OAM, though -- you store them in sprite VRAM. Also, sprite VRAM does not point to files -- it contains whole sprite frames. You can overwrite any part of sprite VRAM at any time and that is one way to do animation.
#78827 - Fenderocker - Mon Apr 10, 2006 2:13 am
ok thanks, I'll just learn how to use VRAM thanks!
#78833 - tepples - Mon Apr 10, 2006 2:37 am
After you read through TONC and a few other tutorials that cover sprites, this document that I wrote years ago may help you understand how sprite cel VRAM really works.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#78883 - Fenderocker - Mon Apr 10, 2006 10:57 am
ok, After readeing that I understand VRAM, thank you tepples, the only problem is that there might not be enough VRAM space for my 6 frame 32*64 main character...........
#78899 - tepples - Mon Apr 10, 2006 1:46 pm
32x64 pixels at 16 colors takes only 1 KB of sprite cel VRAM. (Remember in "Managing Sprite Cel VRAM" that you only need one frame of animation in VRAM at once.) If you are using a tiled background, you have 31 KB left.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#78941 - Fenderocker - Mon Apr 10, 2006 8:11 pm
oh oops mis calculation........Thanks! do you just right to that address just as you would with any normal sprite?
#78960 - tepples - Mon Apr 10, 2006 9:57 pm
Just try it in VisualBoyAdvance and see what ends up in your Tile Viewer and OAM Viewer.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#79006 - Fenderocker - Tue Apr 11, 2006 2:37 am
ok, two things,
one, I was previously writing to the VRAM! I just didn't know it.
two, the sprites aren't coming up in visualboy advance but they are in the VBA Oam viewer. In the Oam viewer they are all black, but I think that that's just a problem with the sprite data, thanks tepples for helping me!
#79016 - tepples - Tue Apr 11, 2006 3:08 am
Three common causes of solid black sprites:
- Entire screen is black, or sprite is a silhouette: Look in the Palette Viewer.
- Sprite is completely transparent in OAM Viewer: Make sure that the index from the OAM Viewer matches the index from the Tile Viewer and that the 1D/2D bit in DISPCNT is set correctly.
- Sprite is a solid color rectangle, or sprite shows up in OAM Viewer but not on screen: Make sure that the sprite is onscreen and that you aren't inadvertently turning on the rotation bits (e.g. by incorrectly handling a sprite that hangs off the top of the screen).
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#79114 - thegamefreak0134 - Tue Apr 11, 2006 7:14 pm
Could you run us through what your code is doing? (or perhaps post it, if it isn't that long) That would help us help you better.
It sounds like you're either (1) setting the pallete wrong, or (2) not pointing to the right area of VRAM.
Remember that in the bitmap modes, you can only use VRAM that starts with 512, so check for that. (that would be modes 3,4,and 5)
Also remember that if you're re-writing VRAM every frame, you do not have to change the pointer in the sprite itself, it will simply be "drawn" that frame with the updated data. (aka, your "animation" only needs to be touching VRAM.)
_________________
What if the hokey-pokey really is what it's all about?
[url=http:/www.darknovagames.com/index.php?action=recruit&clanid=1]Support Zeta on DarkNova![/url]
#79140 - Fenderocker - Tue Apr 11, 2006 8:55 pm
here is my code: | Code: |
#include "gba.h"
#include "graph.h"
void InitializeSprites(void);
void CopyOAM(void);
void MoveSprite(OAMEntry* sp, int x, int y);
void Moveplayer(void);
OAMEntry sprites[128];
u16 xplayer = 3;
u16 yplayer = 150;
u16 xen1 = 10;
u16 yen1 = 10;
u16 xen2 = 222;
u16 yen2 = 10;
u16 xen3 = 222;
u16 yen4 = 10;
u8 playerweapon = 0;
u8 playerdirection = 1;
u8 userScore = 0;
u8 yMax = 150;
int main() {
u16 loop;
SetMode(MODE_4 | BG2_ENABLE | OBJ_ENABLE | OBJ_MAP_1D);
for(loop = 0; loop < 256; loop++) {
OBJ_PaletteMem[loop] = man_left_nadePalette[loop];
}
for (loop = 0; loop < 256; loop++) {
BG_PaletteMem[loop]=bgPalette[loop];
}
for (loop = 0; loop < (120*160); loop++) {
FrontBuffer[loop] = bgData[loop] ;
}
memcpy( (u16 *)0x06010000, &man_right_pistolData, sizeof(man_right_pistolData) );
sprites[0].attribute0 = COLOR_256 | TALL | yplayer;
sprites[0].attribute1 = SIZE_64 | xplayer;
sprites[0].attribute2 = 512;
while(1)
{
Moveplayer();
MoveSprite(&sprites[0],xplayer,yplayer);
WaitForVsync();
CopyOAM();
}
return 0;
}
void InitializeSprites(void)
{
u16 loop;
for(loop = 0; loop < 128; loop++) {
sprites[loop].attribute0 = 160;
sprites[loop].attribute1 = 240;
}
}
void CopyOAM(void)
{
u16 loop;
u16* temp;
temp = (u16*)sprites;
for(loop = 0; loop < 128*4; loop++) {
OAM_Mem[loop] = temp[loop];
}
}
void MoveSprite(OAMEntry* sp, int x, int y)
{
sp->attribute1 = sp->attribute1 & 0xFE00;
sp->attribute1 = sp->attribute1 | x;
sp->attribute0 = sp->attribute0 & 0xFF00;
sp->attribute0 = sp->attribute0 | y;
}
void Moveplayer(void)
{
if(keyDown(KEY_RIGHT) && playerdirection == 1 && xplayer < 237)
{
xplayer++;xplayer++;xplayer++;
}
if(keyDown(KEY_RIGHT) && playerdirection == 0 && xplayer < 237)
{
if(playerweapon == 0)
{
memcpy( (u16 *)0x06010000, &man_right_pistolData, sizeof(man_right_pistolData) );
}
if(playerweapon == 1)
{
memcpy( (u16 *)0x06010000, &man_right_mechData, sizeof(man_right_mechData) );
}
xplayer++;xplayer++;xplayer++;
}
if(keyDown(KEY_LEFT) && playerdirection == 0 && xplayer > 3)
{
xplayer--;xplayer--;xplayer--;
}
if(keyDown(KEY_LEFT) && playerdirection == 1 && xplayer > 3)
{
if(playerweapon == 0)
{
memcpy( (u16 *)0x06010000, &man_left_pistolData, sizeof(man_left_pistolData) );
}
if(playerweapon == 1)
{
memcpy( (u16 *)0x06010000, &man_left_mechData, sizeof(man_left_mechData) );
}
xplayer--;xplayer--;xplayer--;
}
}
|
I think that you might have missunderstood me, The sprite doesn't show up on the main screen, but the BG does. In VBA's Oam viewer the sprite shows up the right size just all black.
#79154 - tepples - Tue Apr 11, 2006 10:18 pm
| Fenderocker wrote: |
| Code: |
SetMode(MODE_4 | BG2_ENABLE | OBJ_ENABLE | OBJ_MAP_1D);
/*...*/
memcpy( (u16 *)0x06010000, &man_right_pistolData, sizeof(man_right_pistolData) );
|
|
There's your problem. You need to copy to 0x06014000, as modes 3 through 5 reserve 0x06010000 through 0x06013FFF for the end of the frame buffer. Here's a macro that calculates the correct destination address in sprite cel VRAM for a given tile index:
| Code: |
| #define SPR_VRAM(tn) ((u32 *)(0x06010000 | ((tn) << 5))) |
Another thing: I think your animation code would be a lot more manageable if you would make a separate function loadCel() that loads a sprite cel into VRAM.
And what did you plan to use mode 4 for that can't be done in mode 0?
| Quote: |
| Code: | | sprites[0].attribute0 = COLOR_256 | TALL | yplayer; |
|
Why specifically do you need 256 colors for a sprite cel?
| Quote: |
| I think that you might have missunderstood me, The sprite doesn't show up on the main screen, but the BG does. In VBA's Oam viewer the sprite shows up the right size just all black. |
That would have been the case "Sprite is completely transparent in OAM Viewer".
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#79281 - thegamefreak0134 - Wed Apr 12, 2006 6:00 pm
| Quote: |
memcpy( (u16 *)0x06010000, &man_right_pistolData, sizeof(man_right_pistolData) );
sprites[0].attribute0 = COLOR_256 | TALL | yplayer;
sprites[0].attribute1 = SIZE_64 | xplayer;
sprites[0].attribute2 = 512;
|
This here is a problem, regardless of mode. Sprite attribute 2 is a number representing tiles, starting at memory address 0x06010000. If you tell it 512, you're telling it to look 512 tiles past that. You need to copy your sprite to tile 512, not tile 0. Otherwise, change to a different mode (few games actually use modes 3-5, so learn tiles and deal with it) and use the sprite at location 0.
Try this: Go into VBA and look in the tile viewer. Click on 0x06010000 at the left. Notice that the tiles for your sprite appear at the top? (you may have to change to 256 to see them properly.)
Now notice this: The top half of this window cannot I repeat cannot be used in mode 4. Thus, you must use the bottom half. You already have your sprite pointing to the bottom half, you just have to get the data there to. With the sprite pointing to all of that non-data, there's your black box.
Cheers!
-thegamefreak
_________________
What if the hokey-pokey really is what it's all about?
[url=http:/www.darknovagames.com/index.php?action=recruit&clanid=1]Support Zeta on DarkNova![/url]
#79465 - Cearn - Thu Apr 13, 2006 9:45 pm
What they said, and to add ...
| Fenderocker wrote: |
here is my code: | Code: | #include "gba.h"
#include "graph.h"
void InitializeSprites(void);
void CopyOAM(void);
void MoveSprite(OAMEntry* sp, int x, int y);
void Moveplayer(void);
[[ code from the Crash course ]]
|
|
Do not use the Crash course as a basis for your GBA code, it contains Bad and sometimes even Wrong code. For example:
- Use devkitARM instead of devkit Advance, which is so very out of date.
- Do not #include code or data files. This will lead to overly long compile times, possible data alignment errors and other badness.
- Use 32bit types for variables. The GBA is a 32bit machine, and therefore prefers 32bit data chunks (words). Using u8 or u16 for variables does not save space as they aren't actually ever put in memory (except if they're global). In fact it even costs space and time because extra instructions need to be generated to make them act as bytes or halfwords. Non-word globals and #including data is asking for alignment errors. Ints if you can, the rest only if you have to.
- On using OAM. Instead of casting 0x07000000 as a halfword array, cast it as a OAMEntry array. That's how it's actually laid out anyway, so it would make dealing with OAM easier.
| Code: |
#define OAM_Mem ((OAMEntry*)0x07000000)
// better CopyOAM
void CopyOAM()
{
int ii;
OAMEntry *dst= (OAMEntry*)OAM_Mem, *src= (OAMEntry*)sprites;
while(ii--)
*dst++ = *src++;
}
|
This version of CopyOAM is just over 5.6 times faster by using struct copies instead of u16 copies. The fact that the loopcount is much lower saves a factor 4, the rest is of the speed is due to special ARM instructions that can copy blocks of words in one go, which is usually used for struct copies.
(Note: using an int for the loop counter instead of u16 would also save about 20%, but devkitARM 18 is smart enough to fix this)
(Note: unfortunately, it doesn't optimize to block copies properly anymore, unless you use an incrementing pointer loop. Oh well)
Sprite positioning badness. MoveSprite doesn't mask the bits of x and y, which will overwrite the whole of attributes 0 and 1 if they're negative.
| Code: |
void MoveSprite(OAMEntry* sp, int x, int y)
{
sp->attribute1 &= ~0x01FF;
sp->attribute1 |= (x&0x01FF);
sp->attribute0 &= ~0x00FF;
sp->attribute0 |= (y&0x00FF);
} |
OAM_Data vs 0x06010000. 0x06010000 is not part of OAM, it is part of VRAM. So the name OAM_Data is wrong, and can lead to confusion -- the kind of confusion we saw at the beginning of this thread. Rename, please.
Magic numbers.
| Code: |
| memcpy( (u16 *)0x06010000, &man_right_pistolData, sizeof(man_right_pistolData) ); |
Do not use literal addresses like 0x06010000, use macros or a typedef'ed memory map to find the addresses of tiles. Also, be aware of the potential problems with memcpy() and sizeof().
On VBlank syncronisation. There are a lot of technically incorrect vsyncing code out there, the Crash course uses one of them. By just checking for REG_VCOUNT != 160 (or even just <160) it is possible that you'll still be in the VBlank when it encounters the next WaitForVBlank, which will then be passed through immediately.
| Code: |
static inline void WaitForVsync()
{
while(REG_VCOUNT >= 160);
while(REG_VCOUNT < 160);
}
|
There is an even better method, namely the BIOS routine VBlankIntrWait, but you'll have to use interrupts first.
Do not get too comfortable with the bitmap modes (modes 3,4,5). They are nice to learn the ropes, but usually too slow and restrictive for real use. The tile modes (0,1,2) are much, much more versatile.
| Code: |
xball++;xball++;xball++;xball++;
|
O_O
please.
A sizable portion of the questions posed on this forum is due to the Wrong code in the Crash course, and are even covered in the FAQ. The items that are not technically wrong but still Bad get you stuck in bad programming habits that you'd have to unlearn lateron. Fix all of them now; it's not hard and you'll benefit from it in the long run.
#79478 - Fenderocker - Thu Apr 13, 2006 11:04 pm
ARRRGGG!! Why is everyone against crash course?I mean it works.
Why would I use a different compiler when I've already got one that works perfectly well?
Whats so bad about mode 4?
also, I only used Crash course because it was so easy to understand! Also, All the other tutorials had broken links to the compilers they told me to use thatI couldn't follow the tutorial even if I wanted to.
If the crash course is so bad why don't they just remove it from the site? hmm?
#79484 - Cearn - Fri Apr 14, 2006 12:05 am
| Fenderocker wrote: |
| ARRRGGG!! Why is everyone against crash course? |
Can't speak for everyone, but I'm against it for the 1, 2, 3 ... 10 points mentioned above. There have been times when the problems caused by #including data came up once a week. Pretty much everyone who's been here a while advises against it. Not masking out coordinates in sprite positioning is also a frequent occurance, as are vsync variants and (unexpected) slow code. Which is why all of these have entries in the FAQ. and of course, anything that uses code like "x++; x++; x++;" should just be smacked down. Hard.
| Fenderocker wrote: |
| I mean it works. |
No, it seems to work. That's actually worse than being flatout wrong as it lulls people into a false sense of security. There are a lot of hidden flaws which will manifest themselves eventually on other projects, and you'd have to spend a lot of time fixing them. Better to do it now and get it over with.
For example, by #including non-word data and using non-word globals, data alignment errors are merely a matter of time. When I first got here I never even considered the possibility of such a thing and I'm sure I'm not alone there. Such bugs are nearly impossible to find unless you know what you're looking for.
| Fenderocker wrote: |
| Why would I use a different compiler when I've already got one that works perfectly well? |
Because devkitARM is easier to install, smaller, faster, more versatile, produces better output, and has been updated some time in the last four years.
| Fenderocker wrote: |
| Whats so bad about mode 4? |
Because you can only use one background (no hardware layering effects or parallax), doesn't support hardware scrolling, cuts the number of object tiles in half and is just to damn slow to use for roughly 90% of the types of games the GBA is known for. Unless your backgrounds are very static (like in the crash course) or very dynamic (like in full 3D games), bitmap modes are just not that useful.
| Fenderocker wrote: |
| also, I only used Crash course because it was so easy to understand! |
True, it is easy to understand. However, complex question often have easy to understand, wrong answers. It's a fair resource to learn a few of the basics of GBA programming, but the code itself is just dreadful. I'd love to see it rewritten to be more up to date, and fixed for errors and bad coding standards. But I don't think the original author will do that, and I'm certainly not going to either (although I have 'fixed' code because I just can't not fix something that looks like that).
| Fenderocker wrote: |
| Also, All the other tutorials had broken links to the compilers they told me to use that I couldn't follow the tutorial even if I wanted to. |
Apart from new pern and tonc, general GBA tutorials haven't been updated in 3 or more years and use devkit Advance. Those two exceptions use devkitARM, and their links work. (although I do have to say that pern's (and the FAQ's) links still point to the old devkitARM address, and it takes 2 redirects to get to the current page)
| Fenderocker wrote: |
| If the crash course is so bad why don't they just remove it from the site? hmm? |
I have wondered this as well. I guess because they're nice people that want to provide as much information about GBA programming as possible. Even if that does include stuff that has a lot of problems. But like you said, the crash course is easy to understand, which speaks in its favor. It should just come with a big, fat warning about its code that's all.
#79485 - wintermute - Fri Apr 14, 2006 12:11 am
| Fenderocker wrote: |
ARRRGGG!! Why is everyone against crash course?I mean it works.
|
Well, let's take a few examples at random.
The tutorial uses a toolchain that was a couple of years out of date even when the page was put together.
It uses .bat files to build projects. These are evil and should be avoided.
| Code: |
#define RGB(r,g,b) ((u16)(r | (g<<5) | (b<<10)))
|
This looks perfectly innocuous at first glance however it is rather easily broken and can introduce all sorts of odd side effects in your code. Take a case where you might want to build a GBA palette entry from an average of other values.
| Code: |
palette[i] = RGB( (red1 + red2) /2, ( green1 + green2)/2 ), (blue1 + blue2)/2 );
|
at best you'll get errors and/or warnings from the compiler. At worst it will fail silently.
| Code: |
#define WaitForVsync() while(REG_VCOUNT != 160);
|
As Cearn already explained, this macro is just broken. It will only work if you happen to hit line 160 of the display when you decide to wait. This is quite rare.
I could go on much further but there are so many things wrong with that particular tutorial I'd be typing this over several days. Suffice to say it should be avoided.
| Quote: |
Why would I use a different compiler when I've already got one that works perfectly well?
|
Up to a point. If you're using the cygwin version then it's rather slow. There are also several compiler bugs which have been fixed since devkit advance was last updated.
| Quote: |
Whats so bad about mode 4?
|
The GBA isn't designed to push pixels and does it quite poorly without extremely carefully designed code. The tilemap modes are much more versatile and hardware accelerated.
| Quote: |
also, I only used Crash course because it was so easy to understand! Also, All the other tutorials had broken links to the compilers they told me to use thatI couldn't follow the tutorial even if I wanted to.
|
One of the unfortunate things about GBA development is that all the crap tutorials with dodgy code and poor practises are "easy to understand". In order to program this little beast effectively you need to put some work into learning the proper way to do things.
| Quote: |
If the crash course is so bad why don't they just remove it from the site? hmm? |
The internet is full of drivel like this and unfortunately there's no way to have it removed. Freedom of speech and all that.
_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog
#79487 - Fenderocker - Fri Apr 14, 2006 12:24 am
OK I now see your guys's points. I will switch to DEVKITARM as soon as possible. My only problem is that I will have to re-learn everthing (pretty much) about GBA deving. If some one could point me to an up-to-date tutorial I could use that would be really helpful. I was already going to compleatly re-do my game graphics so It won't be that hard to re-do the whole thing. I've already looked into the Pren tutorials and they seem pretty good but If anyone else has anything just let me know.
#79490 - Cearn - Fri Apr 14, 2006 12:39 am
| Fenderocker wrote: |
| My only problem is that I will have to re-learn everthing (pretty much) about GBA deving. |
Not really actually. It's still true that there are 128 objects in total and controlled through OAM, that VRAM is at 0x06000000, you have IO registers to manipulate stuff on the 0x04000000 region, etc. It's only the course's code making use of all of that stuff is poor, but all of that is easily remedied and I already gave out plenty of pointers for that on the first page. Consider it an exercise.
| Fenderocker wrote: |
| If some one could point me to an up-to-date tutorial I could use that would be really helpful. |
I think I did plenty of that as well :P
#79498 - sumiguchi - Fri Apr 14, 2006 1:07 am
| Quote: |
| Why is everyone against crash course?I mean it works. |
Don't worry they are still helping you! :)
#79509 - Fenderocker - Fri Apr 14, 2006 1:53 am
I downloaded and installed devkitARM and am really confussed!1. TONC told me to download something else with the installer called MSYS-1.0.10.exe ,that wasn't on the devkitARM download page :(
2. I don't have any Idea how to use devkitARM, the TONC tutorials are really confussing.
I'm gonna try the Pern progect and see if it is clearer.....
#79519 - tepples - Fri Apr 14, 2006 2:53 am
| Fenderocker wrote: |
| TONC told me to download something else with the installer called MSYS-1.0.10.exe ,that wasn't on the devkitARM download page :( |
Did you try using the devkitPro Updater?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#79525 - Fenderocker - Fri Apr 14, 2006 3:12 am
Yep, Just did it works now, what exactly is bad about using a .bat for compiling?
#79533 - poslundc - Fri Apr 14, 2006 4:54 am
| Fenderocker wrote: |
| Yep, Just did it works now, what exactly is bad about using a .bat for compiling? |
Using a batch file to automate your build process generally means you will have to recompile every single unit of your program (.c files), as well as any art and other assets, every time you run the script.
Makefiles use the timestamp on the files to enable you to rebuild only the sections of the project that have changed since the last time you built. They can also track the dependencies of your files, so if you change a header file only the C files that #include it will be rebuilt.
It's a timesaver on small projects. On big projects, it's a lifesaver.
Plus, makefiles are designed for precisely the purpose you're attempting to accomplish with batch files. There are all sorts of features they possess that can be used to make your build process more efficient.
The only thing about makefiles is that they can be tricky to learn. But there's plenty of good documentation and tutorials out there (many linked to from this site). If you ever intend to do any industry-level programming - games or otherwise - you'll have to learn to deal with them sooner or later.
Dan.
#79535 - tepples - Fri Apr 14, 2006 5:20 am
But for a simple 1, 2, or 3-file project, such as one that tests behavior of a specific set of registers, is it worth it to make a makefile right away?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#79560 - sgeos - Fri Apr 14, 2006 10:11 am
| tepples wrote: |
| But for a simple 1, 2, or 3-file project, such as one that tests behavior of a specific set of registers, is it worth it to make a makefile right away? |
Depends. How much do you value instinctively creating makefiles?
A) Good idea.
B) Could care less.
Your answer means:
A) Create a makefile. It is worth the effort.
B) Don't bother. It is not worth your time.
-Brendan
#79587 - tepples - Fri Apr 14, 2006 12:52 pm
Imagine a compiler that can compile multiple modules, but loads and parses header files only once if you compile multiple modules. In that case, recompiling everything (for example, gcc *.c -lthis -lthat -o game.elf) might be significantly faster than recompiling two or three files that have changed. This is the situation in the Java programming language, and I'm considering using the JDK to develop data conversion tools.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#79612 - Fenderocker - Fri Apr 14, 2006 2:57 pm
ok, I now relize that I've wasted a large chunk of your guys's time......... I'm going to fix the things that Cearn mentioned, but not re-do any tutorials, 'cause I think I've got the hang of every thing, just didn't have the code that was up-to-date. I'll get some new functions for OAM and stuff....and start using devkitARM with make files.
one last question: when is it not ok to include a .h file?
#79615 - Cearn - Fri Apr 14, 2006 3:51 pm
| Fenderocker wrote: |
I downloaded and installed devkitARM and am really confused!
1. TONC told me to download something else with the installer called MSYS-1.0.10.exe ,that wasn't on the devkitARM download page :(
|
Crap, good point. The links must have been deleted after the automatic installer came into the picture. Updating now. If the updater doesn't work for you, you can always find everything here.
| Fenderocker wrote: |
| 2. I don't have any Idea how to use devkitARM. |
It's almost the same as using DKA, just the names of a few things have changed. Oh, and the -specs flags of course.
| Fenderocker wrote: |
| the TONC tutorials are really confussing. |
Welcome to the Real World, muwahahahahaha >:). Sorry, couldn't resist.
But seriously, stop just copy-pasting code from everywhere and start to think about what you're actually trying to do. Spend some time learning C, using the command line and makefiles. These things aren't very hard, really, just different than what you may be used to.
| Fenderocker wrote: |
| one last question: when is it not ok to include a .h file? |
The problem isn't #including .h files, the problem is what's in the .h files. The whole point of header is to be #included, but they shouldn't have symbol definitions in them: data arrays, functions, variables, that kind of stuff. All that belongs in separate C files to be compiled separately and linked later. See here for the full story. If your C book or tutorial didn't cover what actually happens when you build a project, it might be time to look for one that does.
#79621 - wintermute - Fri Apr 14, 2006 5:19 pm
| tepples wrote: |
| Imagine a compiler that can compile multiple modules, but loads and parses header files only once if you compile multiple modules. In that case, recompiling everything (for example, gcc *.c -lthis -lthat -o game.elf) might be significantly faster than recompiling two or three files that have changed. This is the situation in the Java programming language, and I'm considering using the JDK to develop data conversion tools. |
But then your data conversion tools will be slower than the native code equivalents.
gcc has been able to use pre-compiled headers for some time.
http://gcc.gnu.org/onlinedocs/gcc/Precompiled-Headers.html
_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog
#79667 - tepples - Sat Apr 15, 2006 3:16 am
| wintermute wrote: |
| tepples wrote: | | I'm considering using the JDK to develop data conversion tools. |
But then your data conversion tools will be slower than the native code equivalents. |
Urban legend. Besides, sometimes developer time (which involves not having to free() all the time) is more valuable than run time.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#79984 - Fenderocker - Mon Apr 17, 2006 11:21 pm
| Cearn wrote: |
| Fenderocker wrote: | | the TONC tutorials are really confussing. |
Welcome to the Real World, muwahahahahaha >:). Sorry, couldn't resist.
But seriously, stop just copy-pasting code from everywhere and start to think about what you're actually trying to do. Spend some time learning C, using the command line and makefiles. These things aren't very hard, really, just different than what you may be used to.
|
I don't just copy and paste code! I read some of your tutorial and thought it was confussing, thats all. Also, I think that I got a lot out of it for being 12 years old! most kids my age would be baflled (sp?) after reading the first line of anything related to GBA deving even the GBA CRASH course!
Sorry 'bout that, but I had to get it out. also after spending a little more time on your tutorial Cearn I realize that it's the best out there, maybe even better than the PERN project.
#79992 - Cearn - Tue Apr 18, 2006 12:01 am
| Fenderocker wrote: |
| Cearn wrote: | | Fenderocker wrote: | | the TONC tutorials are really confussing. |
Welcome to the Real World, muwahahahahaha >:). Sorry, couldn't resist.
But seriously, stop just copy-pasting code from everywhere and start to think about what you're actually trying to do. Spend some time learning C, using the command line and makefiles. These things aren't very hard, really, just different than what you may be used to.
|
I don't just copy and paste code! I read some of your tutorial and thought it was confussing, thats all. Also, I think that I got a lot out of it for being 12 years old! most kids my age would be baflled (sp? "baffled") after reading the first line of anything related to GBA deving even the GBA CRASH course!
|
Well you have to admit that your original did have a good deal of simularities with the crash course. It's still good advice, though: critical thinking is a Good Thing in any field. And if you're twelve I'd have to agree that, if you understand our points mentioned here, you're doing pretty well. I imagine most teens would run away screaming at what you're attempting here. Well, maybe not, but it might not be far off.
| Quote: |
| Sorry 'bout that, but I had to get it out. also after spending a little more time on your tutorial Cearn I realize that it's the best out there, maybe even better than the PERN project. |
^_^
I know it's a little on the technical side and mostly aimed at people who have had at least some formal training in both math and programming. Just take your time, you'll be fine.
#79994 - Fenderocker - Tue Apr 18, 2006 12:11 am
All you guys here are so helpful! actually Cearn, the first time I looked at some code in any programing language i almost did run away and scream. It was HTML but still.......I think that I do pretty well....the only problem with being young is my lack of money for some good hardware and my shorter attention span hehe.........Everything in GBA programing takes so long, but I'll hopefully get a playable Demo out this month......we'll just have to wait and see...
#80009 - gauauu - Tue Apr 18, 2006 2:11 am
| Quote: |
the only problem with being young is my lack of money for some good hardware
|
I remember those days....
The nice thing is that, as long as you have a windows computer with internet access, you can do a lot in the way of gba programming. Sure, proper hardware to test (and see your game on hardware, which is fun) can be expensive, but this is one area where you can do a lot with free tools and emulators....
#80099 - tepples - Tue Apr 18, 2006 8:02 pm
| gauauu wrote: |
| this is one area where you can do a lot with free tools and emulators.... |
Until you run into people such as Michel Iwaniec ("Bananmos" in the NES scene) who seem to think that a program tested only on multiple emulators isn't good enough to release to the public in any form and who have threatened assault and battery against those who do.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.