Messages

16

Java / Re: JSFML for SFML 2.2

« on: March 16, 2015, 07:57:13 am »

You should be able to verify your libjpeg version by asking your package repository. I don't think 8d is required, I always used the latest. The key is that it needs to be linked statically for distributions like Fedora, which only comes with libjpeg-turbo.

About libglew, that's what I did. Grab an old version (should be 1.5) and compile it myself - it also needs static linking. For what I remember, SFML's cmake script will complain about newer libglew versions, unless that was changed or there were other reasons. It's been a while. 

17

Java / Re: From JTextField to JSFML RenderWindow

« on: February 20, 2015, 01:16:41 pm »

First off, you might be running into threading issues, but even if you rule them out, your code is not going to work.

Upon the click of the button, you would draw a circle in the window ONCE only. Your main loop will immediately clear and redraw the whole window, however, so the circle is gone.

You commented out this line:

//if (shape!=null)  rw.draw(shape);

This would be the correct way to approach the issue, save the shape in a member variable and use that in your main loop. Make sure that you synchroninze any modification of that variable, because you are dealing with multiple threads (please read up on Swing / AWT event handling and the AWT thread, I can't offer support for that here).

How to compile project using command line?

Nothing special here, just make sure jsfml.jar is in the classpath.

18

Java / Re: JSFML for SFML 2.2

« on: February 09, 2015, 01:38:17 pm »

Well, what I need are the shared object files (except for networking) of SFML 2.2 built for Linux x64 with libglew-1.5 (or is it 1.6?) and libjpeg8d linked statically. It's messy, I know, but I failed to find a better way to solve those dependencies (e.g. Fedora does not have libjpeg and many systems only have libglew-1.7 or later).

Then the native part of JSFML needs to be built on Linux x64 as well (using "ant linux64") - the output file libjsfml.so needs to be packaged in the release jar.

I'll have to set up some VMs again to make it an automated workflow, but I don't look forward to the effort, especially since VirtualBox had a lot of problems with Debian 7 and/or my host system.

19

Java / Re: JSFML for SFML 2.2

« on: December 19, 2014, 12:39:05 pm »

I applied the SFML 2.2 updates, although they are untested for now.

For the Mac version, ping me when it's ready to be built. 

Thanks! I will get to you about this once I tested the updates, so you won't have to build unstable builds.

Does your computer have 6 gigs of RAM or more?  If it does a virtual machine might help with getting a Linux  Development system running.

Yep, that's what I did before. I had two virtual boxes, one for Linux x86, one for Linux x64. At some point this year, I got rid of them, but I might go for that setup again.

20

Java / JSFML for SFML 2.2

« on: December 18, 2014, 06:53:11 am »

This is just a little sign of life.
Life is keeping me very busy these days, I hope that I can find some time to update JSFML for the new SFML release sooner than later.

From what I've seen, there are not many API changes, so it should all go relatively quick once I find some time.

The problem will be - as always in the past - building and packaging the native (C++) part. I don't have any Linux development systems I use regularly, so the ones I used last are heavily outdated. I also don't own a Mac to build the OS X version. If anybody could help out here, I'd highly appreciate it.

21

Java / Re: How to depoly JSFML game?

« on: December 18, 2014, 06:43:09 am »

Well, how are your resources laid out, and how do you load them? Maybe let's know where your background image is located in your project, and how you load it in the game? That might help getting the answer here.

Do you by any chance know how to do this in Eclipse? Where is the manifest supposed to be located

Nope, I'm not using Eclipse myself, but that bit of info should be easy to find out there.

22

Java / Re: How to depoly JSFML game?

« on: December 16, 2014, 11:03:37 am »

(First off, note that this is not an Eclipse support forum, and I can't help with Eclipse specific problems at all.)

Extract required libraries into generated jars

This sounds scary, what exactly does this do?
I recommend not merging contents of other libraries into your own jar. You might run into licensing troubles - not concerning JSFML, but generally this is an issue. Rather set your jar's classpath in the manifest to jsfml.jar and deploy that separately. It's also easier to update if ever necessary.

the window pops up and the rest of the window is blank white. Then it stops responding.

Is it your game's window? If so, sounds to me like resources can't be found. You share too little information about your project, though, so I cannot really help here.

Make sure that your resources are available in the deployed version. If you load them from the classpath, make sure they're in your jar file. If you load them file-based, you cannot contain them in your jar, but you need to deploy the directory as it is in your development environment.

23

Java / Re: Embed JSFML into SWING

« on: November 12, 2014, 09:23:00 am »

There is a "render-canvas" branch on Github, which worked fine for Windows and Linux the last time I checked. However, there is no release package for it at the moment, so you'd have to build it yourself, that includes the binaries.

Since Swing WILL be abolished and replaced by Java FX in the future, that practically killed my motivation to continue putting any effort into the branch. Therefore, I am not sure if I will ever round this branch up so it goes into the main version of JSFML. There is also zero Mac OS X support for it at this point.

EDIT:
See this thread for some more info, somebody else also tried it before: http://en.sfml-dev.org/forums/index.php?topic=14538.0

24

Java / Re: SFML book source code port

« on: November 05, 2014, 08:02:30 am »

Looks very good indeed!

I have not read the SFML book so I'm not into the examples at all. I also never really thought of the "use case" of translating C++ SFML applications to Java, so there might indeed be some trouble here and there. I'm actually very pleasantly surprised that the only issues seem to occur in the networking part, which I didn't even port.

Java's network library works pretty well, but I'm not sure how close or different it is from the SFML approach. I don't really have the time these days to look through your whole networking code, so as Nexus put it, you should be a little more specific with the exact issues and give us proper introduction - the "minimal reproducible example" approach.

Though he might be right, your questions will most likely be specific to Java networking. That's not exactly on-topic in this forum, but I'd still be willing to help. After all, networking is a part of SFML, and the reason I didn't port SFML's networking features is because I believe the Java networking comes with all you need. Might as well prove that in this forum.

25

Java / Re: How to build JSFML

« on: October 14, 2014, 10:30:26 am »

SFML is used directly, not CSFML.
And correct, the master branch is still based on the SFML 2.1 API, but you found this out already.

From what it looks (I haven't really looked at any 2.2 API changes yet), the BlendMode enumeration will cease to exist and be replaced by a simple class that represents that struct you posted.

This will have an effect on the central drawing dispatcher: SFMLNativeDrawer. The method signatures will need an update from an integer blend mode ordinal to, probably, two integers: factor and equation ordinals. The respective native code will have to be updated accordingly.

It should not be too much work, really, but I'd like to wait until the 2.2 API is "done", so I can take a week or two and do a quick update of JSFML.

26

Java / Re: sockets

« on: September 26, 2014, 01:07:28 pm »

Indeed, sockets are provided by the java.net package. Therefore, there is no port of SFML's sockets.

27

Java / Re: Android

« on: June 27, 2014, 09:33:14 pm »

No, we're using the NDK, so there's not Java directly involved.
Java API for C++, how would that work?

Well, that's exactly what JSFML is. Except for a few types mapped to Java, all the functionality happens in plain old SFML. The delegation is implemented natively, ie in C++.

Android support is not just a binding, but it's built into SFML. You use the NDK and set the right CMake flag and you end up with Android libs.

Hm, that means that JSFML should work fine on Android if the delegation was compiled for Android as well and included in the package. Other than that, no changes should be required.

However, Android development is uncharted area for me and I am one of the few people left that despise mobiles...

28

Java / Re: Android

« on: June 26, 2014, 11:13:43 am »

Isn't SFML's Android binding implemented in Java anyway? Or doesn't it at least provide a Java API? (if not, it really should)

In any event, JSFML is not related to the Android binding. I trust that whenever it is officially released, Laurent will create a separate forum for it.

29

Java / Re: Incorporating OpenGL with JSFML

« on: June 10, 2014, 06:28:32 am »

LWJGL works very well for 3D environments, see Minecraft...

I'm honestly not sure what the better choice is, because when it comes to 3D, I'm not keen on any existing Java engine. LWJGL is used for Minecraft, so there you have a proof that it does work. JOGL seems to be for scientific purposes. Correct me if I'm wrong, but I haven't seen JOGL being used for games so far.

30

Java / Re: JInternalFrame and a RenderWindow?

« on: June 10, 2014, 06:26:25 am »

What don't you understand about the JavaFrame example, anything specifically? Your question is pretty generic and since there is a working example, I'm not sure how exactly to help you now.

I think the RenderCanvas' JavaDoc explains it well enough.
You need to pass a runner to the RenderCanvas when creating it. This runner is supposed to be your main loop. You shouldn't have your main loop in your normal program flow, because in Swing UIs, you are dealing with multiple threads.

By the way, the render-canvas branch might be discontinued in the future. I am not quite sure about its state yet, but Oracle is going to deprecate Swing and will push JavaFX, starting with Java 8. Therefore, I'm not sure how much effort I'm willing to put into completing this branch.