Starting out as I am as a gba developer, I''m trying to think of something nice and simple as a first game to be made. What do you guys think? Pong? Tetris? Something even more amoebic than that? I just want to be able to baby step up to something more significant, and more significant, etc. (Making a killer game on your first try is not impossible, it just feels impossibly hard.) If my understanding of sprites is fair enough, I might be able to design something and actually create a demo of it. But it depends on whether or not my compiler will let me compile certain sprite info or not. Anyways, any ideas? Thank you very VERY much for your time... it is most appreciated. Thanks in advance... -slippers2k p.s. what''s the easiest game YOU''VE programmed for the gba? Attack life''s problems like a Subaru... with all four wheels

Pong sounds like a nice, simple idea. IDEAL for a newbie like me.

I''m assuming I just have to make three white sprites, right? (Two rectangular ones, and a small white square for the ball) Do I have to worry about sprite sizes and collision detection at all, or is there just a general method to creating all that?

I''m also assuming basic AI will be to follow the ball and hit it back with basic collision detection in place. Never really asked this... "how" does it follow the ball?

Thanks in advance for any assistance offered.

-slippers2k

Attack life''s problems like a Subaru... with all four wheels

Im not very familiar with the gameboy advance, but the first game i made was pong. I made it in visual basic and included a 1 player mode with ai. I simply made a timer that went of every .05 seconds and had some simple if state ments like: if ball > paddle paddle = paddle + 5. This is incredibly simple ai, but i didn''t care because it was my first game and was supposed to be simple. Every time the ball bounce off of a paddle i added 1 to its speed. As soon as the ball got fast enough, the ai timer couldn''t keep up and it lost the ball. You can easily fix this problem by putting the if statment in a loop that runs contiuously, but make it try to anticipate where the ball is going to go and start moving there, and then correct itself by some amount. The amount could very each time making it imperfect. There are many ways of doing this, but they all involve repeatadly checking the position of the ball and the position of the paddle. After you have that you can set it up however you want

So far, I''ve got sprites for the ball and the player paddle. I learned to put two sprites on the screen through the Pern Project''s example tutorial... but I''m stuck.

I want to put a third sprite on the screen (the computer opponent''s paddle) and I''m trying to understand the numeric address where the third sprite should go. Here''s some info:

for(index = 0; index<256*4; index++) // don''t have a prob here
OAMData[index+(512*16)]=SPRITE1data[index];

... //so on for ball sprite

for(...)
OAMData[index+256*8+(512*16)]=SPRITE4data[index];
//what''s wrong with the above line?

(512*16) refers to the 16-bit offset in the mode I''m in: 32 bytes per tile * 16 bits (OAMData is 16-bit pointer). I''ll keep checking more of this info out myself in the meantime.

In total, there are going to be 2 32x32 sprites as the paddles. For now, the ball sprite is huge (64x64), but that size will be changed eventually. All I need to know for now is the proper offset information needed in the code. I''m using mode 4.

Any ideas? Help is as always appreciated. I''ll keep cranking away...

-slippers2k

Well, I''d suggest doing it this way.

Hopefully you already know about giving each sprite its own character name, right? That number goes in the first 10 bits of attribute 2. You can use that number to determine the location where the sprite data for each sprite is located.

To quote Dovoto''s tutorial:

"To compute the actual memory address of a character the following equation will work. 0x6010000 + (CharName * 8x4) = addressOfChar."

That means that 0x6010000 is the beginning of the sprite image data. To find the beginning of the sprite you''re looking for, use 0x6010000 + (character_name*32)
or rather
0x6010000 + (character_name<<5)

and you have the location of the beginning of your sprite''s image data.

I think your problem is probably that you''re not compensating for EVERY sprite before the one you''re trying to write to. I know that can be a huge pain to track, so that''s why I advise using the character numbers. After all, that''s how the hardware tracks what''s what, so you might as well use it too.

-Arek the Absolute

Arek,

First off, I''d like to thank you for your continued assistance. It''s hard to find someone to mentor you in learning something new, let alone coding for the GBA. I really appreciate your assistance.

I will be giving the Character number thing some more serious thought... before, I had used the tutorial zipfiles for making sprites on the pern project site. Strangely enough, the files that I worked with never made any mention of CharMem (at least, I don''t recall offhand).

DUMB QUESTION WARNING!

When you know the exact address in character memory of where the sprite image data starts, how do you render it to the screen? I''m so accustomed to using OAMData to load sprites to memory that I''m not sure how it could work any other way. (Hint: check out Dovoto''s tutorial in day 3 for sprite rendering with rotation and you''ll see how he loads the sprites to the screen.)

Thank you again very much for all your assistance. The only thing that is really confusing me is the allocation of character numbers and memory but with study that should go away.

-slippers2k

Attack life''s problems like a Subaru... with all four wheels

I think I have an idea what you''re talking about, but I''m not sure. It''s a good thing I use some of Dovoto''s examples at least as a basis for my own, so if I just dodge that fact by providing code examples, the problem may be averted.

The first thing to do when setting up a sprite, at least Dovoto''s way, is to fill in the data for the sprite''s attributes. You''d do that like this:

sprite[0].attribute0 = COLOR_256 | SQUARE | 10; /* 256 colors | square shape | y position = 10*/
sprite[0].attribute1 = SIZE_32 | 10; /*size 32 | x position = 10*/
sprite[0].attribute2 = character_number;

Now, the problem is that the sprite is completely empty. To solve this, we need to copy in image data. Before we can do that, we need to find out where we need to copy the data in, which is where my last post comes into play:

u16 *destination = 0x6010000 + (character_number<<5);

Once we have that, we can go ahead and copy our image data into place. This would probably be best done with a DMA copy, seeing as its so much faster than for loops or anything like that. To do so, I''ll just use the function Dovoto provided.

u16 color = 0x1111;
DMA_Copy(3,(void*)&color,(void*)destination,512,DMA_16NOW | DMA_SOURCE_FIXED);

This will fill the sprite with the first (visible) color in the palette. The only other important part to explain here is the number 512. This number assumes a couple of things, but should work for this example. To get the number you need for your own sprites, just know this: In a 256 color sprite, every 8 bits contain the data for 2 pixels. We use a 16 bit value for the color rather than an 8 bit number simply because DMA can''t copy only 8 bits at a time. Therefore, the value you put here (which is to say the number of copies DMA needs to make) is the width of the sprite /2, and that number multiplied by the height.

Now, there''s only one thing left that may stop the image from appearing on the screen. That is to say, OAM, as Dovoto uses it, is stored in another buffer, rather than arranged where the hardware needs it. To solve this, he provides a function called CopyOAM. Simply run that function after any changes, or once each frame, or whatever is appropriate.

Assuming you''ve also filled in palette data, everything should work. Or I''m full of it. One of the two. Feel free to let me know which one.

-Arek the Absolute

Arek, thanks again for your input. I definitely value the tutoring session

I thought I'd repay you by showing you a pic of my current progress. This is my current take on the first post: CAR PONG!

http://members.fortunecity.com/slippers99/pics.html

Picture description: the two cars are the paddles. The little yellow tennis ball (yes, I know it's square ) is the ball. The background is actually a screen grab from Tokyo Extreme Racer 2 for the Dreamcast.

Things I have yet to add:

* Collision detection for the ball
* A scoring system
* Text for scorekeeping
* win/lose conditions
* opening screens, etc.

But I'm working on it!

Seriously... the next time I start a GBA project I will put MUCH more attention on using hex to precisely carve up memory.

Thanks to all for your input... more to come!

-slippers
aka the pong martial artist

p.s. the reason why the cars have weird things on top? For one, I found I could not make a nice-looking car sprite in square without stretching it (I'm still learning about sprite sizing and all that). Two: that is a surprise you'll learn about in future versions. Feedback? Comments? Let me know ppl! C-YA! :D

Attack life's problems like a Subaru... with all four wheels

[edited by - slippers2k on December 13, 2002 11:13:22 PM]

Still working on Car Pong... just wanted to pass along a link to my first alpha version:

http://members.fortunecity.com/slippers99/carpong.zip

Added:

* Ball-sprite collision detection
* VERY simple computer AI (follows the ball perfectly, need to make it "dumber"
* Pause/slow-motion feature (don''t know if slow motion will work on Gameboy Advance hardware)
* Splash screen (just doesn''t have the words "press start" on it yet)

The demo should load to the splash screen. Once it does, just press start to commence gameplay. Just the arrow keys for controls for now.

Things to be fixed or added:

* Collision detection for screen edges
* Further collision detection issues for ball and paddles
* Text and additional sprites
* AI and win-lose conditions

Much more to be done still, but I hope you like it.

Thanks for all your assistance out there!
-slippers2k

Attack life''s problems like a Subaru... with all four wheels