Login
Username:

Password:

Remember me



Lost Password?

Register now!

Sections

Who's Online
96 user(s) are online (61 user(s) are browsing Forums)

Members: 1
Guests: 95

Maijestro, more...

Headlines

 
  Register To Post  

« 1 2 (3) 4 »
Re: Optimize SDL blitting routine
Home away from home
Home away from home


See User information
@Capehill

HWSURFACES should be in VRAM, and should be used when composting images, HWSURFACES (in VRAM) should not be used when plotting pixels, so this sounds like not optimized code.

when locking and plotting pixels you should use SWSURFACES (in RAM).

(NutsAboutAmiga)

Basilisk II for AmigaOS4
AmigaInputAnywhere
Excalibur
and other tools and apps.
Go to top
Re: Optimize SDL blitting routine
Not too shy to talk
Not too shy to talk


See User information
Here is very good reason to hurry up SDL2

Freeablo, remake of Diablo engine.

http://freegamer.blogspot.fi/2014/04/ ... t-diablo-source-weve.html


Go to top
Re: Optimize SDL blitting routine
Quite a regular
Quite a regular


See User information
@thread

Tested Mame SDL. More fast.

Some info in the sdl window:

WARNING: SDL_GetVideoInfo() for driver <OS4> is broken.
You should set SDLMAME_DESKTOPDIM to your desktop size.
e.g. export SDLMAME_DESKTOPDIM=800x600
Assuming 1024x768 now!

I think that it renders in 1024x768 but it's scaled. Btw, it's faster.

Tested a modified version of Arkanoid (Michael T.). I added in game background scrolling with large bitmaps (3 1800, 1050), and it's faster (playable now in 32 bit 800x600).

About mame and other games don't know if they should be recompiled.
Btw, there is a large room for improvements.

SDL scaling routines, can be substituted with the Composited version too?

Retired
Go to top
Re: Optimize SDL blitting routine
Just can't stay away
Just can't stay away


See User information
@AmigaBlitter

Does that warning print come from Mame or SDL?

I don't know is there "ldd" command for AOS4, but you can use something like "strings your_binary| grep libSDL" for checking, or serial port/sashimi to check debug prints from the SDL .so.

Which SDL scaling routines you refer to?

Go to top
Re: Optimize SDL blitting routine
Not too shy to talk
Not too shy to talk


See User information
Hello,
After a lot of tests I am completely disconcerting.
All games emulators or do you speak at home using composite rendering, complete failure of all my tests.
Even better I go further, removing the libSDL1.2.so and continues to run the emulator (I mean SDL_MAME) so that means it does not take advantage of the lib Shared object.
Bermuda no difference with the new or the old lib
I tried to include in the new lib like nothing finalburn no difference there.
What I think needs to be done:
Here to source code that exploits the function and be sure it works properly, then expand our testing our games and rework it all
What do you think ??

AmigaOS 4.1 Rulez
Resized Image
Go to top
Re: Optimize SDL blitting routine
Quite a regular
Quite a regular


See User information
@HunoPPC

Please copy the .so first so SObj, then try to clear appdir and reboot.

Try Supertux game enabling the FPS counter.

I get 37 fps here with my Sam440 ep 667 mhz.

Retired
Go to top
Re: Optimize SDL blitting routine
Not too shy to talk
Not too shy to talk


See User information
thank you I know how to do, what I mean is that most games or emulators which you speak will need .so dependence because they are statically compile. how does it to win fps if you do not use the new composite function ?? Please explain me
Best regards
HunoPPC

AmigaOS 4.1 Rulez
Resized Image
Go to top
Re: Optimize SDL blitting routine
Just can't stay away
Just can't stay away


See User information
@AmigaBlitter

Unfortunately both SuperTux and Abe seems to be statically linked.

Please remember, .so with compositing prints to the serial port. You can observe what it is doing by using a terminal connected or Sashimi.

Go to top
Re: Optimize SDL blitting routine
Just can't stay away
Just can't stay away


See User information
@HunoPPC

Sorry but I don't completely follow. So you have linked the new lib, but no any change? Please post link to your rendering code.

As mentioned, there are certain preconditions for compositing.

Go to top
Re: Optimize SDL blitting routine
Quite a regular
Quite a regular


See User information
@Capehill

"Unfortunately both SuperTux and Abe seems to be statically linked."

Don't know why, but are really fast.

I recompiled the libraries using GCC 4.9.1

Moreover, as said previously i modified the Arkanoid source to add large moving backgrounds that are "blitted" while moving the mouse, playing at 32 bit color depth at 800x600, while previously i was able to play (slowly) only at 640x480. Now the speed is acceptable at 800x600x32.

There is certainly a speed increase.

*Done other tests with Arkanoid. The speed is lower than expected. Using HW surfaces the redraw is slow, in the order of 10 rows of pixel at time.

Btw, as said previously above the speed is increased in the SDL game i've tested.




Edited by AmigaBlitter on 2015/12/13 21:21:00
Retired
Go to top
Re: Optimize SDL blitting routine
Just can't stay away
Just can't stay away


See User information
@AmigaBlitter

Please make the Arkanoid binary available. I don't have a native C++11 compiler so I can't compile the code myself.

If possible, add some FPS counter. You can print average FPS with printf() after each "game over" I guess.

Are you sure all your surfaces are HW surfaces? Have you debugged the surface->flags?


Go to top
Re: Optimize SDL blitting routine
Not too shy to talk
Not too shy to talk


See User information
@AmigaBlitter

Please test avec this and return me your evolution
i have added my tests include on the archive on GPmark
launch GPmark.exe and wait
I have added 16 bits with HARDWARE SURFACE on SDL and linked the .so for no static lib
Enjoy now
Best regards
PS: it's possible added new code for your personal tests

www.clubevolution4.com/Test-HW-Surface.lha

AmigaOS 4.1 Rulez
Resized Image
Go to top
Re: Optimize SDL blitting routine
Quite a regular
Quite a regular


See User information

Amiga600/Vampire2/PrismaMegaMix​/32GB CF Card/2x Rys Mk2/A604n/IndivisionECS/Gotek
Go to top
Re: Optimize SDL blitting routine
Just can't stay away
Just can't stay away


See User information
Not sure what is the point here, but GPmark is a CPU2(V)RAM benchmark, it doesn't call SDL_BlitSurface().

If you compile it with -O2, you can double the results on Sam440.

Go to top
Re: Optimize SDL blitting routine
Home away from home
Home away from home


See User information
@Capehill

Quote:

Regarding Bermuda, it doesn't use compositing. It might work faster with SDL_SWSURFACE even, perhaps Raziel want to try it.

Unfortunately Bermuda Syndrome doesn't feature an FPS display.
And it's already fast with the HWSURFACE in place (at least no one ever mentioned any slowdowns).

Would the game's display speed profit from your beta lib if it's compiled with SWSURFACE instead?

People are dying.
Entire ecosystems are collapsing.
We are in the beginning of a mass extinction.
And all you can talk about is money and fairytales of eternal economic growth.
How dare you!
– Greta Thunberg
Go to top
Re: Optimize SDL blitting routine
Home away from home
Home away from home


See User information
@Raziel

It's strange if there compiler switch for that.
The game developer should know when to use what where,
HWSURFACES should be used when the program is compositing bitmaps(surface) on top other bitmaps(surfaces)., SWSURFACEs when there is pixel plotting in side bitmap(surface). so it should depend on what is going on inside the game, not something you enable or disable.

(NutsAboutAmiga)

Basilisk II for AmigaOS4
AmigaInputAnywhere
Excalibur
and other tools and apps.
Go to top
Re: Optimize SDL blitting routine
Home away from home
Home away from home


See User information
@LiveForIt

Oh, you misunderstood, there is no compiler switch for that.

There is only one single instance of HWSURFACE used in the whole source at all, which could be changed to SWSURFACE, that's why i asked if there would be a speed enhancement if i'd compile such a version.
(and if such a version would profit from that beta sobj)
Quote:

void SystemStub_SDL::setScreenDisplay(bool fullscreen) {
_screen = SDL_SetVideoMode(_screenW, _screenH, kVideoSurfaceDepth, fullscreen ? (SDL_HWSURFACE | SDL_FULLSCREEN) : SDL_HWSURFACE);
if (!_screen) {
error("SystemStub_SDL::init() Unable to allocate _screen buffer");
}

People are dying.
Entire ecosystems are collapsing.
We are in the beginning of a mass extinction.
And all you can talk about is money and fairytales of eternal economic growth.
How dare you!
– Greta Thunberg
Go to top
Re: Optimize SDL blitting routine
Just can't stay away
Just can't stay away


See User information
@Raziel

Unfortunately SDL with compositing cannot speed up this kind of drawing, where plotting happens by memory writes.

Compositing can do fast alpha-blending or scaling, but preconditions for HW acceleration is that source and destination bitmaps are in VRAM. (see graphics.library/CompositeTags() documentation)

And limitation for OS4 SDL is that you can only get SDL_HWSURFACEs in fullscreen mode.

So it looks like Bermuda writes to RAM in window mode and VRAM in fullscreen mode.

To summarize, you need a fullscreen videomode allocated with SDL_HWSURFACE, then you need source surfaces that are also allocated with SDL_HWSURFACE. Now, calling SDL_BlitSurface() will call CompositeTags() and operation should be hardware accelerated.

Go to top
Re: Optimize SDL blitting routine
Home away from home
Home away from home


See User information
@Capehill

Thank you for the clarification

People are dying.
Entire ecosystems are collapsing.
We are in the beginning of a mass extinction.
And all you can talk about is money and fairytales of eternal economic growth.
How dare you!
– Greta Thunberg
Go to top
Re: Optimize SDL blitting routine
Quite a regular
Quite a regular


See User information
@Capehill

Check your PM for the link of the modified Arkanoid game.

Retired
Go to top

  Register To Post
« 1 2 (3) 4 »

 




Currently Active Users Viewing This Thread: 1 ( 0 members and 1 Anonymous Users )




Powered by XOOPS 2.0 © 2001-2023 The XOOPS Project