Welcome, Guest. Please login or register. Did you miss your activation email?

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Topics - pdinklag

Pages: 1 [2]
16
Audio / sf::SoundSource::getStatus()
« on: August 20, 2012, 06:43:14 pm »
Is there any special reason for sf::SoundSource::getStatus() having protected access only?

Both stock SFML specializations (sf::Sound and sf::SoundStream) override its access to be public, and I do not really see a reason why it should be hidden away by default if anybody is to implement his own additional sound source (whatever that would be). The playing status of a sound source is an important thing to know no matter what the specific source is.

The fact that it is protected now makes it impossible for generic handling of sound sources. I am having this issue now, trying to minimize the amount of native calls to SFML for the Java binding, but I'm sure somebody will eventually run into this with other intentions, cleanup on exit for instance.

So, is there any special thought behind this protected access or may I ask for it to be changed to public? :)

17
Java / Implementable Drawable class
« on: August 14, 2012, 09:44:45 pm »
Currently, JSFML lacks a way of implementing custom drawables. By that, I mean that there is no Drawable interface that declares a drawing method that can be implemented in pure Java and that defines how an object is drawn. It can, of course, be done by writing a draw method that takes a RenderTarget as an argument and will proceed to draw to it, but this practically inverts the common SFML semantics of RenderTarget.draw(Drawable) and is therefore not ideal.

The question is how to do it properly. Currently, org.jsfml.graphics.Drawable is a basic interface without any method definitions, the main reason for this being the private access of the draw method in sf::Drawable implementations. Therefore, my solution proposal is as follows:

For JSFML (which uses its own set of SFML headers), modify the draw methods of the stock sf::Drawable implementations to be public. This is the simplest of ways and there should not be any real drawback. Nobody will use the JSFML headers for writing SFML applications in C++, so this would break SFML's design for JSFML's internals only.

In RenderWindow and RenderTexture, the draw methods would no longer be implemented natively, but delegate to the draw method of the respective Drawable on a Java level,  which then is delegated to native code, ie exactly like SFML does this itself (except it has access to the protected method). This would result in a single Drawable interface that is implemented natively for the native SFML classes and can be equally used by custom implementations. This would also fix another serious problem that currently exists in the JSFML API: the Drawable interface has to be public, but currently it must not be implemented by anything that is not an SFMLNativeObject and passed to RenderTarget.draw, because it assumes an underlying SFML object.

I'm open to other solutions, of course. I don't really like to touch the SFML headers in any way, but on the other hand, this is a minor change with a huge benefit for the binding.

18
General / [SOLVED] Cannot link against SFML2 on Linux
« on: August 05, 2012, 10:08:18 am »
Hey!
I feel like issues like these are discussed here everyday, but I cannot find any solution.

I'm trying to build JSFML for Linux (Ubuntu 12.04 LTS, 64-bit), but I keep getting undefined references for every single SFML symbol. I built SFML using CMake (no modifications or special flags set, it used to work like this before) and without errors, then copied the binaries into my JSFML dependency directories.

The build command is as follows:
Code: [Select]
[exec] Executing 'g++' with arguments:
     [exec] '-I/home/pdinklag/JSFML/include'
     [exec] '-I/home/pdinklag/JSFML/sfml/include'
     [exec] '-I/usr/lib/jvm/java-6-openjdk-amd64/include'
     [exec] '-I/usr/lib/jvm/java-6-openjdk-amd64/include/linux'
     [exec] '-shared'
     [exec] '-fPIC'
     [exec] '-o/home/pdinklag/JSFML/out/bin/linux_x64/libjsfml.so'
     [exec] '-Wl,-no-undefined,-L/home/pdinklag/JSFML/sfml/bin/linux_x64,-lstdc++,-lsfml-system,-lsfml-window,-lsfml-graphics,-lsfml-audio'
     (... list of cpp files to compile)
     [exec] The ' characters around the executable and arguments are
     [exec] not part of the command.

I get this error for seemingly every SFML symbol:
Code: [Select]
[exec] /tmp/cc6x6B0J.o: In function `JSFML::Color::ToSFML(JNIEnv_*, _jobject*)':
     [exec] Color.cpp:(.text+0x1e1): undefined reference to `sf::Color::Color(unsigned char, unsigned char, unsigned char, unsigned char)'
     [exec] /tmp/cc4jQlbv.o: In function `JSFML::RenderStates::ToSFML(JNIEnv_*, _jobject*)':
     [exec] RenderStates.cpp:(.text+0x201): undefined reference to `sf::RenderStates::RenderStates(sf::BlendMode, sf::Transform const&, sf::Texture const*, sf::Shader const*)'
     [exec] /tmp/ccIR6QV3.o: In function `JSFML::Time::ToSFML(JNIEnv_*, _jobject*)':
     [exec] Time.cpp:(.text+0xeb): undefined reference to `sf::microseconds(long long)'
     [exec] /tmp/ccIR6QV3.o: In function `JSFML::Time::FromSFML(JNIEnv_*, sf::Time const&)':
     [exec] Time.cpp:(.text+0x10a): undefined reference to `sf::Time::asMicroseconds() const'
     [exec] /tmp/ccgkSzcD.o: In function `JSFML::Transform::ToSFML(JNIEnv_*, _jobject*)':
     [exec] Transform.cpp:(.text+0x17c): undefined reference to `sf::Transform::Transform(float, float, float, float, float, float, float, float, float)'
(...)

Obviously, it fails to link against any SFML library.

Now, I made sure that the shared object files are actually found by the linker using this:
Code: [Select]
pdinklag@pdinklag-linux:~/JSFML$ ld -L/home/pdinklag/JSFML/sfml/bin/linux_x64 -lsfml-system -lsfml-window -lsfml-graphics -lsfml-audio
ld: warning: cannot find entry symbol _start; not setting start address

I'd be getting a "library not found" message if anything was actually not found, so that's cleared out.

Now I'm pretty much out of ideas and feel like something went wrong linking SFML itself. As mentioned, I used the default CMake setup that's on github, no special flags set or anything, and it used to work fine before. Is there anything I missed, anything I need to make sure?

19
Java / Writing Tutorials
« on: February 04, 2012, 11:12:23 am »
I started writing tutorials and polishing the website. Suggestions and hints are very welcome! :)
http://jsfml.org
Wiki (with tutorials): https://github.com/pdinklag/JSFML/wiki

I hope the site does not awake the impression that I take all the credit for SFML. After all, I "only" wrote a connection to it. Though, I think that the Java binding could play a big role in the future and deserves its own website. The only real way to have decent OpenGL in Java at this time is LWJGL, and using that requires OpenGL knowledge, which is not suitable for beginners. JSFML is.

20
Graphics / Forcing a certain GLSL specification
« on: January 31, 2012, 09:08:09 pm »
Is it possible to somehow tell the GPU to compile GLSL programs following a certain specification? Let's say my GPU supports the latest GLSL, but I want to make sure my shader program is compatible to GLSL 1.10 (OpenGL 2.0) to avoid problems like this one: http://www.sfml-dev.org/forum/viewtopic.php?t=6930 .

If so, I believe the sf::Shader class (or, depending on how it'd work, the sf::ContextSettings class) should support that feature. I can tell for sure that setting the OpenGL major and minor versions in the context settings does not influence the GLSL specification used for compiling.

21
General / SetFramerateLimit does not seem to work correctly
« on: January 30, 2012, 06:13:27 pm »
Likely related to https://github.com/SFML/SFML/issues/162 (saw this after I wrote this post, sorry)

I noticed oddities while working on JSFML. I set my window's framerate limit to 60, but in fact my test application runs at about 120 FPS. In fact, it varies. Sometimes, the application also runs at 100, I had times where it would only run at 30 for a while, then all of a sudden go up to 120.

I'm not sure what exactly might be the problem, but here is how I can reproduce it:

Code: [Select]
#include <SFML/Graphics.hpp>

int main(int argc, char **argv) {
sf::RenderWindow window(sf::VideoMode(640, 480), "FPS Test");
window.SetFramerateLimit(60);

int numFrames = 0;
int msLeft = 1000;

sf::Event e;
sf::Clock clock;

while(window.IsOpen()) {
while(window.PollEvent(e)) {
if(e.Type == sf::Event::Closed)
window.Close();
break;
}

sf::Time delta = clock.Restart();

numFrames++;
msLeft -= delta.AsMilliseconds();

if(msLeft <= 0) {
printf("Frames last second: %d\n", numFrames);

numFrames = 0;
msLeft += 1000;
}

window.Clear();
window.Display();
}

return 0;
}


This is counting the actual frames within 1000 milliseconds. Unless I'm totally out of my mind this should be a working way to test the FPS. I'm aware this is not perfectly accurate, but it should not be counting 120 frames anyway.

My output of that program a few minutes ago looked as follows (Windows 7 32 bit, Release, latest SFML from github):
Code: [Select]
Frames last second: 115
Frames last second: 124
Frames last second: 114
Frames last second: 115
Frames last second: 121
Frames last second: 117
Frames last second: 115
Frames last second: 120
Frames last second: 119

22
Java / How to build JSFML
« on: January 29, 2012, 06:46:23 am »
The guide to build JSFML has been moved to the Github Wiki: https://github.com/pdinklag/JSFML/wiki/Building-JSFML

Discussion should still happen here. :)

23
Java / Java integration features
« on: January 29, 2012, 04:34:29 am »
While the first release of JSFML will be more like a direct binding to SFML standing by itself, in later versions I would like to build up a range of features to integrate JSFML into Java environments.

Generally, to be able to tell apart between pure SFML bindings and Java integration features, new classes for this task will get a different root package. I am still split about whether to call it org.sfml.java or simply org.jsfml, but I'm leaning towards the latter.

What follows below is a list of goals I want to achieve, a todo list so to speak, which I would like to discuss and possibly extend using this discussion thread.
  • RenderCanvas
    This feature will be a major milestone. It is a Java canvas that can be used as an SFML render window, thus making it possible to have OpenGL contexts in any Java AWT / Swing user interface, including browser applets.

  • Type conversions
    I will introduce several conversion methods between common SFML and Java AWT types. This includes:
    • org.sfml.graphics.Colorjava.awt.Color
    • org.sfml.graphics.FloatRectjava.awt.Rectangle
    • org.sfml.graphics.Imagejava.awt.image.BufferedImage
    • org.sfml.graphics.IntRectjava.awt.Rectangle
    • org.sfml.system.Vector2ijava.awt.Point
    • org.sfml.system.Vector2fjava.awt.Point
    The conversion methods will come as special copy constructors and toXYZ() methods in the SFML classes.

  • Implementable Drawable class
    This will be an abstract subclass of org.sfml.gaphics.Drawable, allowing custom drawables to be implemented in Java. This can be used to create simple extensions of existing drawables such as compounds, but also to create a possible link between JSFML and LWJGL, which would also allow 3D rendering via JSFML.

    A note on that: JSFML is not to be seen as some sort of competitor to LWJGL. LWJGL focuses on providing direct access to OpenGL, OpenAL and OpenCL functions for Java, while JSFML focuses on providing a binding to the straightforward SFML library. There are some aspects that are covered by both libraries (especially concerning input), but in such cases, the user has to decide what to do.

  • Implementable SoundStream class
    This will be an abstract subclass of org.sfml.audio.SoundStream, allowing custom sound streams to be implemented in Java. This will make it possible to write MP3 decoders in Java, for example, and makes JSFML less dependent of C++ source code. A subgoal of this should be to attempt and connect JSFML to Java's sound API (which I do not know too much about yet). That way, any already existing sound decoder library available for Java could also be used for JSFML.

  • AWT / Swing component rendering
    This is still more of a brainstorming, I am not entirely sure how well this will be possible. The idea is to make it possible to render and possibly even manage AWT / Swing components within an SFML render window. This would be the perfect way to create complex GUIs within JSFML applications, using a toolset every Java developer should be perfectly used to. Since it would also support Java LookAndFeels, there would be practically no limits concerning styles either.

24
Java / JSFML - Information
« on: January 21, 2012, 08:49:32 pm »


JSFML is the official Java binding to SFML, a Java library that provides Java applications with access to a wide range of the functionalities of SFML.

Java has been missing a simple, straightforward, but at the same time efficient multimedia library. It is the goal of JSFML to provide such a library for Java developers by taking advantage of the straightforward design and blazing performance of SFML.

What JSFML is and is not
JSFML is a Java binding to SFML. It is not Java re-implementation of SFML. This makes JSFML relatively easy to maintain and ensures that it can be updated to the latest SFML release, including all new features and bugfixes, in a minimal amount of time.

Features
JSFML focuses on bindings to the Graphics, Audio and Input features of SFML as well as all related helper and utility types. Features like multi-threading, networking and unicode support, which Java provides out of the box, are not considered.

Planned features include integration of SFML RenderWindows into AWT / Swing applications, which would also allow the use of SFML in browser applets.

JSFML works on Windows and Linux systems (Mac OS X is planned as well!). The "self-contained" package includes automatic extraction of the platform-specific binaries from the jar file into the user's home directory. This way, developers will not have to bother with packaging JSFML properly, but can simply redistribute the JSFML library as one single jar file.

Conventions
Since JSFML is a binding to SFML, the API will be layed out similarly. However, some things done in C++ are not possible in Java. This includes const references and operator overloading. JSFML follows the following principles:
  • Overloaded operators for SFML objects are represented by appropriately named static methods within the class in question.
  • Objects passed to JSFML methods are never modified by those unless it is explicitly mentioned in the documentation.
  • Objects retrieved from SFML that should not be altered, such as the default font or a render texture's texture object, are of an invisible immutable subtype and reject any change attempts silently.
  • A range of method parameters is marked as @NotNull. If null is passed for these parameters, JSFML will throw an IllegalArgumentException.
For a seamless Java integration, the following conventions intentionally differ from those of SFML:
  • camelBack naming convention for methods, ALL_CAPS naming convention for enum values and constants.
  • Instead of returning a success value (true or false) when resources are loaded, JSFML throws exceptions if something goes wrong.

Source code
JSFML's source code is available from its Github repository: https://github.com/pdinklag/JSFML
Please refer to the notes found there in case you want to build JSFML.

Requests, ideas, bugs and other issues
Feel free to post these in this forum, but also consider getting a Github account and post them in the Issue Tracker for better organization!

Tutorials
On the Github wiki: https://github.com/pdinklag/JSFML/wiki

Javadoc
A Javadoc for JSFML can be found at: http://jsfml.org/javadoc/

Releases
There are no releases of JSFML just yet, but stay tuned to this forum for test pre-releases!
JSFML is set for a first official release not long after the official release of SFML 2.0.

25
Java / Working around operator overloading
« on: January 21, 2012, 03:53:51 pm »
So let's get this forum rolling. 8)

This question already popped up in the initial JSFML discussion: how will overloaded operators (e.g. for sf::Vector or sf::Color) be represented in JSFML?

I have worked with several Java libraries that attempted to do this, and every single one of them had some kind of ugly flaw to it that made working with it a pain. The approach I personally regard as the "best" is to interpret operators as static functions within the class in question. Unary operators take one parameter, binary operators take two parameters. The returned object is actually a new one, so none of the objects passed is altered in any way.

So, as an example, the + operator for Vector2f would look like this:
Code: [Select]

class Vector2f {

public static Vector2f add(Vector2f a, Vector2f b) {
  return new Vector2f(a.x + b.x, a.y + b.y);
}

[...]

}

An alternative to calling it "add" would be "sum", but personally I see it like functions should be named after what they do, not after what they yield.

Now, assignment operators like += that alter the left operand would be missing. They certainly are very convenient, plus you don't always want the result to be in a new object. I would implement them as object methods like this:
Code: [Select]

class Vector2f {

  public Vector2f add(Vector2f v) {
    this.x += v.x;
    this.y += v.y;
    return this;
  }

}

I am not sure whether it's a problem to name them the same. From the context (object or class), it should be easy enough to differentiate. The += should yield "this" in my opinion, as this allows chain calls such as:
Code: [Select]

Vector2f v = new Vector2f(1, 0).add(u).mul(4).normalize();


So, in conclusion, I consider the following methods for Vector2f:
Code: [Select]

static (returns new object):

static Vector2f add(Vector2f a, Vector2f b); //vector addition
static Vector2f sub(Vector2f a, Vector2f b); //vector subtraction
static Vector2f mul(Vector2f a, float s); //scalar multiplication
static Vector2f mul(Vector2f a, Vector2f b); //scalar (component-wise) multiplication
static float dot(Vector2f a, Vector2f b) //dot product
static Vector2f normal(Vector2f v); //normal of v
static Vector2f neg(Vector2f v); //negated v

object (returns this):

Vector2f add(Vector2f other); //vector addition
Vector2f sub(Vector2f other); //vector subtraction
Vector2f mul(float s); //scalar multiplication
Vector2f mul(Vector2f other); //scalar (component-wise) multiplication
Vector2f normalize(); //normalizes the vector
Vector2f negate(); //negates the vector

Classes such as Color or Time would get their respective versions.

26
General / [Solved] Access Violation in FT_Load_Char
« on: January 18, 2012, 10:38:02 pm »
I'm facing a weird problem working on JSFML.
While experimenting with Fonts and Texts, I hit on sudden access violations in the C++ part that appeared very random.  With the help of a disassembler, I could trace back the problem and it definitely occurs in some subsequent (2 further call levels, can't find it exactly) code invoked by FT_Load_Char. Indeed, I can reproduce the problem by making it load a new glyph every frame, after a while it would crash. However, this only happens from within a Java VM, I cannot reproduce it in a pure C++ program.

The glyph which it fails to load seems to be arbitrary. Trying to read any glyph from FreeSerif crashes instantly, but it works fine with FreeMono up to a certain point. This never seems to happen with the SFML default font, which is probably why I never noticed it so far.

I noticed that under Windows (building with MinGW), freetype is linked statically into SFML. Which version is it exactly? I would like to examine the freetype sources further to find exactly the line of code that causes the access violation. Are there any known problems or things to know about freetype that might be involved here?

I will also try to reproduce this problem on Linux tomorrow.

27
Audio / sf::Music - GetDuration() and GetPlayingOffset()
« on: August 15, 2011, 12:25:56 pm »
I'm confused by the return values of these two functions. GetDuration() does not return the actual stream's duration, and GetPlayingOffset() seems to "rotate" in some weird way.

I'm dealing with an ogg vorbis file that streams for 1:15 minutes, so I'm expecting a duration of roughly 75000ms, however, GetDuration() returns 26744ms for me. GetPlayingOffset() seems to return the true offset for a while. However, it goes beyond the duration that gets returned, and when it reaches ~50000ms, it gets reset back to zero and starts counting up again.

During all of the time, the music plays just well, it's just the duration and the playing offset methods that yield weird values.

I'm using an SFML 2.0 C++ build as of late July. The file in question is http://stuff.pdinklag.de/overworld1.ogg (please don't redistribute, worked on this all morning :P).

EDIT: The update as of August 8th fixes the playing offset rotating, but not the wrong duration being returned.

28
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. :)

29
General / Freeze trying to load sfml-window-2.dll
« on: March 11, 2011, 07:23:59 pm »
Hey again!

I have built SFML2 with MSVC++ 2010 on Windows 7 (32bit) with the "Release" configuration. It compiles and links fine, however, "sfml-window-2.dll" cannot be loaded.

There is no error or anything, any application trying to load "sfml-window-2.dll" will straight up freeze. I noticed that when my Java application froze and first thought it might be Java having issues, but now I could reproduce this problem using the following simple program:
Code: [Select]
#include <stdio.h>
#include <Windows.h>

int main(int argc, char** argv) {
printf("Before loadLibrary\n");
HMODULE module = LoadLibrary(L"sfml-window-2.dll");
printf("After loadLibrary (module = %d)\n", module);

return 0;
}

You will get the output "Before loadLibrary", and then it freezes for good. This means that any SFML application using the Graphics or Window module will freeze on startup.

On another machine with Windows XP (32bit as well), where I compiled SFML2 using MSVC++ 2008, everything works fine. So this is either an issue with Windows 7 or the MSVC++ 2010 runtime. Running the application with Administrator priviliges did not help here.

Any idea what might be going on here?

30
General / Access Violation in SFML 2.0 when destroying resources
« on: March 10, 2011, 07:55:40 pm »
Hey!

I've stumbled upon this wonderful multimedia library the other day and found that it featured most things which I would have had to implement by myself. Easy to use straightforward API and cross-platform, exactly what I need. :)

Unfortunately, there was no Java binding, and the one that had been started seems to be dead by now, so here I am writing my own which I may or may not release at some point - but more on that at another time. ;)

I'm writing Java classes that are wrappers around their corresponding SFML classes. When such a Java class is instantiated, I call a native (C++) method that will create an SFML object (using "new") and store the pointer to it back into the Java object. When the Java object gets "finalized" (if you're not into Java: that's pretty much like destruction), I use "delete" to destroy the SFML object refered to by the pointer.

Consider this example of the Image class:
Code: [Select]

JNIEXPORT jlong JNICALL Java_org_sfml_Image_nativeCreate (JNIEnv *env, jobject obj) {
return (jlong)(new Image());
}

JNIEXPORT void JNICALL Java_org_sfml_Image_nativeDelete (JNIEnv *env, jobject obj) {
Image* ptr = PTR(Image);
if(ptr) delete ptr;
}

Note: "PTR" is a macro that retrieves the pointer in the Java object "obj".

When I started I wanted to make sure I'm working with a stable SFML, so I used SFML 1.6. Everything was working fine this way.

However, I have started to upgrade things to SFML 2 today and unfortunately that causes an access violation whenever a resource (Image, SoundBuffer, Font, etc.) gets destroyed. To track the problem down, I made a simple test application that will load an Image from a file and then destroy it.

The exception was this:
Code: [Select]
EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x5f0d530e, pid=1176, tid=1484

This was the stack trace:
Code: [Select]
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C  [OPENGL32.dll+0x530e]
j  org.sfml.Image.nativeDelete()V+0
j  org.sfml.SFMLNativeObject.finalize()V+45
v  ~StubRoutines::call_stub
V  [jvm.dll+0xecf9c]
V  [jvm.dll+0x1741d1]
V  [jvm.dll+0xed01d]
V  [jvm.dll+0xf5e2f]
V  [jvm.dll+0xf8b24]
C  [java.dll+0x2115]
j  java.lang.ref.Finalizer.runFinalizer()V+45
j  java.lang.ref.Finalizer.access$100(Ljava/lang/ref/Finalizer;)V+1
j  java.lang.ref.Finalizer$FinalizerThread.run()V+11
v  ~StubRoutines::call_stub
V  [jvm.dll+0xecf9c]
V  [jvm.dll+0x1741d1]
V  [jvm.dll+0xed167]
V  [jvm.dll+0xed1dd]
V  [jvm.dll+0x116290]
V  [jvm.dll+0x1d0414]
V  [jvm.dll+0x173e4c]
C  [msvcr71.dll+0x9565]
C  [kernel32.dll+0xb50b]


Apparently, something went wrong in opengl32.dll while destroying the object.
The only invocation of an OpenGL function inside the Image destructor that I found is this (Image.cpp line 88):
Code: [Select]
GLCheck(glDeleteTextures(1, &Texture));

I'm not sure what could possibly go wrong here. As mentioned, the Image object was created using "new" and destroyed using "delete", the image has been loaded from a jpg file. The OpenGL version on the Windows XP machine I'm developing on is only 1.4, but this was not a problem with SFML 1.6.

Do you have any idea what could be going wrong here?
Thanks a lot in advance!

Pages: 1 [2]