GP32 Wrong Gfx Output?

[Optimus]

Not that I need it, cause I've solved the problems.
But I was just curious to learn why these happen..

I started in DevKitARM or minigp32 with the official SDK from Gamepark32.
Strange things happened that affected the speed and esp. produced buggy output..

1) I was declaring these variables as global (outside GPmain):
GPDRAWSURFACE GPdraw;
char *vram;

Then the speed was 23fps.

Then, I decided to declare the second line inside each of my functions where I need it, and the speed went to 83fps.

Why did this happened? Also, in the first occation I noticed gfx bugs sometimes (If I didn't vsynced)

2) Generally, when I avoided vsync and tried to run some output as preety fast as possible to the buffer, I noticed a usual bug (that I have noticed in other occasions too), like the display is too slow or vertical strips of the output are written slowly slowly instead of instantly! Strange..

3) Even when moving to Mikro's SDK, I made something wrong and displayed the same bugs. I think have declared the framebuffer globally as static or not, but now it's outside my functions as static and everything works fine. Unfortunatelly I couldn't recreate the bug to find out what is. But it was the same strange bug that happened in my GP32 many times before. Now with Mikro's SDK, I can disable Vsync if I want and output fast gfx at 300fps without any problem..

Do you know anything about it, does the description of the bug sounds familiar? I'd like to know what caused it and what to avoid when writting gfx to the buffer, flipping, vsyncing or not.

p.s. Not that I need them for my programms (cause I can just enable vsync and write gfx the usual bugfree ways), but I just wanted to know for my knowledge, cause I hate it when a bug happens, then dissapears and I never know what this happened. I thought this case would be familiar to some of you, so you may know..

 

[Optimus]

>1) I was declaring these variables as global (outside GPmain):
>GPDRAWSURFACE GPdraw;
>char *vram;

Perhaps I don't give much detail, now I read my post again..
Anyways, vram was for the framebuffer. I later did vram=GPdraw.ptbuffer; and then my stuff. When *vram was a global, low speed. When it was inside my functions, good speed. Strange..

 

[Zap]

Now you know that global variables are ugly.
How many functions are using that vram variable ? I think the bugs come from the fact that more than one function was using that variable.

 

[Optimus]

>How many functions are using that vram variable ? I think the bugs come from >the fact that more than one function was using that variable.

At least 2 of them. One for preparing a screen which outputs a text, another clear screen function, and the main one outputting the algorithm. But if I did nothing wrong, noone was interfearing with the rest. I set the pointer to show at the beginning of the framebuffer pixel data each time I wanted to repaint. So, why would that happen? Why or when are global pointers nasty?

 

[Oankali]

I think you should use double buffering to avoid this type of artifacts.
When switching from one surface to the other with GpSurfaceFlip() this function syncronizes with the vertical retrace.

Oankali

 

[Saotome]

...Why or when are global pointers nasty?

i'm not really sure, but i quess its because globals are stored in ram, and local variables are stored in registers (if there are enough registers).

 

[Optimus]

>i'm not really sure, but i quess its because globals are stored in ram, and local >variables are stored in registers (if there are enough registers).

A friend says that it's just because global variables are visible from all my functions and perhaps outer parts from my programm, possibly functions from the gamepark SDK that I am not aware off. He beleives something is going wrong and my global variable is affected from a piece of code either from my code or another outside my programm, while I didn't asked for it. Anyways,. I either declare my variables inside my programm, or the ones who are outside main are declared as static (I think this means that external code can't touch them). However, the pointer of the screenbuffer should not be static in order to be able to page flip with Mikro's SDK but now it works fine..