sdljava-users — General Discussion about sdljava and gljava

Re: [sdljava-users] Anyone using get/setPixelDataXX()?

[S. Meslin-W. <st...@ta...>]

Hi Ivan,

Thought so - for some reason the native dir hadn't been updated on my
tree so I thought you'd forgotten to push your changes... woops! :)

I recompiled the dll (and the java code of course) and now I get an SDL
window for a fraction of a second before the JVM crashes; and without
any error messages or log files.

I'm a bit stumped as JNI is definately beyond my skills - is there
anything I can do on my end to speed up the debugging?

Thanks,

Steph

On Wed, Jul 20, 2005 at 05:52:07PM -0400, Ivan Z. Ganza wrote:
> Hi Steph,
>=20
> Yes you need to rebuild the sdljava.dll because the native layer code
> changed.  As well as recompilation of SDLSurface.java source file.
>=20
> The files that changed were:
>=20
> -- native layer
>     SDLVideo.i
>     SDLVideo_wrap.c
>=20
> - java layer
>     SDLSurface.java
>=20
> So I regenerated the wrapper file but new shared libraries/dlls need to
> be generated.
>=20
> -Ivan/
>=20
> S. Meslin-Weber wrote:
>=20
> >Hi Ivan,
> >
> >Thanks for looking into this :)
> >
> >I've checked out head from cvs but with my existing .dll the jvm dies;
> >have I missed a step? Wouldn't this kind of change mean regenerating
> >some of the SWIG java and native files?
> >
> >Cheers,
> >
> >Steph
> >
> >
> >On Tue, Jul 19, 2005 at 06:36:59PM -0400, Ivan Z. Ganza wrote:
> > =20
> >
> >>Greetings,
> >>
> >>I've changed the get/setPixelData32 methods to use int[] instead of
> >>long[].  Please let me know if this is working properly.  I didn't have
> >>a chance to test it...
> >>
> >>If we find this to be good I'll adjust the other two methods in the same
> >>way.  Also I saw one thing that could be optimized which I will also do.
> >>
> >>So we should end up with:
> >>
> >>    get/setPixelData8   --> byte[]
> >>    get/setPixelData16 --> short[]
> >>    get/setPixelData32 --> int[]
> >>
> >>Nothing else anywhere will be affected by this.
> >>
> >>Let me know any comments...
> >>
> >>-Ivan/
> >>
> >>S. Meslin-Weber wrote:
> >>
> >>   =20
> >>
> >>>Hi everyone,
> >>>
> >>>I'm cleaning up some code in Odonata and in the sdljava provider I've
> >>>found that I use get/setPixelData32(long[]). Would it be possible to
> >>>rationalise the types used for these methods? Does anyone still use
> >>>them?
> >>>
> >>>long[]  64 bit colour data
> >>>int[]   32 ...
> >>>short[] 16 ...
> >>>byte[]   8 ...
> >>>
> >>>Essentially it'd mean changing the signatures for the get/set methods =
to
> >>>match the bit sizes they're operating with.
> >>>
> >>>I've seen the gradual move to using ByteBuffer and Buffers in general.=
=2E.
> >>>Odonata intends to work with JVM versions 1.1+ so those classes wouldn=
't
> >>>necessarily be available on those targets :)
> >>>
> >>>Cheers,
> >>>
> >>>Steph
> >>>
> >>>=20
> >>>
> >>>     =20
> >>>
> >>
> >>-------------------------------------------------------
> >>SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> >>from IBM. Find simple to follow Roadmaps, straightforward articles,
> >>informative Webcasts and more! Get everything you need to get up to
> >>speed, fast. http://ads.osdn.com/?ad_id=3D7477&alloc_id=3D16492&op=3Dcl=
ick
> >>_______________________________________________
> >>sdljava-users mailing list
> >>sdl...@li...
> >>https://lists.sourceforge.net/lists/listinfo/sdljava-users
> >>   =20
> >>
> >
> > =20
> >
>=20
>=20
>=20
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=3D7477&alloc_id=3D16492&op=3Dclick
> _______________________________________________
> sdljava-users mailing list
> sdl...@li...
> https://lists.sourceforge.net/lists/listinfo/sdljava-users

--=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Stephane Meslin-Weber         Email: st...@ta...
Senior Software Engineer      Web: http://odonata.tangency.co.uk
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Re: [sdljava-users] Anyone using get/setPixelDataXX()?

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

Hi Steph,

Yes you need to rebuild the sdljava.dll because the native layer code
changed.  As well as recompilation of SDLSurface.java source file.

The files that changed were:

-- native layer
    SDLVideo.i
    SDLVideo_wrap.c

- java layer
    SDLSurface.java

So I regenerated the wrapper file but new shared libraries/dlls need to
be generated.

-Ivan/

S. Meslin-Weber wrote:

>Hi Ivan,
>
>Thanks for looking into this :)
>
>I've checked out head from cvs but with my existing .dll the jvm dies;
>have I missed a step? Wouldn't this kind of change mean regenerating
>some of the SWIG java and native files?
>
>Cheers,
>
>Steph
>
>
>On Tue, Jul 19, 2005 at 06:36:59PM -0400, Ivan Z. Ganza wrote:
>  
>
>>Greetings,
>>
>>I've changed the get/setPixelData32 methods to use int[] instead of
>>long[].  Please let me know if this is working properly.  I didn't have
>>a chance to test it...
>>
>>If we find this to be good I'll adjust the other two methods in the same
>>way.  Also I saw one thing that could be optimized which I will also do.
>>
>>So we should end up with:
>>
>>    get/setPixelData8   --> byte[]
>>    get/setPixelData16 --> short[]
>>    get/setPixelData32 --> int[]
>>
>>Nothing else anywhere will be affected by this.
>>
>>Let me know any comments...
>>
>>-Ivan/
>>
>>S. Meslin-Weber wrote:
>>
>>    
>>
>>>Hi everyone,
>>>
>>>I'm cleaning up some code in Odonata and in the sdljava provider I've
>>>found that I use get/setPixelData32(long[]). Would it be possible to
>>>rationalise the types used for these methods? Does anyone still use
>>>them?
>>>
>>>long[]  64 bit colour data
>>>int[]   32 ...
>>>short[] 16 ...
>>>byte[]   8 ...
>>>
>>>Essentially it'd mean changing the signatures for the get/set methods to
>>>match the bit sizes they're operating with.
>>>
>>>I've seen the gradual move to using ByteBuffer and Buffers in general...
>>>Odonata intends to work with JVM versions 1.1+ so those classes wouldn't
>>>necessarily be available on those targets :)
>>>
>>>Cheers,
>>>
>>>Steph
>>>
>>> 
>>>
>>>      
>>>
>>
>>-------------------------------------------------------
>>SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
>>from IBM. Find simple to follow Roadmaps, straightforward articles,
>>informative Webcasts and more! Get everything you need to get up to
>>speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
>>_______________________________________________
>>sdljava-users mailing list
>>sdl...@li...
>>https://lists.sourceforge.net/lists/listinfo/sdljava-users
>>    
>>
>
>  
>

Re: [sdljava-users] Anyone using get/setPixelDataXX()?

[S. Meslin-W. <st...@ta...>]

Hi Ivan,

Thanks for looking into this :)

I've checked out head from cvs but with my existing .dll the jvm dies;
have I missed a step? Wouldn't this kind of change mean regenerating
some of the SWIG java and native files?

Cheers,

Steph


On Tue, Jul 19, 2005 at 06:36:59PM -0400, Ivan Z. Ganza wrote:
> Greetings,
>=20
> I've changed the get/setPixelData32 methods to use int[] instead of
> long[].  Please let me know if this is working properly.  I didn't have
> a chance to test it...
>=20
> If we find this to be good I'll adjust the other two methods in the same
> way.  Also I saw one thing that could be optimized which I will also do.
>=20
> So we should end up with:
>=20
>     get/setPixelData8   --> byte[]
>     get/setPixelData16 --> short[]
>     get/setPixelData32 --> int[]
>=20
> Nothing else anywhere will be affected by this.
>=20
> Let me know any comments...
>=20
> -Ivan/
>=20
> S. Meslin-Weber wrote:
>=20
> >Hi everyone,
> >
> >I'm cleaning up some code in Odonata and in the sdljava provider I've
> >found that I use get/setPixelData32(long[]). Would it be possible to
> >rationalise the types used for these methods? Does anyone still use
> >them?
> >
> >long[]  64 bit colour data
> >int[]   32 ...
> >short[] 16 ...
> >byte[]   8 ...
> >
> >Essentially it'd mean changing the signatures for the get/set methods to
> >match the bit sizes they're operating with.
> >
> >I've seen the gradual move to using ByteBuffer and Buffers in general...
> >Odonata intends to work with JVM versions 1.1+ so those classes wouldn't
> >necessarily be available on those targets :)
> >
> >Cheers,
> >
> >Steph
> >
> > =20
> >
>=20
>=20
>=20
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=3D7477&alloc_id=3D16492&op=3Dclick
> _______________________________________________
> sdljava-users mailing list
> sdl...@li...
> https://lists.sourceforge.net/lists/listinfo/sdljava-users

--=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Stephane Meslin-Weber         Email: st...@ta...
Senior Software Engineer      Web: http://odonata.tangency.co.uk
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Re: Using SDL_PushEvent (was Re: [sdljava-users] Re: sdljava-users digest, Vol 1 #82 - 2 msgs)

[Wouter <wo...@w7...>]

A while ago I got pushevent to work with sdljava. It took just a couple
of minor adjustments to the code, you might look at how swig handles the
JNI call. Most of the code for pushevent is already there in sdljava,
it's just commented.

Wouter

p.s. Although my hack for pushevent/userevent did work, It's too much of
a hack too add it to cvs.


Ivan Z. Ganza wrote:
> It is strange that SDL_PushEvent isn't working for you.  You might want
> to search on the sdl mailing list for "Using SDL_PushEvent".  There mus=
t
> be some reason it is returning -1.  It might require debugging the SDL =
C
> code to see why it is returning -1.
>=20
> I'll see if I can find anything out on my end.
>=20
> -Ivan/
>=20
> Christian Bourque wrote:
>=20
>=20
>>>I think the following (unimplemented) method from SDLEvent should do t=
he
>>>trick.=3D20
>>>
>>>       int SDL_PushEvent(SDL_Event *event);
>>>
>>>  =20
>>>
>>
>>Hi Ivan! Thanks for your reply!
>>
>>I've already tried SDL_PushEvent inside my native lib (using JNI),
>>basically I catch mousePressed events inside the canvas and then call
>>a native function which will call SDL_PushEvent() but it always
>>returns -1...
>>
>>Regards
>>
>>Christian
>>
>>
>>-------------------------------------------------------
>>SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
>=20
>>from IBM. Find simple to follow Roadmaps, straightforward articles,
>=20
>>informative Webcasts and more! Get everything you need to get up to
>>speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id=16492&op=CCk
>>_______________________________________________
>>sdljava-users mailing list
>>sdl...@li...
>>https://lists.sourceforge.net/lists/listinfo/sdljava-users
>>=20
>>
>=20
>=20
>=20
>=20
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id=16492&op=3Dclick
> _______________________________________________
> sdljava-users mailing list
> sdl...@li...
> https://lists.sourceforge.net/lists/listinfo/sdljava-users

Re: [sdljava-users] Anyone using get/setPixelDataXX()?

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

Greetings,

I've changed the get/setPixelData32 methods to use int[] instead of
long[].  Please let me know if this is working properly.  I didn't have
a chance to test it...

If we find this to be good I'll adjust the other two methods in the same
way.  Also I saw one thing that could be optimized which I will also do.

So we should end up with:

    get/setPixelData8   --> byte[]
    get/setPixelData16 --> short[]
    get/setPixelData32 --> int[]

Nothing else anywhere will be affected by this.

Let me know any comments...

-Ivan/

S. Meslin-Weber wrote:

>Hi everyone,
>
>I'm cleaning up some code in Odonata and in the sdljava provider I've
>found that I use get/setPixelData32(long[]). Would it be possible to
>rationalise the types used for these methods? Does anyone still use
>them?
>
>long[]  64 bit colour data
>int[]   32 ...
>short[] 16 ...
>byte[]   8 ...
>
>Essentially it'd mean changing the signatures for the get/set methods to
>match the bit sizes they're operating with.
>
>I've seen the gradual move to using ByteBuffer and Buffers in general...
>Odonata intends to work with JVM versions 1.1+ so those classes wouldn't
>necessarily be available on those targets :)
>
>Cheers,
>
>Steph
>
>  
>

Using SDL_PushEvent (was Re: [sdljava-users] Re: sdljava-users digest, Vol 1 #82 - 2 msgs)

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

It is strange that SDL_PushEvent isn't working for you.  You might want
to search on the sdl mailing list for "Using SDL_PushEvent".  There must
be some reason it is returning -1.  It might require debugging the SDL C
code to see why it is returning -1.

I'll see if I can find anything out on my end.

-Ivan/

Christian Bourque wrote:

>>I think the following (unimplemented) method from SDLEvent should do th=
e
>>trick.=3D20
>>
>>        int SDL_PushEvent(SDL_Event *event);
>>
>>   =20
>>
>
>Hi Ivan! Thanks for your reply!
>
>I've already tried SDL_PushEvent inside my native lib (using JNI),
>basically I catch mousePressed events inside the canvas and then call
>a native function which will call SDL_PushEvent() but it always
>returns -1...
>
>Regards
>
>Christian
>
>
>-------------------------------------------------------
>SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
>from IBM. Find simple to follow Roadmaps, straightforward articles,
>informative Webcasts and more! Get everything you need to get up to
>speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id=16492&op=CCk
>_______________________________________________
>sdljava-users mailing list
>sdl...@li...
>https://lists.sourceforge.net/lists/listinfo/sdljava-users
> =20
>

Re: [sdljava-users] Anyone using get/setPixelDataXX()?

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

Interesting...

I've had a look at vncJ.  I didn't even know such a thing existed.  vnc
is an awesome program!

I'm not sure why the swig team choose to use long.  Probably because
they wanted to support arithmetic operations.  I see now that in our
case, since we interpret as pixel data, things are different.  I will
investigate changing this but only when dealing with pixel data.  The
other instances of uint32 should remain longs I think.

-Ivan/

S. Meslin-Weber wrote:

>Hi Rainer,
>
>On Tue, Jul 19, 2005 at 12:04:57AM +0200, Rainer Koschnick wrote:
>  
>
>>Maybe there's nothing to fix.  Java primitives are always signed so the 
>>range is not the same as the unsigned 32 bit int.
>>
>>Java Data Types:
>>
>>int
>>    4 bytes, signed (two's complement). -2,147,483,648 to 
>>2,147,483,647. Like all numeric types ints may be cast into other 
>>    
>>
>
>[snip]
>
>So... 32 bits, right? we're dealing with pixel data here, not arithmetic
>operations. When I deal with colour information, each byte is treated as
>unsigned and upcasted to int (Java does love its ints); things are then
>repacked into 32bits, again ignoring signs. The fact that Java deems
>them signed isn't relevant in this context.
>
>So ok, since SWIG is multipurpose, perhaps we simply need to let it know
>that we have a specific interpretation of these type conversions?
>
>Cheers,
>
>Steph
>
>  
>

Re: [sdljava-users] Anyone using get/setPixelDataXX()?

[S. Meslin-W. <st...@ta...>]

Hi Rainer,

On Tue, Jul 19, 2005 at 12:04:57AM +0200, Rainer Koschnick wrote:
> Maybe there's nothing to fix.  Java primitives are always signed so the=
=20
> range is not the same as the unsigned 32 bit int.
>
> Java Data Types:
>=20
> int
>     4 bytes, signed (two's complement). -2,147,483,648 to=20
> 2,147,483,647. Like all numeric types ints may be cast into other=20

[snip]

So... 32 bits, right? we're dealing with pixel data here, not arithmetic
operations. When I deal with colour information, each byte is treated as
unsigned and upcasted to int (Java does love its ints); things are then
repacked into 32bits, again ignoring signs. The fact that Java deems
them signed isn't relevant in this context.

So ok, since SWIG is multipurpose, perhaps we simply need to let it know
that we have a specific interpretation of these type conversions?

Cheers,

Steph

--=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Stephane Meslin-Weber         Email: st...@ta...
Senior Software Engineer      Web: http://odonata.tangency.co.uk
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Re: [sdljava-users] Anyone using get/setPixelDataXX()?

[Rainer K. <ar...@gm...>]

S. Meslin-Weber wrote:

> Hi Ivan,
> 
> On Tue, Jul 12, 2005 at 05:54:19PM -0400, Ivan Z. Ganza wrote:
> 
>>Not a problem.  I did not have time to properly test them, however, the
>>code was actually still in the native layer from where I first coded
>>that part , and I know it was working at that point.
> 
> 
> Yup, it's back as it was...
> 
> 
>>The reason for long instead of int is because that is how swig maps it.
>>
>>    void SWIG_GetPixelData32(SDL_Surface *surface, Uint32 pixelData[])
> 
> 
> Argh. that's a huge bottleneck for me. I treat ints as uint32 as it is
> (for AARRGGBB) and other libraries I use (VNCj notably) also use this
> interpretation for int.
> 
> 
>>For the above SWIG mapg the Uint32 to a long[].  I suppose we could add
>>our own (additonal) method with takes an int[] and casts it to long[]
>>calling the appropriate method (for conviencence).  Not sure if that
>>would cause any problems due to the cast.
> 
> 
> No, it's not possible to cast int[] to long[]. I end up having to do the
> following:
> 
>   long[] longs = new long[source.length];
>   for (int i = 0; i < source.length; i++) {
>     longs[i] = source[i];
>   }
>   SDLUtil.setPixelData32(screen, longs);
> 
> You can imagine how expensive this can get :( I don't think that pushing
> this to C is the answer. Perhaps SWIG needs fixing?

Maybe there's nothing to fix.  Java primitives are always signed so the 
range is not the same as the unsigned 32 bit int.

Java Data Types:

int
     4 bytes, signed (two's complement). -2,147,483,648 to 
2,147,483,647. Like all numeric types ints may be cast into other 
numeric types (byte, short, long, float, double). When lossy casts are 
done (e.g. int to byte) the conversion is done modulo the length of the 
smaller type.

long
     8 bytes signed (two's complement). Ranges from 
-9,223,372,036,854,775,808 to +9,223,372,036,854,775,807.

C:

uint8
	0 to 255
	Unsigned 8-bit integer
	1
	uint8
uint16
	0 to 65535
	Unsigned 16-bit integer
	2
	uint16
uint32
	0 to 4,294,967,295
	Unsigned 32-bit integer
	4
	uint32

Re: [sdljava-users] Anyone using get/setPixelDataXX()?

[S. Meslin-W. <st...@ta...>]

Hi Ivan,

On Tue, Jul 12, 2005 at 05:54:19PM -0400, Ivan Z. Ganza wrote:
> Not a problem.  I did not have time to properly test them, however, the
> code was actually still in the native layer from where I first coded
> that part , and I know it was working at that point.

Yup, it's back as it was...

> The reason for long instead of int is because that is how swig maps it.
>=20
>     void SWIG_GetPixelData32(SDL_Surface *surface, Uint32 pixelData[])

Argh. that's a huge bottleneck for me. I treat ints as uint32 as it is
(for AARRGGBB) and other libraries I use (VNCj notably) also use this
interpretation for int.

> For the above SWIG mapg the Uint32 to a long[].  I suppose we could add
> our own (additonal) method with takes an int[] and casts it to long[]
> calling the appropriate method (for conviencence).  Not sure if that
> would cause any problems due to the cast.

No, it's not possible to cast int[] to long[]. I end up having to do the
following:

  long[] longs =3D new long[source.length];
  for (int i =3D 0; i < source.length; i++) {
    longs[i] =3D source[i];
  }
  SDLUtil.setPixelData32(screen, longs);

You can imagine how expensive this can get :( I don't think that pushing
this to C is the answer. Perhaps SWIG needs fixing?

Steph

--=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Stephane Meslin-Weber         Email: st...@ta...
Senior Software Engineer      Web: http://odonata.tangency.co.uk
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

[sdljava-users] Re: sdljava-users digest, Vol 1 #82 - 2 msgs

[Christian B. <chr...@gm...>]

> I think the following (unimplemented) method from SDLEvent should do the
> trick.=3D20
>=20
>         int SDL_PushEvent(SDL_Event *event);
>=20

Hi Ivan! Thanks for your reply!

I've already tried SDL_PushEvent inside my native lib (using JNI),
basically I catch mousePressed events inside the canvas and then call
a native function which will call SDL_PushEvent() but it always
returns -1...

Regards

Christian

Re: [sdljava-users] AWT Native Interface & SDL

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

Greetings Christian,

I like the JQEMU project.  It seems right now there is no way to pass
events to the native window.

I think the following (unimplemented) method from SDLEvent should do the
trick.=20

	int SDL_PushEvent(SDL_Event *event);

and in sdljava world:

	public static int pushEvent(SDLEvent event) throws SDLException;

I'm not sure how hard it would be to do this properly.  Seems like a very=
 good feature to have though so it will be added.

-Ivan/


Christian Bourque wrote:

>Hi!
>
>I'm the author of JQEMU (http://sourceforge.net/projects/jqemu) which
>is a Java/Swing graphical frontend for QEMU (an x86 emulator) and I'm
>trying to embed the native application window (X11/SDL) inside a Java
>AWT Canvas using JNI and the AWT Native Interface. Everything works grea=
t
>except for mouse/keyboard events which seems to be ignored by the
>native window.
>
>Is there a way to catch keyboard and mouse events inside the canvas
>and pass them to the native window?
>
>Thanks
>
>Christian
>
>
>-------------------------------------------------------
>SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
>from IBM. Find simple to follow Roadmaps, straightforward articles,
>informative Webcasts and more! Get everything you need to get up to
>speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id=16492&op=CCk
>_______________________________________________
>sdljava-users mailing list
>sdl...@li...
>https://lists.sourceforge.net/lists/listinfo/sdljava-users
> =20
>

[sdljava-users] AWT Native Interface & SDL

[Christian B. <chr...@gm...>]

Hi!

I'm the author of JQEMU (http://sourceforge.net/projects/jqemu) which
is a Java/Swing graphical frontend for QEMU (an x86 emulator) and I'm
trying to embed the native application window (X11/SDL) inside a Java
AWT Canvas using JNI and the AWT Native Interface. Everything works great
except for mouse/keyboard events which seems to be ignored by the
native window.

Is there a way to catch keyboard and mouse events inside the canvas
and pass them to the native window?

Thanks

Christian

Re: [sdljava-users] Bug in SDLEventManager ?

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

I've applied this patch in CVS.  Thanks Stefan for finding this!

-Ivan/

Stefan Prelle wrote:

>Hi all,
>
>I just found a typo-bug in the SDLEventManager in the register-Method. 
>
>When checking if the class parameter can be assigned to SDLEvent there
>is a negation missing.
>Line 108 should read:
>   if (!SDLEvent.class.isAssignableFrom(eventType)) return false;
>
>You find the patch attached.
>
>Regards,
>  Stefan
>  
>
>------------------------------------------------------------------------
>
>*** SDLEventManager.java	2005-07-09 00:00:44.000000000 +0200
>--- SDLEventManager_old.java	2005-07-08 23:59:08.000000000 +0200
>***************
>*** 106,110 ****
>  	{
>  		if (listener == null) return false;
>! 		if (!SDLEvent.class.isAssignableFrom(eventType)) return false;
>  		List list = (List)repository.get(eventType);
>  		if (list==null) list = new ArrayList(); 
>--- 106,110 ----
>  	{
>  		if (listener == null) return false;
>! 		if (SDLEvent.class.isAssignableFrom(eventType)) return false;
>  		List list = (List)repository.get(eventType);
>  		if (list==null) list = new ArrayList(); 
>***************
>*** 222,224 ****
>  		  }
>  	}
>! }
>--- 222,224 ----
>  		  }
>  	}
>! }
>\ Kein Zeilenumbruch am Dateiende.
>  
>

Re: [sdljava-users] Anyone using get/setPixelDataXX()?

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

Hi Steph,

Not a problem.  I did not have time to properly test them, however, the
code was actually still in the native layer from where I first coded
that part , and I know it was working at that point.

The reason for long instead of int is because that is how swig maps it.

    void SWIG_GetPixelData32(SDL_Surface *surface, Uint32 pixelData[])

For the above SWIG mapg the Uint32 to a long[].  I suppose we could add
our own (additonal) method with takes an int[] and casts it to long[]
calling the appropriate method (for conviencence).  Not sure if that
would cause any problems due to the cast.

-Ivan/

S. Meslin-Weber wrote:

>Hi Ivan,
>
>Thanks for the additions! Is there a reason for going with long[] for
>32bit instead of int[] ?
>
>Thanks,
>
>Steph
>
>On Fri, Jul 08, 2005 at 10:55:19AM -0400, Ivan Z. Ganza wrote:
>  
>
>>Greetings,
>>
>>I have checked in code which adds the following methods to SDLSurface:
>>
>>   public long[] getPixelData32()
>>   public int[] getPixelData16()
>>   public short[] getPixelData8()
>>
>>   public void setPixelData32(long[] pixelData)
>>   public void setPixelData16(int[] pixelData)
>>   public void setPixelData8(short[] pixelData)
>>
>>Cheers,
>>-Ivan/
>>
>>S. Meslin-Weber wrote:
>>
>>    
>>
>>>Hi everyone,
>>>
>>>I'm cleaning up some code in Odonata and in the sdljava provider I've
>>>found that I use get/setPixelData32(long[]). Would it be possible to
>>>rationalise the types used for these methods? Does anyone still use
>>>them?
>>>
>>>long[]  64 bit colour data
>>>int[]   32 ...
>>>short[] 16 ...
>>>byte[]   8 ...
>>>
>>>Essentially it'd mean changing the signatures for the get/set methods to
>>>match the bit sizes they're operating with.
>>>
>>>I've seen the gradual move to using ByteBuffer and Buffers in general...
>>>Odonata intends to work with JVM versions 1.1+ so those classes wouldn't
>>>necessarily be available on those targets :)
>>>
>>>Cheers,
>>>
>>>Steph
>>>
>>>
>>>
>>>      
>>>
>>
>>-------------------------------------------------------
>>This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening
>>July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual
>>core and dual graphics technology at this free one hour event hosted by HP,
>>AMD, and NVIDIA.  To register visit http://www.hp.com/go/dualwebinar
>>_______________________________________________
>>sdljava-users mailing list
>>sdl...@li...
>>https://lists.sourceforge.net/lists/listinfo/sdljava-users
>>    
>>
>
>  
>

Re: [sdljava-users] Anyone using get/setPixelDataXX()?

[S. Meslin-W. <st...@ta...>]

Hi Ivan,

Thanks for the additions! Is there a reason for going with long[] for
32bit instead of int[] ?

Thanks,

Steph

On Fri, Jul 08, 2005 at 10:55:19AM -0400, Ivan Z. Ganza wrote:
> Greetings,
>=20
> I have checked in code which adds the following methods to SDLSurface:
>=20
>    public long[] getPixelData32()
>    public int[] getPixelData16()
>    public short[] getPixelData8()
>=20
>    public void setPixelData32(long[] pixelData)
>    public void setPixelData16(int[] pixelData)
>    public void setPixelData8(short[] pixelData)
>=20
> Cheers,
> -Ivan/
>=20
> S. Meslin-Weber wrote:
>=20
> >Hi everyone,
> >
> >I'm cleaning up some code in Odonata and in the sdljava provider I've
> >found that I use get/setPixelData32(long[]). Would it be possible to
> >rationalise the types used for these methods? Does anyone still use
> >them?
> >
> >long[]  64 bit colour data
> >int[]   32 ...
> >short[] 16 ...
> >byte[]   8 ...
> >
> >Essentially it'd mean changing the signatures for the get/set methods to
> >match the bit sizes they're operating with.
> >
> >I've seen the gradual move to using ByteBuffer and Buffers in general...
> >Odonata intends to work with JVM versions 1.1+ so those classes wouldn't
> >necessarily be available on those targets :)
> >
> >Cheers,
> >
> >Steph
> >
> >=20
> >
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by the 'Do More With Dual!' webinar happen=
ing
> July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual
> core and dual graphics technology at this free one hour event hosted by H=
P,
> AMD, and NVIDIA.  To register visit http://www.hp.com/go/dualwebinar
> _______________________________________________
> sdljava-users mailing list
> sdl...@li...
> https://lists.sourceforge.net/lists/listinfo/sdljava-users

--=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Stephane Meslin-Weber         Email: st...@ta...
Senior Software Engineer      Web: http://odonata.tangency.co.uk
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Re: [sdljava-users] Bug in SDLEventManager ?

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

Thanks!  I will apply this patch.

-Ivan/

Stefan Prelle wrote:

>Hi all,
>
>I just found a typo-bug in the SDLEventManager in the register-Method. 
>
>When checking if the class parameter can be assigned to SDLEvent there
>is a negation missing.
>Line 108 should read:
>   if (!SDLEvent.class.isAssignableFrom(eventType)) return false;
>
>You find the patch attached.
>
>Regards,
>  Stefan
>  
>
>------------------------------------------------------------------------
>
>*** SDLEventManager.java	2005-07-09 00:00:44.000000000 +0200
>--- SDLEventManager_old.java	2005-07-08 23:59:08.000000000 +0200
>***************
>*** 106,110 ****
>  	{
>  		if (listener == null) return false;
>! 		if (!SDLEvent.class.isAssignableFrom(eventType)) return false;
>  		List list = (List)repository.get(eventType);
>  		if (list==null) list = new ArrayList(); 
>--- 106,110 ----
>  	{
>  		if (listener == null) return false;
>! 		if (SDLEvent.class.isAssignableFrom(eventType)) return false;
>  		List list = (List)repository.get(eventType);
>  		if (list==null) list = new ArrayList(); 
>***************
>*** 222,224 ****
>  		  }
>  	}
>! }
>--- 222,224 ----
>  		  }
>  	}
>! }
>\ Kein Zeilenumbruch am Dateiende.
>  
>

[sdljava-users] Bug in SDLEventManager ?

[Stefan P. <pr...@tz...>]

Hi all,

I just found a typo-bug in the SDLEventManager in the register-Method. 

When checking if the class parameter can be assigned to SDLEvent there
is a negation missing.
Line 108 should read:
   if (!SDLEvent.class.isAssignableFrom(eventType)) return false;

You find the patch attached.

Regards,
  Stefan
-- 
Stefan Prelle <pr...@tz...>

Re: [sdljava-users] Anyone using get/setPixelDataXX()?

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

Greetings,

I have checked in code which adds the following methods to SDLSurface:

    public long[] getPixelData32()
    public int[] getPixelData16()
    public short[] getPixelData8()

    public void setPixelData32(long[] pixelData)
    public void setPixelData16(int[] pixelData)
    public void setPixelData8(short[] pixelData)

Cheers,
-Ivan/

S. Meslin-Weber wrote:

>Hi everyone,
>
>I'm cleaning up some code in Odonata and in the sdljava provider I've
>found that I use get/setPixelData32(long[]). Would it be possible to
>rationalise the types used for these methods? Does anyone still use
>them?
>
>long[]  64 bit colour data
>int[]   32 ...
>short[] 16 ...
>byte[]   8 ...
>
>Essentially it'd mean changing the signatures for the get/set methods to
>match the bit sizes they're operating with.
>
>I've seen the gradual move to using ByteBuffer and Buffers in general...
>Odonata intends to work with JVM versions 1.1+ so those classes wouldn't
>necessarily be available on those targets :)
>
>Cheers,
>
>Steph
>
>  
>

Re: [sdljava-users] Anyone using get/setPixelDataXX()?

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

Hi Steph,

Sorry for the late reply I was travelling last week.

I think I had this in at one point but then removed it in favour of the 
byte buffers.  Also the get/setPixelDataXXXX methods are VERY 
inefficient due to the fact this results in copies between java and the 
native layer.

I don't see any harm in providing this methods though so they will be 
added.  Just be aware of the fact they are inefficient.

I will add them as soon as I can.

Thanks,
-Ivan/

S. Meslin-Weber wrote:

>Hi everyone,
>
>I'm cleaning up some code in Odonata and in the sdljava provider I've
>found that I use get/setPixelData32(long[]). Would it be possible to
>rationalise the types used for these methods? Does anyone still use
>them?
>
>long[]  64 bit colour data
>int[]   32 ...
>short[] 16 ...
>byte[]   8 ...
>
>Essentially it'd mean changing the signatures for the get/set methods to
>match the bit sizes they're operating with.
>
>I've seen the gradual move to using ByteBuffer and Buffers in general...
>Odonata intends to work with JVM versions 1.1+ so those classes wouldn't
>necessarily be available on those targets :)
>
>Cheers,
>
>Steph
>
>  
>

[sdljava-users] Anyone using get/setPixelDataXX()?

[S. Meslin-W. <st...@ta...>]

Hi everyone,

I'm cleaning up some code in Odonata and in the sdljava provider I've
found that I use get/setPixelData32(long[]). Would it be possible to
rationalise the types used for these methods? Does anyone still use
them?

long[]  64 bit colour data
int[]   32 ...
short[] 16 ...
byte[]   8 ...

Essentially it'd mean changing the signatures for the get/set methods to
match the bit sizes they're operating with.

I've seen the gradual move to using ByteBuffer and Buffers in general...
Odonata intends to work with JVM versions 1.1+ so those classes wouldn't
necessarily be available on those targets :)

Cheers,

Steph

--=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Stephane Meslin-Weber         Email: st...@ta...
Senior Software Engineer      Web: http://odonata.tangency.co.uk
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Re: [sdljava-users] UnsatisfiedLinkError Exception Problem

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

Chris,

Sometimes the optional operations are not implemented.  If you want to 
see examples of how the direct buffer stuff is being used have a look in 
the OpenGL code.  If you want to get it into an int[] you should be able 
to just create your own array and copy the elements into it.  Would have 
been nice had they implemented it though. 

-Ivan/

Chris Dennett wrote:

> Sorry, I had outdated versions of the SDLJava dlls, that bit works 
> now. However, I've got problems with the array conversion of the 
> IntBuffer in that code (ByteBuffer -> IntBuffer -> int array). For 
> some reason, the operation doesn't seem to be supported. Is there any 
> other way I can access it? Do you have any examples for doing so?
>
> Thanks in advance,
> Chris
>
>
> Ivan Z. Ganza wrote:
>
>> This is strange.  Is the function present in the sdljava.dll?  send 
>> me your sdljava.dll.  Are you compiling from sources?
>>
>> -Ivan/
>>
>>
>> -------------------------------------------------------
>> This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you 
>> shotput
>> a projector? How fast can you ride your desk chair down the office 
>> luge track?
>> If you want to score the big prize, get to know the little guy.  Play 
>> to win an NEC 61" plasma display: http://www.necitguy.com/?r=20
>> _______________________________________________
>> sdljava-users mailing list
>> sdl...@li...
>> https://lists.sourceforge.net/lists/listinfo/sdljava-users
>>
>
>

Re: [sdljava-users] UnsatisfiedLinkError Exception Problem

[Chris D. <Des...@nt...>]

Sorry, I had outdated versions of the SDLJava dlls, that bit works now. 
However, I've got problems with the array conversion of the IntBuffer in 
that code (ByteBuffer -> IntBuffer -> int array). For some reason, the 
operation doesn't seem to be supported. Is there any other way I can 
access it? Do you have any examples for doing so?

Thanks in advance,
Chris


Ivan Z. Ganza wrote:

> This is strange.  Is the function present in the sdljava.dll?  send me 
> your sdljava.dll.  Are you compiling from sources?
>
> -Ivan/
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you 
> shotput
> a projector? How fast can you ride your desk chair down the office 
> luge track?
> If you want to score the big prize, get to know the little guy.  Play 
> to win an NEC 61" plasma display: http://www.necitguy.com/?r=20
> _______________________________________________
> sdljava-users mailing list
> sdl...@li...
> https://lists.sourceforge.net/lists/listinfo/sdljava-users
>


-- 
                                                |>
 Dessimat0r (Chris Dennett)              /`\    |
 "We cannot turn back time, but we can      _  _|_  _
 move it forwards with our own hands."     |;|_|;|_|;|
                                           \\.    .  /
 [www:    http://codeknight.net   ]         \\:  .  /
 [e-mail: des...@nt... ]          ||: U |        /`\
 [icq:    21477909                ]          ||:.  |
 [msn:    des...@nt... ]     \,/  ||: U.|
                                             ||:   |    \,/
                                             ||: , |
     ___.--'~---''--~.__            __.------'''~`-'-,
-~--'                   ~--.__..--~'                  `~----.__

[sdljava-users] guichan updated to 0.4.0

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

FYI,

I've updated the code in CVS to what Rainer has sent me (version 0.4.0) 
--  Thanks again Rainer.

-Ivan/

Re: [sdljava-users] UnsatisfiedLinkError Exception Problem

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

This is strange.  Is the function present in the sdljava.dll?  send me 
your sdljava.dll.  Are you compiling from sources?

-Ivan/

Chris Dennett wrote:

> Hi, I'm having a bit of a problem with:
> IntBuffer pixelData = surface.getPixelData().asIntBuffer();
>
> The code is throwing me the following exception.
>
> Exception in thread "main" java.lang.UnsatisfiedLinkError: 
> SWIG_getPixelDirectByteBuffer
>    at 
> sdljava.x.swig.SWIG_SDLVideoJNI.SWIG_getPixelDirectByteBuffer(Native 
> Method)
>    at 
> sdljava.x.swig.SWIG_SDLVideo.SWIG_getPixelDirectByteBuffer(SWIG_SDLVideo.java:266) 
>
>    at sdljava.video.SDLSurface.getPixelData(SDLSurface.java:950)
>    at 
> loach.screen.SurfaceTransformer.flipHorizontal(SurfaceTransformer.java:27) 
>
>    at loach.Loach.<init>(Loach.java:102)
>    at loach.Loach.main(Loach.java:177)
> Picked up _JAVA_OPTIONS: -Dsun.java2d.d3d=true
>
> Please help, I'm not sure what is wrong. This code is used in some 
> horizontal image flip transformation code I wrote.
>
>    public static void flipHorizontal(SDLSurface surface) throws 
> SDLException {
>        surface.lockSurface();
>              int
>            width  = surface.getWidth(),
>            height = surface.getHeight(),
>            pixels = width * height
>        ;
>              IntBuffer pixelData = surface.getPixelData().asIntBuffer();
>              int[]     data   = pixelData.array();
>        int[][]   pData  = new int[pixels][4];
>              for (int i = 0; i < pixels; i++) {
>            for (int j = 0; j < 4; j++) {
>                pData[i][j] = data[i * j];
>            }
>        }
>              int[][][] rData = new int[height][width][4];
>              for (int row = 0; row < height; row++) {
>            for (int col = 0; col < width; col++) {
>                rData[row][col] = pData[row * col];
>            }
>        }
>              int[] temp = new int[width];
>        for (int row = 0; row < height; row++) {
>            for (int left = 0, right = rData[row].length - 1; left < 
> right; left++, right--) {
>                /* exchange the first and last */
>                temp = rData[row][left];
>                rData[row][left] = rData[row][right];
>                rData[row][right] = temp;
>            }
>        }
>              /* deconstruct this shit and give me a fucking normal int 
> array */
>        for (int row = 0; row < height; row++) {
>            for (int col = 0; col < width; col++) {
>                for (int i = 0; i < 4; i++) {
>                    data[row * col * i] = rData[row][col][i];
>                }
>            }
>        }
>              pixelData.clear();
>        pixelData.put(data);
>              surface.unlockSurface();
>    }
>
> Thanks in advance,
> Chris
>