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.
To be clear, this:
https://www.sfml-dev.org/documentation/2.6.1/
is the API documentation (that you mentioned in the original post).
There, you can click Classes and look up all the available classes, including sf::Image.
Hope this helps
https://www.sfml-dev.org/documentation/2.6.1/classsf_1_1Image.php#a9e4f2aa8e36d0cabde5ed5a4ef80290bQuoteThe supported image formats are bmp, png, tga, jpg, gif, psd, hdr, pic and pnm. Some format options are not supported, like jpeg with arithmetic coding or ASCII pnm. If this function fails, the image is left unchanged.
I'm currently busy with other things
Okay. Then my only question is: what do "wonky" and "clipping" mean in the following context?:The only problem is how wonky the TriangleFan can be, as more than 0.1 difference between angles cause clipping
for (float i = 0; i < 6.27; i += 0.01)I'm guessing this creates 627 vectors around the circle (not perfectly even at the end, though, due to the obvious rounding of pi), right? So it's a sort of LUT?
{
lightBaker(i);
}
I don't think that's what the term light baking refers to but it's up to you what you call things, of course
That aside, when you're casting rays, do you need this many? I would presume that once you hit something, you can track it in both directions until you reach the line's end points and all of the directions between could be discarded unless there is something in front. Maybe its simpler to calculate all edges that are facing the player and flatten them (in a similar way in concept to the way 3D perspective is flattened to 2D) and then check each line (and cull ones fully "behind" other lines, again like perspective culling).
Your way (although it may be the best way; I've not intensely tested it) seems to be more the "bitmap/brute force" to the other (my?) way's "vector/scalable" graphics. Just a metaphor of how I'm visualising it.
I only looked at those parts because, as eXpl0it3r mentioned, nobody is going to look through your entire code unless you have a specific issue; those parts jumped out at me.
Building light map from primitives worked great on small scale, but the only problem is drawing darkness to fill everything around.
You could use a "post-processing"-style setup and draw to an intermediate step and then draw all the light stuff together at once.
This would be something like:
- create a render texture that covers the entire part you want to draw (likely just the entire window but this can be modified e.g. if you're using double-pixels, you could use a half-size rendertexture)
- fill it with black (that's all the dark parts sorted right away!)
- draw your lights to the render texture (can be coloured but white is normal light; can also have transparency and likely should to allow overlapping lights), adding them together (blendmode: add)
- draw the render texture to the window with some sort of filter (blendmode: multiply is the simplest but a shader may do a better job if you use coloured lights)
Just because something a few years old doesn't necessarily mean that it's outdated. SFML 2.0 came out 10 years ago and what worked back then, will also work today.
What have you tried already?
Have you taken a look at Candle? https://github.com/MiguelMJ/Candle
Do you enforce VSync in your global GPU driver settings?
How do you "measure" CPU usage?From Task Manager, Resource Monitor also shows a huge difference in CPU usage.
Each sf::Sprite that is drawn uses a "draw call". The draw call is most often the most significant time wasted when drawing multiple objects. If there are very many sprites, the number of draw calls is high and can cause performance issues.
However, using a vertex array (or similar) allows you to draw multiple shapes at once with just one draw call, which can severely improve performance. Those shapes can be textured and rectangular so multiple sprites can be mimicked.
As for primitives, if you want to draw rectangles, you simply use the triangles primitives and create two triangles to create each rectangle. It requires a slight duplication of vertices and would therefore be 6 vertices per quad/rectangle:sf::VertexArray rectangles(sf::PrimitiveType::Triangles, 12u); // 2 rectangles = 12 vertices
std::size_t firstVertexOfRectangle;
sf::Vector2f topLeft;
sf::Vector2f bottomRight;
// first rectangle: 100,100 - 300,200 (200x100)
firstVertexOfRectangle = 0u;
topLeft = { 100.f, 100.f };
bottomRight = { 300.f, 200.f };
rectangles[firstVertexOfRectangle + 0u].position = topLeft;
rectangles[firstVertexOfRectangle + 1u].position = { topLeft.x, bottomRight.y };
rectangles[firstVertexOfRectangle + 2u].position = bottomRight;
rectangles[firstVertexOfRectangle + 5u].position = { topLeft.y, bottomRight.x };
rectangles[firstVertexOfRectangle + 3u] = rectangles[firstVertexOfRectangle + 0u];
rectangles[firstVertexOfRectangle + 4u] = rectangles[firstVertexOfRectangle + 2u];
// second rectangle: 500,200 - 600,500 (100x300)
firstVertexOfRectangle = 6u;
topLeft = { 500.f, 200.f };
bottomRight = { 600.f, 500.f };
rectangles[firstVertexOfRectangle + 0u].position = topLeft;
rectangles[firstVertexOfRectangle + 1u].position = { topLeft.x, bottomRight.y };
rectangles[firstVertexOfRectangle + 2u].position = bottomRight;
rectangles[firstVertexOfRectangle + 5u].position = { topLeft.y, bottomRight.x };
rectangles[firstVertexOfRectangle + 3u] = rectangles[firstVertexOfRectangle + 0u];
rectangles[firstVertexOfRectangle + 4u] = rectangles[firstVertexOfRectangle + 2u];
// later: window.draw(rectangles); // draws both rectangles with just one draw code
Note that the actual assigning of the vertices is the same both times.
You can assign colours and the texture co-ordinates in the same way. You can do that before the assigning of the "+ 3u" and "+ 4u" (at the time when the positions are assigned) as we're duplicating the entire vertex including colour and texture!
