Topics

1

Graphics / View, Viewports and getting mouse location

« on: December 05, 2023, 07:17:13 am »

The common recommendation for making games is to have separate Update() and Render() methods.

In Update(), I get all inputs (including mouse x y coordinates) and do all updates.

Problem is in the Render() method, I end up changing the view/viewport a few times because there is a HUD and game area at least. It means that the mouse coordinates (specifically the world mapped version of them) I grabbed in the Update() function are not correct by the time the Render() function changes the view stuff around.

So now it seems like I'm forced to put some of my Update() code inside the Render() function because this is where I will finally have the right inputs.

I really don't want to mix the update and the render logic like this though. What am I missing?

2

Window / Joystick doesn't work unless its connected before program starts

« on: November 20, 2023, 02:28:55 am »

If my joystick is connected and turned on when the game launches, everything seems ok. I can even turn it off, and turn it back on again, and it will keep working.

However if the controller is only turned on after the game has launched, it won't work. I see that the window.JoystickConnected event still fires when the controller comes on, HOWEVER, calling any of the query functions like Joystick.IsButtonPressed(i, 7) always returns false, and so does Joystick.IsConnected(i). Each frame I'm calling Joystick.Update().

How can I get SFML to notice the new controller? Like I said its already firing the JoystickConnected event, so IMO there should be no problem. But there is.

3

Graphics / Best practices for sprites?

« on: November 16, 2023, 07:04:29 am »

Heres the scenario:

I have an image that is composed of many 32x32 squares of sub-images. It is my spritesheet/texture atlass whatever you want to call it. Many of the squares are part of an animation. For example, a bad guy character may have 10 square images which make up a walking animation. I create a Texture of this image, and plan to create Sprites for each 32x32 square in the texture.

The question is how many sprites should I actually create. So far I have exactly 1 sprite per 32x32 square. If there are many objects on screen with the same appearance (for eg 200 instances of the same type of bad guy), then all of these instances share the same sprite reference. When I'm looping through the bad guys to update/render them, for each of them I update the sprite properties, then draw it. For example I might change the position, rotation, color, scaling of the sprite, then render it. On the next iteration, I change the sprite properties all again for the next bad guy then draw it.

Is this an inefficient way to do things? Constantly changing the properties of a single sprite back and forth for each bad guy?

The other option I was considering was to have completely separate spite instances for each bad guy. This way, maybe I won't have to update properties as much. For example a blue bad guy can stay blue and I don't have to update the sprite's color on every iteration through the bad guy update loop. Downside I guess would be more memory. But maybe extra strain on the GPU somehow? I don't know.

The extra wrinkle is each bad guy needs 10 sprites because I change the rendered sprite every second as his walking animation needs to change.

So what is the correct way to do things? Should I try to share and re-use sprites and just change their properties as needed? Or is it better to create as many Sprites as needed and avoid changing their properties ?

4

Graphics / Maximum Image size?

« on: January 15, 2023, 05:11:40 am »

I'm hitting the limits of the SFML Image class, and wondering if theres any easy workarounds.

I was trying to export a texture to a PNG using rtexture.getTexture().copyToImage().saveToFile("toto.png");

But no image was being written to disk. Debugging I found that the pixels array member of the Image class is having an overflow exception. My texture is 30,000 by 30,000 in size. Yes I realize this is crazy but I wanted to export my entire game map to a PNG for my reference and debugging purposes.

Doing the math I see that 30,000 * 30,000 * 4 (4 bits per pixel) = a number larger than a 32 bit integer can handle, so this is probably the issue. I confirmed this by just directly creating an image that large with the Image constructor, so the Texture class and graphics card are not even in the picture. Same issue.

So I know its a long-shot but is there any chance of having the Image class using 64 bit ints internally, or having a new LargeImage class or something?

5

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.

6

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"

7

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?

8

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?

9

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?

10

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);

11

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,