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 ... 226
1
Graphics / Re: Unabled to load file problem - loadFromFile.
« on: December 04, 2024, 02:48:17 pm »
Have you tried absolute paths to make sure the image is able to be loaded?
Presumably it's not loading because it can't find it but it might not be able to read it.

If it can't find it, it would likely be due to local paths and where your IDE is looking for them. How to change this depends on the IDE.

2
SFML projects / Re: Dispersio 3
« on: December 03, 2024, 11:04:11 pm »
Hi again and it's great to see you back at it!

I'll be interested to see your progress throughout.

3
SFML projects / Re: Shape Wars - A 2d Shooter
« on: November 27, 2024, 04:56:36 pm »
Looks good. Congrats :)

4
Graphics / Re: Colour individual triangles in a sf::TriangleStrip
« on: November 27, 2024, 04:41:17 pm »
You can do this with a triangle strip but it requires duplicate vertices and, if you're doing this often, it may be better to just use separate triangles.

e.g.
I'll assume you have 8 vertices in the example and they are bottom0, top0, bottom1, top1, bottom2, top2, bottom3, top3.

You can use (12 vertices) bottom0, top0, bottom1, top1, top1, bottom1, top2, bottom2, bottom2, top3, bottom3.

This allows change of colour over the doubled vertices.
Note that this works because the doubled vertex as well as the previous (or next) vertex create an infinitely thin triangle so those two triangles (where the colour transitions happen) are invisible.

A possibly simpler version
If you need each triangle pair to be the same direction then you can just duplicate the 2 vertices that represent the edge.
This works because, again, you're "drawing invisible lines".

That would be (12 vertices) bottom0, top0, bottom1, top1, bottom1, top1, bottom2, top2, bottom2, top2, bottom3, top3.
This could be more simple as you're still following the same bottom-to-top and left-to-right formula and you it looks a bit clearer in the code as you're effectively separating the vertices into groups of 4 (per quad).

Here's an image of all three of those examples with your original being the top one (number 1):


(click to show/hide)

5
Does this have the same effect if you use
getFullscreenModes()[0u]
instead of
getDesktopMode()
?

6
Graphics / Re: RenderTexture blurry when scaled up
« on: October 19, 2024, 05:49:59 pm »
The render texture is blurry because it is smaller than the final image and then scaled up (as you pointed out in the title). As always, if a smaller image is scaled up, there is less detail and can appear blurry.
Remember that drawing to a larger window directly is effectively drawing to a large surface/texture so it can be expected that it would allow more detail.

The simplest way to combat this is to just make the render texture larger. Scaling down is usually less blurry.
You can start as large as you expect it to be or you can recreate the render texture after resizing the window. It can be relatively slow to recreate a render texture; just keep that in mind.

If the render texture would be far too large, you could consider one of exactly half size (in each dimension) and then scaling up. Removing smoothing would keep this nice and sharp.

7
General discussions / Re: Views and sprite world positions
« on: October 19, 2024, 05:41:20 pm »
Absolutely. It "just sits there" and then the view moves over it and it becomes visible. That's the idea behind the process indeed.

Anything you draw after "setting" the view will be drawn with that view. However, if the view is changed (set to a different view) or even if the current view is modified and then updated (which is the same as setting it to a modified version of that view), everything needs to be drawn under the new view.

With that said, the question really is: do you use more than one view and are you setting it to a different one before drawing the sprite?

It's also worth noting that if you have any calculations based on positions (and the like) of objects where you use things like "getPosition()", you should remember that it takes into account the view that is currently set "at the time of making those calculations."

8
Graphics / Re: origin relative to the Transformable
« on: September 14, 2024, 06:14:16 pm »
Quote
The origin of a drawable should always be updated
I was proposing for SFML to handle this. Thus, when I set the origin of a text to its center, then update the string in the text, I wouldn't have to worry about updating the origin as well.
The problem with this is that the required result of this can be dependent on its use, especially with text.
For example, when you change a character in all lower case string to its capital, the text would move downwards. Most often, it's best to find the "best" centre for the text and then keep that when changing the string. Note that I'm, here, talking about the y value only; the x still needs updating. Also, this is more complicated for multi-line text.

My main point really is that sometimes you may want to allow it to move the text so that the true centre is where you position and sometimes you may want to text a centre based on a 'usual baseline' and centralise the x, meaning that, since that this decision is made by the user, the user should probably centre the text manually.

Of course, you can add simple functions to do this automatically in the specific way you want it, if required. For example:
void setTextString(sf::Text& text, const sf::String& string, const bool autoCenter = true)
{
    text.setString(string);
    if (autoCenter)
        text.setOrigin( /* you know this bit ;) */ );
}

// ...

sf::Text text;
// set up the text including font and character size first!
setTextString(text, "Some string");

9
Audio / Re: Music.setVolume doesn't work.
« on: August 29, 2024, 09:24:25 pm »
Does music.getVolume() return zero correctly?

Is the volume affected if you stop and then re-start the music?

Is it possible you have a line somewhere else that sets its volume to something else?

10
Graphics / Re: origin relative to the Transformable
« on: August 29, 2024, 09:19:54 pm »
The origin of a drawable should always be updated whenever the drawable is manipulated unless you can be sure that it doesn't need it for some reason. This is particularly important with texts that change string, fonts, styles, sizes etc..

Also remember that the centre of an actual visible bit of text, the origin should also take into account the position of the local bounds (as an sf::Text's bounds can be non-zero) so it's likely that you should use (presuming SFML 2.6+) something like:
text.setOrigin(text.getLocalBounds().getPosition() + (text.getLocalBounds().getSize() / 2.f));

If you are interested in using a library that calculates different parts of a drawable automatically (or understand how to calculate it for yourself), then please feel free to have a look at Plinth, in particular "SFML Anchor" (the code - similar to above - that calculates the centre, for example, is here). This also works with SFML pre-v2.6. Note that is still requires manually updating of the origin when needed; it just simplifies the code (and tends to make it more readable).

11
Any ideas why this doesn't work
[...]
"The SetWindowLongPtr function fails if[...]
Could this be a possible reason for not allowing transparency?
Is SetWindowLongPtr function failing? You haven't mentioned that.

12
Graphics / Re: LoadFromMemory Sprites
« on: August 11, 2024, 04:47:41 pm »
Since your function returns an sf::Image, you can use it directly in the call to loadFromImage, presuming you have no intention of using the sf::Image for processing.:
sf::Texture scottTexture;
scottTexture.loadFromImage(LoadImageFromResource("SCOTT_PNG"));

That image will automatically be destroyed (cleaned up) after the texture is loaded from it.

13
Window / Re: How to properly draw multiple RenderTexture ?
« on: August 11, 2024, 04:38:57 pm »
Don't forget to clear your render textures with a colour that is transparent if you want a transparent background as the default colour is an opaque black.

e.g.
renderTexture.clear(sf::Color::Transparent);

This would allow your render textures to be transparent "layers" but don't forget that either the window or the lowest layer should be cleared with the solid colour of choice (and should also fill the entire window if it is a layer).

14
General / Re: Bouncing ball on 2D pane
« on: August 11, 2024, 04:33:35 pm »
Trigonometry and studies on energy conservation would help here for sure.

Just finding a way to use trigonometry to create a "reflection vector" would help for bouncing/rebounding balls.

However, since it's likely that your table boundaries are perfectly vertical and horizontal (assuming a 2D downwards projection) you could "reflect" by inverting the direction's x or y, depending on which side it hits.

Of course, when balls collide with other balls, you will definitely need some trigonometry.



e.g. for a ball that collides with a wall on the right-hand side of the screen (positive x value):
first, I presume you have a velocity vector (the amount added to the ball's position/the ball is moved).
once it collides with the (right-hand) side, negative the x value of the velocity vector:
velocityVector.x = -velocityVector.x;
For example, if the currently velocity vector is (14, 14) (a South-East movement of 10), negating its x value would mean it becomes (-14,14) (a South-West movement of 10).

Something to be aware of is that when a collision happens and the velocity is negated, the collision should not happen again while the ball is still in its position. So, you can move the ball an extra movement after a collision to push it away from the collision area. Or, you could just move the x part to the maximum it is allowed to be before collision.

Doing it more accurately would mean that you would need to calculate the distance it has intersected the collision boundary, move the ball back to the exact point it would have collided, then - after flipping the direction of the velocity vector - move the ball forward by the distance it had intersected.

15
Window / Re: Class for multi-layer sprites rendering
« on: July 10, 2024, 09:27:35 pm »
You'll need to make sure that all of the pointers are valid. That is, both 'not null' and 'of type sf::Drawable*'.

Presuming your using my exact code, is it crashing on where I wrote "i expect this to work"?

Thinking about it, I think I used the wrong cast. It should not be "reinterpret_cast", it should instead be "dynamic_cast". I'll edit my post.

I've also realised that that loop doesn't need to be a reference. i.e. "const auto t" instead of "const auto& t" since it's just a pointer and a reference to a pointer seems to make little sense (unless in very specific scenario).


Pages: [1] 2 3 ... 226