GP2X Just Started Coding

[refractor]

If you are a programmer and think SDL and C++ is slow then you are not much of a programmer/or just do not know how to optimize :blink:

Well that depends, doesn't it. Compared to hand-crafted assembler, SDL/C++ is always going to be slower, but then you'd be insane to hand-code everything in assembler and/or make things hardware-specific (in the SDL case). It's all relative, of course. I could call C++ "slow" because I can shave a few cycles out of whatever assembly output it dumps and recompile. My version would be faster. Would it be worth me hand-optimising the compiler output each time? Hell no. If you want something to be as fast as possible, optimise the algorithm to hell, then use assembler. If C++ speed is fast enough then that's your prerogative. Horses for courses.

So yeah, C++ is slow(er), but it has its uses...
(And I know how to optimise).

 

[Radek]

I was just talking in general I wasn't singling you out at all Radek. I think one of the main problems with coding for the Gp2x is that GPH hasn't release proper docs/samples of the machines ablities. It takes people like us to find them on our own like Squidge Mmu Hack and paeryn hw sdl to get some of the true power behind the machine. If they would release an sdk that was able to tap into the features we could see what the gp2x can really do then there would be less problems with speed.

Thats just my opinion anyway

Imho everyone should do in a way of a best proficiency. I'm very impressed with SDL as it's now with hardware acceleration. I like SDL and I'm using it on my PC for some of my utilities (written in Python) and done two or three proof of concept apps for GP2x. And it's perfectly valid option on GP2x but it impose a surface type aproach.

Even in "2D" there many methods doing it.

 

[GP2X_Coder]

True refractor when I want to do something like alpha blending I code it in asm because it's faster and on a small device like this you need all the speed you can get but all I was trying to state is that c++ is not as slow as everyone tries to make it out to be alot of times it is the programmer that just codes inefficiently.

(and I am glad you no how to optimise)

 

[Alex.]

From what I've experimented, SDL (the default, software one that comes with the GP2X) should be fast enough for most light-medium homebrew games. I only started experimenting with SDL a week or so ago, and it seems to be an excellent library.

- Alex

 

[Radek]

From what I've experimented, SDL (the default, software one that comes with the GP2X) should be fast enough for most light-medium homebrew games. I only started experimenting with SDL a week or so ago, and it seems to be an excellent library.

- Alex

To tell the truth the openning /dev/fb0 device and using even "unsigned short int *" (drastically bad from efficiency standpoint as assembler ldm/stm will vaporize such code) and going after every pixel in usual x,y loop will be fast enough for many homebrew games.

For fullscreen scrolling and some sprites it's good enough on 200MHz Arm9 cpu. Thought resorting to "unsigned int *" and in a register shifting will be way faster. Doing it with hand coded assembly and using every advantage what is possible... never mind.

The point is simple - I like SDL but I like /dev/fb0 as well. It's so especially it's not hard at all.

 

[DavidBeoulve]

Pardon my ignorance, but given that sounds can be called into action and then (largely) left to play their way out, and music as well, isn't the 2nd CPU a prime target for such a workload?

 

[Radek]

Pardon my ignorance, but given that sounds can be called into action and then (largely) left to play their way out, and music as well, isn't the 2nd CPU a prime target for such a workload?

Yes. Even better if 2nd CPU would run something synth like. So no samples, no extra accesses to memory just final output to the codec. And such synth could fit into CPU cache and with 200mips possibilities are vast. At the profesional level I should add.

 

[kevcal]

Pardon my ignorance, but given that sounds can be called into action and then (largely) left to play their way out, and music as well, isn't the 2nd CPU a prime target for such a workload?

Yes. Even better if 2nd CPU would run something synth like. So no samples, no extra accesses to memory just final output to the codec. And such synth could fit into CPU cache and with 200mips possibilities are vast. At the profesional level I should add.

Second CPU uses...

How about a 'mod player'? Or is that old fashioned nowadays ... :blink:
Some sort of physics engine maybe?
Something that post-processes screen-data?
Creation of on-the-fly (offscreen) tiles for a scrolling game?
3d engine based on matrices or a voxel engine?

I dunno - I'm sure there are loads of uses for it that will come to light at some point..
Anyway, haven't used SDL yet - am keen to stick with Allegro, but haven't found the time to install the linux SDK yet Also dunno where the Allegro port stands really - not many people seem fussed about it.

Kev

 

[Parkydr]

Allegro is nice but the GP2X version won't let you read all the buttons

 

[Radek]

Pardon my ignorance, but given that sounds can be called into action and then (largely) left to play their way out, and music as well, isn't the 2nd CPU a prime target for such a workload?

Yes. Even better if 2nd CPU would run something synth like. So no samples, no extra accesses to memory just final output to the codec. And such synth could fit into CPU cache and with 200mips possibilities are vast. At the profesional level I should add.

Second CPU uses...

How about a 'mod player'? Or is that old fashioned nowadays ... :blink:

No it's still a valid aproach to music. Even better filters and effects could be add to usual sample playback. The 940T can handle it power wise.

Some sort of physics engine maybe?
Something that post-processes screen-data?

Depends on needed bandwith - if 1st core is already spending most of it then utilising 2nd core might results in reduced perfomance.

Creation of on-the-fly (offscreen) tiles for a scrolling game?
3d engine based on matrices or a voxel engine?

The same as above - bandwith vs needed cycles issue.

I dunno - I'm sure there are loads of uses for it that will come to light at some point..

I think so but nothing by force.