Messages

1

Window / Re: joystick detection

« on: October 14, 2024, 03:30:02 pm »

I don't know which OS you are on, but at least for Windows SFML only detects new joysticks being plugged in when the window receives a WM_DEVICECHANGE event. sf::Joystick::update() doesn't look for new ones, it only updates the state of existing ones.

Window events are only received when you call the window's pollEvent() method. Since your code is busy looping waiting for a joystick, it will never poll for events and detect a joystick was added.

2

General / Re: Smaller enemy spawning per frame rate

« on: September 24, 2024, 10:40:04 am »

I'm just guessing based on the picture, but if the red shape is a bullet and the blue triangles are enemies, it looks like the triangle touching the red shape has spawned hundreds of small enemies that are moving away and rotating, leaving those white arm shapes. If that's the case, my guess is your destroy function isn't working. Both the red thing and blue triangle are still there, they should have been destroyed on collision, so they are continuing to collide every frame.

One side note, is your dist() function returning distance or distance squared?
if (enemypos.dist(bulletpos) < (eCR + bCR)*(eCR + bCR))
You are squaring the radii, so dist() should be the squared distance, but normally I'd expect that to have a name like distsq or something.

3

General / Re: Does float's imprecision affect transformations?

« on: September 20, 2024, 10:12:27 pm »

For really large worlds, I'd use fixed point maths for all positions. That gives a consistent precision over the entire range. Then get the different between the fixed point objects and the camera and convert to a float, anything on screen will have a small float value (well, a few thousand depending on resolution) and it's purely the visual side, the simulation itself is still in fixed point.
For example using 64bit integers as 48:16 fixed point and a world where 64 pixels represents 1m (that's what I use normally), you'd have a consistent precision of 0.000000238m over an area 29 astronomical units across (over 280 trillion pixels).

I've never used SFML's transform hierarchies, but as far as I remember it's just matrices. So there's going to be float error in there. If the matrices accumulate error for too long, they won't even stay orthogonal.
It depends on what you are doing with the transform hierarchy as to how to avoid it.

4

General / Re: Strange compiler errors in imgui-SFML.cpp code

« on: September 16, 2024, 11:00:55 am »

I think your imgui-sfml might be an older version.

In the error log it says it's trying to pass arguments like this (ImTextureID, ImVec2, ImVec2, ImVec2, const int, ImColor, ImColor) to a function that looks like ImGui::ImageButton(const char *,ImTextureID,const ImVec2 &,const ImVec2 &,const ImVec2 &,const ImVec4 &,const ImVec4 &)

There's two differences there: The ImGui::ImageButton has a const char* at the start and no int in the middle.
This was a breaking change in ImGui 1.89. Back in 1.88 and below, it did have version of ImageButton that would have worked.

ImGui-SFML adapted to the change in the 2.6 branch on 8 december 2023. So it looks like your ImGui-SFML is from before that date. Try updating ImGui-SFML's 2.6 branch to the latest (should be from feb 2024).

5

General / Re: Strange compiler errors in imgui-SFML.cpp code

« on: September 15, 2024, 10:48:57 am »

Next step will be to show us the errors.
The error list version only says the type of error, not the details of what it's having trouble with.

Go to the compiler output and it should have a big block of text saying something like this:

1>F:\work\kf\tests\kil_ui_test\kil_ui_test.cpp(508,6): error C2665: 'BBB::stuff': no overloaded function could convert all the argument types
1>    F:\work\kf\tests\kil_ui_test\kil_ui_test.cpp(495,15):
1>    could be 'void BBB::stuff(float)'
1>        F:\work\kf\tests\kil_ui_test\kil_ui_test.cpp(508,6):
1>        'void BBB::stuff(float)': cannot convert argument 1 from 'const char [5]' to 'float'
1>            F:\work\kf\tests\kil_ui_test\kil_ui_test.cpp(508,12):
1>            There is no context in which this conversion is possible
1>    F:\work\kf\tests\kil_ui_test\kil_ui_test.cpp(494,15):
1>    or       'void BBB::stuff(int)'
1>        F:\work\kf\tests\kil_ui_test\kil_ui_test.cpp(508,6):
1>        'void BBB::stuff(int)': cannot convert argument 1 from 'const char [5]' to 'int'
1>            F:\work\kf\tests\kil_ui_test\kil_ui_test.cpp(508,12):
1>            There is no context in which this conversion is possible
1>    F:\work\kf\tests\kil_ui_test\kil_ui_test.cpp(508,6):
1>    while trying to match the argument list '(const char [5])'

In this case, it's showing I have an overloaded function that takes a float and another that takes an int. But I tried to call them using a literal string. It didn't think either function could convert a string to what they needed.

6

General / Re: Strange compiler errors in imgui-SFML.cpp code

« on: September 14, 2024, 11:57:51 pm »

It's most likely a version difference. ImGui-SFML acts as a wrapper around things like passing SFML graphics (sprites, rendertextures, etc) to ImGui. But you are using a 2018 version of SFML with a Feb 2024 version of ImGui-SFML and a Sep 2024 version of ImGui. Either ImGui-SFML's 2.6 is no longer compatible with SFML 2.5.1 from 6 years ago, or ImGui has changed something since ImGui-SFML came out.

I've had to fix these in the past, but I can't remember what the changes were. I've got 627 imgui-sfml.cpp files on my PC, so a bit hard to check. I think it was adding SFML 3 support before imgui-sfml did, I've been on 3 for quite a while now.

7

General discussions / Re: Texture atlas tiling

« on: August 20, 2024, 10:29:04 am »

Yep, shaders can let you repeat a section of a texture (doing a bit of modulus and stuff with the UV coordinates).
One thing to be careful of though is a sudden jump in UV (like going off one side of the tile and back on the other side) will trip up mip mapping and it will do an edge of 1x1 mipmap, so a solid colour. You need to manually control the mipmapping to avoid it.

8

Graphics / Re: How to properly draw everything and than scale up the screen?

« on: July 22, 2024, 01:43:13 pm »

A view will scale the coordinate system, and sprites will render scaled (so may look pixelated), but line primitive rendering happens at the resolution of the buffer regardless of view.
(Technically the sprites are also at buffer resolution, if you rotate them the edges will be high res, it's just the texture that is pixelated)

To get a complete pixelated view, what you can do is have a RenderTexture with a low resolution. Render all of the gfx into the rendertexture. Then render the rendertexture onto window using a scaled up sprite.

9

Audio / Re: My Sonnd doesn't play

« on: July 14, 2024, 11:09:40 pm »

My guess is it's this part:
bufferSoundWhenBTNClicked = *bufferSoundBtnClicked;
soundWhenBTNClicked = *soundBtnClicked;

That's taking a sound buffer pointer and sound pointer, dereferencing them and duplicating them into two class members.
The problem is the duplicate sound's internal buffer pointer is still pointing at the original buffer (which will be cleaned up once the shared pointer is no longer in use), not the duplicate buffer.

Maybe try calling setBuffer on the class members after assigning them.

10

Window / Re: Class for multi-layer sprites rendering

« on: July 11, 2024, 05:44:18 am »

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.

Exactly as it is, the code shouldn't actually compile. The problem is the top is:
std::vector<const sf::Drawable*> buffer(5u);
(a vector of 5 drawable pointers)
instead of:
std::vector<const sf::Drawable*> buffer[5u];
(an array of 5 vectors of drawable pointers)

The rest of the code treats buffer as an array of vectors (such as buffer.clear() which won't compile if buffer is a vector).

11

Graphics / Re: Core dump with 2D array with RectangleShape type

« on: July 04, 2024, 07:45:10 pm »

Vector's reserve function allocates memory, but it doesn't actually make the elements of the vector, you still have to push_back new rectangles before you call setSize on them.
Instead of reserve try: bricks

• .resize(4);

Resize allocates the memory, but also fills it with the correct number of valid items that you can access right away.

12

General / Re: Check if SFML is installed

« on: June 26, 2024, 08:25:16 pm »

I use __has_include for exactly this. My vector maths class checks for SFML, Box2D and Imgui headers to add casting operators if the required headers are present.

13

General / Re: Setting bullets position to a weapon sprite that changes its rotation

« on: June 20, 2024, 06:07:53 am »

I'm not sure if this works right but you might be able to simply multiply the difference between the two origins against the sin() and tan().
Example:    newbullet.shape.setPosition(sprite.getPosition().x+(32*cos(angle)),sprite.getPosition().y);

EDIT: My mistake. I guess that doesn't work right. I think i'm close tho.

If you add cos on the x, then you need to add sin on the y.

newbullet.shape.setPosition(sprite.getPosition().x+(32*cos(angle)),sprite.getPosition().y+(32*sin(angle)));

14

Network / Re: The problem of transferring data to clients with a UDP socket

« on: June 19, 2024, 05:08:50 pm »

The main advantage to UDP is that some game data isn't necessary as such. For example movement data is going to be sent frequently, if you miss a packet or it arrives out of order you can ignore it because another packet is about to replace it in maybe 50-100ms anyway. It's faster to ignore the missing data and just get the next packet. But TCP would keep retrying to get the missing packet, holding up all of the next packets.

So most games use UDP with their own reliability protocol on top. Basically replicating that part of TCP for data that has to get through (like your map data). THis lets you pick which packets need the (potentially slower) reliable mode, whereas TCP forced every packet to be reliable.

15

General / Re: I need help with this

« on: May 25, 2024, 03:10:16 am »

For ball to ball collision, you can increase the ball radius by the cue ball radius, now the cue ball can be treated as a single point and use raycasts.
But you don't want to actually grow all of the balls by that amount, because they would then collide with each other early, so you need a temporary larger shape.

I'm just guessing on the code off the top of my head, but I think you could do it like this:
Loop over every ball (not including the cue ball)
   Make a temporary b2CircleShape with the same position as the current ball and larger radius
   Do a shape raycast from the cueball position
End of Loop
Make 4 b2EdgeShape for the table sides that are moved inwards by the cue ball radius as eXpl0it3r said
Do shape raycasts against each edge.
Find which of the above raycasts had a hit closest to the cueball

https://box2d.org/documentation/classb2_circle_shape.html#a442e847b9fc3d1344b02b48d490eb0c6