31
Feature requests / Not clearing the contents of a RenderWindow after Display
« on: May 17, 2008, 10:47:24 pm »
Why is redrawing the sprites an issue? Thats part of redrawing the window and falls under what I've already mentioned.
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.
32
Feature requests / Not clearing the contents of a RenderWindow after Display
« on: May 17, 2008, 10:10:41 pm »
The point I was trying to make was that with hardware acceleration, the extra logic required to track the parts that need changing is less efficient than just redrawing the entire screen (especially if your sprites are stored as textures on the graphics hardware, so don't require touching the CPU in it's renderpath).
33
Graphics / Drawing Everything
« on: May 17, 2008, 06:10:33 pm »
I don't think any compiler would replace index notation with iterator constructs. It's not really an optimisation (especially if the iterator coding isn't quite as optimal as possible).
The point of using iterator notation rather than index notation is that iterator notation is pointer notation, which can be used with ANY container that is standard in C++, not just STL ones. That means that the same (templated, generic) code will work with raw arrays in the same way as it will work for vectors, or maps or deques or whatever.
However, if you want a good way to do what you are suggesting, I would suggest using boost and doing:
as then you don't need to worry about messing around with iterators, indices or anything else
There is an STL version of for_each but it isn't as useful as the boost version, although I think there may be an improved version in C++0x.
The point of using iterator notation rather than index notation is that iterator notation is pointer notation, which can be used with ANY container that is standard in C++, not just STL ones. That means that the same (templated, generic) code will work with raw arrays in the same way as it will work for vectors, or maps or deques or whatever.
However, if you want a good way to do what you are suggesting, I would suggest using boost and doing:
Code: [Select]
BOOST_FOREACH(Sprite s, vSprites)
{
s.Draw();
}
as then you don't need to worry about messing around with iterators, indices or anything else
There is an STL version of for_each but it isn't as useful as the boost version, although I think there may be an improved version in C++0x.
34
Feature requests / Not clearing the contents of a RenderWindow after Display
« on: May 17, 2008, 05:59:51 pm »
It is definitely the usual process when you have hardware acceleration available The main reason being that the small gain from only drawing changed sections is offset by the extra logic and processing required to keep track of just changed sections. This changes with software rendering of course, but as SFML is designed around OpenGL and 3d hardware is so prevalent nowadays, there isn't really a need to only clear part of the screen.
The main reason being that the small gain from only drawing changed sections is offset by the extra logic and processing required to keep track of just changed sections. This changes with software rendering of course, but as SFML is designed around OpenGL and 3d hardware is so prevalent nowadays, there isn't really a need to only clear part of the screen.
35
Graphics / Create alpha mask from B/W image
« on: May 15, 2008, 09:28:24 am »
doh... ok I give up and in future I'll try not to argue C++ syntax when I've spent the entire day coding in perl :roll:
and in future I'll try not to argue C++ syntax when I've spent the entire day coding in perl :roll:
36
Graphics / Create alpha mask from B/W image
« on: May 14, 2008, 05:54:37 pm »Quote from: "Laurent"
Quotesf::Image image(), mask();
You should remove the parenthesis, otherwise the compiler will think you're declaring functions.
I think sure in this case, it will just call the default constructor, a kind of reinforcement of the default behaviour. You need to do much more than that to confuse the compiler (there is a great one you can do with the standard library though
. I may be wrong though.and yeah, I was trying to remember the standard conversion to greyscale
I guess I was horribly wrong.
37
Graphics / Create alpha mask from B/W image
« on: May 14, 2008, 04:31:56 pm »
you could also write a function that takes a B&W 'alpha' image and your other image, and constructs the alpha-channel for the first image.
A very basic version would be:
this is untested(written straight into the browser) has no bounds checking (so could overflow and cause issues) and uses what I think is the standard method of producing a greyscale for the alpha of 0.3r + 0.4g + 0.3b. It also has the potential to just return an empty image or the original image with no alpha if either image fails to load. It should be a good starting point though
A very basic version would be:
Code: [Select]
sf::Image CreateAlphaImageWithMask(std::string aImage, std::string aMask)
{
sf::Image image(), mask();
if (image.LoadFromFile(aImage) && mask.LoadFromFile(aMask))
{
for (int i = 0; i < image.GetWidth(); ++i)
{
for(int j = 0; j < image.GetHeight(); ++j)
{
Color c(image.GetPixel(i,j));
Color m(mask.GetPixel(i,j));
c.a = m.r*0.3 + m.g*0.4 + m.b*0.3;
image.SetPixel(i,j,c);
}
}
}
return image;
}
this is untested(written straight into the browser) has no bounds checking (so could overflow and cause issues) and uses what I think is the standard method of producing a greyscale for the alpha of 0.3r + 0.4g + 0.3b. It also has the potential to just return an empty image or the original image with no alpha if either image fails to load. It should be a good starting point though
38
General discussions / Benchmark : SDL vs SFML
« on: May 14, 2008, 04:17:24 pm »
It's also worth noting that SDL is also frequently used as a 2d API without any OpenGL functionality (I know of several indy games that do just that).
What would really be interesting is comparing how much work you would need to do in SDL to either get the same raw speed out of the 2d software API or produce the same results as you can get easily in SFML. Raw speed comparisons are rarely as useful as productivity comparisons due to moores law and other such technology trends increasing the base speed
What would really be interesting is comparing how much work you would need to do in SDL to either get the same raw speed out of the 2d software API or produce the same results as you can get easily in SFML. Raw speed comparisons are rarely as useful as productivity comparisons due to moores law and other such technology trends increasing the base speed
39
as a suggestion to Laurent:
would it be possible to add a non-const overload to the draw function? It seems like you should be able to draw const sprites, which you would prohibit by making the draw function non-const completely, but providing both a const and a non-const version of the same function should work.
would it be possible to add a non-const overload to the draw function? It seems like you should be able to draw const sprites, which you would prohibit by making the draw function non-const completely, but providing both a const and a non-const version of the same function should work.
40
Feature requests / Some features
« on: May 12, 2008, 11:26:56 pm »
Why would Laurent implement a software backend when OpenGL is already a software renderer and a hardware renderer?
41
General discussions / PostFX - random numbers?
« on: May 11, 2008, 07:07:46 pm »
texture is a better idea as textures are arrays for glsl
so a noise texture is the same as that idea, but with a large, auto-generated array
so a noise texture is the same as that idea, but with a large, auto-generated array
42
Graphics / [Solved] Loading Images Inside a Thread
« on: May 09, 2008, 05:58:08 pm »Quote from: "Laurent"
Quote from: "workmad3"If you really want to, create an invisible view and draw your images to it right after loading them to force them into OGL
Calling Bind() would be enough
Give me a break... I haven't actually looked beyond class names in the 2d api so far
I may look into it some more if I ever get beyond my action system in SFML 
43
Graphics / [Solved] Loading Images Inside a Thread
« on: May 09, 2008, 04:39:51 pm »
If you really want to, create an invisible view and draw your images to it right after loading them to force them into OGL
44
Feature requests / sf::Clock Improvement
« on: May 04, 2008, 08:25:17 pm »
Always use the getters and setters provided... if you find they are a performance drain then we should bug Laurent to change them to inline functions instead Data members should stay private so that we can't mess around with SFML's private data and possibly break the clock
Data members should stay private so that we can't mess around with SFML's private data and possibly break the clock
45
General discussions / error LNK2001 ...
« on: May 04, 2008, 08:22:50 pm »
If you are using the pre-built 1.2 files, then I'd suggest rebuilding SFML, using the new .lib and .dll files generated and relinking your app against that. It's a known issue with the 1.2 lib files