OpenGL branch :D

[GoogleCodeExporter]

...yes :D

I've been working on my own platformer and had to switch to gl because of the 
speed issues i was having with SDL. So why not start rewriting the entire 
graphics back-end to use gl textures and do transforms using fragment shaders 
when supported?

I really love this application and just don't want it to seem held back by 
performance issues, SDL is _GRATE_ when your writing a UI or game for an 
embedded device or just about anything else you don't feel like reinventing the 
wheel for. But. For fully fledged graphics manipulation, like a application 
that designs UI's for other applications i think we mite need more power :P

(plz)

Original issue reported on code.google.com by thetoot...@yahoo.com on 14 Nov 2010 at 11:59

[GoogleCodeExporter]

The first reason would be portability. SDL is slow, but works everywhere. We 
have a port on amiga platforms, and on Haiku, both of which don't support GL 
but have a port of SDL.

Anyway, if we were to switch to something else, it would be a more usual GUI 
system like Qt. Unfortunately, none of them reaches the same level of 
portability as SDL.

Also, GrafX2 is a pure 256-color application. I highly doubt that OpenGL is 
really that good for handling that.

The other reason is that when I started the project, SDL was the only thing I 
knew. It was quite near to the existing ms-dos code backend, so I went with 
that. I'm still ignorant of most of the shader stuff, and would be unable to 
write them. Most of the UI code is from the dos version and works quite fine.

Note it is very posible to change the way the drawing is done, even the dos 
version had separate code for each graphics type (cga, ega, svga, ...). The 
pointers should still be there for adding more. I'm not going to spend time on 
that, but others may will to. We can open a branch for playing around, but the 
last time we did that with the ui_rewrite branch, nothing hapenned.

Original comment by pulkoma...@gmail.com on 14 Nov 2010 at 12:10

[GoogleCodeExporter]

We'll i'd offer to help but like you said theres a very good chance it'll go 
dead.

As an alternative maybe you could create a build config for modern operating 
systems that uses the newest version of SDL(1.3) and take advantage of the 
built in acceleration when ever possible.

I've worked with both versions this way and the only porting issue that sticks 
out is the color and mask data has been changed.

Heres a macro i've used to port SDL_gfx and a few others to the newer version:

[code]Uint32 _colorkey(SDL_Surface *src)
{
    Uint32 key = 0; 
#if (SDL_MINOR_VERSION == 3)
    SDL_GetColorKey(src, &key);
#else
    if (src) 
    {
        key = src->format->colorkey;
    }
#endif
    return key;
}[/code]

Original comment by thetoot...@yahoo.com on 14 Nov 2010 at 12:26

[GoogleCodeExporter]

Yes, there is a lot of reasons we want to use SDL 1.3. But it seems to still 
not be part of main linux distributions... Once it gets there we'll likely 
start using it.

Original comment by pulkoma...@gmail.com on 14 Nov 2010 at 12:28

[GoogleCodeExporter]

Oh yes i forgot how linux packaging works :P On another note once you start 
porting to the newer lib would you like me to do some speed builds and hosting? 
I have a dev license for the Intel compiler so the windows releases can get 
some extra optimizations xD

Original comment by thetoot...@yahoo.com on 14 Nov 2010 at 12:34

[GoogleCodeExporter]

> why not start rewriting the entire graphics back-end to use gl textures (...)
Why would we?
Is there a performance issue ? In which cases exactly ? And in these cases, 
check if the costly operation is the display. I'll help profile if you want.

The only operation that kills performances, as far as I know, is transparency, 
when used with very large brushes. But last time I profiled, all the time was 
spent in finding the best color in palette for a given RGB triplet.

Original comment by yrizoud on 14 Nov 2010 at 3:46

[GoogleCodeExporter]

Performance verys greatly depending on the resolution you use. I run grafx2 at 
1080p so i can work on images and not be distracted by background windows, 
additionally using a res native to the screen is necessary as most LCD's 
interpolate and stretch the image.

So while the issue is not critical it would be a good enhancement to look into, 
and as pulkomandy stated a transition to SDL 1.3 for the x86 system builds 
should solve the slow down when using a high-res display.

Original comment by thetoot...@yahoo.com on 14 Nov 2010 at 9:49

[GoogleCodeExporter]

Closing this as we're not going to use a branch nor openGL :)

Patches welcome, still...

Original comment by pulkoma...@gmail.com on 18 Feb 2011 at 1:30

• Changed state: WontFix