#28774 - mr_square - Fri Nov 05, 2004 8:28 pm
I have a 'room' class, which essentially just contains various backgrounds, and limits their scrolling appropriately - preventing them from looping around, basically.
Somehow I got it all working together, but adding just a single additional pointer to my room.h file produces weird scrolling effects - either not scrolling far enough or looping around slighly. This pointer has *nothing* to do with anything - I've just declared it in the header, so I'm not quite sure why it would affect the scrolling in any way.
Adding that pointer but removing another seems to help though - am I using up too much memory or something? How could I tell if I was?
#28776 - Gene Ostrowski - Fri Nov 05, 2004 8:55 pm
I've had this sort of thing happen a few times. It almost always ended up being attributed to one of the following:
1) Out of memory. In my early days, I'd end up declaring many large arrays but forget to tell it to put it in EWRAM or ROM, and after some point, changing a single variable would cause wierd behavior like this. Use nmap or VBA to see your memory usage of the app (search the forums for many threads about it).
mod note: that should be nm not nmap
2) Changing a variable in a .h file would screw up some files, because not all of the dependent files that referred to the variable's address were recompiled. If file1.c was compiled to think that var1 is at address x, and you modify the header and it only compiles file2.c, which now thinks var1 is at address y, strange behavior happens.
3) If you are used to Windows applications that "crash gracefully" to pardon the term, you are in for a shock with the GBA. Many things that would cause a GPF in Windows land will simply silently fail on the GBA-- it has no memory protection devices that a decent OS has, so you could have a null pointer in your code and never know it, since it won't necessarily "crash" like you're used to.
_________________
------------------
Gene Ostrowski
#28784 - DiscoStew - Fri Nov 05, 2004 11:25 pm
I would agree with Gene on option 2, but how are you adding your pointer?
Is it global (by itself)? Or is it in a struct/class/etc?
_________________
DS - It's all about DiscoStew
#28790 - mr_square - Sat Nov 06, 2004 2:08 am
Its in a class. The arrows show the lines that I'm adding.
| Code: |
#ifndef room_H
#define room_H
#include "background.h"
#include "collisionDetector.h"
#include "object.h"
----->#include "playerState.h"<----------
class room
{
public:
background* bg1;
background* bg2;
background* bg3;
background* bg4;
int objectCount;
object* objects[];
----->playerState* player;<----------
int pixelWidth;
int pixelHeight;
room* rightRoom;
room* leftRoom;
room* upRoom;
room* downRoom;
collisionDetector* detector;
virtual void Update();
int hScroll(int xCoord, int xSpeed);
int vScroll(int xCoord, int xSpeed);
private:
int loop;
};
|
Thanks for the tips - don't have time to try them now, but will report back later. I'd guess its (2) as well - the only large data structures I have are headers with graphics data in them, but they're all declared as const, so should be stored on the cartridge.
#28992 - mr_square - Tue Nov 09, 2004 8:11 pm
Argh - it doesn't seem to be option 2. All my files are being recompiled quite happily by my makefile - I deleted all the .o files just in case, but no joy.
I'm fairly sure I'm not out of memory either - its not a massively complex program or anything, and I can declare new pointers in everything but that one class quite happily. I'm just putting everything in ROM at the moment.
#28993 - sajiimori - Tue Nov 09, 2004 8:14 pm
I vote for buffer overrun.
#29052 - mr_square - Wed Nov 10, 2004 9:32 pm
Oh what the....
I just created a new folder, copied all the files across and compiled it from there, and it works fine! Grr....
#29205 - mr_square - Sat Nov 13, 2004 6:26 pm
Sorry for dragging this topic up again, but I never managed to fix it first time around.
I'm having a similar problem again - addding a solitary integer to a class header messes stuff up. Bizarrely though, if I put the integer definition at a different point in the header, it works fine. Near the beginning or end works fine, but put it in the middle and my entire sprite system refuses to run.
sajiimori, you say a buffer overrun? How could I check for this?
#29206 - poslundc - Sat Nov 13, 2004 8:06 pm
See if you still get the problem when you remove the objects array. It's been a while, but I seem to recall that GCC sometimes had trouble if I attempted a static declaration of an array from within a more complicated struct.
If it turns out the object array is what's causing the problem, declare the objects array for each room separate from the room itself (at the global scope) and make "objects" in your struct a double-pointer instead of a pointer to an array. Then just put the array's label in your room definition instead of the whole array.
Dan.
#29207 - sajiimori - Sat Nov 13, 2004 8:51 pm
| Quote: |
| sajiimori, you say a buffer overrun? How could I check for this? |
Print lots and lots of debug output.
Finding out which values are getting corrupted shouldn't be too hard, because you know which parts of your code are responsible for scrolling, and what data they depend on.
Print a log of each time that data is modified via appropriate channels (i.e. method calls), and also print its contents frequently and find the place where it changes without having its mutator called. Whatever happened just before that is your buffer overrun.
But if copying your source tree fixed the problem, it's more likely your build process (earlier called possibility #2). Check again, more slowly.