#146661 - Echo49 - Fri Dec 07, 2007 12:06 pm
I have a program using this struct:
Code: |
typedef struct {
u8 x;
u8 y;
s16 radius;
s16 cir;
u8 number;
disc_color color; // this is an enum of 0-3
bool draw;
} disc; |
Now, I need another variable in it. However, when I try to addinto it, I have to put it at the end after "draw". If I stick it anywhere else, I start getting what I believe to be memory address problems for some reason (ie. after passing pointer to a function and modifying a value, the value is modified in the function but not in the main loop).
What am I doing wrong?
#146662 - Tramboi - Fri Dec 07, 2007 12:14 pm
Looks like:
* either a rebuild problem where an obj file doesn't have an up to date definition of the struct
* or a duplicated structure definitions that doesn't match but should.
Try to rebuild everything :)
#146665 - Mighty Max - Fri Dec 07, 2007 12:51 pm
Access to 16bit or 32bit values have to be aligned. (on the ARM)
Set the alignment of struct members to 4byte to fix this problem, or presort the struct members: 4byte members before 2 byte members before single byte members
If you try to read an unaligned little endian 16bit value, you are actually reading the big endian 16bit value beginning from the next lower alignment.
_________________
GBAMP Multiboot
#146666 - Tramboi - Fri Dec 07, 2007 1:06 pm
Are structs packed by default with libnds?
#146667 - Mighty Max - Fri Dec 07, 2007 1:08 pm
Depends on your makefile.
_________________
GBAMP Multiboot
#146668 - chishm - Fri Dec 07, 2007 1:09 pm
Struct elements should be padded to the correct alignment in devkitARM. As Tramboi said, try rebuilding your project.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com
#146701 - Echo49 - Fri Dec 07, 2007 10:21 pm
I'd already tried a full rebuild before with no success. Rearranging the order does fix it, but interestingly the s16 values are read and written to properly no matter where they are placed in the struct. It's the bool value that's messing up the data. Do you recommend I use bool or just u8?
#146702 - Lick - Fri Dec 07, 2007 10:25 pm
Have you tried recompiling with:
above the struct definition?
_________________
http://licklick.wordpress.com
#146708 - Echo49 - Fri Dec 07, 2007 11:05 pm
Neithernor Code: |
__attribute__ ((packed)) |
helped.
Last edited by Echo49 on Fri Dec 07, 2007 11:07 pm; edited 1 time in total
#146709 - Lick - Fri Dec 07, 2007 11:06 pm
pack, not packet?
_________________
http://licklick.wordpress.com
#146710 - Echo49 - Fri Dec 07, 2007 11:07 pm
Yeah, I noticed after I posted, retested to no avail.
I didn't clean before I built though, I'll try that now.
Edit: Cleaning didn't help. I'm testing on No$gba though, not actual hardware.
#146716 - Lick - Fri Dec 07, 2007 11:44 pm
I think there's a problem somewhere else in your code.
_________________
http://licklick.wordpress.com
#146905 - SaruCoder - Tue Dec 11, 2007 1:29 am
How many of these structs are you instantiating at run time?
If you're creating an array of "disc", then try putting them on the heap using Code: |
discs = new disc[n]; |
instead of following which puts stuff onto the stack:
If you're putting them on the stack then adding one harmless variable can cause memory issues especially if you're creating thousands of these.
#146974 - Echo49 - Wed Dec 12, 2007 11:12 am
I'm instantiating 20 of these on the stack at the moment, but I might up it to 50-100 in the final version.
Putting them on the heap doesn't help. For some reason the program crashes if I use Code: |
disc* discs = malloc(sizeof(disc)*20);
memset(discs, 0, sizeof(disc)*20); |
with __attribute__ ((packed)) set for the disc struct.
When I printf() the values of each member of the struct the values are now correct, but the 3D graphics I'm drawing with this information is messing up. Maybe it's my 3D code, but how can a simple re-ordering of the members mess up the program, even with a full rebuild?
Edit: to be more specific, I *think* it's my textures that are disappearing, since I'm left with white squares rather than my actual texture.