[paeryn]

Was hoping to have this ready for xmas day but several typo's evaded my tired eyes...
Source only, but it's based off the Open2x libs-gp2x project (Open2x).

Initial suport for HW accelerated surfaces. Only 16-bit at the mo, but it seems to be working okay.
Double-buffering works, RectFills are a lot faster, Blits are about 2x faster on 16x16 sprites at the mo.
Currently it allows 5MB of HW surfaces.
-----
Updated locations of where to get HW SDL, as of 16th Jan 2007

Source is available via Open2x svn,

# svn checkout https://open2x.svn.sourceforge.net/svnroot/open2x/trunk/libs/SDL-1.2.9

Pre-compiled, with selectable 5MB or 21MB of HW surfaces here please read the README.GP2X for extra info
Older versions with less surface memory,
Pre-compiled, with 5MB of HW surfaces here
Pre-compiled, with 16MB of HW surfaces here

This post has been edited by paeryn: 14 September 2007 - 11:52 PM

[craigix]

Ah thats really cool, nice to see the graphics hardware finally being easily used via SDL.

Will be cool to see things recompiled to make use of this and how much speed they gain.

[paeryn]

Don't expect too much speedup with small blits, SDL seems to have a fair bit of overhead. I've not tested it properly, but I grabbed several small demo programs at random to test it and they worked.
After I put in 8-bit support I'll see about making a gp2x optimized version. The HW scaler is also screaming to be freed. So much to do...

[Vimacs]

free the poor scaler :-)
great work!

[Blah]

Yes, please incorperate HW scaling into the SDL video stuff, I would be *very* grateful when I get mine and start devving. :)

Also, I've seen a bit of the SDL code, and it looks like I would be able to contribute some stuff to it later.

[Puck2099]

Great news! :)

paeryn, could you upload a precompiled version of this libraries to people who are unabled to compile it by theirself as me? :unsure:

It could be very useful to try in high demand projects as my Exult port :)

Thanks

[DJWillis]

paeryn,

Very good job. It would be cool to combine this with the other efforts to improve SDL and use the H/W. I have dropped you a PM about that.

Blah, on Dec 28 2005, 05:38 AM, said:

Yes, please incorperate HW scaling into the SDL video stuff, I would be *very* grateful when I get mine and start devving. :)

Supporting the scalar is proving fun to get working in a useable manor (timing, speed and flicker :o issues) but there maybe something to show using the scalar (crude not fine (post-processed) modes) with SDL soon(ish).

Rlyeh’s MiniLib supports the crude scalar modes (and a lot of the cool surfaces stuff) already if people want to play.

[slygamer]

DJWillis, on Dec 28 2005, 08:35 PM, said:

Rlyeh’s MiniLib supports the crude scalar modes (and a lot of the cool surfaces stuff) already if people want to play.

As much as we'd like to, Rlyeh has not released his updated library yet.

[DJWillis]

slygamer, on Dec 28 2005, 11:38 AM, said:

As much as we'd like to, Rlyeh has not released his updated library yet.

Ahhh, scratch that then :D , Rlyeh's Minilib may support the scalar in a newer public version ;) .

[Radek]

paeryn, on Dec 28 2005, 06:30 AM, said:

Don't expect too much speedup with small blits, SDL seems to have a fair bit of overhead. I've not tested it properly, but I grabbed several small demo programs at random to test it and they worked.
After I put in 8-bit support I'll see about making a gp2x optimized version. The HW scaler is also screaming to be freed. So much to do...

No only that but other functions of VideoPostProcessor too! :D

...but how it could be exposed in the SDL? It's pretty nonstandard stuff?
(the transluency and alphablending is done in the "fly" for surfaces
as I understand)

[paeryn]

DJWillis, on Dec 28 2005, 11:35 AM, said:

Very good job. It would be cool to combine this with the other efforts to improve SDL and use the H/W. I have dropped you a PM about that.

Hmm, tried replying to your PM and it tells me "This message can not be sent because the recipient does not have permission to use the personal messenger."
Basically, "yes, feel free" and I'll try porting it into 1.2.9 later today.

[DJWillis]

paeryn, on Dec 28 2005, 03:42 PM, said:

Hmm, tried replying to your PM and it tells me "This message can not be sent because the recipient does not have permission to use the personal messenger."
Basically, "yes, feel free" and I'll try porting it into 1.2.9 later today.

Cool,

If you want drop me a mail John . Willis @ Distant - Earth . Com (remove the spaces, obviously) and I will get you the 1.2.9 code to test against, it still has bugs but should be good enough for what you need.

[paeryn]

Puck2099, on Dec 28 2005, 09:38 AM, said:

Great news!  :)

paeryn, could you upload a precompiled version of this libraries to people who are unabled to compile it by theirself as me?  :unsure:

It could be very useful to try in high demand projects as my Exult port  :)

Thanks

Hope this works, clicky
It's compiled with gcc-3.4.4, glibc-2.3.5

[Puck2099]

paeryn, on Dec 28 2005, 04:11 PM, said:

Puck2099, on Dec 28 2005, 09:38 AM, said:

Great news!  :)

paeryn, could you upload a precompiled version of this libraries to people who are unabled to compile it by theirself as me?  :unsure:

It could be very useful to try in high demand projects as my Exult port  :)

Thanks

Hope this works, clicky
It's compiled with gcc-3.4.4, glibc-2.3.5

Thanks a lot :)

[gfoot]

Very nice. I've incorporated these accelerated features into Allegro now, and it's getting great results - nice one!

There are still a few instabilities here though - sometimes a 32-bit block gets corrupted, and I've had it crash occasionally. Things got a lot better when I called your dummy_blit routine after each blit - but I still get some corruption occasionally. Weird. :) I'm reading through the docs now anyway to see if any possible reason stands out.

Blitting withing video memory is now running 30x faster, 5x faster than non-accelerated blitting from user memory to video memory. I'm a little suspicious though that the unaccelerated blitting might be slower than it ought to be - I'm going to investigate more.

Area fills and horizontal lines are nice and fast too. :) Though they weren't bad before - there's only a 50% speed increase here, so it's actually tempting to make the CPU do some of the work while the accelerator is running. I suspect memory bandwidth would slow things down though.

I also did what you said about using 5Mb of video memory from 0x03101000 - that works really well, and hardware scrolling works now.

In short, it's all looking good - hopefully I'll be able to iron out the remaining problems today and make a new release!