Allegro Setup

[BenRoshi]

Thanks for the working you're doing, Parallax flickers for me as well, so I'd assume it does so for everyone.

 

[kevcal]

Thanks for the reply - I was getting a little paranoid & lonely

I'll do some more checking then; allegro always seemed a little weird with respect to this - ie a 'screen' video bitmap & 2 others and then using show_video_bitmap() ... the manual stating don't use screen if using this method... etc.

I was starting to think it was fine and it's just my 'main loop' doing so little that was making it flicker until I saw the parallax demo doing the same thing (using the same 'swap bitmap' method).

The gp2x add-on source code implies we don't actually have video bitmaps - in gp2x_gfx.c or something like that.

I'll continue posting here then as I carry on investigations, now I know someone's interested

 

[kevcal]

Puzzling this gp2x-allegro..:

I still get (almost double!) faster framerates just blitting a buffer to screen rather than swapping the screen pointer; doesn't seem to matter whether it's a video or system bitmap.

EDIT1:
* Looking at gp2x_gfx.c - it implies there is no difference between system/video/'normal' bitmaps??
* I guess memory is just memory in the gp2x - no fast video memory?

Swapping screens using show_video_bitmap() is slow - which is completely the opposite to what I expected..
Can't believe that setting a couple of registers (whether for scroll or swap) is slower than setting up the blitter and copying 320x240x16 bits of data to the screen... I'm obviously missing something!

I take it the mmsp2 mem-mapped registers are documented somewhere (will look at wiki, paeryn's SDL lib source and rlyeh's minimal lib for direction).

I suspect the wait 4 vsync code isn't up-to-date either - were there bits inverted in a new firmware (I remember seeing the ability to invert things like this in a datasheet)?

EDIT2:
Looks to me like memory is 'just memory' on the gp2x -
I guess this is common knowledge to many people, but info is a bit thin on the ground.

For interest - Allegro currently supports the following (my commented lib code):CODE
GFX_DRIVER gfx_gp2x =
{
GFX_GP2X,
empty_string,
empty_string,
"GP2X",
gp2x_gfx_init,
gp2x_gfx_exit,
gp2x_gfx_scroll,
gp2x_gfx_vsync,
gp2x_gfx_set_palette,
NULL, // no request scroll
NULL, // no poll_scroll
NULL, // no triple buffering
NULL, // no create_video_bitmap
NULL, // no destroy_video_bitmap
NULL, // no show_video_bitmap
NULL, // no request_video_bitmap
NULL, // no create_system_bitmap
NULL, // no destroy_system_bitmap
NULL, // no set_mouse_sprite
NULL, // no show_mouse
NULL, // no hide_mouse
NULL, // no move_mouse
NULL, // no drawing_mode
NULL, // no save_video_state
NULL, // no restore_video_state
NULL, // no set_blender_mode
gp2x_gfx_fetch_mode_list,
0, 0, // bank size, granularity
TRUE, // video memory is linear
0, // bank size
0, // bank granularity
0, // video memory size
0, // physical address of video memory
FALSE // windowed
};

The switch video screen use the scroll routine gp2x_gfx_scroll() -
that just sets the two video address pointers addr:lo+hi & interlaced addr:lo+hi..
However there is a vsync() call in there, so this explains the apparent 'slowness'.
Doesn't seem to explain why parallax.gpe flickers though

EDIT3:
At last, with small changes to the allegro lib, the parallax demo is now not flickering -
Have changed lib vsync() and removed the vsync() call in show_video_bitmap() allegro lib function; I now call it implicitly if I want it.

EDIT4:
Have now added dummyblit() to my allegro lib code [at end of __allegro_linux_gp2x_init()] and that's sorted the black screen problem with everything I have built so far...