316
General discussions / ATI fix
« on: March 21, 2011, 03:21:24 pm »
I'm so trying this now. 
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.
317
General discussions / My plans for the website tools
« on: March 18, 2011, 03:59:26 pm »
Dedicated repositories per binding would be the way to go if you ask me, but they should all be linked to the SFML project as Groogy mentioned. That can be done on the website. Have a separate "Bindings" page and mention them there.
That way each author can decide what he wants to use. If github allows multiple repositories per project, that would be a way, too.
That way each author can decide what he wants to use. If github allows multiple repositories per project, that would be a way, too.
318
General discussions / My plans for the website tools
« on: March 18, 2011, 03:16:06 pm »
Git is probably the better choice for the distributed development of the several bindings.
You might reserve a repos for a Java binding, cause I might decide to make mine public, it's working pretty well so far.
Yay!
You might reserve a repos for a Java binding, cause I might decide to make mine public, it's working pretty well so far.
Quote
You should celebrate the move to GIT by getting the ATI fix out on it
Yay!
319
Graphics / Newb Sprite question
« on: March 15, 2011, 04:17:43 pm »
Not copies, but you're generating a new Sprite in every loop iteration, which isn't necessary whatsoever. Why not create one Sprite and use that throughout the loop like so:
You simply move the creation of the Sprite to before the loop enters. It will be available inside the loop from that point on, and there's nothing else you need to change!
Oh, btw, no need to mark your question as a "newb" question, in fact, that will demotivate a good amount of people to even read. Be a little more confident! We have all started at some point.
Code: [Select]
sf::Sprite Test(Ball);
for (i=0; i<20; i++)
{
[...]
}
You simply move the creation of the Sprite to before the loop enters. It will be available inside the loop from that point on, and there's nothing else you need to change!
Oh, btw, no need to mark your question as a "newb" question, in fact, that will demotivate a good amount of people to even read. Be a little more confident! We have all started at some point.
320
Graphics / Tint an Image
« on: March 14, 2011, 06:36:02 pm »
You would display that image using a Sprite in SFML, and Sprites have the SetColor method, which works like a tint. Alpha blending can also be achieved using this.
321
General discussions / Draw Optimizations
« on: March 12, 2011, 08:31:28 am »
The biggest performance hit in OpenGL is caused by texture binding, I noticed that pretty often. The more sprites you have using different textures (sf::Image), the more texture bindings will be required each frame and things will slow down.
The best solution is to use as little different images as possible. This is best achieved by using sprite sheets and tilesets that have as many frames as possible in one single image. It's better to have a few LARGE images that many many small ones. Ultimately you also should code your application to render sprites with the same image in direct sequence to avoid texture binding as much as possible. The CPU time required to sort them accordingly will pay off when rendering. If you work with linked lists intelligently even that CPU use will be minimal.
The best solution is to use as little different images as possible. This is best achieved by using sprite sheets and tilesets that have as many frames as possible in one single image. It's better to have a few LARGE images that many many small ones. Ultimately you also should code your application to render sprites with the same image in direct sequence to avoid texture binding as much as possible. The CPU time required to sort them accordingly will pay off when rendering. If you work with linked lists intelligently even that CPU use will be minimal.
322
General discussions / Window mode runs slower than full screen.
« on: March 12, 2011, 08:25:01 am »
No, a maximized window is still a window. That means all your desktop stuff is rendered (task bar, window frames, other windows, desktop, whatever else your OS needs to render) while rendering your SFML application.
As JAssange said, windowed is naturally slower than fullscreen, because in fullscreen mode your graphics processing is dedicated to it.
If your framerate drops too much while in windowed mode you will either have to render less, or if that doesn't help or isn't possible you might have to get a stronger graphics card.
As JAssange said, windowed is naturally slower than fullscreen, because in fullscreen mode your graphics processing is dedicated to it.
If your framerate drops too much while in windowed mode you will either have to render less, or if that doesn't help or isn't possible you might have to get a stronger graphics card.
323
General / Freeze trying to load sfml-window-2.dll
« on: March 11, 2011, 07:42:16 pm »
I'm indeed using ATI here, but why would this freeze occur when the DLL gets loaded? Any magic in DllMain? :?
Anyway, thanks for the info. Sounds you seriously got some work to do on this.
Anyway, thanks for the info. Sounds you seriously got some work to do on this.
324
General / Help with a simple question
« on: March 11, 2011, 07:39:56 pm »Quote
g++ -Wall -c
Hehe. What -c does is tell GCC to not link, ie that's exactly what makes it not work.
Try it without -c.
Use
Code: [Select]
g++ --helpto get a list of command line parameters and their explanations - its really of great help at times! And it's always good to know what stuff does.
325
General / Help with a simple question
« on: March 11, 2011, 07:26:37 pm »Quote
"you need to write your code, include all the necessary headers and files, compile it and then...."
.... and then LINK!
This sounds like your application didn't get linked.
An object file (.o on Linux systems) is compiled code, but Linux won't know what to do with it until linked into an executable.
What do you compile with? I'm guessing GCC or G++. Tell it to link the output object files to an executable which you will be able to use. If you don't know how, try and check whether you have set anything about linking in your other projects that you could execute.
326
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:
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?
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?
327
General / Access Violation in SFML 2.0 when destroying resources
« on: March 10, 2011, 10:38:47 pm »
It might be the context destruction after all, indeed.
Good to know then, I'll just ignore those for the time being then.
Good to know then, I'll just ignore those for the time being then.
328
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:
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:
This was the stack trace:
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):
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!
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=1484This 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!