Messages

1

DotNet / Re: Can't used a joystick that is connected in the middle of program execution.

« on: June 05, 2024, 08:09:07 pm »

Thank you for the information.

Honestly I'm a bit confused why calling update manually keeps being proposed as a workaround. It does not work. Also I'm calling Joystick.Update() every frame anyway, so I wouldn't even call it a workaround, I would be completely happy with it.

Anyway I guess I'll keep an eye out for updates. Thanks!

2

DotNet / Re: Can't used a joystick that is connected in the middle of program execution.

« on: June 05, 2024, 05:12:39 pm »

Resurrecting this thread because I have the exact same issue and I don't see a solution yet.
Launching a game and then turning your controller on is an extremely common scenario so this bug is a big deal IMHO.
Every single time I'm having to restart the game because I forgot to turn on the controller first.

3

Graphics / Re: How to draw object with position relative to another object?

« on: May 29, 2024, 05:47:50 pm »

Yup I think I have something relatively clean now.

I must have been thinking back to using raw OpenGL, when you could use Push() and Pop() to save and load transformation states, and could get the same effect without having to pass any objects around.

4

Graphics / Re: How to draw object with position relative to another object?

« on: May 27, 2024, 05:35:58 am »

Thanks for this!
Its better than what I had for sure.
I made a small improvement by moving the hitpoint object into the player which makes more sense to me.
Unfortunately something still seems a bit inelegant about it, specifically having to pass the new RenderStates() thing to the draw call. But I guess there is no way to make this implicit.
Anyway thanks again!

5

Graphics / How to draw object with position relative to another object?

« on: May 24, 2024, 10:53:43 pm »

I'm always solving this problem in a dumb way and I know theres a better way.

Suppose I have a Player class, and also a HitPoint class.
The Player object contains an instance of a HitPoint object.
When I draw the player, I also want to draw the hitpoint bar near his head.
So what I end up doing is in the Player's render method, I pass the player's relative position to the HitPoint's render method. So that I can draw the hitpoint bar at the same location of the player, but 50 pixels higher and 10 to the left.

What I'd like to avoid is somehow having to pass positions around like that. It seems like my render code is FULL of ugly little offset maths like xPos + xPos2 + 35.

Example of the problem:

class Player {
        int xPos;
        int yPos;
        HitPoint hpBar;
        public void Render() {
                DrawThePlayer();
                hpBar.Render(xPos, yPos);
        }
}
class HitPoint{
        public void Render(int x, int y) {
                DrawRect(x-10, y-50....
        }
}
 

So for example I'd prefer to have the HitPoint Render method look more like this

class HitPoint{
        public void Render() {
                DrawRect(0, 0)
        }
}
 

So I'm drwaring the hitpoint bar from (0,0) and not worrying about the Player's  position. Something else will "move" the hitpoint bar to the right place.

6

Graphics / Re: View, Viewports and getting mouse location

« on: December 06, 2023, 06:56:53 pm »

I must be missing something.

From what I see, you can't convert screen coords to world coords until you set the View to a Window/RenderTarget. So I actually have to do graphics work in my Update function. Something like this:


Update Method:

RenderWindow.SetView(new View( .. world view / viewport details) );
Vector2i mousecoordsWorld = RenderWindow.MapPixelToCoords(getMouseCoords());
// do world updates such as shoot bullets

RenderWindow.SetView(new View( .. HUD view / viewport details) );
Vector2i mousecoordsHud = RenderWindow.MapPixelToCoords(getMouseCoords());
// do hud updates such as updating button states and detecting clicks...
 

Render Method:

RenderWindow.SetView(new View( .. world view / viewport details) );
// render world

RenderWindow.SetView(new View( .. HUD view / viewport details) );
// render Hud
 

And I don't see how I can avoid adjusting the view in the Render phase because the Update phase has left it in the wrong view state.

On top of it, the Update method is actually called several times for every Render method (accurate physics sometimes requires this), so it ends up being a lot of view switching. Hopefully its fast at least.

7

Graphics / Re: View, Viewports and getting mouse location

« on: December 05, 2023, 02:49:59 pm »

Thanks!
I'm doing that now - the input mouse coordinates are globally accessible in the player object.
No problem adjusting the views based on these coordinates and even calling MapPixelToCoords() a few times during Render, to make the right things happen visually.

The issue is when I want to actually do something, like fire a bullet, which is definitely Update and not Render logic. But I cannot fire the bullet until I'm halfway through the Render function because this is when I've got the right view set up for calling MapPixelToCoords() and actually firing the bullet in the proper direction ad the proper angle.

Editing to give an example

During the Update() method, I grab the mouse coords. Lets say its 243, 150. This is global state accessible from anywhere no problem so far.

Mouse button is clicked, so, still in the Update method, I fire a bullet toward 243,150 coordinates.

Rest of Update method completes.

Now Render method starts
Change View/Viewport to render the Hud. Now that same mouse coord maps to -543, 280 world coordintes.
Change View/Viewport to render the game area. Now that same mouse coord maps to 20943,10080 world coordintes. I should have fired the bullet towards 20943,10080 but could not have known that until this point in the Render method!

8

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?

9

Graphics / Re: Best practices for sprites?

« on: November 21, 2023, 06:04:43 pm »

Your understanding of the code is correct. There is no behind the scenes copying of objects or anything that would be hiding a big performance impact.

I also wonder if there is any texture switching going on. But there absolutely shouldn't be because there is only 1 texture in the entire app, and every sprite references it when it is created, and it never changes.

I'm drawing 20,000 sprites. Release mode, but Debug mode is the same (slightly slower but still a big relative difference between the 2 approaches)

10

Graphics / Re: Best practices for sprites?

« on: November 20, 2023, 10:34:13 pm »

Yea, I'm hearing you guys that vertex arrays are the way to go. I think I tried them long ago, and I forget what but something about them didnt quite work for my scenario. I'll look again.

But as a programmer, I still want to understand whats going on with the sprites.

with pseudocode, here are the 2 scenarios boiled down:

#1:

foreach (var baddie in baddies) {
        theOnlySprite.x = baddie.x;
        theOnlySprite.y = baddie.y;
        theOnlySprite.color = baddie.color;
        theOnlySprite.rotation = baddie.rotation;
        theOnlySprite.scale = baddie.scale;
       
        window.Draw(theOnlySprite);
}
 

#2:

foreach (var baddie in baddies)
{      
        window.Draw(baddie.mySprite);
}
 

#2 has much less setting of variables and creation of unnecessary new objects. The only downside I can see for #2 is more memory usage (and its hardly any). Its the same number of draw calls either way. But #2 is way slower.

11

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

« on: November 20, 2023, 03:34:06 pm »

Yes I am!

Thanks I'll look at these links and see if it can help me (or if I can help out).

12

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.

13

Graphics / Re: Best practices for sprites?

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

Yep

14

Graphics / Re: Best practices for sprites?

« on: November 18, 2023, 06:56:02 pm »

To clarify, by "correct", I meant "most efficient".

I know the answer to this is usually "measure both ways", but I figured there was already a definitive answer to this by now.

Anyway, I measured both ways 

To my pretty big surprise, its significantly worse to have individual sprites per bad guy instance. Its better to have a single sprite per image in the texture atlas, and just change its properties (position, scale, color, rotation) for each badguy before drawing it.

This was surprising because if each badguy has its own sprite, then the sprite properties need to change way less often. I expected this approach to take a bit more memory (and it did - 90MB vs 85MB or similar, so totally not a factor), and I expected it to use less CPU resulting in better FPS.

In fact the FPS reduced from 120 to 75 by using this approach!

I think the conclusion is that somehow sprites are not as lightweight as I originally thought, and its better to re-use them than to create them freely for different purposes.

15

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 ?