GP32 Palette Vs 16bit Mode

[pea]

Is palette graphics code much faster than 16 bit mode?

 

[Blah]

Yes.

 

[pea]

Say I was fullscreen scrolling. What order of magnitude faster?

 

[slaanesh]

Well I guess you can move 4x 8-bit pixels at a time instead of 2x 16-bit pixels.

Of course horizonal scrolling would be easier due to the video memory arrangement.

 

[hal9000]

Say I was fullscreen scrolling. What order of magnitude faster?

In software (which is what the default SDL does), twice, I think.
In hardware, it is less clear.

However, a full screen scrolling in 16 bits, even in pure software, should not be that much a problem, even at 30 fps (after all, it's just 128 KBytes to copy).

Of course horizonal scrolling would be easier due to the video memory arrangement.

Hmmm... I am not sure to understand that...
It is easier to draw or to copy an horizontal line than a vertical one. But for a complete screen...

 

[pea]

Thanks guys,

I'm doing this in pure C, not using SDL or other libraries (apart from my own - based losely on Mirko SDK).

What slaanesh means about the horizontal scrolling is that the LCD is actually rotated CCW by 90 degrees, so in the memory buffer, the first pixel is bottom left and goes upwards in vertical rows to the right with the last pixel being top right. This means to scroll horizontally all you need to do is have a larger framebuffer and offset the framebuffer pointer within it.

 

[A_SN]

I'm doing this in pure C, not using SDL or other libraries (apart from my own - based losely on Mirko SDK).

Ha! I've had the misfortune to look into Mirko SDK's code while porting donskeeto's Cave Copter, and honnestly, don't use it, this is awful, badly written and abysmally inefficiently written.

QUOTE

What slaanesh means about the horizontal scrolling is that the LCD is actually rotated CCW by 90 degrees, so in the memory buffer, the first pixel is bottom left and goes upwards in vertical rows to the right with the last pixel being top right.

Complete balls! Rotated CCW by 90°? Madness! This doesn't even make sense. Maybe you're saying that because you deved on the GP32, but it's not "rotated", it's called row-major order, period. Besides, the first pixel appears on the top left corner of your LCD, and not bottom left.

QUOTE
This means to scroll horizontally all you need to do is have a larger framebuffer and offset the framebuffer pointer within it.

Nonsense! The only way you could achieve scrolling by doing something similar would be by offsetting the pointer to your extended buffer by a multiple of the number of bytes in a line, which would only result in a vertical scrolling, not an horizontal scrolling. Anything else would effectively move the screen horizontally but in such a way that it wraps around itself, with a vertical offset of one line at the wrapping limit.

 

[pea]

Yes, I dev for the GP32 (amongst others) but this IS the gp32 dev board, and this IS a GP32 question!

Yes, the framebuffer is rotated 90deg CCW on the GP32, this is a common fact:
http://www.cs.helsinki.fi/u/jikorhon/gp32/docs.html (SPIVs page)
http://www.gp32x.de/board/index.php?s=&am...st&p=315460

So the first pixel is BOTTOM LEFT
As you progress the framebuffer you move UPWARDS
And you end at the TOP RIGHT

So to scroll horizontally, you set the framebuffer at your image data and jump it around by height pixels up or down.

And of course I have looked at Mirkos code, but rather than complain about it, I vastly improved it (writing a completely new set of graphics routines - Mirko had per-pixel bound checking) and used it as the basis for my own SDK.

 

[A_SN]

Yes, I dev for the GP32 (amongst others) but this IS the gp32 dev board, and this IS a GP32 question!

Yes, the framebuffer is rotated 90deg CCW on the GP32, this is a common fact:
http://www.cs.helsinki.fi/u/jikorhon/gp32/docs.html (SPIVs page)
http://www.gp32x.de/board/index.php?s=&am...st&p=315460

So the first pixel is BOTTOM LEFT
As you progress the framebuffer you move UPWARDS
And you end at the TOP RIGHT

So to scroll horizontally, you set the framebuffer at your image data and jump it around by height pixels up or down.

And of course I have looked at Mirkos code, but rather than complain about it, I vastly improved it (writing a completely new set of graphics routines - Mirko had per-pixel bound checking) and used it as the basis for my own SDK.


LOL, my bad, I didn't realise I was in the GP32 forum, I thought we were talking about GP2X development. And yeah, the per-pixel bound checking in his function dedicated to writing pixels to surfaces is what horrified me the most.

 

[pea]

no worries

 

[kidchaos2k6]

no worries

Hi pea,

I know that this is not the thread, but i was unable to compile the optimised memcpy routines availables at your site (http://www.gp32.co.nz/snippet_view.php?snippet_id=5) with the latest version of DKARM. Will you tellme which compiler options shoul i use to do it?

Regards,

 

[pea]

I use DKARM r17 which is probably pretty old now, and I have no idea about newer versions, sorry. But my makefile (part of my SDK based on Mirkos) is:
CODE

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


INCLUDES = -I../../include

CFLAGS = $(INCLUDES) -O2 -s -mtune=arm9tdmi -Wall

OBJS = memcpy.o gp_arm.o gp_irq.o gp_cpuspeed.o gp_grafik.o gp_buttons.o gp_memory.o gp_timer.o arial9.o gp_debug.o

all: $(OBJS)
$(AR) rcs gp_common.a $(OBJS)
cp gp_common.a ../../lib/
rm *.o *.a

clean:
rm -f *.o *~



Hope it helps!

 

[kidchaos2k6]

It was a matter of redefine some asm tags... Its all done now,

Thanks anyway