#15524 - schoebey - Sat Jan 24, 2004 12:50 am
hello
i have defined a struct like this:
| Code: |
struct ROOM
{
char extended[2];
const u8* objectinfo[10];
const u8* screendata;
const u8* screenpalette;
struct point borderedge[10];
struct SWAPLINE swapline[2];
struct OBJECT object[10];
} __attribute__ ((aligned (8)));
|
(not sure about the __attribute stuff...it seems to fix some probs i had without it though...)
now, i create an array of structs:
| Code: |
struct ROOM rooms[50];
|
which seems to work fine. But if i change the size of the array to, say 100, my whole mem-layout seems to be turned upside-down.
Pointers don't seem to point to the correct memory-locations, and thus i'm unable to decompress data correctly anymore....
furthermore, i think it should not matter whether a "u8" definition is standing before a "u8*" definition in the struct (except it might, depending on the situation, make the struct-size slightly smaller).
But if i change the order of the definitions, everything is being turned upside-down (same as the above problem)....
maybe i'm missing a crutial point here, but according to the exercises we did with gcc @university, it should run perfectly, no matter how big the struct-array and no matter what the order of the struct-members is...
(unless the size of the whole thing exceeds mem-capacity)
It may even happen, that the alignment of ever struct-member is correct up to element 20 of the array, then el.20 has one member with an incorrect alignment and everything else works.....
has anybody some suggestions? i'd really appreciate any help
thanks
schoebey
_________________
to an artificial mind, all reality is virtual
#15527 - sajiimori - Sat Jan 24, 2004 1:39 am
Depending on the size of SWAPLINE and OBJECT, your array could be overflowing IWRAM (assuming you're putting it in IWRAM). For instance, if SWAPLINE and OBJECT are both 20 bytes, an array of 100 ROOMs will consume at least 35K.
DKA's malloc is configured to use EWRAM by default, so you could always try that out.
#15536 - sgeos - Sat Jan 24, 2004 7:04 am
You only have so much space to work with. If I wrote the following code:
| Code: |
struct magic_box {
/* A whole bunch of suff in the body */
};
struct magic_box[1000001];
|
In theory that would work. The compiler may generate code that works- in theory. In reality, I don't have enough space for one million and one magic boxes.
-Brendan
#15563 - schoebey - Sun Jan 25, 2004 1:46 am
it's not the space i'm talking about...i have plenty of space for my struct-array, IF it's located in EWRAM....
...in fact, it's even the case that (for example) everything works fine with 100 elements in the struct-array, but when i reduce it to 50, everything is messed up (and i'm NOT using the elements above 50)
however, the suggestion of sajiimori might work....i'll give that one a try as soon as i have the time
but i still don't understand why the order of the members in the struct matters this much....
thanks
_________________
to an artificial mind, all reality is virtual
#15564 - sgeos - Sun Jan 25, 2004 2:35 am
Do you know if it is in EWRAM? You could always dump a pointer to the first word in EWRAM and than look at that location in VBA to see where your array starts.:
| Code: |
struct type_t {
/* data */
};
struct type_t array[50];
void *address = &array[0];
*(void *)0x02000000 = address;
whie (1) {
/* Loop forever so I can look at 0x02000000 */
} |
What do the insides of your other structs look like? Even if the struct is used for some display related, storage and retrieval of data can be tested on the PC. Have you done any testing of the code on the PC?
-Brendan
#15575 - schoebey - Sun Jan 25, 2004 2:19 pm
| sgeos wrote: |
What do the insides of your other structs look like? Even if the struct is used for some display related, storage and retrieval of data can be tested on the PC. Have you done any testing of the code on the PC?
|
do you mean whether the struct contains the right data or not?
i use the struct for:
-vertices of a polygon in which the character should be able to move
-objects (including coordinates and pointers to text-strings related to the object)
-pointers to gfx-data
-etc.
i did not test any of this on the PC, but everything seems to be filled with the correct data (if i don't change the order of the struct-members or the size of the array).
The funny thing is: if i create an array of 20, then fill this array with data for those 20 rooms, it may occur that only room 15 is messed up. if i then leave ar[14] (room 15) blank and move room 15 to ar[15], it's not messed up anymore, so i thought it had to be an alignment-problem...
(so one way to fix my problems would be to introduce a "buffer" every couple of rooms - i've tested it and it seems to work, but it's a waste of space)
btw. thanks for the tip with the pointer-dump...haven't thought of that ;-)
(hopefully i'll find some time soon to test all that)
schoebey
_________________
to an artificial mind, all reality is virtual
#15576 - poslundc - Sun Jan 25, 2004 2:30 pm
[quote="schoebey"] | sgeos wrote: |
| The funny thing is: if i create an array of 20, then fill this array with data for those 20 rooms, it may occur that only room 15 is messed up. if i then leave ar[14] (room 15) blank and move room 15 to ar[15], it's not messed up anymore, so i thought it had to be an alignment-problem... |
Can you confirm that the struct gets messed up when you first assign its value?
That is to say, try filling your buffer however your normally fill it, then immediately check to see if those values are correct. For example:
| Code: |
room[14].a = 10;
room[14].b = 14;
room[14].c = 25;
if ((room[14].a == 10) && (room[14].b == 14) && (room[14].c == 25))
while (1); |
You would expect this code snippet to enter an infinite loop if your values are being assigned properly (thus crashing your game when you run it).
If it doesn't enter the infinite loop, then there may be a problem with your struct alignment or how you load/save the data or something.
If it does, though, then I'll bet your problem lies in a faulty pointer somewhere else in your program that is overriding your data. I've had this happen before, where code that used to work fine suddenly stopped working fine because two unrelated sections of my program were overwriting memory (because of a faulty pointer). The only way to track this down is to systematically test and narrow down the spot in the code where your values get overwritten.
Dan.
#15588 - Paul Shirley - Sun Jan 25, 2004 9:57 pm
removed
Last edited by Paul Shirley on Sun Mar 28, 2004 9:18 pm; edited 1 time in total
#15638 - schoebey - Mon Jan 26, 2004 10:19 pm
Thanks to everyone of you!
as it seems, it really was the case that my struct occupied all of IWRAM...
using a malloc and the proper sizeof(), everything works (more or less) as it should...now i'm also able to change the order of the struct-members without any side-effect...
...now i can concentrate again fully on geting the sound to work...(which might result in some more posts ;-) )
thanks again, folks! you're really helpful
_________________
to an artificial mind, all reality is virtual