Closed GoogleCodeExporter closed 9 years ago
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
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
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
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
> 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
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
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
Original issue reported on code.google.com by
thetoot...@yahoo.com
on 14 Nov 2010 at 11:59