Messages

31

General / Re: Problems with x64

« on: February 08, 2021, 07:58:05 am »

It happens when you include <Windows.h> before SFML headers. It contains "min" and "max" macros, which totally ruin this kind of code using std::min and std::max. The solution is to define the "NOMINMAX" preprocessor symbol in your project.

32

Graphics / Re: View and rectangle "hitbox" problem

« on: February 05, 2021, 12:25:56 pm »

"worldPos" is the mouse position, translated to the same coordinates system as your button. It replaces "sf::Mouse::getPosition(window)" in Button::isButtonClicked.

If you don't understand what you're doing, take some time to think about it. And if you still don't get it, don't hesitate to ask for more explanations.

33

Graphics / Re: View and rectangle "hitbox" problem

« on: February 05, 2021, 11:01:09 am »

sf::Mouse::getPosition returns coordinates relative to the window, not to the view. You need to translate these coordinates with window.mapPixelToCoords, before doing your click test.

34

Graphics / Re: drawing a 1 pixel thick line

« on: February 02, 2021, 06:07:36 pm »

This only applies to points and lines primitives.

A simple solution would be to offset the whole view by (0.5, 0.5). But then you'll probably have troubles with other shapes (sprites, rectangles, ...). So adding the offset manually, only for lines and points, is probably the best solution.

35

Graphics / Re: drawing a 1 pixel thick line

« on: February 02, 2021, 07:51:24 am »

Try 10.5 and 100.5 for the points coordinates. I assume that you didn't change the view, nor resized the window.

36

Graphics / Re: Is there a way to load PDF document into image buffer ?

« on: February 01, 2021, 01:55:45 pm »

Hi

make some stuff

I think we'll need some details about this step.

I thought that SFML will be good library for this project since it is easy to use and it provides many useful functions for project like this

I can't see any useful function in SFML for a project like this. It won't help in loading your PDF, modifying it, and printing it. It seems like the best answer we can give you is to find a better library (or a combination of better libraries) for this task.

37

Graphics / Re: creating a texture through code

« on: January 14, 2021, 01:29:25 pm »

Indeed, all that stuff seems to be static, there's really no need to do it every frame. Even if the map was changing dynamically, you could make it much more efficient by creating the texture and allocating the pixel buffer once at init.

38

Graphics / Re: creating a texture through code

« on: January 14, 2021, 07:49:38 am »

std::vector<sf::Uint8> image(width * height * 4);

// set pixel (x, y):
image[(x + y * width) * 4 + 0] = color.r;
image[(x + y * width) * 4 + 1] = color.g;
image[(x + y * width) * 4 + 2] = color.b;
image[(x + y * width) * 4 + 3] = color.a;

// update texture:
texture.update(image.data());

39

General / Re: 'Window' in struct Shared_Context does not name a type

« on: January 13, 2021, 08:19:03 pm »

So, yes, you have headers that include each other. That doesn't work. #include statements are not always needed, a forward declaration is often enough.

40

Graphics / Re: creating a texture through code

« on: January 13, 2021, 04:06:44 pm »

sf::Image is in many ways just a pixel buffer, so use that to update the texture as Laurent says.

If the texture is filled in real-time (ie. every frame), that's not what we advise, as pixel access in sf::Image is quite unoptimized. A raw array of sf::Uint8 is preferred in this case.

41

General / Re: 'Window' in struct Shared_Context does not name a type

« on: January 13, 2021, 04:05:11 pm »

The code looks ok. Maybe a loop in includes? What headers do EnventManager.h and StateManager.h include?

42

Graphics / Re: creating a texture through code

« on: January 13, 2021, 09:17:37 am »

No, SFML doesn't allow direct access to the texture pixels. A better solution is to work on a local pixel buffer, stored in system RAM, and then update the entire texture in a single call with the Texture::update function.

43

General / Re: Bouncing ball simulation

« on: January 11, 2021, 02:21:39 pm »

That's quite different from what I posted. It's a good thing to try to make your own version, but if you don't know what you're doing, don't do it

Start with something similar to what I posted, make it work, and then tweak it if you need to.

44

General / Re: Bouncing ball simulation

« on: January 11, 2021, 08:05:47 am »

The classical equation for realistic gravity is, if I remember correctly:

initial_position = 0; // where the ball is at the beginning of the jump
initial_velocity = xxx; // some positive initial velocity
gravity = 9.81; // on earth

void update()
{
    time = clock.getElapsedTime().asSeconds();
    velocity = -0.5 * gravity * time * time + initial_velocity;
    position = velocity * time + initial_position;

    // handle bouncing
    if (position <= 0)
    {
        clock.restart();
        initial_velocity = -velocity; // * factor
        initial_position = position;
    }
}

(probably needs some adjustments, but that's the idea)

That's for Y axis. For X axis it's easier, velocity remains constant as there's no horizontal gravity.

To make the ball bounce, you have to invert velocity when it reaches the ground, and optionally multiply it with a factor because it loses energy when it touches the ground (factor < 1).

45

General / Re: Abandoned SFML because of the install process

« on: January 09, 2021, 10:48:24 am »

Hi

Let's take all these issues one by one.

Versions of VC++ should be compatible starting at Visual Studio 2015, so downloading the VS2017 build of SFML should work fine with VS2019.

Cmake-gui (don't know if that's what you used) explicitly states, when you choose the VS2019 generator, that the default is x64; the second combobox allows you to choose the Win32 preset if you prefer a 32-bit build.

I generated the SFML solution with CMake, with all default options, opened it, built it, no problem. Then compiled the INSTALL target, which failed as I expected it would. Why does it fail? Because the default install path, which is in C:/Program Files, requires admin rights to create and write stuff. Changing CMAKE_INSTALL_PREFIX to anything else solves the problem.

Is it an issue with Windows, that by default you can't write to where you're supposed to install program? Most likely, or we don't (want to) understand access rights enough. Is it a problem with CMake, which uses a default install path where regular users can't write? Most likely, but it can't be blamed for following the OS rules. Is it an issue with SFML, to simply use the CMake/OS defaults? I don't know. But one thing's sure: as a developer, you must know that C:/Program Files requires admin rights for writing. You can't blame other tools or middlewares for that.

I don't know what you did with your example program, and why you got linker errors. But I'm pretty sure it's something that's explained in the "Getting started" tutorial.

I don't know if you want to elaborate on the remaining problems, or if you just don't care. Both ways are fine But remember one thing: every environment is different, as it's a complex combination of OS, tools, configurations, etc. all with their specific version. You can't expect something to always work smoothly for 100% of users. There will always be problems, and understanding them is, in my opinion, a much better solution (as a developer) than giving up and losing the will to live