GP32 Weird Flicker. Help Me Get Rid.


Daz_Genetic

Certified Guru
Joined
Oct 26, 2003
Messages
424
Age
46
Location
Maine, USA
Website
www.dazos.com
http://www.dazgenetic.pwp.blueyonder.co.uk/DazEngin.fxe

Run that fxe on a real GP32, and then try and explain to me what the hell is going on with those flickering lines.

I am using ARM ADS 1.2 with the Official SDK. I am going to blame that, as I don't think I am doing anything unusual.

I've tried implementing a VBlank using code posted on this site previously, but it seems to make absolutely no difference. It's running at 133mhz, but lowering the clockspeed doesn't help one bit.

If I have to switch over to mr.mirko's SDK to fix things, how do I get it to work in ARM ADS?
 
Are you sure that you are using both buffers? For a loooooong time, my programs were going at half FPS, and horribly flickery, until I realised my buffer switching code actually "switched" form one buffer to itself ;)
 
could you post a bit of you sourcecode? then it would be much easier to localize the bug. doesnt have to be the whole code, maybe just the draw and switch part
 
I think this is a problem with the LCD DMA and the writeback buffer.
check chapter 25 of the users manual for s3c2400x

"The excessive continuous STM instruction on write-buffered memory area keeps the DMA(LCD,IIS,...) from fetching. So, LCD or IIS DMA will not fetch the data while the write-buffer occupies the bus. So, there will be noise in LCD screen or speaker sound."

---
mithris
 
I had a problem like this, until I found out I hadn't activated the second buffer.

Code:
GpLcdSurfaceGet(&gpDraw[0], 0);
GpLcdSurfaceGet(&gpDraw[1], 1);

It should look ( somewhat ) like that.
 
I can't post my code yet, but I can say this. I was using the SDK off Ishani's website in order to use the ADS integration it offers.

Last night I rebuilt my project using the Gamepark released version of the SDK, and the flickering is all but gone. You can still make it out slightly, but I can make it out in many other titles also. Most noticably across the top bar in PacRom, for example.

If I compile my project with the Debug libraries it works perfect and there is no flicker but it's noticably slower. Though If I try to slow my code down manually with the release build, there is no change. I'm beginning to think that there is some major bugs in the Gamepark SDK. A reason why I am going to switch over to Mirko's as soon as possible.

Another thing I noticed wrong with the SDK located on Ishani's website, is that GpTickCountGet() always returns 1. I would recommend avoiding that download until someone with more experience helps to get rid of those problems.
 
I really don't beleive so, because I have been running that on both my GP32s for days now, and I haven't got any artefacts left over on mine.

What program are you noticing the dark line?
 
I am going to flip out..

All of a sudden, my application is doing the same thing that it was before I switched the libraries. The flicker is returning and If I call GpTickCountGet, all I ever get is '1'. I've commented out the entire code so that all it does is display the result of GpTickCountGet, yet 1 is all I get.

Everything is working on the emulator perfectly. And I was really getting somewhere. In fact, I had even implemented my bmp file loader and everything. I was loading images off a virtual SMC just fine. But when I ran it on my GP32, it just crashed out.

I have pretty much given up on getting my entry finished for the GBAX competition :(. Instead, I think I am going to concentrate on setting up a GCC environment with mr.mirko's SDK. It's gotten to the point where I really can't see how this shit could be my fault (though it woudln't suprize me). Any code that I have written has been commented out.
 
There can be a lot of reasons for flickering.. wrong values for GpClockSpeed..(), some SDK gfx functions cause flickering when used extensively, memcpy() & memset() used to wback cached memory, bug in timing/buffer flipping code, frame buffers in wback cached etc..
 
Could it be something simple like your accidently writing to the visible screen instead of your buffer?

-Craig

www.gbax.com
 
Hiya mate, i had a similar problem.

i had my code double buffered, i was always drawing to the back buffer and not the screen, yet it'd still flicker and i've have to crank the framerate down to the 20's for it to stop.

all i did to solve it was added a third buffer (triple buffering) and volla, problem solved.

normally you just have to add 2/3 lines of code so its worth a shot, worked for me and some others i've spoken to. its normally caused when your drawing alot and still getting high framerates.

regards

pirotic
 
drat.

alot of the GPDraw functions can cause flickering i heard - Rect and so forth. but it may simply be a hardware thing and without a third buffer i can't think what else to do. have you tried optimizing your graphics routine so it doesn't draw so much? or locking the framerate down :p
 
I wonder what I have done differently to others.. as I never had a "flickering" problem. And most of my stuff runs 50fps (and 50Hz framerate) and some stuff push pretty much stuff to frame buffer during refresh period. Even without triplebuffering. Must be something simple lurking there that is too obvious to be spotted out ;)
 
I had flickering problems too, I solved by changing the order I blit sprites on the (from left to right, larger tiles first) screen... weird, but that helped
 
Back
Top