aliens

Author Topic: SPriG: An alternative to SDL_gfx  (Read 15823 times)

Offline SupSuper

  • Lazy Developer
  • Administrator
  • Commander
  • *****
  • Posts: 2162
    • View Profile
SPriG: An alternative to SDL_gfx
« on: November 15, 2010, 12:34:17 am »
I've been looking for easier-to-use / more-efficient alternatives to SDL_gfx, and so far the most promising one seems to be SPriG.

It seems to cover all of SDL_gfx's features (and more which might be useful later), have a simpler interface and it's easier to set up (pre-built binaries for Windows and Linux). Here's the performance I got when replacing some SDL_gfx calls with SPriG calls:

Average FPS with SDL_gfx / Average FPS with SPriG

Screen scaling (x2):
190 vs 420 (menu)
180 vs 320 (globe)

Screen scaling (x3):
140 vs 190 (menu)
110 vs 150 (globe)

Globe Land Rendering (textured polygons):
220 vs 215

Globe Ocean Rendering (flat polygons):
200 vs 220

As you can see the results are mostly positive for SPriG (specially the scaling!), so I'm looking into porting it over once I get all the issues worked out with the author. But I figured I'd post it here ahead of time so all you contributors can try it out yourselves and let me know if it's easier to build and get working on your platforms than SDL_gfx, and how the performance pans out.
« Last Edit: November 17, 2010, 10:04:36 pm by SupSuper »

Offline luciderous

  • Colonel
  • ****
  • Posts: 108
  • There is no spoon...
    • View Profile
Re: SPriG: An alternative to SDL_gfx
« Reply #1 on: November 15, 2010, 09:32:11 am »
Looks promising. If you feel it can be of advantage to SDL_gfx, then I say - go for it.
It builds fine into a framework on Mac OS X (10.6.5) with only some minor warnings (several "Type qualifiers ignored on function return type") and it should work within OpenXcom as well.

Offline michal

  • Commander
  • *****
  • Posts: 629
    • View Profile
Re: SPriG: An alternative to SDL_gfx
« Reply #2 on: November 15, 2010, 10:09:01 am »
What about merging SPriG code into OpenXcom sourcecode? This would simplify bulding (you wouldn't need to build sprig seperately) and would allow to fix some simple bugs within it.

Offline Daiky

  • Battlescape Programmer
  • Administrator
  • Commander
  • *****
  • Posts: 904
    • View Profile
Re: SPriG: An alternative to SDL_gfx
« Reply #3 on: November 15, 2010, 10:22:57 am »
And you probably can use SPG_FloodFill to fill the oceans :)

Offline SupSuper

  • Lazy Developer
  • Administrator
  • Commander
  • *****
  • Posts: 2162
    • View Profile
Re: SPriG: An alternative to SDL_gfx
« Reply #4 on: November 15, 2010, 11:31:21 pm »
What about merging SPriG code into OpenXcom sourcecode? This would simplify bulding (you wouldn't need to build sprig seperately) and would allow to fix some simple bugs within it.
It'd be a pain to maintain though. The whole point of external dependencies is so someone else can worry about the library while I worry about my game. :P And everytime there was an update on either side I'd have to keep merging changes (and if I'm gonna be fixing bugs I might as well send them to the author too).

In any case SPriG seems to include pre-built binaries so people shouldn't need to compile it themselves.

Offline sir_nacnud

  • Captain
  • ***
  • Posts: 54
    • View Profile
Re: SPriG: An alternative to SDL_gfx
« Reply #5 on: November 16, 2010, 04:52:24 am »
I think switching to SPrig is a good idea given there aren't any performance issues.  I assume your numbers were from a desktop pc?  It would be interesting to see the difference on an embedded device.

I think the main advantage of switching would be ease of porting OpenXcom to non SDL platforms, assuming SPrig is a stand alone library.  I have some interest in porting OpenXcom to other platforms, but the SDL_gfx dependency is making it difficult.  If the SDL_gfx dependency was removed, that would be awesome.

Offline michal

  • Commander
  • *****
  • Posts: 629
    • View Profile
Re: SPriG: An alternative to SDL_gfx
« Reply #6 on: November 16, 2010, 01:53:07 pm »
I think switching to SPrig is a good idea given there aren't any performance issues.  I assume your numbers were from a desktop pc?  It would be interesting to see the difference on an embedded device.
There won't be major difference in embedded devices as they probably aren't using scaling (for example dingoo).

I think the main advantage of switching would be ease of porting OpenXcom to non SDL platforms, assuming SPrig is a stand alone library.  I have some interest in porting OpenXcom to other platforms, but the SDL_gfx dependency is making it difficult.  If the SDL_gfx dependency was removed, that would be awesome.

SPrig is addon library for SDL, so it won't help.

Offline michal

  • Commander
  • *****
  • Posts: 629
    • View Profile
Re: SPriG: An alternative to SDL_gfx
« Reply #7 on: November 16, 2010, 02:16:03 pm »
I have big concern about Sprig. Does it support SDL 1.3? SDL_gfx supports 1.3 from version 2.0.21.

Generally, sdl_gfx looks more active than sprig:

https://code.google.com/p/sprig/updates/list
https://sdlgfx.svn.sourceforge.net/viewvc/sdlgfx/?view=log
« Last Edit: November 16, 2010, 02:21:36 pm by michal »

Offline Daiky

  • Battlescape Programmer
  • Administrator
  • Commander
  • *****
  • Posts: 904
    • View Profile
Re: SPriG: An alternative to SDL_gfx
« Reply #8 on: November 17, 2010, 01:13:36 pm »
Good points michal.
Especially the faster full-screen scaling is not a valid argument in my opinion, because I still see it as a hack and not the right solution. I see no other big advantages that outweigh the disadvantage of adding another dependency on top, and probably a not so activly developed one.

Offline michal

  • Commander
  • *****
  • Posts: 629
    • View Profile
Re: SPriG: An alternative to SDL_gfx
« Reply #9 on: November 17, 2010, 01:29:56 pm »
Even staying with sdl_gfx, there is way to increase scaling speed:
Quote
19:26 < _michal> anyway, i did that thing with scaling (scaling with blitting)
19:27 < _michal> for 640 x 400, fps in menu has raised 130 => 200
19:27 < _michal> in geoscape ~ 115 => 180
19:28 < Nils^> _michal: and visual effect?
19:30 < _michal> same
19:31 < _michal> 960 x 600, menu 68 => 110
19:32 < _michal> Nils^: you're asking if there are any artefacts?
19:36 < Nils^> _michal: I mean what is the price for better framerate?
19:39 < _michal> there aren't any price
19:39 < _michal> it's just different code used for scaling
19:39 < _michal> with less operations
19:42 < Nils^> good
19:42 < Nils^> :)
19:49 < SupSuper> _michal: what exactly did you do?
20:10 < _michal> i copied _zoomSurfaceY from https://sdlgfx.svn.sourceforge.net/viewvc/sdlgfx/SDL_rotozoom.c?revision=44&content-type=text%2Fplain
20:10 < _michal> and used in in Screen::flip for scaling
20:11 < _michal> _zoomSurfaceY(_surface->getSurface(), _screen, 0, 0);
20:12 < _michal> _zoomSurfaceY() is internal function used by zoomSurface
20:12 < _michal> in our case, we can call it directly on destination (_screen) surface
20:12 < SupSuper> cheeky
20:12 < _michal> without creating and blitting temporary (zoom) surface

Anyway, final decision belongs to SupSuper, but i think that it's more important to use maintaned library. So i'm not sure if switching to SPriG is good idea.
« Last Edit: November 17, 2010, 01:32:22 pm by michal »

Offline luciderous

  • Colonel
  • ****
  • Posts: 108
  • There is no spoon...
    • View Profile
Re: SPriG: An alternative to SDL_gfx
« Reply #10 on: November 17, 2010, 02:06:12 pm »
SDL_gfx has some issues, namely this one - https://openxcom.ninex.info/forum/index.php?topic=104.0 - that I certainly see as a problem. If SPriG helps to overcome this - I vouch for it.

Offline SupSuper

  • Lazy Developer
  • Administrator
  • Commander
  • *****
  • Posts: 2162
    • View Profile
Re: SPriG: An alternative to SDL_gfx
« Reply #11 on: November 18, 2010, 06:12:45 pm »
Ok let me clear something up. The reason I rely on external libraries is so they can do the work I don't wanna have to worry about. But of course the problem with them is that they complicate the deployment process, since everyone has to be able to download and compile and set up the libraries separately, both users and developers. I never really went into this for the performance or whatever.

Anyways, nobody had an issue with SDL or SDL_mixer, but overtime people complained that SDL_gfx had some bugs and could be hard to compile (dated Mac project, etc). So I reported the problems to the SDL_gfx author and went looking for other promising alternatives, and SPriG was what I found. So I wanted to know if people had the same issues they had with SDL_gfx, if it was easier to download / compile / deploy on their various platforms and systems and such. That was my main concern, I'd be replacing one dependency (SDL_gfx) for another (SPriG) so I wanted to know if that was for the better. Because for me it's a non-issue, but I don't know about everybody else, that's what I want feedback on.


Stuff like activity, performance, etc, it's all highly subjective. A library can be as ancient as 1990 but still work fine out of the box, likewise a really active library might just mean it's constantly full of stuff that needs bugs. Performance can vary wildly from platform to platform and anything above 100fps isn't really noticeable. It can be a plus but it's not really what I'm looking for, plus both library authors have been pretty responsive to my feedback regarding bugs and improvements (otherwise we'd still have a broken globe and resizing and so on). On that note, if you have an issue with a library, feel free to tell the authors about it directly, it's the only way they'll learn.

In the end it's gonna be me programming and working with the library all the time so the choice will be mine, but you're not really helping me pick. :P

Offline michal

  • Commander
  • *****
  • Posts: 629
    • View Profile
Re: SPriG: An alternative to SDL_gfx
« Reply #12 on: November 18, 2010, 08:56:55 pm »
So I wanted to know if people had the same issues they had with SDL_gfx, if it was easier to download / compile / deploy on their various platforms and systems and such. That was my main concern, I'd be replacing one dependency (SDL_gfx) for another (SPriG) so I wanted to know if that was for the better. Because for me it's a non-issue, but I don't know about everybody else, that's what I want feedback on.

Maybe it would be wise to ask such question on sdl forum:
https://forums.libsdl.org/

As for me, i'm compiling openxcom on ubuntu. I have sdl_gfx preinstalled in system. There aren't packages for SPrig. So that's advantage of sdl_gfx. On the other side, i compiled lot of different things, so it wouldn't be a problem for me, to compile SPriG.