Messages

16

Graphics / Re: Is there a function to sort through pngs?

« on: September 20, 2022, 08:48:24 pm »

 Is there a faster, quicker, or automated way to do this such as a 'for' or 'while' function/loop?

Yes.
Pseudocode but something like:

for (int i = 0; i< myVector.length; i++)
{
    myVector[i].loadFromFile(i + ".png");
}
 

Side note, this is a very basic "intro to programming" type of question, so I would recommend you forget about SFML for a week and just read a beginners book or several hours of youtube videos on coding first.

17

Graphics / VertexArray with Texture not working - nothing drawn

« on: September 16, 2022, 04:01:53 pm »

See below for a minimal example. I've tried lots of variations of this code as well.
Nothing is drawn on the screen (except the green background color). If I instead create sprites from this same texture, I can draw those no problem.
If I add a white color to the vertices, and don't pass the RenderStates to Draw(), then it draws a white square of the expected size. So it seems to be just the texture association with the vertex array thats broken.

using SFML.Graphics;
using SFML.System;
using SFML.Window;

namespace VAD
{
    class Program
    {      
        static void Main(string[] args)
        {
            VideoMode videoMode = new VideoMode(500, 500);
            RenderWindow window = new RenderWindow(videoMode, "vertex arrays");

            VertexArray va = new VertexArray(PrimitiveType.Quads);            
            Texture theTexture = new Texture(@"C:\pics\house.png");
            RenderStates renderStates = new RenderStates();
            renderStates.Texture = theTexture;

            va.Append(new Vertex(new Vector2f(0, 0), new Vector2f(0, 0)));
            va.Append(new Vertex(new Vector2f(500, 0), new Vector2f(100, 0)));
            va.Append(new Vertex(new Vector2f(500, 500), new Vector2f(100, 100)));
            va.Append(new Vertex(new Vector2f(0, 500), new Vector2f(0, 100)));

            while (true)
            {
                window.DispatchEvents();
                window.Clear(Color.Green);
                window.Draw(va, renderStates);
                window.Display();
            }
        }
    }
}

 

This is C# obviously, using the SFML 2.5 nuget package. .NET6, Windows 10, Visual Studio 2022.

18

DotNet / nuget package not working

« on: September 16, 2022, 03:00:37 am »

I've been using SFML/C#/Visual Studio for a long time. But as I recall the initial setup was difficult. I had to download the right DLLs and put them in the right places, and reference them correctly. It was not fun.

Anyway I noticed there is a new version of SFML out AND it supports nuget. Yay!

I removed my old dlls and installed the nuget package. But now things don't work

I get an error saying DllNotFoundException: Unable to load DLL 'csfml-graphics': The specified module could not be found. (Exception from HRESULT: 0x8007007E)

So I thought maybe the nuget package is only the C# bindings, and not the actual libraries. So I downloaded the 2.5 dlls from the site and put them in what I thought was the correct folders. But things are still not working!

Can anyone please advise what to do next? I use nuget a lot at work and it always "just works"

19

Graphics / Re: May sprites vs 1 sprite ?

« on: July 12, 2021, 10:31:17 pm »

@AnhBao I swear I saw a thread on these forums way back saying that an individual sprite per sub-image would be more efficient. It wasn't until I was 75% done implementing it that I realized actually this doesn't seem more efficient for any particular reason, so this post was a sanity check. I guess the idea is that if you only use a single sprite, then you constantly have to change the position, scale, color, etc before drawing anything with that sprite.
However I found that even with many sprites, I'm still changing many of those properties before drwaing.

@eXpl0it3r True but my old code had a dictionary of all the TextureRects within my atlas, so I was just looking it up instead of creating a new one each time.

Once nice improvement would be if the sprite position property was writeable. Currently I have to do this A LOT:
sprite.Position = new Vertex2f(posX, posY);
but it would be much nicer if I could just do this:
sprite.Position.X = posX;
sprite.Position.Y = posY;


Also, I see that Vertex Arrays are mentioned A LOT when performance is discussed... would it be possible for SFML to use Vertex Arrays under the hood, even if the dumb user (me) is not explicitly using them in code?

20

Window / create a window, then close it and re-open it?

« on: July 07, 2021, 09:44:22 pm »

I'm familiar with creating a single window, and when they click the X, I close the window and exit the program.

But now I'm working on a different program which will have many windows. The windows can be closed, and you can always go back to the "main" window and click a button to open other additional windows.

I see from the documentation that RenderWindow/Window has a close() function that:

"Close the window and destroy all the attached resources.

After calling this function, the sf::Window instance remains valid and you can call create() to recreate the window. All other functions such as pollEvent() or display() will still work (i.e. you don't have to test isOpen() every time), and will have no effect on closed windows."


What does it mean that the attached resources are destroyed but the window is still valid?
Is this close(), create() pair the right thing for me to be doing in my scenario?

What if I really wanted the window to be completely destroyed and I'm OK with create() creating a truly brand new window, instead of resurrecting some half-dead one?

Finally, I'm using the C# bindings, and I don't actually see a create() method. Is the equivalent simply the C# RenderWindow() constructor? If so how different is the C# version from the C++ documentation that I'm reading?

Main question, how should I go about allowing new windows to be created and destroyed on the fly?

21

Graphics / May sprites vs 1 sprite ?

« on: July 03, 2021, 07:08:08 am »

Question about how to efficiently draw a lot of small images.

I've already built a texture atlas consisting of about 100 small images so that I only have 1 large texture loaded to the graphics card.

I've been using a single sprite to draw subsections of this texture atlas at different positions on the screen.

At some point I got the idea to use many sprites instead of just one. Basically, one sprite per image within the texture atlas. I think I actually got the idea from these forums.

But now that I'm nearly done making this change, I'm questioning whether it was actually a good idea, and if so, how does it actually improve things?

Because even though I have a single sprite dedicated to each actual image within the texture atlas, I'm still changing the properties of each sprite every frame. In particular, the images are moving so I'm at least changing the Position of each sprite each frame. And sometimes the color and the scale too. So does this defeat the purpose of having 100 different sprites instead of just 1? Because with just 1 sprite I was also changing the properties of it before making the draw call.... so it feels like the only real difference is that now I  have 99 extra sprites I might not actually need.

Hope that made sense. Thoughts?

22

Graphics / Texture created by RenderTexture is going out of scope

« on: February 17, 2021, 06:09:55 pm »

I frequently use RenderTextures to pre-draw complicated textures, then I create a Sprite out of the resulting RenderTexture.Texture for drawing to the screen.

I used to maintain a list of all the RenderTextures for the life of the program, just so they wouldn't go out of scope.

But then I realized I don't need the entire RenderTexture once I'm done my pre-drawing. I only need the texture part. So I changed my resource manager to only store the RenderTexture.Texture, but of course that didn't work. I guess because my reference to the Texture field was no enough to keep the overall RenderTexture object from going away.

So I guess my question is what is the best practice here? Should I go back to storing the entire RenderTexture even though I'm no longer rendering to it? It seems unclean to do this. Maybe the other option is to COPY the Texture field to my list and create the sprite from that copy. That way, I'm only keeping around the exact thing I need. Downside is that copying might be slow?

What do you guys do?

23

Graphics / Re: drawing a 1 pixel thick line

« on: February 02, 2021, 06:25:58 pm »

Disappointing answer but I really appreciate your time (and your library) anyway!

Thanks,

24

Graphics / Re: drawing a 1 pixel thick line

« on: February 02, 2021, 05:21:22 pm »

Very interesting, thank you that worked!

Now the obvious next question, is there a global setting to add (or subtract) 0.5 from all line coordinates or something like that?

I'm trying to build a pixel-perfect drawing that is composed of lines, and all of my inputs and math is using integers. It would be really nice to have a global solution rather than adding 0.5 to everything all over the place.

Interestingly, when I draw a RectangleShape it doesn't have this problem.

25

Graphics / Re: drawing a 1 pixel thick line

« on: February 02, 2021, 03:04:18 am »

I don't think so.
I don't see anywhere to set anti-aliasing in regards to these lines.

26

Graphics / drawing a 1 pixel thick line

« on: February 01, 2021, 08:10:20 pm »

How can I draw a simple 1-pixel thick line?
I've tried the obvious but it draws a 2-pixel thick line thats the wrong color! (I'm trying to draw it white but it comes out grey instead).

BTW I'm using the C# bindings if that matters.


Vertex[] line = new Vertex[2];
line[0].Position.X = 10;
line[0].Position.Y = 10;
line[0].Color.R = col.R;
line[0].Color.G = col.G;
line[0].Color.B = col.B;
line[0].Color.A = col.A;

line[1].Position.X = 10;
line[1].Position.Y = 100;
line[1].Color.R = col.R;
line[1].Color.G = col.G;
line[1].Color.B = col.B;
line[1].Color.A = col.A;

currentRenderTarget.Draw(line,0, 2, PrimitiveType.Lines);

27

Graphics / Why does RenderTarget class not declare the display() function?

« on: May 08, 2017, 04:12:20 am »

Both of it's children, RenderWindow and RenderTexture have a display() function. Why not define it in the base class of RenderTarget?

Why do I care?

I want to re-use the same code for drawing to a window and drawing to a texture. So I want to be able to pass in the parent object (RenderTarget) into a drawing class that will just draw and not care about whether it is to a window or a texture.

But the lack of the display() function is preventing this.  What am I missing? This seems like an obvious thing to do.

Thanks,