Messages

301

General discussions / Switched times to Uint32 milliseconds in SFML 2

« on: June 10, 2011, 04:50:15 pm »

There is the omnipresent /1000.f to get seconds or

Isn't that what macros were invented for? (which I don't have in Java )

302

General discussions / Switched times to Uint32 milliseconds in SFML 2

« on: June 10, 2011, 10:02:43 am »

Couldn't we just overload the function? And keep the float version also? Not sure what harm that would do....

The float version is obsolete really. The simple conversion from Uint32 milliseconds to float seconds comes for free basically and allows for the highest possible precision.

Using a 32-bit field for a time stamp is becoming really uncommon these days, though. There shouldn't be too much of a problem since the counting begins with the initialization of the clock, but I'd still suggest going with the flow and using a 64-bit value here.

Since overloading isn't possible with the same signature, I'd suggest to simply change the return time of GetElapsedTime to Uint64. That will require people to change their code again, but SFML2 isn't yet official and this hassle wouldn't have to be bothered with anymore in the future (at least not the foreseeable future).

Another possibility would be adding a function like "GetElapsedTimeLong" that returns a Uint64. The clock's internal counter would be a Uint64 value and the old Uint32 version would simply return the lower 32 bits. It would keep people from having to alter their sources again, but IMO going to Uint64 entirely is the best way.

303

General discussions / A new logo for SFML

« on: June 09, 2011, 07:59:24 pm »

I like it.

Many edges look aliased, though, any way that can be compromised?
I know that's being picky, but overall it's really great, it should be in a fine tuning stage!

304

SFML projects / JSFML - A Java binding for SFML

« on: June 08, 2011, 03:12:13 pm »

Done.
The JSFMLCanvas is now focusable and receives all events correctly.

305

SFML projects / JSFML - A Java binding for SFML

« on: June 08, 2011, 12:46:00 pm »

Looked at the X11 and Cocoa code, I don't think this issue will occur on Linux and Mac.

My idea for Windows is as follows upon creation of the JSFMLCanvas:
[list=1]

• Retrieve the GWLP_USERDATA field for the canvas (AWT component pointer) and save it.
  
• Let SFML initialize the Window for the canvas' handle.
• Get the WindowImplWin32 pointer from the overridden GWLP_USERDATA and save it into the canvas' java object.
  
• Restore the old GWLP_USERDATA value (AWT component pointer) so the canvas will still behave correctly in the Swing GUI.
  [/list:o]
  
  It is possible for me to retrieve the Java object from the AWT component pointed to by Java's GWLP_USERDATA value. So what I'm going to do is create a custom GlobalOnEvent that will retrieve the WindowImplWin32 right from that Java object instead from the user data.
  
  Quite a hack, but it should work just fine.
  
  EDIT:
  OK screw that, a hash map should be a lot easier. :D

306

SFML projects / JSFML - A Java binding for SFML

« on: June 08, 2011, 11:37:09 am »

I was able to figure out (but not yet fix) the focus problem.

Java uses the GWLP_USERDATA field to store a pointer to an AWTComponent object, which apparently is required so the Canvas can cooperate with AWT correctly. SFML overrides that field to store its own Window object pointer, which will of course break AWT functionality.

I'm not yet sure how to solve this conflict, but I'll find a way.
I also have no idea yet whether this problem even exists in any environment other than Windows.

I'd appreciate any hints you can give me.

307

SFML projects / JSFML - A Java binding for SFML

« on: May 31, 2011, 02:33:14 pm »

So I guess this does not need any extra work, except that the JSFMLCanvas should be focusable by clicking on it, I suppose. Does it work this way in the .NET binding?

Absolutely. It even works this way with a C++ SFML window --> if the window loses the focus it doesn't receive keyboard events anymore (whether it is a top-level window or not).

Alright, I have some trouble with this, further detailed in here: http://stackoverflow.com/questions/6187472/awt-component-cannot-gain-focus-in-the-presence-of-a-text-field
I hope I can find a solution to this or somebody knows one.

What's the default behaviour, say in .NET, when the control containing the RenderWindow gets resized? In my case, the default behaviour is that the contents get scaled with the control.

This is the expected default behaviour regardless the language, it's implemented like this in the core C++ code.

Alright, I removed the option again, works this way by default in Java as well.

308

SFML projects / JSFML - A Java binding for SFML

« on: May 30, 2011, 10:27:56 pm »

Nop, I'm talking about whatever flags your specific API (in this case SWIG) may offer -- which usually have a direct effect on the OS-specific low-level.

It's called Java Swing, not SWIG.
Swing is built upon AWT, Java's old GUI builder. Unlike AWT, Swing components have no actual window handle anymore but are lightweight, meaning that Swing itself draws them itself. This JSFMLCanvas is an AWT component, I need to use the old AWT one here ("old" does not in any way mean bad or deprecated) because those still get their own window handle.

Sorry if that's confusing, just wanted to clarify the terms "Swing" and "AWT". You're probably no Java developer, so why would you even need to know.

Anyway, I'm not sure how exactly those AWT components are linked to their actual OS window counterparts, what events they take, etc. That's why I personally call them "non-ordinary", no special meaning really.

While I couldn't make the RenderWindow receive resize events on its own, I could catch them on a Java level and the RenderWindow's size from the Java level. This works just fine, I don't see any problem with this. And luckily, since the RenderWindow's SetSize method also creates a "Resized" event, people can catch that fine.

This seems quite normal to me, that's how all controls work. If everything could react to keyboard events without having the focus, it would be a big mess

True that. So I guess this does not need any extra work, except that the JSFMLCanvas should be focusable by clicking on it, I suppose. Does it work this way in the .NET binding?

I'm not sure that you should provide such an extension to the SFML default behaviour, it may confuse people. Especially since it can be achieved without Java/internal specific code, it's just a matter of SFML views.

What's the default behaviour, say in .NET, when the control containing the RenderWindow gets resized? In my case, the default behaviour is that the contents get scaled with the control.

You're right, the viewport extension is simply done using Views and could be left to the users by reacting on resize events.

309

SFML projects / JSFML - A Java binding for SFML

« on: May 30, 2011, 09:04:10 pm »

Found out a little about the events.

All input events work fine if the JSFMLCanvas does have the focus on itself. The problem is that text fields and areas always request focus on themselves, so as soon as a text field or area is involved, the JSFMLCanvas will not receive any keyboard or mouse wheel events. The Input class will not work either in that case.

I'll have to play with this a little and see what could be done about it.

Concerning the resizing, no luck so far.

EDIT:
OK, interestingly, if the canvas does have the focus, the RenderWindow will not receive any resize events, but my custom resizing will work just fine!

So I'll need to somehow make sure that the RenderWindow has the focus in as many situations as possible...

I hope this page helps me to learn more: http://download.oracle.com/javase/6/docs/api/java/awt/doc-files/FocusSpec.html

EDIT 2:
OK, for the matter of resizing, it's enough if the canvas is focusable at all. The position popping doesn't happen anymore either, so even though the RenderWindow doesn't get any resize events, this seems to work just fine now.

EDIT 3:
The sizing issues are completely fixed now. I even added an option: you can have the image in the JSFMLCanvas scale with the canvas itself, or have its viewport extend so it can display more.

310

SFML projects / JSFML - A Java binding for SFML

« on: May 30, 2011, 08:49:32 pm »

If it has a window handle, it probably generates native resize events. A native window is not necessarily a top-level window, it may be a canvas, a button, a label, or whatever. So if you can get a native window handle from a control, you're not supposed to do anything else, SFML handles it.

What happens sometimes is that there are flags that control the behaviour of the canvas, and you may need to adjust them to get the expected results.

I am aware that "window" doesn't mean a window in the Windows sense only.

What are the flags I need to adjust? I suppose I do that using SendMessage in Windows?

311

SFML projects / JSFML - A Java binding for SFML

« on: May 30, 2011, 08:39:13 pm »

Good luck with this project!

EDIT : about the resize problem, couldn't you use something like http://download.oracle.com/javase/tutorial/uiswing/events/componentlistener.html ?

Thanks.
Gonna get back to you about Mac / Linux (whatever you can provide).

I don't need to be using a ComponentListener really, because I'm using a java.awt.Canvas subclass called JSFMLCanvas, I can directly react to resizes etc.

Keyboard events are most likely caught by the main window, I might try setting the focus on the JSFML canvas. Gonna try what Input reports as for which keys are pressed etc, to see whether that works fine.

Concerning the resize, those Java Canvases do have a window handle, but they are no ordinary windows, so to speak. So whatever RenderWindow does to detect a resize, I'm not surprised it doesn't work.

My question is, how can I modify the RenderWindow upon a resizing event? Simply setting its size causes this weird behaviour with a clipped area and it being bound to the bottom left.

312

SFML projects / JSFML - A Java binding for SFML

« on: May 30, 2011, 07:35:01 pm »

It seems like the RenderWindow is not getting OS events. Are you able to use an SFML event loop in this example, and get all events properly?

I only get these event types:

• MouseButtonPressed
• MouseButtonReleased
• MouseMoved
• MouseEntered
• MouseLeft

MouseWheel and keyboard events don't get caught, neither does the resize one.

What I actually tried is override the "setBounds" method in the JSFML canvas, which gets called everytime the control's size and position changes. In that function, I use the RenderWindow's "setSize" function, which results in the issue I described above.

313

SFML projects / JSFML - A Java binding for SFML

« on: May 30, 2011, 03:38:31 pm »

Another question: do you plan to maintain this binding in the long term? I'm asking because if it's serious enough, I can make it the "official" Java binding -- with packages on the download page of the website, and a forum here. Tell me what you think about it.
And did you already setup a public repository for the project?

As for the time being, I'm all up for it!
Before we go there I'd suggest that I make a usable version first.

So far I'm using a private SVN repository, I think it'd be no trouble to move it onto a github on this page.

It all might need some integration work, as I fully rely on Apache Ant to automate building right now. Not sure what standard you'd like to see if any. Also no idea yet how it's gonna look on Linux or Mac. The C++ code should work for any OS, it's mainly the includes and some very special code parts (retrieving a Java canvas' handle) that are platform dependant.

I say we should care about all that when I got something that works, especially considering you're updating the whole Drawable tree soon.

Actually, I think I'm doing the same thing in SFML.Net (using pure interfaces to allow multiple inheritance).

Yep, Java classes can implement multiple interfaces. This will mean some duplicate code but it's better than not having it at all. I'll look into this in the near future.

(<- I believe there's a phpBB extension that introduces this horizontal rule tag, very useful thing to make posts more readable )

Meanwhile, good progress getting a RenderWindow onto a Java AWT canvas!

(click to enlarge)

As you see, the basic stuff works, just a few details don't.
[list=1]

• The render area pops a little out of the canvas after a while. Looks to me like the RenderWindow's position gets changed for some reason, I'll try and find out what happens.
• The RenderWindow's resizing behaviour is a little weird, as you can see on the second picture. The area filled by Clear actually got enlarged with the canvas, however the render area is still clipped to the initial size, also the render area seems to be bound to the bottom left corner of the canvas. Any ideas?
[/list:o]

314

SFML projects / JSFML - A Java binding for SFML

« on: May 29, 2011, 03:23:59 pm »

Do you re-implement everything on your own? Maybe you could reuse some code of the older jSFML project, I don't know how evolved it is however.

Yep, did it from scratch. I have no idea how that older jSFML project worked and didn't look into it. I would believe our approaches are different, but I don't know and frankly I don't really care too much.

Are you using CSFML or SFML directly? Do you use JNI?

I'm using SFML2 (not CSFML) and the binding is done using the JNI, yes. Right now JSFML consists of a jar (the Java library) and a dll (for Windows), the dll was supposed to simply contain delegation functions but now I also statically linked SFML into it (because of that sf::Text problem I had, you'll remember my "bug" report a few days ago).

the Renderer class won't exist anymore in a few weeks. So as the Drawable base class.

OK, gonna be interesting to see what the new class layout looks like then.

Why can't you provide the Window class? It's very useful for people who just want an OpenGL context.

I think I could provide it, but I laid focus on the Graphics and Audio modules really because that's where Java lacks possibilities greatly.

If you simply need an OpenGL context, you could use LWJGL, which is a raw Java binding to OpenGL, OpenAL, OpenCL and some other libraries. Works well, but if you were to create a game engine or similar you'd still have to do all the work from ground up, which I became sick of and thus looked for something that features the most common things out of the box while being flexible at the same time.

Anyway, another reason I didn't include it yet is because Java doesn't support multiple class inheritance (one of the greatest drawbacks really). It'd be a pain to get Window and RenderTarget connected into one class. I'm sure there is a Java way to approach this, but like many things done the Java way it'd probably be very ugly...

If you can manage to retrieve the system handle of a SWIG control, you can directly use the Window constructor that takes a native window handle. I don't know if it's possible with Java, but for example it works with .Net.

Yep, that's exactly where I'm heading. I've been getting crashes trying to retrieve an AWT Canvas' window handle though, so I moved this into the future for now.

And I love the logo

Thanks :lol:

315

SFML projects / JSFML - A Java binding for SFML

« on: May 29, 2011, 11:43:02 am »

After a good while of hidden progress, I can finally give a first sneak peek at JSFML, a Java binding for SFML.



The goal of this project is to allow Java developers like myself to make use of SFML, which I find to be the most straightforward multimedia library out there. A project like this happened to exist already, but has seemingly died ( http://www.sfml-dev.org/forum/viewtopic.php?t=1256 ). Therefore I am also allowing myself to use the same name, even though my version has nothing to do with that cancelled attempt.

The idea behind JSFML is not to implement all the SFML features in Java from scratch, but instead to define wrapper classes that delegate their functionality to the actual SFML. This is done using native code and has been working very well, however I have not been able to test the native part on any OS other than Win32 so far.

JSFML is based on the latest SFML2 snapshots. Since SFML2 is still in development, I will not yet release JSFML, however, I might release some builds in the near future for people to try.

So sorry, this is no release thread, but an announcement only.

The following is an overview of JSFML's features and status concerning the SFML modules.

SFML modules

Graphics
Most of the SFML Graphics module will be available for JSFML. Almost all classes mentioned in the SFML2 documenation are already supported. One exception is the Glyph class which I don't see any use for in JSFML (if you know any reason why I should make it available, let me know).



A more notable exception is the Renderer class. Using JSFML, you can not yet create custom Drawables, that's also why the Renderer class has not yet been bound. This feature will require quite some work and therefore is planned for a future release, set for when the basic stuff is proven to work.

Audio
Most of SFML's Audio module is already available. You can load and play sounds and musics SFML style.

What's not really done yet is the ability to implement custom sound streams (e.g. for MP3 support). The basic foundation for that is already done, but I have not been able to test this yet. Much like custom Drawables, this is set for a future release.

Network
The Network module of SFML will not be available in JSFML, frankly because there's absolutely no need for it. The Java runtime library provides everything you need for networking.

System
Much like the Network module, SFML's System module is mostly unneeded for JSFML. Java provides multithreading, timing and unicode supprt.

However, the Vector2f and Vector3f classes will be defined as minimal data holders to simplify communication between JSFML and SFML. I do not think vector mathematics should be part of a multimedia library, instead people can extend these minimal vector classes and stuff in as much functionality as they like.

Window
The Window module port will fully include Event and Input handling and also provide the ContextSettings and VideoMode classes. The Window class itself will not be available, you will be forced to use the (fully supported) RenderWindow class of the Graphics module in the first releases.

In future releases, I plan to make it possible to have a Java Swing control wrapper around a RenderWindow so you can perfectly integrate a render targetinto your Swing GUI. So far I have only done some research on this, and this will be tough...



I am currently writing a Javadoc for this which I will upload as quickly as possible. In late June, you can expect a sneak peek release (most likely Win32 only).

In the meantime, feel free to share your comments, ideas and ask questions.