9346
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.
9347
System / AW: sf::err result what does it mean?
« on: October 28, 2012, 02:36:12 am »
Well you are returning the address of the stream and that's what you're getting on the output. &x denotes: address of x. 
9348
General / AW: Re: AW: Memory Delete?
« on: October 28, 2012, 02:28:03 am »Could you explain that a little bit better so I fully understand whats going on?You need to add virtual ~GameState(); to the GameState header and then implement a destructor for each state.
Which destructor are you talking about?
Btw a nicer solution would be to use std::unique_ptr.
9349
General / AW: Text Input
« on: October 28, 2012, 02:24:00 am »
I guess that static cast of a unicode (w_char or similar) can't be performed and if so I wouldn't know what the output should be...
9350
System / AW: sf::err result what does it mean?
« on: October 28, 2012, 02:21:25 am »
What are you trying to do? 
What, when and how does sf::err do what and in which way?
What, when and how does sf::err do what and in which way?
9351
General / AW: Memory Delete?
« on: October 28, 2012, 02:19:43 am »
Since the play state is derived from GameState the destructor needs to be defined virtual, which I think is not the case atm, otherwise the child's class destructor won't be called.
9352
SFML projects / Re: QuickSnap - Screenshot program
« on: October 27, 2012, 11:42:10 pm »There are hex numbers there as const sf::Uint8 FONT[] to use load from memory on them, a bit like what sfml did before default font removal.Oh GitHub simply suppressed that in the normal view. The RAW output shows it though.
9353
SFML projects / Re: QuickSnap - Screenshot program
« on: October 27, 2012, 11:33:53 pm »main.cpp, line 10:Which numbers? I don't see anything, see here.
Where did you get those numbers from?!?! Hex editor?
9354
Audio / Examples that use (self built) OpenAL fail to build
« on: October 27, 2012, 11:31:36 pm »
So I've been try to build a native 64bit version of SFML with MinGW-w64, but since SFML doesn't ship with 64bit external libraries, I had to build them on my own.
Everything seems to work quite well (after editing the CMake macro file) except when trying to build the examples that use the static audio module of SFML it errors out with the following message:
Since I've build OpenAL myself I'm not sure if I've used the correct version or setup everything right and thus I'm not only asking how to resolve this issue, but also if there are any special steps required when building SFML?
Everything seems to work quite well (after editing the CMake macro file) except when trying to build the examples that use the static audio module of SFML it errors out with the following message:
..\..\lib\libsfml-audio-s.a(SoundBuffer.cpp.obj):SoundBuffer.cpp:(.text+0x65): undefined reference to `__imp_alBufferData'
..\..\lib\libsfml-audio-s.a(SoundBuffer.cpp.obj):SoundBuffer.cpp:(.text+0x68a): undefined reference to `__imp_alDeleteBuffers'
..\..\lib\libsfml-audio-s.a(SoundBuffer.cpp.obj):SoundBuffer.cpp:(.text+0xcf3): undefined reference to `__imp_alDeleteBuffers'
c:/dev/mingw64-rubenvb/bin/../lib/gcc/x86_64-w64-mingw32/4.7.2/../../../../x86_64-w64-mingw32/bin/ld.exe: ..\..\lib\libsfml-audio-s.a(SoundBuffer.cpp.obj): bad reloc address 0x0 in section `.pdata'
c:/dev/mingw64-rubenvb/bin/../lib/gcc/x86_64-w64-mingw32/4.7.2/../../../../x86_64-w64-mingw32/bin/ld.exe: final link failed: Invalid operation
collect2.exe: error: ld returned 1 exit status
mingw32-make[2]: *** [examples/pong/pong.exe] Error 1
mingw32-make[1]: *** [examples/pong/CMakeFiles/pong.dir/all] Error 2
mingw32-make: *** [all] Error 2
..\..\lib\libsfml-audio-s.a(SoundBuffer.cpp.obj):SoundBuffer.cpp:(.text+0x68a): undefined reference to `__imp_alDeleteBuffers'
..\..\lib\libsfml-audio-s.a(SoundBuffer.cpp.obj):SoundBuffer.cpp:(.text+0xcf3): undefined reference to `__imp_alDeleteBuffers'
c:/dev/mingw64-rubenvb/bin/../lib/gcc/x86_64-w64-mingw32/4.7.2/../../../../x86_64-w64-mingw32/bin/ld.exe: ..\..\lib\libsfml-audio-s.a(SoundBuffer.cpp.obj): bad reloc address 0x0 in section `.pdata'
c:/dev/mingw64-rubenvb/bin/../lib/gcc/x86_64-w64-mingw32/4.7.2/../../../../x86_64-w64-mingw32/bin/ld.exe: final link failed: Invalid operation
collect2.exe: error: ld returned 1 exit status
mingw32-make[2]: *** [examples/pong/pong.exe] Error 1
mingw32-make[1]: *** [examples/pong/CMakeFiles/pong.dir/all] Error 2
mingw32-make: *** [all] Error 2
Since I've build OpenAL myself I'm not sure if I've used the correct version or setup everything right and thus I'm not only asking how to resolve this issue, but also if there are any special steps required when building SFML?
9355
Graphics / Re: Moving sf::View smoothly
« on: October 27, 2012, 07:44:01 pm »
You could work with a fixed timestep instead or take the average deltatime (i.e. time over x frames or frames over x seconds).
You might want to read this blog post.
You might want to read this blog post.
9356
Audio / Re: Best way to compress music...
« on: October 27, 2012, 07:40:37 pm »Also, I notice that some projects don't even include the music as a different .wav file. It seems they include the audio in a .dat file along with the graphics. How is this possible?They somehow pack it. A common way is to use zlib and decompress the contained data at runtime. There are even some libraries that can 'stream' it directly from the zipped file.
Others might have defined their own packing 'protocol' and then wrote a loader for it.
9357
Graphics / Re: Tile won't texture SFML 2.0
« on: October 27, 2012, 06:20:16 pm »
Copying code must be eeextremly complex... 
From the small snippet I can't determine anything. Might be that the texture gets invalid on copying, might be that you don't adjust the texture rect, might be that you accidentally change the view so it doesn't show anymore, etc etc.
You need to shrink your code until you get a minimal and complete example that reproduces the problem and if you do it right, you'll most probably find the problem on your own...
From the small snippet I can't determine anything. Might be that the texture gets invalid on copying, might be that you don't adjust the texture rect, might be that you accidentally change the view so it doesn't show anymore, etc etc.
You need to shrink your code until you get a minimal and complete example that reproduces the problem and if you do it right, you'll most probably find the problem on your own...
9358
Window / Re: Static Window? "static sf::Window renderWindow;"
« on: October 27, 2012, 06:11:09 pm »
Instead of reimplementing every function you could simply derive from sf::Window and then add your custom functions. Also keep in mind that sf::Window != sf::RenderWindow...
Why do you think accessing the window member would get easier with the static keyword, or better said why doesn't it work with just having it public?
Static class member basically means that multiple instance of the class will have the same window, but you shouldn't have multiple instances of your 'manager' in the first place, so I don't really see where the advantage is.
Why do you think accessing the window member would get easier with the static keyword, or better said why doesn't it work with just having it public?
Static class member basically means that multiple instance of the class will have the same window, but you shouldn't have multiple instances of your 'manager' in the first place, so I don't really see where the advantage is.
9359
Graphics / Re: create a sf::Image from an sqlite blob
« on: October 27, 2012, 01:02:05 pm »
Are the casts really necessary for int & char?
You can load image data directly from memory with loadFromMemory(), just make sure the format match.
You can load image data directly from memory with loadFromMemory(), just make sure the format match.
9360
General discussions / Re: Linking dependencies
« on: October 27, 2012, 12:37:04 pm »
I'd really like to see this change to happen soon... 
Could you at least change the macro in a way that it doesn't assume the library path?
Because with mingw-w64 the libraries are not located in the root/lib but in root/some-strange-version-name/lib folder...
Also there should be x64 extlibs build for mingw.
Could you at least change the macro in a way that it doesn't assume the library path?
Because with mingw-w64 the libraries are not located in the root/lib but in root/some-strange-version-name/lib folder...
Also there should be x64 extlibs build for mingw.