GP2X F200 Test

[xcen]

Kevcal: kudos my friend! Nice to hear the squashing sound of bugs being...err...squashed! haha

 

[kevcal]

As you say the allegro.cfg needs to be in the same directory as the .gpe - not the script.

This file is often overridden by set_config_file() - maybe do a strings on the .gpe to find out what it could be.. (also grep for cfg or ini possibly).
eg. for Alex the Alligator 4 I think it's something like alex4.cfg or something like that.

Other method is chuck the allegro.cfg file in /etc and then any allegro progs will find it... (unless overridden I guess).

I will strip out the debug from my static allegro lib and post it on my website (hopefully tomorrow).

Can't see why 44100 would cause slowdowns as it was previously 45454 so I'd expect a slight improvement - oh well I can see why 22050 would help speed stuff up though.

O2EM_GP2X- the .cfg file has a different name... it's o2em_def.cfg CODE
fn = "o2em_def.cfg";
f = fopen(fn,"r");
if (!f) {
fn = "O2EM_DEF.CFG";
f = fopen(fn,"r");
}
and Stella is SDL .. someone else can look at that - probably same kind of problem...?

Glad it's been of interest and use to more people than myself
Makes the journey worthwhile, despite the solution being obvious at the end(!).
STill don't know 'why' - but I've had enough of wading through kernel driver files for a few days - it can remain a mystery for now.

For interest:
void set_config_file(const char *filename);

Sets the configuration file to be used by all subsequent config functions. If you don't call this function, Allegro will use the default `allegro.cfg' file, looking first in the same directory as your program and then in the directory pointed to by the ALLEGRO environment variable and the usual platform-specific paths for configuration files. For example it will look for `/etc/allegro.cfg' under Unix.

 

[sbock]

Stephan,

LiquidWar overrides the standard config file using set_config_file().

Try adding the parameters to the end of lwdata/.liquidwarrc

Yeah! It worked. I tested 22050.

Regards,
Stephan

 

[kevcal]

Stephan,

As you are the only one with both an F100 & an F200 -
if you leave Liquidwar on the F100 _without_ the .cfg fix and set the F200 .cfg to _44100_ that the F200 runs slower???

Can you run the side-by-side as a comparison to check for sure?

@xcen - cheers for the support

Kev

 

[spoyser]

O2EM_GP2X- the .cfg file has a different name... it's o2em_def.cfg CODE
fn = "o2em_def.cfg";
f = fopen(fn,"r");
if (!f) {
fn = "O2EM_DEF.CFG";
f = fopen(fn,"r");
}


That file is actually a optional config file for the emulator itself rather than the allegro config file.

I've just scoured the source and can't find any call to set_config_file so I can only think that allegro.cfg file is the correct name but that it doesn't fix the problem. Maybe the value that it is setting is hard-coded elsewhere? Hopefully your new lib will sort everything out although given that the allegro.cfg file doesn't help I'm not so sure a new lib will either :-(

 

[kevcal]

Ah, okay
Have you got some sort of trace/debug output from o2em that can be looked at - ie when in the o2em code is it failing...

I'm just putting together some allegro stuff and will post when it's 'up' - although I guess it'll be ~12 hours from now as I have no ftp at work

EDIT:
Or maybe sooner - 2 libs one 'normal' but with fixed sound_freq (hopefully )
Hope the libs work okay on your setups - they work for me okay
One enhanced - more sound setup debug for o2em_gp2x/whoever and _also_ indicates HW accelerated blits with pretty pink & yellow boxes.
If you don't see these then, you're not running your application properly optimised...

There's also a (very) quickly put together readme.txt with lib details and some (hopefully) useful hints using allegro on the gp2x...
Which are wrong - sorry didn't sleep well last night and some of the stuff in there is _wrong_. I will redo it tonight, if time; sorry.

Click here -> http://homepage.ntlworld.com/kevcallahan/a...ev_liballeg.zip

Kev

 

[Parkydr]

Stephan,

LiquidWar overrides the standard config file using set_config_file().

Try adding the parameters to the end of lwdata/.liquidwarrc

Yeah! It worked. I tested 22050.

Regards,
Stephan



That's good to know, thanks.

 

[Parkydr]

Can't see why 44100 would cause slowdowns as it was previously 45454 so I'd expect a slight improvement - oh well I can see why 22050 would help speed stuff up though.

It doesn't speed up BunkerMaster2X (on the PC), I profiled it with 22050 and 11025 and the results were the same (the sound at 11025 was crap though).

As I said before, what makes the difference is changing the frequency in al_start_duh() - it was 48000 and duh_render was using 35% of the processing, reducing it to 22050 made it 20%.

 

[kevcal]

Out of interest, how are you profiling and are you just doing it on the pc?
I did mess around with -fprofile-generate and -fprofile-use but didn't know I could get any details out from that.. Is that what you're doing or something else (would be really useful).

When I used to 'do Atari ST programming' there was a byte you could access that changed the current screen output colour (memory a bit hazy). I used that and had blocks of colour on the atari screen for blocks of code - that way I figured out where all the processing was being carried out for each vblank and helped to direct my attention to the areas that would give most benefit.
I wonder if there's any mmsp register that could give the same functionality...?

 

[Parkydr]

I have profiled on the GP2X and PC (Linux) with gprof (add -pg to compiler and link flags) but the results are hard to interpret.

I'm now using valgrind with the callgrind tool and displaying the results with kcachegrind. It gives you graphical call graphs and maps which make it easy to see what's going on.

Unfortunately the standard x86 allegro library has some dodgy assembler which crashes valgrind so you have to build it with assember disabled.

 

[kevcal]

Ah - cheers for the info - looks very impressive!
I take it the code has profile statements stuffed in it - bit like dynamic test coverage.
Will have to look at this some time - introduce some fun to my work as well

 

[Parkydr]

Valgrind emulates the processor, so there's no source instrumentation, but you can look at the source or even the assembler and it annotates it with percentages or counts.

 

[kevcal]

Definitely sounds like something I should be investigating for the gp2x and work

 

[sbock]

I've got success with O2EM. I tried kevcal's suggestion to add the setting file to /etc.
Now kevcal's test, BunkerMaster and O2EM work without doing anything else.
LiquidWar needs furthermore forceful the edit of the config file.

I write a script for easy file transfer for the F-200.

You can find the file here. The frequency is set to 22050, but can be easily edited via the allegro.cfg file in the archive.

Just copy the unzipped "AllegroPatch" folder on a SD card and run the "install.gpu" file inside.

Warning! The file will be written directly to the NAND. There is always a risk writing files to this area.
There may be unforeseen consequences from adding this file, so you have been warned.

I can't test the O2EM emulator fully because I haven't the bios file and any roms. But the bios missing screen now pops up.

QUOTE
As you are the only one with both an F100 & an F200 -
if you leave Liquidwar on the F100 _without_ the .cfg fix and set the F200 .cfg to _44100_ that the F200 runs slower???


Will try that later this evening...

Regards,
Stephan

 

[spoyser]

I've got success with O2EM. I tried kevcal's suggestion to add the setting file to /etc.
Now kevcal's test, BunkerMaster and O2EM work without doing anything else.
LiquidWar needs furthermore forceful the edit of the config file.

I can't test the O2EM emulator fully because I haven't the bios file and any roms. But the bios missing screen now pops up.

QUOTE
As you are the only one with both an F100 & an F200 -
if you leave Liquidwar on the F100 _without_ the .cfg fix and set the F200 .cfg to _44100_ that the F200 runs slower???

Will try that later this evening...

Regards,
Stephan


@Stephan: That is great news, the bios screen is definately further then my tester got so that sounds like it may have solved the problem with o2em, I will suggest he tries the /etc folder

I have also sent him a version linked using the new allegro lib provided by kevcal (many thanks for that) I will update whether that worked as soon as I hear back.

I believe all the odyssey roms and bios are freeware these days, but if you google search odyssey roms you should find them very easy (1st hit when I tried it a minute ago) should you want to try it out.

Many thanks,

Sean

 

[Parkydr]

If you don't want the file in etc, you could try setting HOME to point to the o2em directory and put the config file in there - allegro also looks in your home directory.

 

[kevcal]

I am going to create a page on my website that explains how to use the blitter with gp2x allegro to it's maximum advantage..

Looking through some allegro-based ports' source code on gp32x.de, it looks to me like some(all?) aren't using video page flipping or possibly any blitter functions; although I could be wrong; as is frequently the case

eg some don't even use create_video_bitmap() calls:
Explanation - GP2X Allegro will check the vtable of the source graphics with &_screen_vtable, and if it doesn't match, then the blits will be done by the cpu and not use the blitter.

This all stems from the set_gfx_mode() call - you need to allocate (generally all 5M) to video memory for graphics.
I reckon (and I hope I'm right B)) there may be a lot of improvements that could be made to gp2x allegro ports.

Anyone who has done a port, please try linking with the enhanced lib I link to earlier in this thread this will indicate what graphics are hardware blitted.. (Actually I have a better version now, but that one is 'good enough' for now as an indicator). Anything that hasn't got a yellow or pink box around it (or sometimes 'next to it' - found a 'bug ), isn't using the blitter.. This helps screen-sized blits especially.

I have had the same problem the last couple of days with Abduction and now am back to fully utilising the blitter for all graphics and hugely sped everything up - I'm talking double framerate increase(!).. It's taken quite a while to understand how it works but am on top of it now.

 

[sbock]

@kevcal

I tested LiquidWars on the F-100 and the F-200 and there is no visibly difference in speed.

@Parkydr

Hmm, can't get this to work.

@spoyser

I found the files and tested the emulator. There are no problems.


I edited the Allegro patch file and now there is an uninstall script and a readme included. I found no negative side effect on my F-200, so i think it's save to use.

Regards,
Stephan

 

[kevcal]

Cheers stephan for that - I'll keep the library to 44100 default then; people can override it themselves if they like.
Hadn't expected it to affect performance at all but good to be sure.

Yeah your install file was fine and shouldn't mess anything up on anyone's machine..

 

[spoyser]

Cheers stephan for that - I'll keep the library to 44100 default then; people can override it themselves if they like.
Hadn't expected it to affect performance at all but good to be sure.

Yeah your install file was fine and shouldn't mess anything up on anyone's machine..

The person testing o2em_gp2x for me on his F200 has also confirmed that it works with using the new library (cheers for that).

I will look in to the HW blitter stuff as soon as I get chance.