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 - Laurent

Pages: [1] 2 3 ... 1284
1
General / Re: Threading problem
« on: August 05, 2020, 04:28:23 pm »
Thread arguments are passed by value. If you have references, you must therefore wrap them with std::ref.

std::thread thread1(PlayerInput, std::ref(window), std::ref(player_x), std::ref(player_y), std::ref(player_a), std::ref(player_ya));

Note that what you're doing will most likely bring new problems (concurrent access) for no gain ;) But if it's for practicing, ok.

2
General / Re: Getting things to happen once inside the game loop.
« on: August 05, 2020, 08:28:32 am »
If all this code does is to check which button is clicked, and execute the corresponding action, then I would do it this way:

// THIS IS PSEUDO-CODE

// event loop! never use sf::Event instances outside
sf::Event event;
while (window.pollEvent(event))
{
    if (event is MouseButtonReleased and button is Left)
    {
        for each GUI button...
        {
            if (mouse cursor (event.mouseButton.x/y) is inside button)
            {
                execute action...
                break;
            }
        }
    }
}

By checking the button released event, you make sure that your code is only executed once. And by breaking the loop after finding the clicked button, you make sure that you don't check other buttons that the click would have brought below the mouse cursor (new scene).

3
System / Re: Limitations of repeated key events
« on: August 01, 2020, 05:49:33 pm »
And your question is?

Note that this behaviour is controlled by the OS, not by SFML. You have the exact same anywhere you can type text.

4
System / Re: SFML already use 4 threads (include main)?
« on: July 27, 2020, 10:34:03 pm »
I think that VerySleepy (a Windows profiler) can show CPU usage of each thread in a monitored process. You can try it, it's straight-forward to use.

5
Graphics / Re: sf::Color multiplication not working
« on: July 27, 2020, 08:29:26 pm »
So, multiply by 255.

To make color multiplication more intuitive, normalize the components: convert them from [0 .. 255] to [0 .. 1] (ie. divide by 255). Then you can multiply using standard maths conventions.

6
System / Re: SFML already use 4 threads (include main)?
« on: July 27, 2020, 08:25:02 pm »
As I said, it's driver / OpenGL / OS / ... stuff, nobody knows! Profile them if you really want to be sure that they are not consuming CPU.

7
System / Re: SFML already use 4 threads (include main)?
« on: July 27, 2020, 06:43:45 pm »
There's no internal thread created by SFML if you don't use the audio module, is that the case?

Don't forget that the OS and drivers create threads as well. There are also many other processes with potentially multiple threads running on your system... which doesn't mean that they are all active and eat CPU, most of them are background threads. So you can consider that only the threads that you create eat a significant amount of CPU, and create as much as you need.

8
Graphics / Re: sf::Color multiplication not working
« on: July 27, 2020, 05:16:21 pm »
(1 * 80) / 255 = 0, not 80.

You should get more familiar with how color multiplication works ;)

9
Graphics / Re: sf::Color multiplication not working
« on: July 27, 2020, 03:23:37 pm »
Indeed, if this operator is already defined in SFML, it should work as expected. And it looks like it does, what do you think is wrong in your example?

10
Graphics / Re: sf::Color multiplication not working
« on: July 27, 2020, 08:23:23 am »
Quote
Just multiply each element individually like so:
Not like so. You must then divide by 255 to bring it back to range [0 .. 255]. Or normalize components in [0 .. 1], if you need to do a lot of these multiplications.

11
It's because std::vector<Layer> will move it's elements when it needs more contiguous space in memory. You should handle copy or move construction for your Layer class, or better, store textures outside them (especially if they share the same ones).

The address returned by Sprite::getTexture() never magically goes back to null of course, the problem is that there's no more valid texture at that address, because it moved somewhere else. Your sprite thinks it points to a valid texture, but it's just garbage, and therefore it needs to be updated (which never happens in your code).

12
General / Re: Idea for sf::Keyboard
« on: July 18, 2020, 04:58:58 pm »
bool showDeltaTime = false;

// on keypressed event...
showDeltaTime = !showDeltaTime;

// at draw time
if (showDeltaTime)
    DevMode.displayDeltaTime();

14
Almost OK. You call the right functions, but with the wrong initial coordinates: you transform the player position, which has nothing to do with your bullets.

The initial coordinates should be the starting point of bullets relatively to the player's texture, ie. a fixed offset (for example, sf::Vector2f(5, 12)).

15
Take the player sprite's global transform (Sprite::getTransform()), and use it to convert your offset from local to global coordinates. That's the starting coordinates for your bullet. No math for you, and it works regardless of how the player is transformed (translated, rotated, scaled, ...).

Pages: [1] 2 3 ... 1284
anything