GP32 Weird Doublebuffer Error With Mrmirko's Sdk + C++

[no_skill]

i wanted to add doublebuffer support to my port of SuperMarioWar.

but geepee32 always crashed with a memory write out of bounds error.
so i tried to compile the doublebuffer example in c++.
(changed filename, lg in the makefile and added #include "cpp_prototypes"

help: http://jnrdev.weed-crew.net/the_wonderful_...weird_stuff.zip

and here's what i encountered:

u16 *framebuffer;
u16 *framebuffer2;

int main(){
 // example.doublebuffer
}

won't display text on the buffer and crash randomly

int main(){
 u16 *framebuffer;
 u16 *framebuffer2;
 // example.doublebuffer
}

works as usual.


this is a very strange behaviour and might also cause other bugs in your projects.

but i aint am sure what's causing this, here's my person list of maybe sources:

crt0.s
geepee32
devkitARM (oh, i forgot to mention that i compiled this example on devkitarm (with MrMirko's also build on devkitARM)


has anybody encountered a similar problem, or is it my urge for c++ again?


asap i'll try it on gp32_MrMirkos and run the exapmle on my gp32 (but my batteries are out and i'm not at home).

 

[loki666]

dont know about your problem...
i'm using ADS with mr.mirko sdk and c++ compile just fine...
never tried with gcc...

 

[no_skill]

ADS? the commercial compiler?

i have no compile problem. but i have weird runtime probs. eg: the text from the example shows not up when buffer1,2 are not local variables in main.
and my game smw just crashes with doublebuffering.

and the problem is i think this missfeature doesn't only affect doublebuffering but will cause other bugs i won't ever find.

 

[loki666]

maybe you should put yours framebuffer references as private member of some kind of object (your gfx.cpp i don't know)
think object or make it plain c

 

[Dalto]

and here's what i encountered:

u16 *framebuffer;
u16 *framebuffer2;

int main(){
 // example.doublebuffer
}

won't display text on the buffer and crash randomly

int main(){
 u16 *framebuffer;
 u16 *framebuffer2;
 // example.doublebuffer
}

works as usual.

This is not a c++ problem, it happens in straight c as well.

When I move the framebuffers into main() in that example I get a lot of linker warnings that are probably relevant to your probem. The look like this:

arm-elf-gcc -nostartfiles -s -Wall -Wl,-Map,Test.map -T lnkscript crt0.o -o double.elf double.o -L../lib -lmirkoSDK
/cygdrive/c/source/gp32_MrMirko/bin/../lib/gcc-lib/arm-elf/3.3.3/../../../../arm-elf/bin/ld: warning: no memory region specified for section `.bss.1'
/cygdrive/c/source/gp32_MrMirko/bin/../lib/gcc-lib/arm-elf/3.3.3/../../../../arm-elf/bin/ld: warning: no memory region specified for section `.bss.2'
/cygdrive/c/source/gp32_MrMirko/bin/../lib/gcc-lib/arm-elf/3.3.3/../../../../arm-elf/bin/ld: warning: no memory region specified for section `.bss.3'
/cygdrive/c/source/gp32_MrMirko/bin/../lib/gcc-lib/arm-elf/3.3.3/../../../../arm-elf/bin/ld: warning: no memory region specified for section `.bss.4'
/cygdrive/c/source/gp32_MrMirko/bin/../lib/gcc-lib/arm-elf/3.3.3/../../../../arm-elf/bin/ld: warning: no memory region specified for section `.bss.5'
/cygdrive/c/source/gp32_MrMirko/bin/../lib/gcc-lib/arm-elf/3.3.3/../../../../arm-elf/bin/ld: warning: no memory region specified for section `.bss.6'
/cygdrive/c/source/gp32_MrMirko/bin/../lib/gcc-lib/arm-elf/3.3.3/../../../../arm-elf/bin/ld: warning: no memory regionarm-elf-objcopy -O binary double.elf double.bin

 

[no_skill]

hmm... i gotta try it in c with the buffers inside of main.

this is weird. i wonder how other developers are able to code games.

 

[no_skill]

maybe you should put yours framebuffer references as private member of some kind of object (your gfx.cpp i don't know)
think object or make it plain c

but this would just put the problem somewhere else.

i think the fact that the place of a variable can crash a program is very scary imho. this can produce bugs you won't be able to find.

 

[loki666]

in c:
i got a module with the global framebuffers (usually the main() module)

'cdogs.c'
u8 *framebuffer[2];
char nflip=0;

in each module i have to refecrence the framebuffer i use

'blit.c'
extern u8 *framebuffer[2];
extern char nflip;

and that's all, but that's for straight c
in c++:
the main() module don't have any reference to framebuffer because it creates an object like this one...

struct GP32Stub : SystemStub {

	uint8 *_screen[2];
	uint8 nflip;

	virtual ~GP32Stub() {}
	virtual void init(const char *title);
	virtual void destroy();
	virtual void setPalette(uint8 s, uint8 n, const uint8 *buf);
	virtual void copyRect(uint16 x, uint16 y, uint16 w, uint16 h, const uint8 *buf, uint32 pitch);

	void prepareGfxMode();

};
void GP32Stub::prepareGfxMode() {
	_screen[0] = (uint8*) FRAMEBUFFER1;
	_screen[1] = (uint8*) FRAMEBUFFER2;
	nflip=0;
    gp_initFramebuffer((u32)_screen[nflip],8,85);
    gp_setFramebuffer((u32)_screen[nflip],0);
    nflip=1;
}

when i have to draw something i make a call to a methode of this object (drawline(),drawsprite()...)

 

[no_skill]

and putting everything in a class works for you?

i'm just wondering that two global 4B variables instead of one (assuming that a pointer on a arm9 has 4B) cause such a undefinated behaviour.

i just worry that this causes much more trouble i won't expect when using global variables.

btw: which compiler/devkit do you use?

 

[loki666]

just dont use global variable in c++
yes all pointer are 32bits
i'm using ads1.2 with mr.mirko sdk

 

[no_skill]

isnt ads the 3140[insert more 0s here] $ commercial sdk?

 

[loki666]

yes it is

 

[no_skill]

i guess you haven't payed the 3140[insert more 0s here] $

and it works reliable?

 

[no_skill]

now i tested everything with the original mrmirko win sdk.

result:

gp32_MrMirko 2.1 (windows)
 C++ (with g++ as cc for the crt0 (like in the .zip))
  buffers global
   white screen
  buffers local
   black screen
 C++ (with gcc as cc for the crt0)
  buffers global
   crash
  buffers local
   crash
 C
  buffers global
   ok
  buffers local
   ok

devkitARM 6a (windows)
 C++
  buffers global
   crash
  buffers local
   white screen
 C
  buffers global
   ok
  buffers local
   [not tested]

if someone could thest this on linux, on mac or with another compiler he'd be doing me a great favour.

i'm going to build g++ out of the box tomorrow.

you can get the premade examples here: help: http://jnrdev.weed-crew.net/the_wonderful_...weird_stuff.zip