Re: [sdljava-users] SDLImage

[Ivan Z. G. <iva...@ya...>]

You bring up a good question.  The reason it has been implemented this 
way is because SDLSurface should not have a dependency on the SDL_Image 
library.  If we put those methods into SDLSurface you would also have to 
link in the SDL_Image into the core.  I would like to keep them 
separated as such so that you can pick and choose which library to use 
-- but not depend on any others.

In reality all the SDLImage API is already provided by java libraries in 
java core and jai I believe.  So the benefit of SDLImage for us is 
questionable.  The method SDLVideo.createRGBSurfaceFrom(...) could be 
used to load images loaded via standard java libraries (note;  for next 
release this method will be re-implemented with NIO buffers).

Perhaps we should provide some helper methods within SDLVideo to create 
surfaces from images which then invoke the standard java api's to do so.

It cannot be an actual java filehandle because the string is transferred 
directly to:
    SDL_Surface * SDLCALL IMG_Load(const char *file);

And SDL has no idea what a java file handle would mean.

Thanks for the compliment.  I want this to be a an API that can 
seriously be used to develop most types of games in java.  Please give 
me any more of your comments.

PS:  we're ramping up for the next release.  Should be within two weeks 
or so.  Please see the CHANGES_0_9_1 for a list of whats coming.  There 
is more to add to the file but its mostly up to date.

If anyone wants to get a feature in for 0_9_1 please drop me a note.

Thanks
-Ivan/


Chris Dennett wrote:

> I've got a question regarding SDLImage. Is it me, or is this class 
> redundant? To me, it just seems to be a factory class for SDLSurface, 
> from which image surfaces can be created from filename handles (as 
> strings), and it may be better to transfer the load methods back to 
> SDLSurface as constructors, while keeping stub methods in SDLimage for 
> backwards compatiblity. Also, perhaps filename should be an actual 
> file handle type, instead of a String, from the underlying Java 
> architecture (if it exists)? ;)
>
> On the whole, however, this seems really well implemented, but I think 
> you have to carry on reaching into the Java architecture for well 
> defined types.
>
> Regards,
> Chris
>