sdljava-users — General Discussion about sdljava and gljava

Re: [sdljava-users] Re: Small patch to SDLVideo.mapRGBA

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

No worries.  I see to have applied it correctly anyhow.  It was so small 
I typed it in.  I have also applied to fix to SDLSurface at this time.  
CVS on sourceforge is slugish right now but it will be checked in next 
time I can access the repository.

Thanks for finding these!

-Ivan/

Flavio Chierichetti wrote:

>On Mon, 2005-01-24 at 10:42 +0100, Flavio Chierichetti wrote:
>  
>
>>Hi,
>>	the mapRGBA method switch the green and blue component (the mapRGB
>>method works well). While the right order should be RGBA, the native
>>method is called with RBGA.
>>
>>This little patch fixes the problem (I took the file from cvs on the
>>21st of this month):
>>
>>457c457
>><       return SWIG_SDLVideo.SDL_MapRGBA(format.getSwigPixelFormat(),
>>(short)r, (short)g, (short)b, (short)a);
>>---
>>    
>>
>>>      return SWIG_SDLVideo.SDL_MapRGBA(format.getSwigPixelFormat(),
>>>      
>>>
>>(short)r, (short)b, (short)g, (short)a);
>>    
>>
>
>The same problem can be found in SDLSurface.java :
>
>939c939
><       return SDLVideo.mapRGBA(getFormat(), r, b, g, a);
>---
>  
>
>>      return SDLVideo.mapRGBA(getFormat(), r, g, b, a);
>>    
>>
>
>
>Ciao!
>   Flavio
>
>P.S.: I've made the previous patch the wrong way around *blush*. I hope
>this one is good ;)
>
>  
>

Re: [sdljava-users] Small patch to SDLVideo.mapRGBA

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

Nice!  Thanks for the patch.  We now have Direct NIO access to the pixel 
data.  This is pretty damn fast!!  The only problem appears to be that I 
tried to create the variable like I was in java -- I wish there would 
have been a compilier error...

BTW:  When sending patches for the native code the patch for the .i is 
enough.  You don't need to send the patch info for the C file as it is 
always regenerated by swig...

Commiting this to CVS as well as updated testcase:  
SDLDirectBufferPixelDataTest

Thanks again,
-Ivan/


LEBOEUF Bart wrote:

>Hi,
>
>	Here a patch for SDLVideo native code correcting init of jobject
>variable, because the compilation failed with VisualC. If someone has
>trouble with it, let me know it.
>
>/Bart.
>  
>

RE: [sdljava-users] Small patch to SDLVideo.mapRGBA

[LEBOEUF B. <bar...@ya...>]

Hi,

	Here a patch for SDLVideo native code correcting init of jobject
variable, because the compilation failed with VisualC. If someone has
trouble with it, let me know it.

/Bart.

[sdljava-users] lowering SDL_mixer requirement

[Robert S. <the...@gm...>]

Hello, 
would it be possible to lower the requirement for the SDL_mixer library to 
version 1.2.5? 
 
I have a number of distributions where 1.2.6 is not yet stable and another 
bunch of admins which cannot be easily convinced to update :) 
 
cu 
Robert 

-- 
10 GB Mailbox, 100 FreeSMS http://www.gmx.net/de/go/topmail
+++ GMX - die erste Adresse für Mail, Message, More +++

[sdljava-users] Re: Small patch to SDLVideo.mapRGBA

[Flavio C. <fl...@li...>]

On Mon, 2005-01-24 at 10:42 +0100, Flavio Chierichetti wrote:
> Hi,
> 	the mapRGBA method switch the green and blue component (the mapRGB
> method works well). While the right order should be RGBA, the native
> method is called with RBGA.
> 
> This little patch fixes the problem (I took the file from cvs on the
> 21st of this month):
> 
> 457c457
> <       return SWIG_SDLVideo.SDL_MapRGBA(format.getSwigPixelFormat(),
> (short)r, (short)g, (short)b, (short)a);
> ---
> >       return SWIG_SDLVideo.SDL_MapRGBA(format.getSwigPixelFormat(),
> (short)r, (short)b, (short)g, (short)a);

The same problem can be found in SDLSurface.java :

939c939
<       return SDLVideo.mapRGBA(getFormat(), r, b, g, a);
---
>       return SDLVideo.mapRGBA(getFormat(), r, g, b, a);


Ciao!
   Flavio

P.S.: I've made the previous patch the wrong way around *blush*. I hope
this one is good ;)

-- 
Flavio Chierichetti
http://lightless.org/

Re: [sdljava-users] Small patch to SDLVideo.mapRGBA

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

Thanks for the patch.  I've applied it to SDLVideo and CVS has been updated.

Glad to be of service ;-)

-Ivan/

Flavio Chierichetti wrote:

>Hi,
>	the mapRGBA method switch the green and blue component (the mapRGB
>method works well). While the right order should be RGBA, the native
>method is called with RBGA.
>
>This little patch fixes the problem (I took the file from cvs on the
>21st of this month):
>
>457c457
><       return SWIG_SDLVideo.SDL_MapRGBA(format.getSwigPixelFormat(),
>(short)r, (short)g, (short)b, (short)a);
>---
>  
>
>>      return SWIG_SDLVideo.SDL_MapRGBA(format.getSwigPixelFormat(),
>>    
>>
>(short)r, (short)b, (short)g, (short)a);
>
>
>Thanks for the excellent work,
>	Flavio
>
>  
>

Re: [sdljava-users] Problem with SDLMixer

[Robert S. <the...@gm...>]

Hi Ivan.

>
> Do you know if we can run a wiki on sourceforge's site?
>
I am not used to sf's site management but I know that the Gnome bindings 
for Java run a Wiki on their sf page. Their home is java-gnome.sf.net .

cu
Robert

> I will add the version API thanks for the suggestion.
>
> -Ivan/
>
> Robert Schuster wrote:
>
>> Hi.
>>
>> Ivan Z. Ganza wrote:
>>
>>> Sweet!  Thank you very much for the patch.  I have integrated this 
>>> code.  That is a really nice way to do it.  I was wracking my brain 
>>> for an elegant solution.
>>
>>
>>
>> Well, one could make sure that the small buffers are really filled to 
>> their maximum before another one is allocated. If the 
>> ReadableByteChannel delivers a megabyte in chunks of 100 bytes then 
>> each small buffer wastes ~900 byte. This is not so nice but I think 
>> this can be fixed.
>>
>>>
>>> Its been tested and the changes are committed to CVS.  I made one 
>>> small change which was to call order(ByteOrder.nativeOrder()) on the 
>>> byte buffers.  I think this is required in the case when the buffers 
>>> might be accessed from the C code.
>>
>>
>>
>> I think we need some PPC-style hardware to test this. AFAIK the 
>> byteorder is only neccessary if Java would do non-byte sized 
>> accesses. Since ReadableByteChannel processes only bytes it should be 
>> ok.
>>
>>>
>>> BTW:  let me know if you want dev access.  Or feel free to keep 
>>> sending me patches as you have them.
>>>
>> Thank you, but I think I have not enough time to contribute regularly 
>> (nor the knowledge about the Swig/SDL trickery). I keep sending 
>> patches to you instead. Now that sdljava's mixer library found its 
>> way into our game this may happen more often :-)
>>
>> If you are interested in seeing (or better hearing) your binding at 
>> work try the latest JNLP of our game which is on the download page of 
>> our project page: freefodder.dev.java.net (the unstable link). Please 
>> read the last paragraph of the latest announcement which describes 
>> how to set the sound output to SDLMixer (or wait some days/weeks 
>> until I fixed the launcher app).
>>
>> Btw: Could you add a version API? It would be nice to retrieve SDL's 
>> version and the version of the binding itself programmatically.
>>
>> cu
>> Robert
>>
>> Btw2: You may want to install a Wiki on your project page. I have 
>> seen that some statements are outdated (requirement for Java1.5 and 
>> SDLMixer 1.2.*5*) and I know that updating the website is extremely 
>> boring and timeconsuming. :-)
>>
>>> Also finally I have moved the location of BufferUtils to 
>>> src/sdljava/util;  it used to be in just "src" which was the wrong 
>>> place.
>>>
>>> Thanks again!
>>> -Ivan/
>>>
>>> Robert Schuster wrote:
>>>
>>>> Great! That was the problem.
>>>>
>>>> Along with that I fixed the problem with the loading of URLs from 
>>>> the net (or arbitrary slow locations). The problem with your 
>>>> implementation was that you asserted that InputStream.available() 
>>>> returns the complete size of the stream. However available() 
>>>> returns only the amount of bytes that can be read without blocking.
>>>>
>>>> I fixed BufferUtil.readInputStream() in the following way:
>>>> I am reading the parts of the stream into separate ByteBuffers 
>>>> until the stream is really finished. Afterwards I merge the buffers 
>>>> into one big buffer and return that.
>>>> The implementation uses Channel.newChannel() to retrieve a 
>>>> ReadableByteChannel which allows a ByteBuffer for its read() 
>>>> method. The behavior of this method is otherwise the same as 
>>>> InputStream.read(). The important bit is that -1 is returned when 
>>>> the end of the stream is reached.
>>>>
>>>> I have attached the patch to this mail. Tell me if the list daemon 
>>>> rips it away to send it to you directly.
>>>>
>>>> If you are using BeanShell try this snippet as a proof of concept:
>>>>
>>>> import sdljava.*;
>>>> import sdljava.mixer.*;
>>>> SDLMain.init(SDLMain.SDL_INIT_AUDIO);
>>>> SDLMixer.openAudio(44100, SDLMixer.AUDIO_S16SYS, 2, 4096);
>>>> imc = SDLMixer.loadWAV(new 
>>>> URL("http://www.barbneal.com/wav/lucy/lucy01.wav"));
>>>> SDLMixer.playChannel(0, imc, 0);
>>>>
>>>> However you can add type information and make that a real Java 
>>>> class, too. :-)
>>>>
>>>> cu
>>>> Robert
>>>>
>>>> Btw: Thanks again for reviving the Java binding for SDL. sdljava is 
>>>> the first library that allows me to do portable sound output in 
>>>> Java without having to sacrifice other useful Java API (like 
>>>> resource loading system which is essential for JNLP!).
>>>>
>>>> Ivan Z. Ganza wrote:
>>>>
>>>>> Make sure you have at least SDL Mixer 1.2.6 as the Mix_LoadMUS_RW 
>>>>> was added for 1.2.6.  Its strange though that you were able to 
>>>>> compile if this function wasn't present.
>>>>>
>>>>> BTW I've found that loading over the network doesn't work, 
>>>>> filebased urls are fine though.  I need to find an example of the 
>>>>> proper way to load a byte stream from a URL....
>>>>>
>>>>> Let me know if this helped.
>>>>> -Ivan/
>>>>>
>>>>> Robert Schuster wrote:
>>>>>
>>>>>> Hi,
>>>>>> I wanted to try the new URL based loading of WAV file and was 
>>>>>> stopped by this:
>>>>>>
>>>>>> java.lang.UnsatisfiedLinkError: 
>>>>>> /home/rob/tmp/lwtest/libsdljava_mixer.so: 
>>>>>> /home/rob/tmp/lwtest/libsdljava_mixer.so: undefined symbol: 
>>>>>> Mix_LoadMUS_RW
>>>>>>        at java.lang.ClassLoader$NativeLibrary.load(Native Method)
>>>>>>        at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1586)
>>>>>>        at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1511)
>>>>>>        at java.lang.Runtime.loadLibrary0(Runtime.java:788)
>>>>>>        at java.lang.System.loadLibrary(System.java:834)
>>>>>>        at sdljava.mixer.SDLMixer.<clinit>(SDLMixer.java:1184)
>>>>>>
>>>>>> I took sdljava from CVS (01.22.05) and compiled all files (using 
>>>>>> Blackdown 1.4.2 for GNU/Linux).
>>>>>>
>>>>>> cu
>>>>>> Robert
>>>>>>
>>>>>>
>>>>>> -------------------------------------------------------
>>>>>> This SF.Net email is sponsored by: IntelliVIEW -- Interactive 
>>>>>> Reporting
>>>>>> Tool for open source databases. Create drag-&-drop reports. Save 
>>>>>> time
>>>>>> by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, 
>>>>>> etc.
>>>>>> Download a FREE copy at http://www.intelliview.com/go/osdn_nl
>>>>>> _______________________________________________
>>>>>> sdljava-users mailing list
>>>>>> sdl...@li...
>>>>>> https://lists.sourceforge.net/lists/listinfo/sdljava-users
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> -------------------------------------------------------
>>>>> This SF.Net email is sponsored by: IntelliVIEW -- Interactive 
>>>>> Reporting
>>>>> Tool for open source databases. Create drag-&-drop reports. Save time
>>>>> by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, 
>>>>> etc.
>>>>> Download a FREE copy at http://www.intelliview.com/go/osdn_nl
>>>>> _______________________________________________
>>>>> sdljava-users mailing list
>>>>> sdl...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/sdljava-users
>>>>>
>>>>>
>>>> ------------------------------------------------------------------------ 
>>>>
>>>>
>>>> Index: src/util/BufferUtil.java
>>>> ===================================================================
>>>> RCS file: /cvsroot/sdljava/sdljava/src/util/BufferUtil.java,v
>>>> retrieving revision 1.2
>>>> diff -u -r1.2 BufferUtil.java
>>>> --- src/util/BufferUtil.java    7 Jan 2005 03:11:49 -0000    1.2
>>>> +++ src/util/BufferUtil.java    22 Jan 2005 22:20:40 -0000
>>>> @@ -7,15 +7,23 @@
>>>> import java.net.URLConnection;
>>>> import java.net.MalformedURLException;
>>>> import java.nio.ByteBuffer;
>>>> +import java.nio.channels.Channels;
>>>> +import java.nio.channels.ReadableByteChannel;
>>>> +import java.util.Iterator;
>>>> +import java.util.List;
>>>> +import java.util.LinkedList;
>>>>
>>>> /**
>>>>  * Some usefull methods for reading URLs or streams and returning 
>>>> the data as Direct Buffers
>>>>  *
>>>> - * @author  Ivan Z. Ganza
>>>> + * @author Ivan Z. Ganza
>>>> + * @author Robert Schuster
>>>>  * @version $Id: BufferUtil.java,v 1.2 2005/01/07 03:11:49 
>>>> ivan_ganza Exp $
>>>>  */
>>>> public class BufferUtil {
>>>>
>>>> +    private static final int BUFFER_SIZE = 1024;
>>>> +
>>>>     /**
>>>>      * Tries to open the given URL, get its input stream, returns 
>>>> the data in a <I><B>direct</I></B> ByteBuffer
>>>>      *
>>>> @@ -48,14 +56,48 @@
>>>>      * @exception IOException if an error occurs
>>>>      */
>>>>     public static ByteBuffer readInputStream(InputStream in) throws 
>>>> IOException {
>>>> -    int avail  = in.available();
>>>> -    byte buf[] = new byte[avail];
>>>> +            /* Converts the InputStream into a channels which allows
>>>> +             * us to read into a ByteBuffer.
>>>> +             */
>>>> +            ReadableByteChannel    ch = Channels.newChannel(in);
>>>> +   +            // Creates a list that stores the intermediate 
>>>> buffers.
>>>> +            List list = new LinkedList();
>>>>
>>>> -    int read = in.read(buf);
>>>> -    if (read != avail) throw new IOException("needed to read: " + 
>>>> avail + " bytes, but actually read: " + read);
>>>> +            // A variable storing the accumulated size of the data.
>>>> +            int sum = 0, read = 0;
>>>>
>>>> -    ByteBuffer byteBuffer = ByteBuffer.allocateDirect(buf.length);
>>>> -    byteBuffer.put(buf);
>>>> -    return byteBuffer;
>>>> -    }
>>>> -}
>>>> \ No newline at end of file
>>>> +            /* Reads all the bytes from the channel and stores them
>>>> +              * in various buffer objects.
>>>> +             */
>>>> +            do {
>>>> +                ByteBuffer b = 
>>>> ByteBuffer.allocateDirect(BUFFER_SIZE);
>>>> +                read = ch.read(b);
>>>> +
>>>> +                if(read > 0) {
>>>> +                    b.flip(); // make ready for reading later
>>>> +                    list.add(b);
>>>> +                    sum += read;
>>>> +                }
>>>> +            } while(read != -1);
>>>> +
>>>> +            /* If there is only one buffer used we do not
>>>> +             * need to merge the data.
>>>> +             */
>>>> +            if(list.size() == 1) {
>>>> +                return (ByteBuffer) list.get(0);
>>>> +            }
>>>> +
>>>> +            ByteBuffer bb = ByteBuffer.allocateDirect(sum);
>>>> +
>>>> +          /* Merges all buffers into the Buffer bb */
>>>> +            Iterator ite = list.iterator();
>>>> +            while(ite.hasNext()){
>>>> +                bb.put((ByteBuffer) ite.next());
>>>> +            }
>>>> +
>>>> +            list.clear();
>>>> +
>>>> +            return bb;
>>>> +    }
>>>> +}
>>>>  
>>>>
>>>
>>>
>>>
>>> -------------------------------------------------------
>>> This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
>>> Tool for open source databases. Create drag-&-drop reports. Save time
>>> by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
>>> Download a FREE copy at http://www.intelliview.com/go/osdn_nl
>>> _______________________________________________
>>> sdljava-users mailing list
>>> sdl...@li...
>>> https://lists.sourceforge.net/lists/listinfo/sdljava-users
>>>
>>>
>>
>>
>> -------------------------------------------------------
>> This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
>> Tool for open source databases. Create drag-&-drop reports. Save time
>> by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
>> Download a FREE copy at http://www.intelliview.com/go/osdn_nl
>> _______________________________________________
>> sdljava-users mailing list
>> sdl...@li...
>> https://lists.sourceforge.net/lists/listinfo/sdljava-users
>
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
> Tool for open source databases. Create drag-&-drop reports. Save time
> by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
> Download a FREE copy at http://www.intelliview.com/go/osdn_nl
> _______________________________________________
> sdljava-users mailing list
> sdl...@li...
> https://lists.sourceforge.net/lists/listinfo/sdljava-users
>
>

[sdljava-users] Small patch to SDLVideo.mapRGBA

[Flavio C. <fl...@li...>]

Hi,
	the mapRGBA method switch the green and blue component (the mapRGB
method works well). While the right order should be RGBA, the native
method is called with RBGA.

This little patch fixes the problem (I took the file from cvs on the
21st of this month):

457c457
<       return SWIG_SDLVideo.SDL_MapRGBA(format.getSwigPixelFormat(),
(short)r, (short)g, (short)b, (short)a);
---
>       return SWIG_SDLVideo.SDL_MapRGBA(format.getSwigPixelFormat(),
(short)r, (short)b, (short)g, (short)a);


Thanks for the excellent work,
	Flavio

-- 
Flavio Chierichetti
http://lightless.org/

Re: [sdljava-users] Problem with SDLMixer

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

Thanks I'm happy to accept patches.

I will have a look at the freefodder site and am looking forward to 
downloading it.

Regarding update of web page, etc... It not really a big deal to update 
the site.  Can be done fairly quickly.  The requirements listed on the 
webpage are specific to the latest released version of sdljava.  For the 
requirements of the CVS version please see the INSTALL file.  I have 
updated the website to be more clear in this respect.

Do you know if we can run a wiki on sourceforge's site?

I will add the version API thanks for the suggestion.

-Ivan/

Robert Schuster wrote:

> Hi.
>
> Ivan Z. Ganza wrote:
>
>> Sweet!  Thank you very much for the patch.  I have integrated this 
>> code.  That is a really nice way to do it.  I was wracking my brain 
>> for an elegant solution.
>
>
> Well, one could make sure that the small buffers are really filled to 
> their maximum before another one is allocated. If the 
> ReadableByteChannel delivers a megabyte in chunks of 100 bytes then 
> each small buffer wastes ~900 byte. This is not so nice but I think 
> this can be fixed.
>
>>
>> Its been tested and the changes are committed to CVS.  I made one 
>> small change which was to call order(ByteOrder.nativeOrder()) on the 
>> byte buffers.  I think this is required in the case when the buffers 
>> might be accessed from the C code.
>
>
> I think we need some PPC-style hardware to test this. AFAIK the 
> byteorder is only neccessary if Java would do non-byte sized accesses. 
> Since ReadableByteChannel processes only bytes it should be ok.
>
>>
>> BTW:  let me know if you want dev access.  Or feel free to keep 
>> sending me patches as you have them.
>>
> Thank you, but I think I have not enough time to contribute regularly 
> (nor the knowledge about the Swig/SDL trickery). I keep sending 
> patches to you instead. Now that sdljava's mixer library found its way 
> into our game this may happen more often :-)
>
> If you are interested in seeing (or better hearing) your binding at 
> work try the latest JNLP of our game which is on the download page of 
> our project page: freefodder.dev.java.net (the unstable link). Please 
> read the last paragraph of the latest announcement which describes how 
> to set the sound output to SDLMixer (or wait some days/weeks until I 
> fixed the launcher app).
>
> Btw: Could you add a version API? It would be nice to retrieve SDL's 
> version and the version of the binding itself programmatically.
>
> cu
> Robert
>
> Btw2: You may want to install a Wiki on your project page. I have seen 
> that some statements are outdated (requirement for Java1.5 and 
> SDLMixer 1.2.*5*) and I know that updating the website is extremely 
> boring and timeconsuming. :-)
>
>> Also finally I have moved the location of BufferUtils to 
>> src/sdljava/util;  it used to be in just "src" which was the wrong 
>> place.
>>
>> Thanks again!
>> -Ivan/
>>
>> Robert Schuster wrote:
>>
>>> Great! That was the problem.
>>>
>>> Along with that I fixed the problem with the loading of URLs from 
>>> the net (or arbitrary slow locations). The problem with your 
>>> implementation was that you asserted that InputStream.available() 
>>> returns the complete size of the stream. However available() returns 
>>> only the amount of bytes that can be read without blocking.
>>>
>>> I fixed BufferUtil.readInputStream() in the following way:
>>> I am reading the parts of the stream into separate ByteBuffers until 
>>> the stream is really finished. Afterwards I merge the buffers into 
>>> one big buffer and return that.
>>> The implementation uses Channel.newChannel() to retrieve a 
>>> ReadableByteChannel which allows a ByteBuffer for its read() method. 
>>> The behavior of this method is otherwise the same as 
>>> InputStream.read(). The important bit is that -1 is returned when 
>>> the end of the stream is reached.
>>>
>>> I have attached the patch to this mail. Tell me if the list daemon 
>>> rips it away to send it to you directly.
>>>
>>> If you are using BeanShell try this snippet as a proof of concept:
>>>
>>> import sdljava.*;
>>> import sdljava.mixer.*;
>>> SDLMain.init(SDLMain.SDL_INIT_AUDIO);
>>> SDLMixer.openAudio(44100, SDLMixer.AUDIO_S16SYS, 2, 4096);
>>> imc = SDLMixer.loadWAV(new 
>>> URL("http://www.barbneal.com/wav/lucy/lucy01.wav"));
>>> SDLMixer.playChannel(0, imc, 0);
>>>
>>> However you can add type information and make that a real Java 
>>> class, too. :-)
>>>
>>> cu
>>> Robert
>>>
>>> Btw: Thanks again for reviving the Java binding for SDL. sdljava is 
>>> the first library that allows me to do portable sound output in Java 
>>> without having to sacrifice other useful Java API (like resource 
>>> loading system which is essential for JNLP!).
>>>
>>> Ivan Z. Ganza wrote:
>>>
>>>> Make sure you have at least SDL Mixer 1.2.6 as the Mix_LoadMUS_RW 
>>>> was added for 1.2.6.  Its strange though that you were able to 
>>>> compile if this function wasn't present.
>>>>
>>>> BTW I've found that loading over the network doesn't work, 
>>>> filebased urls are fine though.  I need to find an example of the 
>>>> proper way to load a byte stream from a URL....
>>>>
>>>> Let me know if this helped.
>>>> -Ivan/
>>>>
>>>> Robert Schuster wrote:
>>>>
>>>>> Hi,
>>>>> I wanted to try the new URL based loading of WAV file and was 
>>>>> stopped by this:
>>>>>
>>>>> java.lang.UnsatisfiedLinkError: 
>>>>> /home/rob/tmp/lwtest/libsdljava_mixer.so: 
>>>>> /home/rob/tmp/lwtest/libsdljava_mixer.so: undefined symbol: 
>>>>> Mix_LoadMUS_RW
>>>>>        at java.lang.ClassLoader$NativeLibrary.load(Native Method)
>>>>>        at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1586)
>>>>>        at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1511)
>>>>>        at java.lang.Runtime.loadLibrary0(Runtime.java:788)
>>>>>        at java.lang.System.loadLibrary(System.java:834)
>>>>>        at sdljava.mixer.SDLMixer.<clinit>(SDLMixer.java:1184)
>>>>>
>>>>> I took sdljava from CVS (01.22.05) and compiled all files (using 
>>>>> Blackdown 1.4.2 for GNU/Linux).
>>>>>
>>>>> cu
>>>>> Robert
>>>>>
>>>>>
>>>>> -------------------------------------------------------
>>>>> This SF.Net email is sponsored by: IntelliVIEW -- Interactive 
>>>>> Reporting
>>>>> Tool for open source databases. Create drag-&-drop reports. Save time
>>>>> by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, 
>>>>> etc.
>>>>> Download a FREE copy at http://www.intelliview.com/go/osdn_nl
>>>>> _______________________________________________
>>>>> sdljava-users mailing list
>>>>> sdl...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/sdljava-users
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> -------------------------------------------------------
>>>> This SF.Net email is sponsored by: IntelliVIEW -- Interactive 
>>>> Reporting
>>>> Tool for open source databases. Create drag-&-drop reports. Save time
>>>> by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
>>>> Download a FREE copy at http://www.intelliview.com/go/osdn_nl
>>>> _______________________________________________
>>>> sdljava-users mailing list
>>>> sdl...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/sdljava-users
>>>>
>>>>
>>> ------------------------------------------------------------------------ 
>>>
>>>
>>> Index: src/util/BufferUtil.java
>>> ===================================================================
>>> RCS file: /cvsroot/sdljava/sdljava/src/util/BufferUtil.java,v
>>> retrieving revision 1.2
>>> diff -u -r1.2 BufferUtil.java
>>> --- src/util/BufferUtil.java    7 Jan 2005 03:11:49 -0000    1.2
>>> +++ src/util/BufferUtil.java    22 Jan 2005 22:20:40 -0000
>>> @@ -7,15 +7,23 @@
>>> import java.net.URLConnection;
>>> import java.net.MalformedURLException;
>>> import java.nio.ByteBuffer;
>>> +import java.nio.channels.Channels;
>>> +import java.nio.channels.ReadableByteChannel;
>>> +import java.util.Iterator;
>>> +import java.util.List;
>>> +import java.util.LinkedList;
>>>
>>> /**
>>>  * Some usefull methods for reading URLs or streams and returning 
>>> the data as Direct Buffers
>>>  *
>>> - * @author  Ivan Z. Ganza
>>> + * @author Ivan Z. Ganza
>>> + * @author Robert Schuster
>>>  * @version $Id: BufferUtil.java,v 1.2 2005/01/07 03:11:49 
>>> ivan_ganza Exp $
>>>  */
>>> public class BufferUtil {
>>>
>>> +    private static final int BUFFER_SIZE = 1024;
>>> +
>>>     /**
>>>      * Tries to open the given URL, get its input stream, returns 
>>> the data in a <I><B>direct</I></B> ByteBuffer
>>>      *
>>> @@ -48,14 +56,48 @@
>>>      * @exception IOException if an error occurs
>>>      */
>>>     public static ByteBuffer readInputStream(InputStream in) throws 
>>> IOException {
>>> -    int avail  = in.available();
>>> -    byte buf[] = new byte[avail];
>>> +            /* Converts the InputStream into a channels which allows
>>> +             * us to read into a ByteBuffer.
>>> +             */
>>> +            ReadableByteChannel    ch = Channels.newChannel(in);
>>> +   +            // Creates a list that stores the intermediate 
>>> buffers.
>>> +            List list = new LinkedList();
>>>
>>> -    int read = in.read(buf);
>>> -    if (read != avail) throw new IOException("needed to read: " + 
>>> avail + " bytes, but actually read: " + read);
>>> +            // A variable storing the accumulated size of the data.
>>> +            int sum = 0, read = 0;
>>>
>>> -    ByteBuffer byteBuffer = ByteBuffer.allocateDirect(buf.length);
>>> -    byteBuffer.put(buf);
>>> -    return byteBuffer;
>>> -    }
>>> -}
>>> \ No newline at end of file
>>> +            /* Reads all the bytes from the channel and stores them
>>> +              * in various buffer objects.
>>> +             */
>>> +            do {
>>> +                ByteBuffer b = ByteBuffer.allocateDirect(BUFFER_SIZE);
>>> +                read = ch.read(b);
>>> +
>>> +                if(read > 0) {
>>> +                    b.flip(); // make ready for reading later
>>> +                    list.add(b);
>>> +                    sum += read;
>>> +                }
>>> +            } while(read != -1);
>>> +
>>> +            /* If there is only one buffer used we do not
>>> +             * need to merge the data.
>>> +             */
>>> +            if(list.size() == 1) {
>>> +                return (ByteBuffer) list.get(0);
>>> +            }
>>> +
>>> +            ByteBuffer bb = ByteBuffer.allocateDirect(sum);
>>> +
>>> +          /* Merges all buffers into the Buffer bb */
>>> +            Iterator ite = list.iterator();
>>> +            while(ite.hasNext()){
>>> +                bb.put((ByteBuffer) ite.next());
>>> +            }
>>> +
>>> +            list.clear();
>>> +
>>> +            return bb;
>>> +    }
>>> +}
>>>  
>>>
>>
>>
>>
>> -------------------------------------------------------
>> This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
>> Tool for open source databases. Create drag-&-drop reports. Save time
>> by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
>> Download a FREE copy at http://www.intelliview.com/go/osdn_nl
>> _______________________________________________
>> sdljava-users mailing list
>> sdl...@li...
>> https://lists.sourceforge.net/lists/listinfo/sdljava-users
>>
>>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
> Tool for open source databases. Create drag-&-drop reports. Save time
> by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
> Download a FREE copy at http://www.intelliview.com/go/osdn_nl
> _______________________________________________
> sdljava-users mailing list
> sdl...@li...
> https://lists.sourceforge.net/lists/listinfo/sdljava-users

Re: [sdljava-users] Problem with SDLMixer

[Robert S. <the...@gm...>]

Hi.

Ivan Z. Ganza wrote:

> Sweet!  Thank you very much for the patch.  I have integrated this 
> code.  That is a really nice way to do it.  I was wracking my brain 
> for an elegant solution.

Well, one could make sure that the small buffers are really filled to 
their maximum before another one is allocated. If the 
ReadableByteChannel delivers a megabyte in chunks of 100 bytes then each 
small buffer wastes ~900 byte. This is not so nice but I think this can 
be fixed.

>
> Its been tested and the changes are committed to CVS.  I made one 
> small change which was to call order(ByteOrder.nativeOrder()) on the 
> byte buffers.  I think this is required in the case when the buffers 
> might be accessed from the C code.

I think we need some PPC-style hardware to test this. AFAIK the 
byteorder is only neccessary if Java would do non-byte sized accesses. 
Since ReadableByteChannel processes only bytes it should be ok.

>
> BTW:  let me know if you want dev access.  Or feel free to keep 
> sending me patches as you have them.
>
Thank you, but I think I have not enough time to contribute regularly 
(nor the knowledge about the Swig/SDL trickery). I keep sending patches 
to you instead. Now that sdljava's mixer library found its way into our 
game this may happen more often :-)

If you are interested in seeing (or better hearing) your binding at work 
try the latest JNLP of our game which is on the download page of our 
project page: freefodder.dev.java.net (the unstable link). Please read 
the last paragraph of the latest announcement which describes how to set 
the sound output to SDLMixer (or wait some days/weeks until I fixed the 
launcher app).

Btw: Could you add a version API? It would be nice to retrieve SDL's 
version and the version of the binding itself programmatically.

cu
Robert

Btw2: You may want to install a Wiki on your project page. I have seen 
that some statements are outdated (requirement for Java1.5 and SDLMixer 
1.2.*5*) and I know that updating the website is extremely boring and 
timeconsuming. :-)

> Also finally I have moved the location of BufferUtils to 
> src/sdljava/util;  it used to be in just "src" which was the wrong place.
>
> Thanks again!
> -Ivan/
>
> Robert Schuster wrote:
>
>> Great! That was the problem.
>>
>> Along with that I fixed the problem with the loading of URLs from the 
>> net (or arbitrary slow locations). The problem with your 
>> implementation was that you asserted that InputStream.available() 
>> returns the complete size of the stream. However available() returns 
>> only the amount of bytes that can be read without blocking.
>>
>> I fixed BufferUtil.readInputStream() in the following way:
>> I am reading the parts of the stream into separate ByteBuffers until 
>> the stream is really finished. Afterwards I merge the buffers into 
>> one big buffer and return that.
>> The implementation uses Channel.newChannel() to retrieve a 
>> ReadableByteChannel which allows a ByteBuffer for its read() method. 
>> The behavior of this method is otherwise the same as 
>> InputStream.read(). The important bit is that -1 is returned when the 
>> end of the stream is reached.
>>
>> I have attached the patch to this mail. Tell me if the list daemon 
>> rips it away to send it to you directly.
>>
>> If you are using BeanShell try this snippet as a proof of concept:
>>
>> import sdljava.*;
>> import sdljava.mixer.*;
>> SDLMain.init(SDLMain.SDL_INIT_AUDIO);
>> SDLMixer.openAudio(44100, SDLMixer.AUDIO_S16SYS, 2, 4096);
>> imc = SDLMixer.loadWAV(new 
>> URL("http://www.barbneal.com/wav/lucy/lucy01.wav"));
>> SDLMixer.playChannel(0, imc, 0);
>>
>> However you can add type information and make that a real Java class, 
>> too. :-)
>>
>> cu
>> Robert
>>
>> Btw: Thanks again for reviving the Java binding for SDL. sdljava is 
>> the first library that allows me to do portable sound output in Java 
>> without having to sacrifice other useful Java API (like resource 
>> loading system which is essential for JNLP!).
>>
>> Ivan Z. Ganza wrote:
>>
>>> Make sure you have at least SDL Mixer 1.2.6 as the Mix_LoadMUS_RW 
>>> was added for 1.2.6.  Its strange though that you were able to 
>>> compile if this function wasn't present.
>>>
>>> BTW I've found that loading over the network doesn't work, filebased 
>>> urls are fine though.  I need to find an example of the proper way 
>>> to load a byte stream from a URL....
>>>
>>> Let me know if this helped.
>>> -Ivan/
>>>
>>> Robert Schuster wrote:
>>>
>>>> Hi,
>>>> I wanted to try the new URL based loading of WAV file and was 
>>>> stopped by this:
>>>>
>>>> java.lang.UnsatisfiedLinkError: 
>>>> /home/rob/tmp/lwtest/libsdljava_mixer.so: 
>>>> /home/rob/tmp/lwtest/libsdljava_mixer.so: undefined symbol: 
>>>> Mix_LoadMUS_RW
>>>>        at java.lang.ClassLoader$NativeLibrary.load(Native Method)
>>>>        at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1586)
>>>>        at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1511)
>>>>        at java.lang.Runtime.loadLibrary0(Runtime.java:788)
>>>>        at java.lang.System.loadLibrary(System.java:834)
>>>>        at sdljava.mixer.SDLMixer.<clinit>(SDLMixer.java:1184)
>>>>
>>>> I took sdljava from CVS (01.22.05) and compiled all files (using 
>>>> Blackdown 1.4.2 for GNU/Linux).
>>>>
>>>> cu
>>>> Robert
>>>>
>>>>
>>>> -------------------------------------------------------
>>>> This SF.Net email is sponsored by: IntelliVIEW -- Interactive 
>>>> Reporting
>>>> Tool for open source databases. Create drag-&-drop reports. Save time
>>>> by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
>>>> Download a FREE copy at http://www.intelliview.com/go/osdn_nl
>>>> _______________________________________________
>>>> sdljava-users mailing list
>>>> sdl...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/sdljava-users
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> -------------------------------------------------------
>>> This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
>>> Tool for open source databases. Create drag-&-drop reports. Save time
>>> by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
>>> Download a FREE copy at http://www.intelliview.com/go/osdn_nl
>>> _______________________________________________
>>> sdljava-users mailing list
>>> sdl...@li...
>>> https://lists.sourceforge.net/lists/listinfo/sdljava-users
>>>
>>>
>> ------------------------------------------------------------------------
>>
>> Index: src/util/BufferUtil.java
>> ===================================================================
>> RCS file: /cvsroot/sdljava/sdljava/src/util/BufferUtil.java,v
>> retrieving revision 1.2
>> diff -u -r1.2 BufferUtil.java
>> --- src/util/BufferUtil.java    7 Jan 2005 03:11:49 -0000    1.2
>> +++ src/util/BufferUtil.java    22 Jan 2005 22:20:40 -0000
>> @@ -7,15 +7,23 @@
>> import java.net.URLConnection;
>> import java.net.MalformedURLException;
>> import java.nio.ByteBuffer;
>> +import java.nio.channels.Channels;
>> +import java.nio.channels.ReadableByteChannel;
>> +import java.util.Iterator;
>> +import java.util.List;
>> +import java.util.LinkedList;
>>
>> /**
>>  * Some usefull methods for reading URLs or streams and returning the 
>> data as Direct Buffers
>>  *
>> - * @author  Ivan Z. Ganza
>> + * @author Ivan Z. Ganza
>> + * @author Robert Schuster
>>  * @version $Id: BufferUtil.java,v 1.2 2005/01/07 03:11:49 ivan_ganza 
>> Exp $
>>  */
>> public class BufferUtil {
>>
>> +    private static final int BUFFER_SIZE = 1024;
>> +
>>     /**
>>      * Tries to open the given URL, get its input stream, returns the 
>> data in a <I><B>direct</I></B> ByteBuffer
>>      *
>> @@ -48,14 +56,48 @@
>>      * @exception IOException if an error occurs
>>      */
>>     public static ByteBuffer readInputStream(InputStream in) throws 
>> IOException {
>> -    int avail  = in.available();
>> -    byte buf[] = new byte[avail];
>> +            /* Converts the InputStream into a channels which allows
>> +             * us to read into a ByteBuffer.
>> +             */
>> +            ReadableByteChannel    ch = Channels.newChannel(in);
>> +   
>> +            // Creates a list that stores the intermediate buffers.
>> +            List list = new LinkedList();
>>
>> -    int read = in.read(buf);
>> -    if (read != avail) throw new IOException("needed to read: " + 
>> avail + " bytes, but actually read: " + read);
>> +            // A variable storing the accumulated size of the data.
>> +            int sum = 0, read = 0;
>>
>> -    ByteBuffer byteBuffer = ByteBuffer.allocateDirect(buf.length);
>> -    byteBuffer.put(buf);
>> -    return byteBuffer;
>> -    }
>> -}
>> \ No newline at end of file
>> +            /* Reads all the bytes from the channel and stores them
>> +              * in various buffer objects.
>> +             */
>> +            do {
>> +                ByteBuffer b = ByteBuffer.allocateDirect(BUFFER_SIZE);
>> +                read = ch.read(b);
>> +
>> +                if(read > 0) {
>> +                    b.flip(); // make ready for reading later
>> +                    list.add(b);
>> +                    sum += read;
>> +                }
>> +            } while(read != -1);
>> +
>> +            /* If there is only one buffer used we do not
>> +             * need to merge the data.
>> +             */
>> +            if(list.size() == 1) {
>> +                return (ByteBuffer) list.get(0);
>> +            }
>> +
>> +            ByteBuffer bb = ByteBuffer.allocateDirect(sum);
>> +
>> +          /* Merges all buffers into the Buffer bb */
>> +            Iterator ite = list.iterator();
>> +            while(ite.hasNext()){
>> +                bb.put((ByteBuffer) ite.next());
>> +            }
>> +
>> +            list.clear();
>> +
>> +            return bb;
>> +    }
>> +}
>>  
>>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
> Tool for open source databases. Create drag-&-drop reports. Save time
> by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
> Download a FREE copy at http://www.intelliview.com/go/osdn_nl
> _______________________________________________
> sdljava-users mailing list
> sdl...@li...
> https://lists.sourceforge.net/lists/listinfo/sdljava-users
>
>

Re: [sdljava-users] Problem with SDLMixer

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

Sweet!  Thank you very much for the patch.  I have integrated this 
code.  That is a really nice way to do it.  I was wracking my brain for 
an elegant solution.

Its been tested and the changes are committed to CVS.  I made one small 
change which was to call order(ByteOrder.nativeOrder()) on the byte 
buffers.  I think this is required in the case when the buffers might be 
accessed from the C code.

BTW:  let me know if you want dev access.  Or feel free to keep sending 
me patches as you have them.

Also finally I have moved the location of BufferUtils to 
src/sdljava/util;  it used to be in just "src" which was the wrong place.

Thanks again!
-Ivan/

Robert Schuster wrote:

> Great! That was the problem.
>
> Along with that I fixed the problem with the loading of URLs from the 
> net (or arbitrary slow locations). The problem with your 
> implementation was that you asserted that InputStream.available() 
> returns the complete size of the stream. However available() returns 
> only the amount of bytes that can be read without blocking.
>
> I fixed BufferUtil.readInputStream() in the following way:
> I am reading the parts of the stream into separate ByteBuffers until 
> the stream is really finished. Afterwards I merge the buffers into one 
> big buffer and return that.
> The implementation uses Channel.newChannel() to retrieve a 
> ReadableByteChannel which allows a ByteBuffer for its read() method. 
> The behavior of this method is otherwise the same as 
> InputStream.read(). The important bit is that -1 is returned when the 
> end of the stream is reached.
>
> I have attached the patch to this mail. Tell me if the list daemon 
> rips it away to send it to you directly.
>
> If you are using BeanShell try this snippet as a proof of concept:
>
> import sdljava.*;
> import sdljava.mixer.*;
> SDLMain.init(SDLMain.SDL_INIT_AUDIO);
> SDLMixer.openAudio(44100, SDLMixer.AUDIO_S16SYS, 2, 4096);
> imc = SDLMixer.loadWAV(new 
> URL("http://www.barbneal.com/wav/lucy/lucy01.wav"));
> SDLMixer.playChannel(0, imc, 0);
>
> However you can add type information and make that a real Java class, 
> too. :-)
>
> cu
> Robert
>
> Btw: Thanks again for reviving the Java binding for SDL. sdljava is 
> the first library that allows me to do portable sound output in Java 
> without having to sacrifice other useful Java API (like resource 
> loading system which is essential for JNLP!).
>
> Ivan Z. Ganza wrote:
>
>> Make sure you have at least SDL Mixer 1.2.6 as the Mix_LoadMUS_RW was 
>> added for 1.2.6.  Its strange though that you were able to compile if 
>> this function wasn't present.
>>
>> BTW I've found that loading over the network doesn't work, filebased 
>> urls are fine though.  I need to find an example of the proper way to 
>> load a byte stream from a URL....
>>
>> Let me know if this helped.
>> -Ivan/
>>
>> Robert Schuster wrote:
>>
>>> Hi,
>>> I wanted to try the new URL based loading of WAV file and was 
>>> stopped by this:
>>>
>>> java.lang.UnsatisfiedLinkError: 
>>> /home/rob/tmp/lwtest/libsdljava_mixer.so: 
>>> /home/rob/tmp/lwtest/libsdljava_mixer.so: undefined symbol: 
>>> Mix_LoadMUS_RW
>>>        at java.lang.ClassLoader$NativeLibrary.load(Native Method)
>>>        at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1586)
>>>        at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1511)
>>>        at java.lang.Runtime.loadLibrary0(Runtime.java:788)
>>>        at java.lang.System.loadLibrary(System.java:834)
>>>        at sdljava.mixer.SDLMixer.<clinit>(SDLMixer.java:1184)
>>>
>>> I took sdljava from CVS (01.22.05) and compiled all files (using 
>>> Blackdown 1.4.2 for GNU/Linux).
>>>
>>> cu
>>> Robert
>>>
>>>
>>> -------------------------------------------------------
>>> This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
>>> Tool for open source databases. Create drag-&-drop reports. Save time
>>> by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
>>> Download a FREE copy at http://www.intelliview.com/go/osdn_nl
>>> _______________________________________________
>>> sdljava-users mailing list
>>> sdl...@li...
>>> https://lists.sourceforge.net/lists/listinfo/sdljava-users
>>
>>
>>
>>
>>
>>
>> -------------------------------------------------------
>> This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
>> Tool for open source databases. Create drag-&-drop reports. Save time
>> by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
>> Download a FREE copy at http://www.intelliview.com/go/osdn_nl
>> _______________________________________________
>> sdljava-users mailing list
>> sdl...@li...
>> https://lists.sourceforge.net/lists/listinfo/sdljava-users
>>
>>
>------------------------------------------------------------------------
>
>Index: src/util/BufferUtil.java
>===================================================================
>RCS file: /cvsroot/sdljava/sdljava/src/util/BufferUtil.java,v
>retrieving revision 1.2
>diff -u -r1.2 BufferUtil.java
>--- src/util/BufferUtil.java	7 Jan 2005 03:11:49 -0000	1.2
>+++ src/util/BufferUtil.java	22 Jan 2005 22:20:40 -0000
>@@ -7,15 +7,23 @@
> import java.net.URLConnection;
> import java.net.MalformedURLException;
> import java.nio.ByteBuffer;
>+import java.nio.channels.Channels;
>+import java.nio.channels.ReadableByteChannel;
>+import java.util.Iterator;
>+import java.util.List;
>+import java.util.LinkedList;
> 
> /**
>  * Some usefull methods for reading URLs or streams and returning the data as Direct Buffers
>  *
>- * @author  Ivan Z. Ganza
>+ * @author Ivan Z. Ganza
>+ * @author Robert Schuster
>  * @version $Id: BufferUtil.java,v 1.2 2005/01/07 03:11:49 ivan_ganza Exp $
>  */
> public class BufferUtil {
> 
>+	private static final int BUFFER_SIZE = 1024;
>+
>     /**
>      * Tries to open the given URL, get its input stream, returns the data in a <I><B>direct</I></B> ByteBuffer
>      *
>@@ -48,14 +56,48 @@
>      * @exception IOException if an error occurs
>      */
>     public static ByteBuffer readInputStream(InputStream in) throws IOException {
>-	int avail  = in.available();
>-	byte buf[] = new byte[avail];
>+			/* Converts the InputStream into a channels which allows
>+			 * us to read into a ByteBuffer.
>+			 */
>+			ReadableByteChannel	ch = Channels.newChannel(in);
>+	
>+			// Creates a list that stores the intermediate buffers.
>+			List list = new LinkedList();
> 
>-	int read = in.read(buf);
>-	if (read != avail) throw new IOException("needed to read: " + avail + " bytes, but actually read: " + read);
>+			// A variable storing the accumulated size of the data.
>+			int sum = 0, read = 0;
> 
>-	ByteBuffer byteBuffer = ByteBuffer.allocateDirect(buf.length);
>-	byteBuffer.put(buf);
>-	return byteBuffer;
>-    }
>-}
>\ No newline at end of file
>+			/* Reads all the bytes from the channel and stores them
>+ 			 * in various buffer objects.
>+			 */
>+			do {
>+				ByteBuffer b = ByteBuffer.allocateDirect(BUFFER_SIZE);
>+				read = ch.read(b);
>+
>+				if(read > 0) {
>+					b.flip(); // make ready for reading later
>+					list.add(b);
>+					sum += read;
>+				}
>+			} while(read != -1);
>+
>+			/* If there is only one buffer used we do not
>+			 * need to merge the data.
>+			 */
>+			if(list.size() == 1) {
>+				return (ByteBuffer) list.get(0);
>+			}
>+
>+			ByteBuffer bb = ByteBuffer.allocateDirect(sum);
>+
>+  		/* Merges all buffers into the Buffer bb */
>+			Iterator ite = list.iterator();
>+			while(ite.hasNext()){
>+				bb.put((ByteBuffer) ite.next());
>+			}
>+
>+			list.clear();
>+
>+			return bb;
>+	}
>+}
>  
>

Re: [sdljava-users] Problem with SDLMixer

[Robert S. <the...@gm...>]

Great! That was the problem.

Along with that I fixed the problem with the loading of URLs from the 
net (or arbitrary slow locations). The problem with your implementation 
was that you asserted that InputStream.available() returns the complete 
size of the stream. However available() returns only the amount of bytes 
that can be read without blocking.

I fixed BufferUtil.readInputStream() in the following way:
I am reading the parts of the stream into separate ByteBuffers until the 
stream is really finished. Afterwards I merge the buffers into one big 
buffer and return that.
The implementation uses Channel.newChannel() to retrieve a 
ReadableByteChannel which allows a ByteBuffer for its read() method. The 
behavior of this method is otherwise the same as InputStream.read(). The 
important bit is that -1 is returned when the end of the stream is reached.

I have attached the patch to this mail. Tell me if the list daemon rips 
it away to send it to you directly.

If you are using BeanShell try this snippet as a proof of concept:

import sdljava.*;
import sdljava.mixer.*;
SDLMain.init(SDLMain.SDL_INIT_AUDIO);
SDLMixer.openAudio(44100, SDLMixer.AUDIO_S16SYS, 2, 4096);
imc = SDLMixer.loadWAV(new 
URL("http://www.barbneal.com/wav/lucy/lucy01.wav"));
SDLMixer.playChannel(0, imc, 0);

However you can add type information and make that a real Java class, 
too. :-)

cu
Robert

Btw: Thanks again for reviving the Java binding for SDL. sdljava is the 
first library that allows me to do portable sound output in Java without 
having to sacrifice other useful Java API (like resource loading system 
which is essential for JNLP!).

Ivan Z. Ganza wrote:

> Make sure you have at least SDL Mixer 1.2.6 as the Mix_LoadMUS_RW was 
> added for 1.2.6.  Its strange though that you were able to compile if 
> this function wasn't present.
>
> BTW I've found that loading over the network doesn't work, filebased 
> urls are fine though.  I need to find an example of the proper way to 
> load a byte stream from a URL....
>
> Let me know if this helped.
> -Ivan/
>
> Robert Schuster wrote:
>
>> Hi,
>> I wanted to try the new URL based loading of WAV file and was stopped 
>> by this:
>>
>> java.lang.UnsatisfiedLinkError: 
>> /home/rob/tmp/lwtest/libsdljava_mixer.so: 
>> /home/rob/tmp/lwtest/libsdljava_mixer.so: undefined symbol: 
>> Mix_LoadMUS_RW
>>        at java.lang.ClassLoader$NativeLibrary.load(Native Method)
>>        at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1586)
>>        at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1511)
>>        at java.lang.Runtime.loadLibrary0(Runtime.java:788)
>>        at java.lang.System.loadLibrary(System.java:834)
>>        at sdljava.mixer.SDLMixer.<clinit>(SDLMixer.java:1184)
>>
>> I took sdljava from CVS (01.22.05) and compiled all files (using 
>> Blackdown 1.4.2 for GNU/Linux).
>>
>> cu
>> Robert
>>
>>
>> -------------------------------------------------------
>> This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
>> Tool for open source databases. Create drag-&-drop reports. Save time
>> by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
>> Download a FREE copy at http://www.intelliview.com/go/osdn_nl
>> _______________________________________________
>> sdljava-users mailing list
>> sdl...@li...
>> https://lists.sourceforge.net/lists/listinfo/sdljava-users
>
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
> Tool for open source databases. Create drag-&-drop reports. Save time
> by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
> Download a FREE copy at http://www.intelliview.com/go/osdn_nl
> _______________________________________________
> sdljava-users mailing list
> sdl...@li...
> https://lists.sourceforge.net/lists/listinfo/sdljava-users
>
>

Re: [sdljava-users] Problem with SDLMixer

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

Make sure you have at least SDL Mixer 1.2.6 as the Mix_LoadMUS_RW was 
added for 1.2.6.  Its strange though that you were able to compile if 
this function wasn't present.

BTW I've found that loading over the network doesn't work, filebased 
urls are fine though.  I need to find an example of the proper way to 
load a byte stream from a URL....

Let me know if this helped.
-Ivan/

Robert Schuster wrote:

> Hi,
> I wanted to try the new URL based loading of WAV file and was stopped 
> by this:
>
> java.lang.UnsatisfiedLinkError: 
> /home/rob/tmp/lwtest/libsdljava_mixer.so: 
> /home/rob/tmp/lwtest/libsdljava_mixer.so: undefined symbol: 
> Mix_LoadMUS_RW
>        at java.lang.ClassLoader$NativeLibrary.load(Native Method)
>        at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1586)
>        at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1511)
>        at java.lang.Runtime.loadLibrary0(Runtime.java:788)
>        at java.lang.System.loadLibrary(System.java:834)
>        at sdljava.mixer.SDLMixer.<clinit>(SDLMixer.java:1184)
>
> I took sdljava from CVS (01.22.05) and compiled all files (using 
> Blackdown 1.4.2 for GNU/Linux).
>
> cu
> Robert
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
> Tool for open source databases. Create drag-&-drop reports. Save time
> by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
> Download a FREE copy at http://www.intelliview.com/go/osdn_nl
> _______________________________________________
> sdljava-users mailing list
> sdl...@li...
> https://lists.sourceforge.net/lists/listinfo/sdljava-users

[sdljava-users] Problem with SDLMixer

[Robert S. <the...@gm...>]

Hi,
I wanted to try the new URL based loading of WAV file and was stopped by 
this:

java.lang.UnsatisfiedLinkError: 
/home/rob/tmp/lwtest/libsdljava_mixer.so: 
/home/rob/tmp/lwtest/libsdljava_mixer.so: undefined symbol: Mix_LoadMUS_RW
        at java.lang.ClassLoader$NativeLibrary.load(Native Method)
        at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1586)
        at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1511)
        at java.lang.Runtime.loadLibrary0(Runtime.java:788)
        at java.lang.System.loadLibrary(System.java:834)
        at sdljava.mixer.SDLMixer.<clinit>(SDLMixer.java:1184)

I took sdljava from CVS (01.22.05) and compiled all files (using 
Blackdown 1.4.2 for GNU/Linux).

cu
Robert

[sdljava-users] OpenGL 1.1 support added!!

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

I've checked in code into CVS which adds an opengl 1.1 binding to 
sdljava!!  Later version of OpenGL coming soon.

The binding is provided by wrapping GLEW (http://glew.sourceforge.net).  
GLEW is a library which handles all the specifics of the OpenGL 
support.  GLEW is available for a vast number of platforms.

Currently I've only updated the linux Makefile to build the shared 
library (gljava).  It should be trivial to compile under Windows if the 
same idea if followed as the linux Makefile.  I will be updating the 
Windows scripts in the future.

Two new methods were added to SDLSurface:
    public GL getGL() throws SDLException
       - will return an instance of GL interface IF the surface has 
SDL_OPENGL set.  The surface must be a framebuffer surface and must have 
been initialize with SDL_OPENGL

    public void glSwapBuffers()
        - will swap the OpenGL buffer

There are also two (simple) example of how to use it in:  
testsrc/org/gljava/opengl directory

Finally I have created a separate sourceforge project for the binding 
called:  gljava (gljava.sourceforge.net).  The idea is that I want to 
provide a generic opengl binding for java that does not depend on sdl.  
The gljava project will offer this. 

sdljava will always contain the latest gljava code and be distributed 
with it so sdljava will always provide an opengl binding.

This will be integrated into the next release.

Thanks.  Please let me know any feedback.

-Ivan/
   

[sdljava-users] CVS compile problem fixed (Missing SDLMain.java)

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

There was a problem which would prevent compilation of the java files in 
CVS.  The SDLMain.java source file was mistakingly not included.  This 
has been fixed and compilation works fine when checking out the code 
from CVS.

Sorry about this problem.

Thanks,
-Ivan/

[sdljava-users] JDK 1.5 no longer required (CVS updated)

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

Greetings!

I wanted to let you know that I've checked in code which breaks the 
dependency on JDK 1.5.  sdljava is now usable with 1.4 or greater VM!

This will be included in the next release.

cheers,
-Ivan/

Re: [sdljava-users] Upcoming Features

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

Robert Schuster wrote.

> Ivan Z. Ganza wrote:
>
>>
>> This should allow one to use these modules more naturally from java.  
>> I've already got it working for loadWAV using SDL_RWops on the C side 
>> and it works perfectly.  Thanks to Robert Schuster for the suggestion.
>
>
> This is pretty cool!
> Does your implementation rely on direct byte buffers (ie. it will fail 
> when on some ByteBuffer b b.isDirect() returns false)?
>
> And does it rely upon full JNI compliance? In a JNI library of my own 
> using direct buffers I am doing this check first:
>
> JNIEXPORT jboolean JNICALL 
> Java_de_bitecode_input_linux_impl_core_LinuxEventDevice  (JNIEnv *env, 
> jobject object, jobject buffer) {
>        return (jboolean) ((*env)->GetDirectBufferAddress(env, buffer) 
> != NULL);
> }
>
> This is because JNI specification allows to return NULL on each call. 
> That means that the VM has no direct buffer capabality.
> AFAIK Free Java VMs lack this kind of functionality yet. It would be a 
> good idea if you mention that somewhere in the docs.
> In the meantime I try to find out which Free VMs support it.


Yes I'm using direct buffers!  And it WILL fail if isDirect() returns 
false.  Thanks to your suggestion I wasn't even aware of them.  Now I 
see they are the greatest thing for java-->native integration.  I didn't 
think about the case where the VM might not support them.  I'll mention 
this in the docs.

>
>> I'm also planning to implement SDLSurface.updateRects(...) in a much 
>> faster way using Direct buffers.  Finally there will be a few new 
>> methods added called queueBlit(...) and queueUpdateRect(...).  What 
>> they will do is basically allow one to "queue" blits or updates, then 
>> later call either flushBlits() or flushUpdates() to send them to the 
>> native layer and have ALL the blits or updates processed at one time 
>> in C.  So for example if you did 100 blits normally that would be 100 
>> separate JNI calls.  In this case it will mean one JNI to do all 100 
>> updates.  I believe this should produce performance near to that 
>> which can now be achieved in C code.
>
>
> That is definitely a good idea!
>
>> Oh and I've been able to get a full OpenGL binding working via the 
>> import of the opengl from the Lightweight Java Game Library -- 
>> http://www.lwjgl.org/.
>
>
> Cool LWJGL goes SDL! Does this mean that the LWJGL Window's key and 
> mouse events are routed to SDL's input system?


No actually I don't initialize any part of LWJGL except for the OpenGL 
subsystem.  Everything else is still handled by SDL.

>
>> Actually needed to slightly hack the jar file to make a few methods 
>> public, however, I am able to use their opengl binding so far without 
>> any troubles.  I'm not sure that I want to stick with this forever 
>> due to certain aspects of its design, but, for now we would have the 
>> capability to fully utilize opengl from sdljava.  I'm not sure that 
>> this will make it into next release but if anyone really needs to use 
>> opengl in this way please let me know.
>>
> I wonder whether it would make sense to ask the LWJGL team about 
> making a specific API to make the LWJGL-sdljava integration a stable 
> feature. Anyway SDL is ported to far more platforms than LWJGL and 
> they could save a lot of development time by relying on SDL or at 
> least please the developers who want the later.


I've been seriously thinking about this!  It really would make much 
sense to offload all the things from LWJGL that SDL already has.  Its 
ported to many more platforms and its very stable.  They could offload 
all that work and concentrate on more important things.  I'm not sure 
how receptive they would be to this.  I will have to post in their forum 
and see what comes of it.

There is a problem with LWJGL OpenGL implementation though.  This is the 
fact that you access the OpenGL subsystem in a static way, eg:  
GL11.glBegin()

This really needs to be behind an interface that you get in some way.  
For instance I would like to have a method on SDLSurface such as:
    public GL getOpenGLContext()

Where you call this on a framebuffer (or window/visible type surface) 
and you get back the GL interface which has all the appropriate OpenGL 
methods on it.  We CAN do this will LWJGL but it imposes one extra 
method call each time as the GL would delegate out to the static GL11 
class.  Another really important reason to have the GL interface is that 
you can support the idea of "composable" which was implemented by the 
old Magician binding and currently by jogl.  Using this you can wrap the 
GL interface with a DebugGL which checks for error on each of your 
OpenGL calls.  If it finds one it throws an exception with the error and 
you can see in the stack trace the precise line where your OpenGL error 
occured.

One another note I found a neat project called GLee 
(http://elf-stone.com/glee.php).  This is also a possibility for 
supporting open gl.

So many ways to evaluate, so little time....In any case when it is added 
to sdljava it will be behind an interface so we could substitue other 
implementations later if need be.

If anyone might have a pointer who I can contact at LWJGL please let me 
know.

Cheers,
-Ivan/

>
>
>
> cu
> Robert
>
>
> -------------------------------------------------------
> The SF.Net email is sponsored by: Beat the post-holiday blues
> Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
> It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
> _______________________________________________
> sdljava-users mailing list
> sdl...@li...
> https://lists.sourceforge.net/lists/listinfo/sdljava-users

Re: [sdljava-users] Upcoming Features

[Robert S. <the...@gm...>]

Hi.

Ivan Z. Ganza wrote:

>
>
> This should allow one to use these modules more naturally from java.  
> I've already got it working for loadWAV using SDL_RWops on the C side 
> and it works perfectly.  Thanks to Robert Schuster for the suggestion.

This is pretty cool!
Does your implementation rely on direct byte buffers (ie. it will fail 
when on some ByteBuffer b b.isDirect() returns false)?

And does it rely upon full JNI compliance? In a JNI library of my own 
using direct buffers I am doing this check first:

JNIEXPORT jboolean JNICALL 
Java_de_bitecode_input_linux_impl_core_LinuxEventDevice  (JNIEnv *env, 
jobject object, jobject buffer) {
        return (jboolean) ((*env)->GetDirectBufferAddress(env, buffer) 
!= NULL);
}

This is because JNI specification allows to return NULL on each call. 
That means that the VM has no direct buffer capabality.
AFAIK Free Java VMs lack this kind of functionality yet. It would be a 
good idea if you mention that somewhere in the docs.
In the meantime I try to find out which Free VMs support it.

> I'm also planning to implement SDLSurface.updateRects(...) in a much 
> faster way using Direct buffers.  Finally there will be a few new 
> methods added called queueBlit(...) and queueUpdateRect(...).  What 
> they will do is basically allow one to "queue" blits or updates, then 
> later call either flushBlits() or flushUpdates() to send them to the 
> native layer and have ALL the blits or updates processed at one time 
> in C.  So for example if you did 100 blits normally that would be 100 
> separate JNI calls.  In this case it will mean one JNI to do all 100 
> updates.  I believe this should produce performance near to that which 
> can now be achieved in C code.

That is definitely a good idea!

> Oh and I've been able to get a full OpenGL binding working via the 
> import of the opengl from the Lightweight Java Game Library -- 
> http://www.lwjgl.org/.

Cool LWJGL goes SDL! Does this mean that the LWJGL Window's key and 
mouse events are routed to SDL's input system?

> Actually needed to slightly hack the jar file to make a few methods 
> public, however, I am able to use their opengl binding so far without 
> any troubles.  I'm not sure that I want to stick with this forever due 
> to certain aspects of its design, but, for now we would have the 
> capability to fully utilize opengl from sdljava.  I'm not sure that 
> this will make it into next release but if anyone really needs to use 
> opengl in this way please let me know.
>
I wonder whether it would make sense to ask the LWJGL team about making 
a specific API to make the LWJGL-sdljava integration a stable feature. 
Anyway SDL is ported to far more platforms than LWJGL and they could 
save a lot of development time by relying on SDL or at least please the 
developers who want the later.


cu
Robert

[sdljava-users] Upcoming Features

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

Greetings,

I wanted to update you on features that will be in the next release. 

I'm adding a set of methods to SDLImage, SDLMixer and SDLTTF so that 
each module can load images, wav, music or ttf files like so:

    SDLImage.load(byte[] data)
    SDLImage.load(URL url)
    SDLImage.load(ByteBuffer data)

    SDLMixer.loadWAV(byte[] data)
    SDLMixer.loadWAV(URL url)
    SDLMixer.loadWAV(ByteBuffer data)
    SDLMixer.loadMUS(byte[] data)
    SDLMixer.loadMUS(URL url)
    SDLMixer.loadMUS(ByteBuffer data)

    SDLTTF.openFont(byte[] data)
    SDLTTF.openFont(URL url)
    SDLTTF.openFont(ByteBuffer data)

This should allow one to use these modules more naturally from java.  
I've already got it working for loadWAV using SDL_RWops on the C side 
and it works perfectly.  Thanks to Robert Schuster for the suggestion. 

I'm also planning to implement SDLSurface.updateRects(...) in a much 
faster way using Direct buffers.  Finally there will be a few new 
methods added called queueBlit(...) and queueUpdateRect(...).  What they 
will do is basically allow one to "queue" blits or updates, then later 
call either flushBlits() or flushUpdates() to send them to the native 
layer and have ALL the blits or updates processed at one time in C.  So 
for example if you did 100 blits normally that would be 100 separate JNI 
calls.  In this case it will mean one JNI to do all 100 updates.  I 
believe this should produce performance near to that which can now be 
achieved in C code.

Oh and I've been able to get a full OpenGL binding working via the 
import of the opengl from the Lightweight Java Game Library -- 
http://www.lwjgl.org/.  Actually needed to slightly hack the jar file to 
make a few methods public, however, I am able to use their opengl 
binding so far without any troubles.  I'm not sure that I want to stick 
with this forever due to certain aspects of its design, but, for now we 
would have the capability to fully utilize opengl from sdljava.  I'm not 
sure that this will make it into next release but if anyone really needs 
to use opengl in this way please let me know.

Next release should be in about one month.

Please let me know any suggestions, comments or questions.

Thanks,
-Ivan/

Re: [sdljava-users] Announcing sdljava-0.9.0

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

A few people have mentioned this.  It never really occurred to me but I 
see now that choosing to limit to 1.5.0 or greater was not a good 
choice.  sdljava will be changed to work with java 1.4 or higher.  We'll 
loose the enums and the use of the generics in the lists but this is 
done only in a few places and its not much of a loss compared to the 
much greater compatibility gained.

Thanks for the feedback,
-Ivan/

Robert Schuster wrote:

> Hello Ivan,
> thanks for taking over jsdl! sdljava looks very promising and I am 
> going to write an output layer for it in our game 
> (freefodder.dev.java.net)
>
> Unfortunately, I hoped to escape the Java trap by using a Java binding 
> to SDL but sdljava needs at least JDK 1.5.0 . Are you
> planning to support 1.4 at a later time?
> I know that Java5 is now officially released but it will take a long 
> time before GNU Classpath, the Free java class library, (where I am 
> helping out)
> will support 1.5 features. Until that time our game relies on non-Free 
> software and cannot being run by people who care about their software 
> freedom.
>
> Nevertheless I greatly appreciate your effort!
>
> cu
> Robert
>
>
> Ivan Z. Ganza wrote:
>
>> Hello everyone,
>>
>> I'm happy to announce the release of sdljava 0.9.0!  sdljava is a
>> binding to the SDL API for java.
>>
>> You can find it here:
>>    http://sdljava.sourceforge.net
>>
>> sdljava provides a complete binding to all the SDL API functions.
>> Almost the entire binding has been implemented.  Please see the TODO
>> for a list of what is still pending.
>>       Required/Recommended Libraries: (higher version should be fine)
>>
>>     - Java 1.5
>>     - SDL 1.2.7
>>         - SDL_image 1.2.3 (optional)
>>     - SDL_mixer 1.2.5 (optional)
>>     - SDL_ttf 2.0.6   (optional)
>>     - SDL_gfx 2.0.13  (optional)
>>     - Ant 1.6.2       (optional, only if you need to compile
>>               sdljava.jar)
>>     - ruby 1.8.2      (optional, only if you want to re-generate
>>               native layer)
>>     - SWIG 1.3.22     (optional, only if you want to re-generate
>>               native layer)
>>
>>
>> Please let me know any questions, comments or feedback.  I hope you
>> will find this useful!
>>
>> Regards,
>> -Ivan/
>>
>>
>> -------------------------------------------------------
>> The SF.Net email is sponsored by: Beat the post-holiday blues
>> Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
>> It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
>> _______________________________________________
>> sdljava-users mailing list
>> sdl...@li...
>> https://lists.sourceforge.net/lists/listinfo/sdljava-users
>>
>>
>
>
> -------------------------------------------------------
> The SF.Net email is sponsored by: Beat the post-holiday blues
> Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
> It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
> _______________________________________________
> sdljava-users mailing list
> sdl...@li...
> https://lists.sourceforge.net/lists/listinfo/sdljava-users

Re: [sdljava-users] feature request: better Java integration

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

Robert,

Thanks for the feedback.  This is a really good point!  I agree that 
this type of change should be made and that the NIO package should be 
used.  I will add it to the list of whats going to be done.

-Ivan/

Robert Schuster wrote:

> Hi Ivan,
> I have been playing around with sdljava and thought about the 
> following problem: The SDLMixer API allows me to read WAV and MUS 
> files only from the local filesystem. However a typical Java 
> application loads its resources from streams or out of a JAR file 
> (using the ClassLoader).
>
> My suggestion is to use the so-called direct buffers from the NIO 
> package (since 1.4). These are buffers in native memory which can be 
> shared by Java and SDL. Direct buffers are pretty famous for doing all 
> kind of native<->Java interaction (e.g. OpenGL bindings use them 
> extensively) maybe they are of use here, too :)
>
> cu
> Robert
>
> Btw: Same kind of problem arises in the SDLImage API.
>
>
> -------------------------------------------------------
> The SF.Net email is sponsored by: Beat the post-holiday blues
> Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
> It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
> _______________________________________________
> sdljava-users mailing list
> sdl...@li...
> https://lists.sourceforge.net/lists/listinfo/sdljava-users

[sdljava-users] feature request: better Java integration

[Robert S. <the...@gm...>]

Hi Ivan,
I have been playing around with sdljava and thought about the following 
problem: The SDLMixer API allows me to read WAV and MUS files only from 
the local filesystem. However a typical Java application loads its 
resources from streams or out of a JAR file (using the ClassLoader).

My suggestion is to use the so-called direct buffers from the NIO 
package (since 1.4). These are buffers in native memory which can be 
shared by Java and SDL. Direct buffers are pretty famous for doing all 
kind of native<->Java interaction (e.g. OpenGL bindings use them 
extensively) maybe they are of use here, too :)

cu
Robert

Btw: Same kind of problem arises in the SDLImage API.

Re: [sdljava-users] Announcing sdljava-0.9.0

[Robert S. <the...@gm...>]

Hello Ivan,
thanks for taking over jsdl! sdljava looks very promising and I am going 
to write an output layer for it in our game (freefodder.dev.java.net)

Unfortunately, I hoped to escape the Java trap by using a Java binding 
to SDL but sdljava needs at least JDK 1.5.0 . Are you
planning to support 1.4 at a later time?
I know that Java5 is now officially released but it will take a long 
time before GNU Classpath, the Free java class library, (where I am 
helping out)
will support 1.5 features. Until that time our game relies on non-Free 
software and cannot being run by people who care about their software 
freedom.

Nevertheless I greatly appreciate your effort!

cu
Robert


Ivan Z. Ganza wrote:

> Hello everyone,
>
> I'm happy to announce the release of sdljava 0.9.0!  sdljava is a
> binding to the SDL API for java.
>
> You can find it here:
>    http://sdljava.sourceforge.net
>
> sdljava provides a complete binding to all the SDL API functions.
> Almost the entire binding has been implemented.  Please see the TODO
> for a list of what is still pending.
>       Required/Recommended Libraries: (higher version should be fine)
>
>     - Java 1.5
>     - SDL 1.2.7
>         - SDL_image 1.2.3 (optional)
>     - SDL_mixer 1.2.5 (optional)
>     - SDL_ttf 2.0.6   (optional)
>     - SDL_gfx 2.0.13  (optional)
>     - Ant 1.6.2       (optional, only if you need to compile
>               sdljava.jar)
>     - ruby 1.8.2      (optional, only if you want to re-generate
>               native layer)
>     - SWIG 1.3.22     (optional, only if you want to re-generate
>               native layer)
>
>
> Please let me know any questions, comments or feedback.  I hope you
> will find this useful!
>
> Regards,
> -Ivan/
>
>
> -------------------------------------------------------
> The SF.Net email is sponsored by: Beat the post-holiday blues
> Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
> It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
> _______________________________________________
> sdljava-users mailing list
> sdl...@li...
> https://lists.sourceforge.net/lists/listinfo/sdljava-users
>
>

[sdljava-users] Announcing sdljava-0.9.0

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

Hello everyone,

I'm happy to announce the release of sdljava 0.9.0!  sdljava is a
binding to the SDL API for java.

You can find it here:
    http://sdljava.sourceforge.net

sdljava provides a complete binding to all the SDL API functions.
Almost the entire binding has been implemented.  Please see the TODO
for a list of what is still pending.
       
Required/Recommended Libraries: (higher version should be fine)

     - Java 1.5
     - SDL 1.2.7
     
     - SDL_image 1.2.3 (optional)
     - SDL_mixer 1.2.5 (optional)
     - SDL_ttf 2.0.6   (optional)
     - SDL_gfx 2.0.13  (optional)
     - Ant 1.6.2       (optional, only if you need to compile
               sdljava.jar)
     - ruby 1.8.2      (optional, only if you want to re-generate
               native layer)
     - SWIG 1.3.22     (optional, only if you want to re-generate
               native layer)


Please let me know any questions, comments or feedback.  I hope you
will find this useful!

Regards,
-Ivan/