| View previous topic :: View next topic |
| Author |
Message |
Phr00t
Joined: 03 Mar 2006
Posts: 203
|
 Posted: Sat Apr 01, 2006 4:49 pm Post subject: SDL SGE |
 |
|
Derelict is full of some cool stuff, but can it do rotated blits etc. out of the box? It doesn't look like SDL has it already... can you add SGE to the mix or tell me how I can do it already?
http://www.etek.chalmers.se/~e8cal1/sge/
Thank you!  |
|
| Back to top |
|
 |
Crispy
Joined: 26 Nov 2005
Posts: 67
|
| Posted: Sat Apr 01, 2006 8:23 pm Post subject: |
|
|
It says it can be linked to C code, so that's a big advantage for a start - no name mangling or objects to worry about. Basically all you need is to get the DLL for it, find out what functions the DLL exports, and then write a piece of code that loads the DLL functions and exposes them as D functions. Check out the existing D modules to see how it works, or you can look at the bindings I posted on this forum for FastEvents and NET2; they're not part of Derelict but they work the same way (http://www.dsource.org/forums/viewtopic.php?t=1103). It's not all that difficult; even if you don't fully understand the code, it's straightforward enough that you can basically copy an existing binding and just change some function names and such.
Personally I almost always use OpenGL when I'm using SDL - it's quite a bit faster (especially if the scene is changing quickly), you get rotation, scaling, etc. for free, and it isn't much additional work. |
|
| Back to top |
|
|
Phr00t
Joined: 03 Mar 2006
Posts: 203
|
| Posted: Sat Apr 01, 2006 8:39 pm Post subject: |
|
|
Hrm... I would perfer to use OpenGL for all that rotation and whatnot too I guess I just don't know how to do it with Derelict yet  I'll find out... any good tutorials I should look at to get started? e.g. just to load a PNG, rotate and blit it on the screen in a 2D fashion? |
|
| Back to top |
|
|
clayasaurus
Joined: 21 May 2004
Posts: 857
|
|
| Back to top |
|
|
aldacron
Joined: 05 May 2004
Posts: 1322
Location: Seoul, South Korea
|
| Posted: Sun Apr 02, 2006 7:54 am Post subject: |
|
|
| SGE isn't something I see getting added to Derelict. Since it's just a collection of graphics algorithms, a better option would be to port it to D directly as a new project. Even better, IMO, would be to port Anti-Grain to D. Its a more versatile package and it's license is more palatable (I'm really not a fan of GPL and LGPL when looking for stuff to port). |
|
| Back to top |
|
|
Phr00t
Joined: 03 Mar 2006
Posts: 203
|
| Posted: Sun Apr 02, 2006 11:38 am Post subject: |
|
|
SGE seems like it would fit right into Derelict. SGE is made for SDL, SDLImage etc. which Derelict already uses. And SGE adds things I would expect a multimedia/gaming library to already have (e.g. draw a simple line, rotated sprites). And why would you want to make a whole new library when 80? of the functionality you want is already in Derelict?
Anti-Grain -> D might be a worthy project, but I don't think it is a solution for SGE added to Derelict
[ edit ] just noticed clayasaurus link to rotozoom, thanks -- but still not simple drawing functions :-\ |
|
| Back to top |
|
|
clayasaurus
Joined: 21 May 2004
Posts: 857
|
| Posted: Sun Apr 02, 2006 8:56 pm Post subject: |
|
|
http://freshmeat.net/projects/sdl_gfx/
SDL_gfx is a nice library and would probably be simple to port to D. It is LGPL so you can use it in commercial projects as long as you load it dynamically, aka derelict style.
If you really want it then I would suggest you study how derelict works (SDL_image is a good example) and write your own port for it, and if you are feeling lucky ask aldacron to put it in his project, if not then you can always post it in the bindings project and make a forum topic here for it.
Goodluck.
~ Clay |
|
| Back to top |
|
|
aldacron
Joined: 05 May 2004
Posts: 1322
Location: Seoul, South Korea
|
| Posted: Tue Apr 04, 2006 7:02 pm Post subject: |
|
|
| Phr00t wrote: | | SGE seems like it would fit right into Derelict. SGE is made for SDL, SDLImage etc. which Derelict already uses. And SGE adds things I would expect a multimedia/gaming library to already have (e.g. draw a simple line, rotated sprites). And why would you want to make a whole new library when 80? of the functionality you want is already in Derelict? |
The criteria I use to determine if a new package should be created in Derelict are, loosely:
* is the library too complex to easily port to D?
* does the library abstract away cross platform APIs?
* is the library easily compiled into DLL form?
* are there any license issues?
If a library is not overly complex and can be easily ported to D without worrying about cross-platform issues, then I don't see the need to add it to Derelict. SGE fits that description. Pixel operations in SDL are easily ported to D and do not depend on any OS-specific APIs. We should be looking to minimize our dependence on C libraries, not propagating it.
Ultimately, there will be a move in the D community to get away from C libraries and port as many of them as possible to D (or create new ones). This will allow the ported code to take advantage of garbage collection and other D-isms that aren't available in C and eliminate the potential safety issues inherent in the mixing of C and D. Obviously, we aren't going to be porting libraries like OpenGL and OpenAL. Someone might be willing to port SDL, SDLimage, SDLnet and SDLaudio, but the size of the codebase and the cross platform issues make such ports nontrivial. Considering that there is not yet a comprehensive port of the Win32 and X headers, those libs are better suited as bindings rather than ports at present.
Liscensing is also a big concern. I'm well aware that the common interpretation of the LGPL is that one need not release the source of an application when linking dynamically to an LGPLed library. But I do not yet know how that applies to D bindings as no one has given me a definitive answer. The issue is that the D modules themselves are compiled into object files and because they are created from LGPLed headers they must also be under LGPL. So when you use DerelictSDL you are linking directly with LGPLed object files. Many of the C macros have been rewritten as D functions. So how can this be interpreted? Are the D modules equivalent to C headers (which basically get inserted into C source modules, with expanded macros)? Or are the D modules considered statically linked objects? If the latter is true, then any D apps using any SDL bindings will be forced to release their source under the LGPL. Until I get a definitive answer, I want to minimize the amount of LGPLed code in Derelict.
So SGE just doesn't meet my criteria. Neither does SDL_gfx. There are a bazillion pixel manipulating libraries out there, any of which could easily be ported to D and made to work with SDL. Or even better, made to work with any hardware interfacing library (by working on generic buffers rather than SDL surfaces). |
|
| Back to top |
|
|
Phr00t
Joined: 03 Mar 2006
Posts: 203
|
| Posted: Tue Apr 04, 2006 7:51 pm Post subject: |
|
|
OK, fair enough.
It seems clayasaurus has already been working on something that I was looking for: http://warbots.dsource.org/arc/index.html
I will follow that project for the functionality, even if it does/doesn't get included with Derelict. |
|
| Back to top |
|
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
