GP32 Wierd Graphics Glitch


TheMrCul

Still Fresh
Joined
Apr 18, 2003
Messages
52
Hi everyone
just plodding along with my program, and all was coming along well - for a long time I've had some collision detection routines, but they had some problems. I added some if statements to it, and it seems that the GP32 is overloaded because what is appearing on the screen is not right. The picture is split in half and reversed! What should look like this:
Code:
================
[              ]
[||          ||]
[||    %%    ||]
[||          ||]
[              ]
================

Looks like this:
================
[              ]
[     ||||     ]
[%    ||||    %]
[     ||||     ]
[              ]
================
My speed is set to 133MHTZ and there was plenty of CPU cycles left in each game loop. Also, it was just a few if statements that have nothing to do with the graphics! Can someone tell me what's happened and how to fix it?
Thanks!
-TheMrCul
 
Yip, that's a known (and common) glitch which has many variants (including both a horizontal and/or a vertical split). It is due to the timing of the LCD drawing code, which does not happen exactly on a VBlank (or whatever). Sorry, I don't know how to fix it, but if you are using an older version of Mr.Mirkos SDK (for example) upgrading to the latest version should fix it because Reesy submitted a patch for it.

I'll try to find the threads.
 
Yeah, I searched and found the other version of the lcd code thingy, but had no effect! I'm using the latest version of mr mirko's sdk aswell. Did anyone else fix the problem another way? Thanks for your help.
 
I took away -O2 from my makefile and the problem's fixed, but I hope it doesn't slow it down too much! Wonder what it's problem is... :(

Thanks for your help pea :)
 
Hi MrCUl,

I forgot about the optimistations -
Try to put different compiler flags (i.e. remove -O2) on each of your files in turn instead of over the whole project, and see exactly which file is the problem. That was you can still optimise everything else.

p.s. Is a file called a 'unit' in c? I have a lot of delphi/pascal experience where it is called a unit.
 
Okay that sounds like a great idea, but I've no idea how to do that!
My makefile looks like this:
Code:
# Only edit PRG and OBJS 
# Dont touch anything else

CC = arm-elf-gcc
LD = arm-elf-gcc
AS = arm-elf-as
AR = arm-elf-ar

PRG  = GPRanchr
OBJS = GPRancher.o Backup/gp_asmlib.o Backup/gp_clipped.o

LIBS      = -LC:/gp32_MrMirko/gp32_SDK/lib -lmirkoSDK -lm
CRT0      = C:/gp32_MrMirko/gp32_SDK/lib/crt0.S
LNKSCRIPT = C:/gp32_MrMirko/gp32_SDK/lib/lnkscript
INCLUDES  = -IC:/gp32_MrMirko/gp32_SDK/include
CFLAGS    = $(INCLUDES) -O2 -s -mtune=arm9tdmi

all:	$(OBJS)
	$(CC) -c -o crt0.o $(CRT0)
	$(LD) -nostartfiles -s -Wall -Wl,-Map,Test.map  -T $(LNKSCRIPT) crt0.o -o $(PRG).elf $(OBJS) $(LIBS)
	arm-elf-objcopy -O binary $(PRG).elf $(PRG).bin
	b2fxec -a TheMrCul -t GPRancher $(PRG).bin $(PRG).fxe

install:
	gplink put $(PRG).fxe gpmm

clean:
	rm -f *.o *~ Test.map *.bin *.elf

I can see that -O2 is under CFLAGS, but there seems to be no way to separate it to different files!
 
Hmm, I'm no make expert, thats for sure. Any takers?

My immediate response, though a weird round-a-bout solution, would be to compile the parts seperately into .a files (see the makefiles in each seperate folder in the Mr.Mirko src) using a different makefile, and the combine them with the linker (see the makefile in the lib directory of Mr.Mirkos SDK).

By the way, you can remove some of the b2fxe flags and have them as variables too. Makes it a bit easier:

Code:
# Only edit PRG and OBJS 
# Dont touch anything else

CC = arm-elf-gcc
LD = arm-elf-gcc
AS = arm-elf-as
AR = arm-elf-ar

PRG  = GPRanchr
AUTHOR = TheMrCul
TITLE = "GPRancher"
OBJS = GPRancher.o Backup/gp_asmlib.o Backup/gp_clipped.o

LIBS      = -LC:/gp32_MrMirko/gp32_SDK/lib -lmirkoSDK -lm
CRT0      = C:/gp32_MrMirko/gp32_SDK/lib/crt0.S
LNKSCRIPT = C:/gp32_MrMirko/gp32_SDK/lib/lnkscript
INCLUDES  = -IC:/gp32_MrMirko/gp32_SDK/include
CFLAGS    = $(INCLUDES) -O2 -s -mtune=arm9tdmi

all: $(OBJS)
$(CC) -c -o crt0.o $(CRT0)
$(LD) -nostartfiles -s -Wall -Wl,-Map,Test.map  -T $(LNKSCRIPT) crt0.o -o $(PRG).elf $(OBJS) $(LIBS)
arm-elf-objcopy -O binary $(PRG).elf $(PRG).bin
b2fxec -a $(AUTHOR) -t $(TITLE) $(PRG).bin $(PRG).fxe

install:
gplink put $(PRG).fxe gpmm

clean:
rm -f *.o *~ Test.map *.bin *.elf

You can also specify an icon (8 bpp bitmap with standard palette) using the -b flag
 
I had the same problem. I have seen demos and programms by other developers producing the same problem at rare moments. I think that the problem doesn't appear if you sync the output. If you use double buffering, the page switching automatically waits at a fixed frame rate. The only problem is that diferrent clock speeds gives diferrent screen refresh.

I use MikroSDK too. The problem only appeared with gfx going too fast while I didn't do double buffering. Probably, when you removed -O2, the drawing went too slow, so that it didn't produced the problem. But it's a pitty to disable optimizations for that. Yes,. it's a bit annoying, but find out an example of double buffering at Mikro's example directory and use something similar with your screen. Switching video pages, will automatically sync your graphics and the problem will most probably not appear any more. (I don't know,. I haven't tried to run my projects 1000 times, but they always worked with double buffering on ;)
 
I am using doubble buffering as far as I know!!
This is double buffering, isn't it?

Code:
u16  	*framebuffer[2];

framebuffer[0] = (u16*)FRAMEBUFFER1;
framebuffer[1] = (u16*)FRAMEBUFFER2;

gp_setCpuspeed(133);

gp_initFramebuffer(framebuffer[0],16,85);

and then to swap buffers:
Code:
void FlipScreen(void)
{
	gp_setFramebuffer(framebuffer[swapper],1);
	swapper++;
	if (swapper == 2) swapper=0;
}

So am I the only one who has experienced this? Oh no!!! :(
 
Back
Top