#58818 - Issac - Wed Oct 26, 2005 1:39 pm
I'm sorry if this has been asked before, I did a search, but didn't find it.
Hello, I tried to do a start menu to my game.
I've tried to use background pictures, and variables:
show background 1 where 1:st option is selected, variable x=1,
press down to:
show background 2 where 2:st option is selected, variable x=2,
etc.
the two first went all right, but when i added all my seven backgrounds, i got errors when compiling.
something about the ewram(or if it was named some other way).
Anyone have any better ideas how i should do it? or.... yeah.. anyway, I need help with it.
_________________
yeah, well, maybe... or? anyways.... eh... what was i talking about??
#58821 - tepples - Wed Oct 26, 2005 2:50 pm
Are you compiling in multiboot mode? Don't.
Please copy and paste the exact error message.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
Last edited by tepples on Wed Oct 26, 2005 3:06 pm; edited 1 time in total
#58823 - Cearn - Wed Oct 26, 2005 2:58 pm
If you're compiling for multiboot (-specs=gba_mb.specs), all code and data goes into EWRAM, which is 256 kb in size. If you have, say, 7 mode 3 backgrounds, that's 7*240*160*2 = 538 kb, which wouldn't fit. If this is the case and gcc complains (does gcc check the section sizes? If so: cool!), be happy for that: compile-time errors are better than runtime errors.
There are plenty of solutions for this. You could compile for ROM code. ROM is much bigger, but you wouldn't be able to test on hardware with just an xboo cable. Other solutions are the use of tile-modes, which can be drastically smaller if you have repeating tile patterns; or compression. The better conversion tools should have compression options. If yours doesn't have them, consider switching.
#58921 - Issac - Thu Oct 27, 2005 7:58 am
okay, I might use multiboot, but I'm not sure.
I'll post the full error message here:
My perverted friend wanted Pr0n as a workname hehe..
| Code: |
d:\devkitarm\bin\..\lib\gcc\arm-elf\4.0.1\..\..\..\..\arm-elf\bin\ld.exe: region ewram is full (pr0n.elf section .rodata)
d:\devkitarm\bin\..\lib\gcc\arm-elf\4.0.1\..\..\..\..\arm-elf\bin\ld.exe: section .ctors [02000000 -> 02000007] overlaps section .init [02000000 -> 02000237]
d:\devkitarm\bin\..\lib\gcc\arm-elf\4.0.1\..\..\..\..\arm-elf\bin\ld.exe: section .dtors [02000008 -> 0200000f] overlaps section .init [02000000 -> 02000237]
d:\devkitarm\bin\..\lib\gcc\arm-elf\4.0.1\..\..\..\..\arm-elf\bin\ld.exe: section .jcr [02000010 -> 02000013] overlaps section .init [02000000 -> 02000237]
d:\devkitarm\bin\..\lib\gcc\arm-elf\4.0.1\..\..\..\..\arm-elf\bin\ld.exe: section .eh_frame [02000014 -> 02000017] overlaps section .init [02000000 -> 02000237]
d:\devkitarm\bin\..\lib\gcc\arm-elf\4.0.1\..\..\..\..\arm-elf\bin\ld.exe: section .data [02000018 -> 0200001f] overlaps section .init [02000000 -> 02000237]
d:\devkitarm\bin\..\lib\gcc\arm-elf\4.0.1\..\..\..\..\arm-elf\bin\ld.exe: pr0n.elf: section .init lma 0x2000000 overlaps previous sections
d:\devkitarm\bin\..\lib\gcc\arm-elf\4.0.1\..\..\..\..\arm-elf\bin\ld.exe: pr0n.elf: section .dtors lma 0x2000008 overlaps previous sections
d:\devkitarm\bin\..\lib\gcc\arm-elf\4.0.1\..\..\..\..\arm-elf\bin\ld.exe: pr0n.elf: section .jcr lma 0x2000010 overlaps previous sections
d:\devkitarm\bin\..\lib\gcc\arm-elf\4.0.1\..\..\..\..\arm-elf\bin\ld.exe: pr0n.elf: section .eh_frame lma 0x2000014 overlaps previous sections
|
I think it might be that multiboot problem.
Umm, how do I choose how to compile non-multibooting? (if i can't find it myselft)
and im not using a xboo cable. I'm using a flashcard, so it's all good.
Only limitations are 256 Mbit, which I think is more than enough for my simple game.
Thanks for the help!
EDIT:
Okay, I think i found out how to compile it normally:
i changed:
| Code: |
| set SPECS=gba_mb.specs |
to:
| Code: |
| set SPECS=gba.specs |
Thats right?
_________________
yeah, well, maybe... or? anyways.... eh... what was i talking about??
#58941 - thegamefreak0134 - Thu Oct 27, 2005 1:46 pm
Unless I'm mistaken, you actually have to tell it to compile for multiboot with a line at the top of the program. Take that line out and it should work.
Otherwise, try looking in your makefiles/batch files (depending) to see if there is a specification there. Some makefiles (especially those with certain tutorials) compile for multiboot automatically because all of their demos are small enough to fit.
_________________
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]
#58952 - Fatnickc - Thu Oct 27, 2005 3:39 pm
If I remember correctly, with DevKitARM you don't need the line at the top, thegamefreak0134.
#58964 - Issac - Thu Oct 27, 2005 5:40 pm
well yeah, now i got that to work.
It was my makefile (that i took from a tutorial, yes) that had that multiboot line i wrote about above.
now, by some strange reason, I can't move through the menu... I will look into that a bit more tomorrow though. cause i think i MIGHT have missed one thing... but that's related to coding... so it wouldn't be a question to ask here? right?
_________________
yeah, well, maybe... or? anyways.... eh... what was i talking about??
#58972 - Fatnickc - Thu Oct 27, 2005 7:14 pm
This is a coding forum too. It's for anything and everything to do with programming for GBA and DS.
#58975 - Issac - Thu Oct 27, 2005 8:03 pm
yeah.. But this is the graphics part of the forum... that's why i said that =)
anyway.
my idea of how to get it to work is:
* one variable to see if i press "press" (this is because I don't want to jump several steps at one press, I want to press to jump ONE step, press again to jump another etc.)
* one variable to see which option is selected "z"
(now i dont remember the names exactly, but you should get the idea)
| Code: |
if((!(REG_KEYS && KEY_DOWN)) && (z==1) && (press==0)) { z++; press=1;}
if(REG_KEYS) { press=0;}
ETC. |
now, I think that SHOULD do it, right?
(and i have if(z==1){draw menu1;} etc later)
and everything within while(1){ .... }
Pseudocode:
| Code: |
if the fist option is shown, and i dont have anything pressed, go to the next option.
if nothing is pressed, allow pressing again.
...etc.
|
OH, and obviously this is C...
somehow this doesn't work for me, but i have it all in my school so i MIGHT have declared z as 0... and... that makes every if-statements false.
(tho, i do get a picture...)
ah...
I'm sorry for my choppy thought-like text, and my poor english...
Thanks!
_________________
yeah, well, maybe... or? anyways.... eh... what was i talking about??
#58995 - Cearn - Thu Oct 27, 2005 10:58 pm
| Issac wrote: |
* one variable to see if i press "press" (this is because I don't want to jump several steps at one press, I want to press to jump ONE step, press again to jump another etc.)
* one variable to see which option is selected "z"
(now i dont remember the names exactly, but you should get the idea)
| Code: |
if((!(REG_KEYS && KEY_DOWN)) && (z==1) && (press==0)) { z++; press=1;}
if(REG_KEYS) { press=0;}
ETC. |
|
REG_KEYS is low-active, meaing that the bits are set when they're up. the "if(REG_KEYS)" will run unless you press all the buttons.
The effect you're trying to avoid is called key bounce, and there are plenty of threads on it. If you want a simple solution, tonc: advanced key handling. Even if you don't need to check for bouncing, using some sort of key polling is preferable as you can get rid of that annoying low-active stuff by flipping everything at the poll. You also wouldn't have to read the contents of REG_KEYS every time you use it; it's volatile, remember? Using bit-ops rather than logical operators might make more sense too: that's what you're really checking for anyway and you can check multiple keys at once.
#59035 - Issac - Fri Oct 28, 2005 8:43 am
hmm, I've been looking through the tonc text there, and to be honest, i dont understand that much of it.
Do you think you could explain a little how and why it works? (i could just copy and test on my own, but I wouldn't understand that much)
I see what you mean with this reply, but... yeah... you understand what i mean...
Thanks!
_________________
yeah, well, maybe... or? anyways.... eh... what was i talking about??
#59043 - Cearn - Fri Oct 28, 2005 11:18 am
The basic issue here is that you need to compare the current keystate with an earlier one, so you use two variable to store these states in: key_curr and key_prev, respectively. Once per frame, you read in the frame's keystate, and save the old state. That's whay key_poll() is for.
| Code: |
void key_poll()
{
key_prev= key_curr; // save old state
key_curr= ~REG_KEYS; // get new state
}
|
Note that I'm flipping all the bits of the key register to get the more familiar high-active state, i.e., bit is set when button is down.
After this, you can simply use your knowledge of boolean logic and bit operators to get what you want. If you want to know the bits that are down now AND NOT in the previous frame, use key_curr & ~key_prev. Then AND with the bits you want to actually check for. Same thing if you want to know which keys were down in the previous frame AND NOT in the current one.
| Code: |
// down now, but not before
static inline u16 key_hit(u16 key)
{ return (key_curr&~key_prev) & key; }
// down before, but not now
static inline u16 key_released(u16 key)
{ return (~key_curr&key_prev) & key; }
|
As a simple example:
| Code: |
// bit patterns, already high-active
key_curr: 0000 0000 1010 0110 // down, left, sel, B
key_prev: 0000 0010 0110 0101 // L, up, left, sel, A
key_curr & ~key_prev:
0000 0000 1010 0110
1111 1101 1001 1010 &
-----------------------
0000 0000 1000 0010 // down, B are down not but not before
// check if select was newly pressed
(key_curr & ~key_prev) & KEY_SELECT
0000 0000 1000 0010
0000 0000 0000 0100 &
-----------------------
0000 0000 0000 0000 // Nope, I guess not.
|
#59068 - thegamefreak0134 - Fri Oct 28, 2005 5:35 pm
BTW, sorry. I'm used to DevKitAdv since I can't get the site to work for DevKitARM.
_________________
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]
#59155 - Issac - Sat Oct 29, 2005 8:54 pm
Cearn:
I think I understand that, seems all clear to me, EXCEPT all those 1001 1000 0000 etc. in the example? what are those? :S
_________________
yeah, well, maybe... or? anyways.... eh... what was i talking about??
#59166 - Cearn - Sat Oct 29, 2005 10:32 pm
Those would be bit patterns | Code: |
0000 0000 = 0x00 = 0
0000 0001 = 0x01 = 1
0000 0010 = 0x02 = 2
0000 0011 = 0x03 = 3
...
0101 0110 = 0x56 = 86
etc
|
#59171 - Issac - Sat Oct 29, 2005 11:57 pm
sorry for being a "noob"
but i still dont get it, like: 0x56 = 86 ?
i dont see how that pattern goes (since 0x03 = 3 and 0x02 = 2)
and I dont really know how to see which button is what... is it binary?
i'm ultra-confused... maybe i should go through your tutorial... just downloaded the cht-file (or whatever it is called (me and names haha))
anyway, even if i seem "stupid" This is Highly appriciated, and i learn a lot!! which is great!!
(credits? of course!!) <3
_________________
yeah, well, maybe... or? anyways.... eh... what was i talking about??
#59176 - Cearn - Sun Oct 30, 2005 12:31 am
Binary, decimal, hexadecimal. Things will make a whole lot more sense if you know your way around these three number systems. The numbers page wuld be a good place to start. Well, maybe not to start, but should be a useful read. Also recommended: scientific mode of the windows calculator, it has buttons so you can quickly change between binary, octal, decimal and hex representations.
Simple hex (base 16) examples using "0x56" and "0x1234"
The "0x" part is just a prefix, you should have seen it before. The actual number part is in the "56" and "1234" but we need the prefix to indicate the numbers are hexadecimal.
| Code: |
0x56 = 0x50 + 0x06
= 5*16^1 + 6*16^0
= 80 + 6
= 86 (dec)
0x1234 = 0x1000 + 0x0200 + 0x0030 + 0x0004
= 1*16^3 + 2*16^2 + 3*16^1 + 4*16^0
= 4096 + 512 + 48 + 4
= 4660 (dec)
|
| Issac wrote: |
| I dont really know how to see which button is what... is it binary? |
Everything in computers is binary, so yeah :P
But more to the point, each button has its own bit in REG_KEYS. Whenever you see something like (1<<n) in #defines, the n is the bit that the define is about. For example, KEY_L is bit 9, so you'd use (1<<9). You can also write it in hex. As there are exactly 4 bits in each hex digit (that's why hex is often used), KEY_L can also be written as 0x0200. You can still use decimal, of course, in which case it's 2^9= 512.
| Code: |
// KEY_L (bit 9) in binary, hex and decimal
bin: 0000 0010 0000 0000
hex: 0x0200
dec: 512
// KEY_L | KEY_SELECT (bit 9 and bit 2), bin, hex, dec
bin: 0000 0010 0000 0100
hex: 0x0204
dec: 516
|
From binary and hexadecimal you can easily see which bits are set and which are not, but that's not generally true for decimal. Which is why the first two are preferable for bit defines ... admittedly at the expense of newbies.
#59261 - Issac - Sun Oct 30, 2005 8:07 pm
aaah, this makes it all more clear!
(I know how to use the binary system, i just wondered if it was that you used it :P I was tired when i wrote it, so it came out wrong.)
so I know Binary and decimal.. and I think I understand hex now too..
and just to see if i understand:
bit 4 can be written as 2^4 = 16... = 0x10 (1*16^1)?
seems logical to me :P
now I will read through this a few more times, and check your tutorial, to adapt it all to my game :)
Thanks a lot!! (oh, and if you want to suggest me to read / practice some stuff, please go ahead and tell me!)
_________________
yeah, well, maybe... or? anyways.... eh... what was i talking about??
#59452 - wintermute - Tue Nov 01, 2005 10:02 pm
| thegamefreak0134 wrote: |
| BTW, sorry. I'm used to DevKitAdv since I can't get the site to work for DevKitARM. |
What's the problem?
#60958 - Issac - Wed Nov 16, 2005 9:35 am
hmmm, cearn, I think I need some help in how to implement all this you thought me into my own code.... it would be really helpfull...
EDIT:
Hey hey hey! I got it now!
working all fine, just had problems cause i didn't define key_curr and key_prev as u16...
thanks anyway!!
But, now I have more questions to ask this time graphic related again...
I have many many many sprites and backgrounds... now, will i have any problems with my pallettes or something?? or are there ways to avoid that?
and how should i.... insert the sprites as sprites? and... how to count the memory things to put it all and.... you know.. basic stuff....
and... i will look through your tutorial.. but just if you want to explain something special, that you maybe assume i will need help with or something.. Thanks!!! <3
_________________
yeah, well, maybe... or? anyways.... eh... what was i talking about??