Messages

46

General / Re: Question about the coordinate system (how to plot negative x and y)

« on: January 08, 2021, 06:12:50 pm »

From what I understood, SFML coordinate system has its origin (0,0) in the top left corner of the screen while max coordinates are defined by the window size.

That's just the default. Using sf::View (see doc, tutorials, etc.) you can show any part of your scene into the window, including parts where coordinates are negative.

47

Graphics / Re: Drawing a hyperbola in SFML

« on: January 05, 2021, 06:08:08 pm »

At the end the graphics card only understands 3 types of primitives: points, lines and triangles. So no matter what you do, the solution will be an approximation using lines or triangles.

The only alternative is to directly draw your curve pixel by pixel on a texture, and show that texture with a sprite.

48

System / Re: Frame-independent movement with sf::Clock

« on: January 05, 2021, 11:41:18 am »

Problem is, I have to move exactly 48 pixels (the size of a tile), so since the elapsed time could vary, the player might end up in-between tiles.

There are simple solutions to this problem. Like storing the distance walked by the player, and clamping the last move so that it never exceeds 48.

auto frame_distance = speed * elapsed_time;
if (frame_distance + total_distance > 48)
{
    frame_distance = 48 - total_distance;
    is_moving = false;
}

total_distance += frame_distance;
move(frame_distance);

49

System / Re: Frame-independent movement with sf::Clock

« on: January 05, 2021, 10:11:54 am »

A common and simple solution is to choose a fixed speed (in units/s) and then move the player by speed * elapsed_time every frame.

There are two problems with your implementation:
1. you move only once every N frames; movement would be smoother if you moved every frame
2. you move by a constant amount of pixels when time is > 0.033, but it could be any value, not exactly 0.033, so the result is a variable speed

50

Network / Re: UDP Socket not recieving updated data.

« on: January 01, 2021, 04:43:10 pm »

Maybe you have a persistent sf::Packet instance, and you forget to clear it between each new data?

51

Graphics / Re: OSX - failed to compile fragment shader

« on: December 29, 2020, 09:42:59 am »

Removing the 'f' should be ok. Just '1.0' for literals.

52

Graphics / Re: sf::ConvexShape and sf::Mouse

« on: December 24, 2020, 08:20:33 am »

setPosition is exactly the same for ConvexShape and CircleShape. It's also the same for all SFML entities, since it's defined in the Transformable base class.

I'm sorry but I really don't understand your question/problem, so I can't give you a correct answer.

A Shape, either a convex shape that you define manually or another pre-defined one for which SFML computes the points, has a set of points defined in local coordinates. Then, like any other drawable/transformable entity, these points are transformed with the origin, translation, rotation and scale of the entity to produce their final position on screen. I don't know what else to say.

53

Graphics / Re: sf::ConvexShape and sf::Mouse

« on: December 23, 2020, 09:21:18 am »

Do you mind explaining why it can't have an origin and position?

It can, but these will offset the final position of the point, and it will not be under the mouse. Unless, as I said, you take them in account when computing the local coordinates of the point.

I'm also confused about why this is different than using like sf::CircleShape(10,3) and doesn't respond with the mouse the same?

I don't understand the question. How can you compare that to sf::CircleShape, since you can't set the position of the circle's points like you do with a convex shape?

54

Window / Re: WaitEvent loop but with some timed updates

« on: December 22, 2020, 03:42:18 pm »

waitEvent can't return without an event. The common solution is the one you mention: using waitEvent in main thread for events management only, and the rest in a secondary thread.

No need to deal with setActive if all graphics calls are done from the same thread (ie. the secondary one), you'll just have to call window.setActive(false) once before launching your thread. Then you'll just need one synchronization point to pass events from the primary thread to the secondary one.

Or you could implement a fake waitEvent (as SFML does internally): call pollEvent at a given frequency, fast enough so that you don't notice any lag, but not too much to preserve CPU cycles. waitEvent uses 10 ms sleep.

55

Graphics / Re: sf::ConvexShape and sf::Mouse

« on: December 22, 2020, 08:11:15 am »

The shape's points are defined in local cooridinates. This means that the position and origin of the shape, which are non-zero in your example, are then applied to produce the final positions. If you want the point to be exactly where the mouse is, then your shape can't have a position and origin (or you must take them in account when computing the local position of the point).

56

Graphics / Re: Textures not loading properly in sprites in vectors

« on: December 20, 2020, 07:51:40 pm »

This is known as the white square problem. I'm sure you'll find many topics on this subject on the forum, it's even mentioned in the sprites tutorial.

57

Audio / Re: Audio not working with GCC 7.3.0 MinGW (DW2) - 32-bit

« on: December 19, 2020, 08:13:55 pm »

Is this documented somewhere that we sometimes have to manually copy .dll files to the output directory?

At the end of the "Getting started" tutorial. Moreover, knowing how shared libraries work (how they are loaded by the OS) -- which is not very complicated -- is something that every developer should know.

58

SFML website / Re: a "beginners" board in forum?

« on: December 18, 2020, 08:51:32 am »

This is just my personal opinion, but I'm not in favor of such a forum.

First, the scope: "Beginners" doesn't specify a technical scope, and since a large part of the members here can be considered as "beginners", it would receive 90% of the messages. In fact it would just be the new "Help > General" forum, but worse

Then what would we get in this new forum? C++ questions, mostly, but then why not posts about other languages where SFML exists? Algorithms? OpenGL? Win32? Physics engines? It would open the door to many new things -- too much.

Would it be a problem to have all this new stuff possibly posted on the SFML forum? Definitely. More work for us (reading all posts, sometimes answering, moderating). And more difficulties to find answers on a specific topic, as everything would get mixed into this generic forum. Inefficient search of existing topics, so more duplicates posted

I really want to focus on SFML here, I think we can be efficient at helping people if we keep the scope limited; I don't intend to create yet another generic game dev forum -- there are already tons of them elsewhere.

But this is just my personal thoughts.

59

General / Re: Moving a point around a falling circle

« on: December 14, 2020, 03:25:02 pm »

The circle center is not "position + radius / 2 + radius". It should be "position + radius" (given that "position" is the top-left corner -- ie. you don't call setOrigin).

And sin/cos functions definitely do not take angles in degrees.

I don't know how you can get something "working" with this code

60

General / Re: Moving a point around a falling circle

« on: December 14, 2020, 10:45:58 am »

Hi

A point on circle is given by (pseudo-code):

p.x = circle_center.x + circle_radius * cos(angle_in_rad);
p.y = circle_center.y + circle_radius * sin(angle_in_rad);

According to how your 2D coordinates system is defined, you may have to negate and/or switch the sin/cos terms to get the right orientation.