[Note: I just subscribed to this list, so if I sound like a total idiot, please
forgive me, okay? ;)]
Is anyone working on (or considering working on, or planning to work on, or
already worked on) SDL bindings to Java? I think I could use that right about
now.
Regards,
Alex.
[Note: I just subscribed to this list, so if I sound like a total idiot, please
forgive me, okay? ;)]Is anyone working on (or considering working on, or planning to work on, or
already worked on) SDL bindings to Java? I think I could use that right about
now.
http://jsdl.sourceforge.net/ - JSDL - Java/SDL bindings
http://www.fasterlight.com/hugg/projects/jsdl.html - JSDL (another Java/SDL)
So far that I’ve found. Haven’t tried either yet. (farely recent - ie
last couple days - discussions)
Later!
- TeunisOn Sat, 31 Mar 2001, Alexander Hvostov wrote:
Hi,
I think I brought this up some time ago, but I don’t think it was
properly resolved.
Presumably, all surfaces init’d with HW_SURFACE are in video
memory if there is enough memory. So if I init screen memory with
HW_SURFACE and another surface with HW_SURFACE, blitting
to the screen memory should be, and is in my tests, very fast.
The problem is when I try to blit between two surfaces that have
been init’d with HW_SURFACE, and the destination is not the
screen memory, it is much slower. As I understand it, it shouldn’t
make a difference because it’s all operating with video memory,
whether one part is designated as the screen memory or not.
Can anyone explain this?
The problem is when I try to blit between two surfaces that have
been init’d with HW_SURFACE, and the destination is not the
screen memory, it is much slower. As I understand it, it shouldn’t
make a difference because it’s all operating with video memory,
whether one part is designated as the screen memory or not.
I agree. what exact platform are you experiencing this on? A Very Short
example program would also be handy
Are here any known problems with event handling in SDL 1.2 under Windows
2000?
SDL seems to be sending multiple mouse events (some of them incorrect),
when running in fullscreen.
For example, I will get two consecutive left mouse button down events
without ever having gotten a left mouse button up event. Also, sometimes
my program will receive a rght mouse button down event, even though I
never pressed the right mouse button.
This only happens when in fullscreen, though. If I run the exact same
program in a window, it works fine.
I don’t know if it makes a difference, but I am only using SDL for event
handling (ie, not sound or threads or networking), and for initilaizing
OpenGL.
I use Visual C++ 6.
I don’t need to link against the multithreaded libraries, do I?
-Dan
Funny this should be asked, Steven Hugg just finished setting up
a SourceForge project where a number of us are attempting to
integrate the existing projects, and produce a single complete
binding. For the record, I’m going to try and get the perl bindings
to use a similar API when done.
The project is located at:
And will produce a cannonically named package
org.libsdl.*
for java after the www.libsdl.org site :)On Sat, Mar 31, 2001 at 06:51:39PM -0800, Alexander Hvostov wrote:
[Note: I just subscribed to this list, so if I sound like a total idiot, please
forgive me, okay? ;)]Is anyone working on (or considering working on, or planning to work on, or
already worked on) SDL bindings to Java? I think I could use that right about
now.Regards,
Alex.
–
david j. goehrig bit twiddler www.valinux.com
“There was nothing creative, charming, admirable or innovative in
Pok?mon except that it parted small children from their
money with brutal efficiency. It inexplicably featured the
dramatic story of cockfighting monsters who lived in your pants…”
- John TynesFunny this should be asked, Steven Hugg just finished setting up
a SourceForge project where a number of us are attempting to
integrate the existing projects, and produce a single complete
binding. For the record, I’m going to try and get the perl bindings
to use a similar API when done.The project is located at:
http://sourceforge.net/projects/org-libsdl/
And will produce a cannonically named package
org.libsdl.*
for java after the www.libsdl.org site
If you haven’t thought of this already, I suggest setting it up so that you
can use the native libsdl.so if it’s present (ie, via JNI or some other native-
code interface), and if it’s not, use a slower, pure-Java implementation that
simply draws onto an AWT Frame or something like that. This way, even those
unfortunate (or lazy) enough not to have the native library installed can still
use the application, but it would be lots slower.
On the other hand, this means a lot of duplication of code, with questionable
actual value, so I’d like to hear some opinions on this.
By the way, the Java version of OpenPTC (openptc.sourceforge.net) actually does
this already. That’s how I thought of this.
Regards,
Alex.On Sun, 1 Apr 2001 12:03:38 -0700 Dave wrote:
I’m on Win32… I should be able to come up with a quick test
program. It’s really basic stuff.On 1 Apr 2001, at 16:19, Mattias Engdeg?rd wrote:
The problem is when I try to blit between two surfaces that have
been init’d with HW_SURFACE, and the destination is not the
screen memory, it is much slower. As I understand it, it shouldn’t
make a difference because it’s all operating with video memory,
whether one part is designated as the screen memory or not.I agree. what exact platform are you experiencing this on? A Very Short
example program would also be handy
Although the idea of implementing SDL on top of AWT might sound
interesting, the goal afaik is to support the native library.
The point here is to replace the AWT and get more people to use
SDL. I mean seriously, most distributions of linux now come with
the SDL in some form, and windows users can download the necessary DLLs.
A more interesting idea, IMHO is to take the AWT and port it to SDL,
providing a widely known interface for SDL structured graphics :)–
david j. goehrig bit twiddler www.valinux.com
“There was nothing creative, charming, admirable or innovative in
Pok?mon except that it parted small children from their
money with brutal efficiency. It inexplicably featured the
dramatic story of cockfighting monsters who lived in your pants…”
- John TynesA more interesting idea, IMHO is to take the AWT and port it to SDL,
providing a widely known interface for SDL structured graphics
Unless I’m mistaken, that could be accomplished by providing a
java.awt.Toolkit implementation. AWT was designed for this kind of
flexibility, so accomplishing such a goal shouldn’t be too non-trivial.
Of course, you have to provide a set of heavyweight components. To my
knowledge, SDL does not provide a widget set of any kind to use there.
Perhaps calls to instantiate heavyweight components should be redirected
to a “slave” Toolkit?
Regards,
Alex.On Mon, 2 Apr 2001 09:22:13 -0700 Dave wrote:
Here is a quick and somewhat messy program to test the problem.
It doesn’t simulate a tile-based engine, which is what I was working
on and which obviously has many blits per frame, but it gets the
job done.
On my Duron 600, blitting the full screen (640x480x16) 20 times
per frame, I get about 3ms difference (which amounts to ca.
180ms/second). I haven’t tested it on my other (slower) computer.
Hopefully attaching a 1.5K file won’t upset anyone 
-------------- next part --------------
The following section of this message contains a file attachment
prepared for transmission using the Internet MIME message format.
If you are using Pegasus Mail, or any another MIME-compliant system,
you should be able to save it or view it from within your mailer.
If you cannot, please ask your system administrator for assistance.
---- File information -----------
File: vidtest.zip
Size: 1412 bytes.
Type: ZIP-archive
-------------- next part --------------
A non-text attachment was scrubbed…
Name: vidtest.zip
Type: application/zip
Size: 1412 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20010404/794748d6/attachment.zipDate: 4 Apr 2001, 23:44
Here is a quick and somewhat messy program to test the problem.
I don’t have a machine to try it on, but I urge others to do so. I couldn’t
see any obvious fault in the test program at a first glance.
I see no reason for non-screen surfaces to be slower so this should be
worth some attention. Try increasing the number of blits/frame (COPY)
to get better timing resolution
(you are also timing the flip which adds half the refresh period on average;
but it’s perhaps safer to do in order to make sure the blitter fifo is
flushed)
Hopefully attaching a 1.5K file won’t upset anyone
no worry. in fact if you had included it as plain non-MIME text it
would have been easier for us to comment on directly
Good, that’s a start. I don’t see any reason for it to be slower,
either. If it’s necessary, I can repost the code in plain text, of
course.On 5 Apr 2001, at 11:36, Mattias Engdeg?rd wrote:
Here is a quick and somewhat messy program to test the problem.
I don’t have a machine to try it on, but I urge others to do so. I couldn’t
see any obvious fault in the test program at a first glance.
I see no reason for non-screen surfaces to be slower so this should be
worth some attention. Try increasing the number of blits/frame (COPY)
to get better timing resolution(you are also timing the flip which adds half the refresh period on average;
but it’s perhaps safer to do in order to make sure the blitter fifo is
flushed)Hopefully attaching a 1.5K file won’t upset anyone
no worry. in fact if you had included it as plain non-MIME text it
would have been easier for us to comment on directly