Messages

1

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.

2

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.

3

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).

4

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.

5

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.

6

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)));

7

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.

8

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

9

Graphics / Re: Sprite is drawn in incorrect position after RenderWindow is resized

« on: May 22, 2024, 11:20:29 am »

The view controls how the scene is mapped onto the window. But when a window resizes, the view isn't modified. So you'll need to generate a new view. For example:

                                if (event.type == sf::Event::Resized)
                                {
                                        sf::Vector2u size = g_window.getSize();
                                        g_window.setView(sf::View(sf::Vector2f(size.x / 2.0f, size.y / 2.0f), sf::Vector2f(size.x, size.y)));
                                }
 

10

General / Re: I have a problem

« on: May 19, 2024, 09:08:51 am »

The biggest hit here is that you are loading the background jpg from disk every frame. It really should be loaded just once at the beginning then reused, like the hero sprite's texture.

11

General / Re: Can you integrate allegro into an sfml window?

« on: May 15, 2024, 11:32:16 am »

If you don't need audio, OpenCV is very easy to get working in SFML (1 line of code to load a video, about 5 lines to read a frame into a texture, do that with a timer). I haven't done much with it, I was just testing security camera footage analysis and playback, so the video was already low framerate.

12

Graphics / Re: [SOLVED] MacOS Build and Windows Build has a Difference when Drawing Rectangle

« on: May 14, 2024, 03:21:00 am »

Views are like cameras in other engines. They transform SFML coordinates into window coordinates.
By default it's a 1:1 pixel scale. So coordinates 100,100 in SFML would be pixel 100,100 in the window. But you can change the position, rotation and scale of the view, which lets you pan around and zoom on the scene without messing with what's rendered.
https://www.sfml-dev.org/tutorials/2.6/graphics-view.php

13

Graphics / Re: MacOS Build and Windows Build has a Difference when Drawing Rectangle on Screen

« on: May 14, 2024, 12:41:53 am »

It might be a good idea to also try the program at the same window size on both. Currently the windows one is 1910x1102 and the mac is 3474x2214.
Also the mac screenshot appears to have the right side cut off, the rounded corners of the window aren't visible on the top or bottom right.

14

Window / Re: Problem handling multiple key stroke

« on: May 13, 2024, 05:25:58 pm »

Yep, sounds like keyboard ghosting / ghost keys.
Microsoft have an webpage demo that can help find ghost keys (basically just highlights keys on screen as you press them): https://www.microsoft.com/applied-sciences/projects/anti-ghosting-demo

Most non gaming keyboards have ghosting, which keys ghost depends on the keyboard hardware.
Some keyboards will have a rating like 4-key rollever which means you are guaranteed to be allowed to press 4 different keys at once before ghosting happens. A keyboard with n-key rollover can handle any number of keys at once.

If we're talking about arcade machines based on a PC, it depends on how the controls are hooked up. One popular device (I've even got one here somewhere) is the I-PAC2. It's a $39 device that lets you wire up 2 arcade joysticks with 8 buttons each (and some extra like player 1 and 2) and emulate a keyboard. No coding needed. The good thing is it has no ghost keys.

One option if you are just testing is to plug in two keyboards at once. Definitely for Windows and maybe for Linux (not sure) keyboards are merged into one system device. So software like SFML sees one keyboard but really it gets the results of both merged together. That would still have ghosting on each keyboard, but not one ghosting the other.

So yeah, this is a keyboard hardware issue, not the fault of the OS, SFML or USB.
(Also very annoying. My sister worked out the keys on my old keyboard that she could press while we were playing Mortal Kombat 3 that would stop my jump and kick keys from registering)

15

General / Re: Can you integrate allegro into an sfml window?

« on: May 13, 2024, 05:07:34 pm »

I guess it depends on what you require as to whether Allegro is a good idea.
Taking a look at the official Allegro video addon, it only supports Ogg Theora video files and the top of the main source file says:

/* This is just a quick hack. But good enough for our use of displaying
 * a short intro video when our game starts up - so might as well share
 * it.
 *
 * Known bugs:
 *
 * - Only very crude synching. Audio is slightly delayed and some
 *   videos seem to constantly drift off and then the audio gets all
 *   distorted...
 *
 * - Seeking/Pausing doesn't really work.
 *
 * - Memory leaks. Easy to fix but don't have time right now.

https://github.com/liballeg/allegro5/blob/master/addons/video/video.c