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

Pages: 1 2 [3] 4 5 ... 223
Did the answers given on the other thread that you made about this topic not help?

General / Re: How do I make a rectangle move at the direction of a line
« on: January 23, 2024, 06:34:09 pm »
Will fix that right up, thanks!
You're welcome. :)

How do I rotate the line the direction is decided like this
        line.setPosition(shape.getPosition().x - (shape.getSize().x),shape.getPosition().y + (shape.getSize().y/2));
It would depend on what "line" is. If it's a rectangle, set its rotation to the direction you already calculated. If it's a vertex array (2-vertex line), set its start and end points by using the offset you just calculated.

General / Re: How do I make a rectangle move at the direction of a line
« on: January 22, 2024, 06:22:46 pm »
Here's an example...
Could this line:
auto deltaPosition = sf::Vector2f{ mousePosition.x - triangle.getPosition().x, mousePosition.y - triangle.getPosition().y };
not just be this:
auto deltaPosition = mousePosition - triangle.getPosition();

Graphics / Re: Issue with LoadFromFile
« on: January 21, 2024, 05:11:53 pm »
Hi and welcome! :)

More information may be needed to help with this quite specific issue.

Your device set-up details can help as well as which version of SFML you are using etc..

Also, providing the actual error will help, including error codes and surrounding information.

Depending on if it's "not working" during runtime or compilation, call stack information may also be helpful.

One thing to be aware of, first, is that SFML's version has to match the compiler exactly. With VS, however, the latest one should be okay (it's 2022 version anyway!)
That is if you're using pre-build binaries. If you are building yourself, it's likely to match but it must be build correctly to work.

Similarly, the DLL have to match the Configuration. 32- or 64- bit DLLs must be used when building for 32- or 64- bit. Debug DLLs have "-d" on the end of the filename whereas Release DLLs do not. Debug and Release DLLs should match if building with Debug or Release.

It should be noted that events are usually treated as independent effects so shouldn't necessarily rely on order.
With that said, you should expect that the events given by SFML are in the order that they happened.

If you look at the popEvent call in your quoted code, you can see that it's called on m_impl so that's where you would have found it. Here it is (popEvent):

Note that it removes the first one so it's a queue:

Graphics / Re: Velocity visualizer
« on: January 17, 2024, 08:35:50 pm »
If the arrow is a sprite/quad or some other transformable, you can simply set its origin to match the point of rotation (start of the arrow or centre depending on your preference), set its position to the centre of the player sprite and then scale it based on the velocity. Assuming your unrotated arrow points to upwards, you would need to scale the y size only to stretch its length (this is not affected by the rotation).

If you just need a vector, using a polar vector is the simplest way.
If you're using SFML 3, you'll already be able to do some of that. SFML 3's sf::Vector2 can allow you to set its rotation angle so you'd just need to set it to a "flat" vector at the correct length and then set its angle.
If you're not using SFML 3 - or you need to set its length directly - you could use an actual polar vector. Plinth and Thor both provide these. You could also do the calculations yourself. It's actually not too hard: calculate its length, divide the vector by that length to get its unit vector and then multiply by the preferred length. Remember to make sure you're not dividing by zero though!

If a stretched arrow isn't even that important, you could just scale the arrow fully so that its width also increases.

Of course, you'd also need to know the player's velocity and have mapped that to the scale you want. e.g. 0-100 speed -> 0-1 ratio -> 0-200 arrow length.

System / Re: Process finished with exit code -1073741515 (0xC0000135)
« on: January 17, 2024, 12:39:51 pm »
The same issue?
The same error code when the music doesn't load?

Confirm the music file is valid and in the correct location. An absolute path test can help with this.

You can have multiple textures and switch between them as and when required. The one you use shouldn't cause any lag if it's still just one at a time (instead of multiple textures just for the player, for example) although if may not be as optimised as using the same texture as the objects drawn before and after it; it also reduces ability to batch stuff.

So, yes, you can just change which texture to use. You can use different textures for different things if needed.

If you have a limit of how many textures you can have at once (for whatever reason), you could store images and swap textures in and out. Note that this is slower and should only be done occasionally.

I heard something about it being possible to load large textures using vertices. Is this correct?
I'm not exactly sure what this means so to clarify:
  • Images are a pixel array stored in memory. This holds the data of the image (pixel colours). This is limited only be size of RAM.
  • Textures are similar to Images but are stored on the graphics card's memory. This can be accessed by drawing operations. The limit to the size of a Texture is determined by the graphics card.*
  • Sprites (or other Vertex arrays that show textures) show a part of a texture. For a Sprite, this is rectangular. Their appearance's size is limitless. For a Sprite, you change its size using its Scale.

So, a texture is a rectangular image that is stored on the graphics card that can be used while drawing.

One issue that sometimes occurs is that you may want to show an image larger than you can store in any one image. For this, you can use multiple textures and stitch them together; basically, it's just drawing multiple things together. The Thor library can do this automatically for you.

However, it doesn't sound like you're trying to draw a large texture, rather can't fit all frames of an animation on the same texture. This is absolutely not an issue; you can simply put some frames on one texture and some on another and just change which texture to use when you draw it. For example, with a Sprite, you'd just set its texture at the time when you set its texture rectangle.

*To determine the largest possible texture that you graphics card can use, you can use SFML:
const unsigned int maxTextureSize{ sf::Texture::getMaximumSize() };
Note that this is a one-dimensional length. The texture size is a square area with this length for both dimensions; its size is (maxTextureSize x maxTextureSize).

This can help you determine the size of the images you create externally but be aware that this can be different for different devices so may need to account for different sizes if you intend for others to use it.

Probably the best solution is just move it away so it no longer collides. It shouldn't be penetrating anyway, right?

Still, another option is to have a flag that triggers (sets) when it collides. Then, when you test for the next collision, if the flag is set, don't change its velocity. If it is no longer colliding, reset the flag.

General / Re: Rotating a drawing from its center
« on: January 14, 2024, 10:38:55 pm »
Changing the origin changes the part of the sprite that is at the sprite's position.
This is important to remember.

If a sprite is 100x100 and at position (100, 100).
If its origin is at top-left (0, 0), its top left will be at (100, 100) and its centre will be at (150, 150).
It its origin is at centre (50, 50), its centre will be at (100, 100) and its top-left will be at (50, 50).

Basically, set its origin where you want to rotate it and then position that point where you want it.
In your case, set its origin to its centre (and keep it there) and then position its centre when the centre should be.
This means that when its "not rotated", it should have a rotation of 0 and its position should be half of its size added on to where you think its top-left should be.

To be more complete, I shall just add that all transformations are applied around its origin so it rotates around it, scales from/to it and its position matches it.

Graphics / Re: Updating Tile Map?
« on: January 14, 2024, 01:59:19 pm »
You're very welcome. Glad you sorted it.

For your information, however, there are existing solutions for tilemaps. Here are a couple:
Selba Ward's Tile Map (basic 2D grid with automatic separation support)
Cheese Map (flexible layered maps and free tiles with automatic culling)
Note: I made both of these to help people create maps more simply.

When they collide, they aren't being moved so that they no longer collide; the velocity is changed but not the position. This means that during the next update, they will still be colliding even if they are "about to" move away but this will cause them to move in opposite direction again (the original direction that caused them to collide in the first place) and this gets repeated.

The solution is to make sure that you respond to the collision by changing their position so that they no longer collide and not just change their velocity.
A simple way to do this is to simply add the velocity to its position immediately after changing it.

Note that if there are many circles, they may get stuck between multiple circles and can no longer just be moved out of the way on their own; they would all need to be moved to allow them to fit without colliding!

Graphics / Re: Can't get snake to grow
« on: January 13, 2024, 10:47:45 pm »
I will assume the body has the part nearest the head first in the vector but you can do it in the other direction as well but this would need to be adjusted to fit.

To move the body:
remove the last item in the vector,
copy head's and insert it at the front of the vector.

You can do this before updating the head to its new position.

If there is no body, don't try to move it.

If the body grows, just don't remove the last item when moving.

General / Re: Ayuda
« on: January 13, 2024, 10:42:01 pm »
Remember to link to SFML (specify where its include folder is) when building (Windows) or install it (Linux). (Possibly both for Mac)

System / Re: Failed to activate OpenGL context
« on: January 13, 2024, 10:36:03 pm »
It sounds like you're drawing a sprite per pixel but I could be wrong. If you are, though, you should more likely use a vertex array of points.
With that said, converting from thousands of sprites to a vertex array will also help improve performance.

You could use a ready and automatic batcher such as this one (easiest option), write a custom batcher or create the vertex array from the ground up (best but most complicated option).

If the issue is during preparation, you could likely perform the generation on values in memory (off the GPU) and only transfer to GPU when it's ready (such as by drawing a vertex array or other option).

"Other option": You could create an image or texture that contains what you are drawing and then draw just that as a quad (or multiple textures and quads if required). This is a pre-render.

A mid-way option is to do the same thing but to a render texture and that allows you to possibly more easily update it (or parts of it) if things change.

Pages: 1 2 [3] 4 5 ... 223