Messages

286

Graphics / Re: Access violation reading location while drawing sprites

« on: April 27, 2021, 03:58:22 pm »

Sandbag has a window member. But init takes a window argument, then does:
window = window;
The window argument is "shadowing" the window member, meaning the member one is hidden due to duplicate name. So window = window is assigning the argument to itself, the member version isn't changed, meaning when it gets to the paint function the window member is invalid and crashes.
https://www.learncpp.com/cpp-tutorial/variable-shadowing-name-hiding/

Change either the member name or argument name and it should work.

287

Window / Re: XboxOne GamePad Triggers

« on: April 25, 2021, 07:59:19 pm »

I haven't tried it myself, but there's https://github.com/speps/XInputDotNet
It says it lets any .Net app access xinput.

Looking at their demo source, it would be used like:

GamePadState state = GamePad.GetState(PlayerIndex.One);

Then look in state.Triggers.Left and state.Triggers.Right for the trigger values.

288

Window / Re: XboxOne GamePad Triggers

« on: April 25, 2021, 07:16:06 pm »

This was an intentional design decision by Microsoft when they made the Direct Input drivers for xbox controllers. I've seen them say that it is because it makes it easier to do car games with accelerator/brake on the two triggers. Any direct input based input lbirary (like sfml) will have this issue.

The way to bypass it is to use XInput instead. It exposes all features of the xbox controller as well as keeping the triggers separate. Luckily it's also very easy to use.
There's no setup or initialisation. include the xinput.h header, link with the xinput library, then every update in the game do:

XINPUT_STATE state;
DWORD result = XInputGetState(0, &state);

(The 0 is the index (0-3) of the controller you want)
The triggers can then be read using state.GamePad.bLeftTrigger and state.GamePad.bRightTrigger (values 0-255).
Using vibration is just as easy. (make state variable, set 2 motor values, call set state)

289

Window / Re: Mouse::getPosition(window) always returns 0

« on: April 25, 2021, 05:18:36 am »

Your for loop isn't making item a reference, so you are changing the radius of a temporary CircleShape, not the ones in the list.
If the circles start with a 0 radius, then when the code does the setRadius(50) to make them big, that's done to the temporary, so next pass they are all back to 0.

Try this:

for (CircleShape& item : list) {

290

General / Re: Erasing An Enemy From Enemy Class

« on: April 23, 2021, 07:39:07 pm »

How is touch being set on enemies? It's defaulting to false but isn't used again in the code above except to select which ones to remove. It looks like one enemy isn't having touch set to true, so it won't be removed.

291

General / Re: Erasing An Enemy From Enemy Class

« on: April 23, 2021, 07:52:14 am »

I haven't used std::remove_if before, but based on the docs you shouldn't need the erase part.
std::remove_if does the erase internally, then typically returns the end() iterator. That means the erase is going to be trying to erase starting at the end() (which isn't a valid element), so the last element will have trouble.
Try this instead (same code but with erase taken out):

std::remove_if(enemies1.begin(), enemies1.end(), [](const auto &itr) {return itr->touch; });

292

Audio / Re: [SOLVED] No sound is played but in debug mode is played

« on: April 23, 2021, 12:28:26 am »

Yes, your point makes sense but for now the sounds in my game will not be a big number and I think the vector will not rearrange addresses.

Actually the fewer items in the vector the more often it rearranges memory.
In visual studio pushing 10 items into a vector will rearrange the entire vector's memory 6 times (it rearranges all items after pushes 2, 3, 4, 5, 7, 10). GCC has a slightly different pattern, but same idea.
You can call reserve() on the vector to give it a bigger capacity before it rearranges again, but that's just delaying potential trouble.
Or use a vector of sound buffer pointers instead of sound buffers and allocate them explicitly, then reallocating the vector is harmless since the buffers themselves are fixed on the heap.

293

Graphics / Re: problem with drawing multiple objects

« on: April 22, 2021, 01:21:41 am »

References and pointers are one of the harder parts of common C++ to get used to, especially for people who have used languages like C# that hide them. (All classes are references in C# already)

294

General / Re: Weirdly slow event loop

« on: April 21, 2021, 12:50:48 pm »

Are you doing anything to limit frame rate?  (like vsync or the window's setFramerateLimit)
The player is moving at 1 pixel per frame with no delta time use, which is pretty slow at 60Hz (depends on your sprite size and world scale I guess).
I'm guessing it's not frame rate limited, so the actual rate is going to vary a fair bit depending on your system's activity, resulting in the player moving at different speeds.

295

General / Re: Sprite rotated hit box broken

« on: April 17, 2021, 07:17:53 pm »

You might want to check this out: https://en.sfml-dev.org/forums/index.php?topic=22241.0
Sounds like it does what you want.

296

General / Re: Sprite rotated hit box broken

« on: April 17, 2021, 04:20:49 am »

SFML uses Axis Aligned Bounding Boxes for the global bounds. This means they can't rotate, instead they will grow and shrink as needed to fit the rotated sprite. This is good for rendering, but not for game collisions.

You'll either need to write your own Oriented Bounding Box intersect test (such as Separating Axis Theorem) or use a library like Box2D (2D physics).

297

General / Re: Problem using delta time

« on: April 17, 2021, 04:06:37 am »

Your deltaTime() function is making a new clock every time you call it. The clock starts at zero.
You need to make one clock and keep using it. Either move the clock outside of the function or place the "static" keyword before the clock in the function. (Static on a variable in a function makes it continue to live after the function ends and reuses it next time without recreating it).

298

Graphics / Re: Achiving some sort of projection texture mapping

« on: April 14, 2021, 11:05:17 am »

Well, sure, if you want to do it the easy and sensible way...

299

General / Re: How can I not put the .dll files and the .exe file in the same directory??

« on: April 14, 2021, 11:03:29 am »

The easiest way would be to use a static build of sfml. But you explicitly said the dynamic build so I guess that's not an option.

Otherwise it's tricky to change DLL search.
DLLs are either load time linked (happens automatically on program start, such as with sfml's libs) or run time linked (you have to manually load each library and search for functions inside of it one by one)
Run time linked dlls are specified with a file path, so you can load them from anywhere.
Load time linked dlls have fixed locations that are searched (the system path, the working directory, the directory of the exe, etc).

The path used can be changed using SetDllDirectory, but your main function happens after load time linking.
I think setting your app to delayload the dlls (it's an option in the project's linker settings, it makes dlls not get loaded until the first time a function in them is called) might work with SetDllDirectory, but sfml's graphics library is incompatible with delayload (just tested, something with Color upset the linker), so that doesn't work.

300

Graphics / Re: Achiving some sort of projection texture mapping

« on: April 14, 2021, 03:39:35 am »

One way would be messing with UV coordinates each frame.

Or you can use a shader. Here's a quick test hack I just made:
Vertex shader:

void main()
{
    // transform the vertex position
    gl_Position = gl_ModelViewProjectionMatrix * gl_Vertex;

    // transform the texture coordinates
    gl_TexCoord[0] = gl_Vertex/64;

    // forward the vertex color
    gl_FrontColor = gl_Color;
}

Fragment shader:

sampler2D texture;
void main()
{
    // lookup the pixel in the texture
    vec4 c = texture2D(texture, gl_TexCoord[0].xy);
    gl_FragColor = c;
}
 

Applied to a sprite, that made the sprite's texture (which was set to repeat) stay in place as the sprite moved.
The 64 in the vertex shader was the resolution of the sprite's texture.