Welcome, Guest. Please login or register. Did you miss your activation email?

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.

Messages - smurf

Pages: [1] 2
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.

Graphics / Re: View, Viewports and getting mouse location
« on: December 05, 2023, 02:49:59 pm »
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!

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?

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)

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:

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;

foreach (var baddie in baddies)

#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.

Yes I am!

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

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.

Graphics / Re: Best practices for sprites?
« on: November 20, 2023, 02:22:55 am »

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  :P

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.

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 ?

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?

Graphics / Re: How animation with touch button
« on: September 26, 2022, 04:45:51 pm »
Hi, it seems like you have something like this:

while (true)
    if (touching button)
        run animation()

but you probably want something like this:

while (true)
    if (touching button and isShouldRunAnimation == false)
        isShouldRunAnimation = true
        reset animation to beginning
    if (isShouldRunAnimation)
        run animation()
        if (animation is done)
            isShouldRunAnimation = false

DotNet / Re: nuget package not working
« on: September 23, 2022, 05:17:45 am »
Thank you I will try it out.

Graphics / Re: VertexArray with Texture not working - nothing drawn
« on: September 23, 2022, 05:15:17 am »
Oh wow that is super tricky. Thank you!!

It seems that when using the constructor, other properties are set besides just the texture that I passed in.
But when using the parameterless ctor and just setting the texture property, those other properties (like transform) are NOT set.

maybe an improvement would be, in the setter for the properties, the transform property is also set to Identity matrix, if it has not already been set to something.

Graphics / Re: Is there a function to sort through pngs?
« on: September 22, 2022, 09:29:49 pm »
It was pseudocode and it was actually C#
But good to know.

Pages: [1] 2