16
Feature requests / Vectors and scalar operators
« on: September 24, 2008, 10:47:53 pm »
Only normalize is missing (really), and I don't know why you'd need those in SFML.
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.
17
Audio / MIDI support
« on: September 24, 2008, 12:29:22 am »
Hmm, aren't .it/.mod files similar to MIDI files? If they are then DUMB might be an option. Then again I've never used any MIDI formats...
Edit: Ah never mind, it appears to have the same problem as Port Media.
Edit: Ah never mind, it appears to have the same problem as Port Media.
18
Graphics / SetBackgroundColor in SVN version
« on: September 23, 2008, 12:04:50 am »
It appears to not be in SVN documentation, do you know what file it would have been in?
19
Well its pretty simple add another variable to all your objects that represents layer, then draw in order =]. As for 3D, SFML is (as stated above) strictly 2D in the built-in functions, but if you're using your own OpenGL you can find loaders for basically any 3D file on the 'net.
20
Feature requests / Mixing straight OpenGL with SFML/Graphics
« on: September 21, 2008, 04:50:50 am »
If I remember correctly lonesock claimed to have a really fast encoding method (never checked :wink: ). And a DirectX backed would interesting to see.
21
Feature requests / Mixing straight OpenGL with SFML/Graphics
« on: September 21, 2008, 04:13:29 am »
I believe DXT compression actually makes rendering faster, but if you want image loading capabilities use SOIL (distributed with SFML). Thus you can use the same library just in an uglier method.
See SOIL.h for all SOIL_FLAGs... As for exposing the identifier, couldn't you just make an GetOGLTexture() function? I do think this is a good idea though, as sf::Image is a well designed and capable class (ie loading from memory properly).
Code: [Select]
GLuint Texture = SOIL_load_OGL_texture(
"filename.ext",
SOIL_LOAD_AUTO,
SOIL_CREATE_NEW_ID,
SOIL_FLAGS);See SOIL.h for all SOIL_FLAGs... As for exposing the identifier, couldn't you just make an GetOGLTexture() function? I do think this is a good idea though, as sf::Image is a well designed and capable class (ie loading from memory properly).
22
Graphics / LoadFromFile() Problem:"[...] Reason : Unable to open f
« on: September 20, 2008, 10:18:22 pm »
Are you sure the image is actually in your working directory?
23
Graphics / How do I undraw text
« on: September 20, 2008, 02:46:57 am »Quote from: "ravenheart"
ok so far so good, now when i want some kind of breakout clone, how can i manage collision and visibility for each brick?
i dont know how to manage more than 3 objects ^^
does anyone know maybe a good site with example code?
I suppose you'll need an array of some sort of sf::Sprites, I'm not sure which you want to implement but for break out its only like 64 bricks? So it really does not matter (for this anyways). Pseudo-code is as follows:
Code: [Select]
const int WindowX = 800;
const int WindowY = 600;
//Assuming your window goes from 0,0 to 800,600
sf::Sprite Bricks[64] = {...} // I assume you'd set there position somewhere
int InView(sf::Sprite& Arg)
{
//compare to window view
if(Arg.X > WindowX || Arg.X <0)
return 0;
if(Arg.Y > WindowY || Arg.Y < 0)
return 0;
if(Arg.Y < WindowY && Arg.Y > 0)
return 1;
if(Arg.X < WindowX && Arg.X > 0)
return 1;
}
//... somewhere in render-loop
for(int i = 0; i <= 64; i++) //++i?
{
if(InView(Bricks[i]))
{
//draw
}
}
Didn't try to check if it was correct or anything, but if it is outside of the window range it should not draw it. Coincidentally you can rewrite InView to be Collision(int X, int Y, sf::Sprite& Arg) it will compare the X,Y you provide to the position of the object and see if they collide...
24
General discussions / Benchmark : SDL vs SFML
« on: September 20, 2008, 01:34:03 am »Quote from: "Stonefish"
Ah yes... well, SFML doesn't use many OpenGL accelerations from what I have seen (or even DXT compression?), so such conclusions are premature considering SFML's age when compared to SDL.
As you can see sprites drawing without alpha using SDL is faster then using SFML.
25
SFML wiki / German wiki?
« on: July 05, 2008, 03:18:05 am »
A single English site may actually cut down on a number of French visitors and feedback, and seeing as Laurent is fluent in English and French I can see why he made only English/French forums and wikis. I'm an American, and can read French (to an extent, as I have never taken a class).
26
Network / Receive loop
« on: July 03, 2008, 12:52:03 am »
I use while(1)...Shortest way is the best way.
27
Audio / Memory Leak loading Ogg Vorbis
« on: July 02, 2008, 07:50:25 pm »
Just wondering: Was this an actual problem? If so, was it fixed?
28
SFML wiki / [Tutorial]Manage different screens in a game
« on: July 02, 2008, 05:54:24 pm »
Tsk, your English is fine. Interesting tutorial, I always just had used the same window for my "games", but they were all SDL.
29
General / 2 Problems
« on: July 01, 2008, 11:10:04 pm »
"-s" endings are for static. Just check and make sure under project settings you have disabled debug information from being included
30
General discussions / Stable?
« on: July 01, 2008, 11:07:27 pm »
Version 1.3 is very stable, and I've had near zero problems running from the SVN, however I did have problems with version 1.2 (VS2008 libraries were built incorrectly and is now fixed).
But I did notice that features are being added a rate much higher than that of SDL/Allegro, and is still faster than either, which I find impressive. However I did read that SDL is back in active development, which may be nice to see... I still use SDL and SFML, but I seem to be using SFML more and more.
But I did notice that features are being added a rate much higher than that of SDL/Allegro, and is still faster than either, which I find impressive. However I did read that SDL is back in active development, which may be nice to see... I still use SDL and SFML, but I seem to be using SFML more and more.