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

Pages: [1] 2 3 ... 16
Graphics / Re: Using sf::Text and sf::Font in Windows ×64 MinGW
« on: June 01, 2023, 03:25:58 am »
Space can be a factor too.
When a static library is linked, the linker can see which parts are being used, so it only merges those into your final executable.
When a dynamic library is linked, the linker doesn't know who will load it at runtime, so it must include everything.
This means a static link results in a slightly bigger executable than dynamic, but no dlls with unneeded stuff, so overall static will be smaller.

On the other hand, if you have several executables in your project (maybe a game, an editor, a config program, etc) that all use the same library, static linking means every one of them has to include the parts they need, while dynamic linking lets them all share the same dll. So dynamic might have a saving there.

Window / Re: Vsync enforced before draw methods instead of display
« on: May 31, 2023, 07:08:08 am »
There's a stack overflow answer to this (not sfml related, but same cause) here: https://stackoverflow.com/a/24136893

Basically the display call uses SwapBuffers (I'm talking about on Windows). This may not block, it returns immediately, queuing the swap to actually happen at the right time (vsync) in the background. Any rendering operation then executed after the swap but before the swap has internally completed will block.
So your 16ms clear calls are actually waiting for the previous swapbuffers to finish.

I guess the quick hack would be to do something simple immediately after the display to force it to block then. Maybe move the clear call to there.

Window / Re: window.draw() and window.display are slow
« on: May 22, 2023, 07:19:25 pm »
At a guess, the segfault might be because your event loop closes the window (on escape or close button), but then does a clear, draw and display of the window (which is already closed).

Audio / Re: multiple concurrent sound effects
« on: May 17, 2023, 10:39:17 am »
Also, if you are using the same audio file in each one, you only need a single SoundBuffer. You can have many Sound objects all sharing a single SoundBuffer (that you can load at the beginning so it doesn't cause a delay during the game).
So if your game has 2 different sound effects to play, you only need 2 SoundBuffers, then as many Sounds as you'd like.

The way my sound manager used to work was I had a vector of Sound pointers. For each sound I played I'd push a new sound object into the vector (pointers aren't hurt by the vector reallocating as it grows). Every update I'd loop over the sound vector and check to see if each sound had finished playing. If they had finished, I'd delete them and remove them from the vector.

These days I do it similar, but using the Entt entity component system to store the sounds.
(That's getting a bit complicated if you aren't used to ECS style programming)

Pull Requests & Testing / Re: Scancodes Round 3 & Release Readiness
« on: May 17, 2023, 12:39:53 am »
I couldn't get printscreen to work in the app. It couldn't manually map it, it thought no key was being pressed.
But looking online I see that windows intentionally doesn't send keydown events for Printscreen, it only sends keyup. I tested in my own SFML 3.0 app and I do get the correct scancode for printscreen on keyup.
Is this a thing? Maybe I'll change it slightly to reflect keys that have been released as well.
I had searched around a bit, there are posts on places like stack overflow going back 12 years saying key down isn't sent by the printscreen key because Windows captures it, you need to use an input hook to intercept it. I also found a unity forum post about the same thing, Unity's input can't see printscreen key down.
I couldn't find any official info on it from microsoft.
Although this page from MS says Keyboard LANG1 and Keyboard LANG2 (scan codes 0x72 and 0x71) don't send key down events, only key up: https://learn.microsoft.com/en-us/windows/win32/inputdev/about-keyboard-input

Pull Requests & Testing / Re: Scancodes Round 3 & Release Readiness
« on: May 16, 2023, 02:19:55 pm »
Right alt is 133 for me. Do you have any keyboard software in the background?

I thought the menu key wasn't working, but it turned out by default my wooting software had mapped the menu key to function layer 1.

Pull Requests & Testing / Re: Scancodes Round 3 & Release Readiness
« on: May 16, 2023, 05:49:50 am »
(Testing on windows 10 with a Wooting Lekker keyboard)

In the test app above, using the default auto mapping the R Sys key is mapped to the Menu key instead of RSystem. Both menu and rsystem do work correctly if manually mapped though.

I couldn't get printscreen to work in the app. It couldn't manually map it, it thought no key was being pressed.
But looking online I see that windows intentionally doesn't send keydown events for Printscreen, it only sends keyup. I tested in my own SFML 3.0 app and I do get the correct scancode for printscreen on keyup.

What's odd is the screenshots show several different offsets. The background is offset vertically. The text is offset horizontally and the box around the text is offset diagonally.

Something to try, go to where you are rendering and just before check the values of the view to see if its changed. Something like this:
                sf::View view = g_window.getView();
                sf::Vector2f center = view.getCenter();
                sf::Vector2f size = view.getSize();
                std::cout << center.x << " " << center.y << std::endl;
                std::cout << size.x << " " << size.y << std::endl;
It should give 960 540 and 1920 1080.
(If you don't have a console window to cout to, write it to a file or use some onscreen debug text, etc)

As MrMisteron said, without seeing the whole engine it is hard to tell if something else in there is affecting it.

The code posted looks like its in a function that takes a name and a scene, but with the start cut off. Is all of the game in that function?
The reason I ask is you are making a local variable render window, then getting its address to put in the window variable. But at the end of that function the render window will stop existing, and window will point to left over memory that might get corrupted.

Otherwise the view should be correct (I just did a test, it works as expected). Maybe something else is messing with views (the scene class might have a render method that resets the view?).

General / Re: Exe File Different From What I Compile
« on: April 28, 2023, 07:39:48 am »
One of the common causes for this is the working directory.
When you run a program from explorer, the working directory is set to the same directory as where the exe is.
When you run a program from visual studio, the default is to set the working directory to where the .vcxproj file is (which is rarely the same place as the exe).

How this affects the program running is all file access that doesn't have absolute paths will be relative to the working directory.
Let's say I have a project set up (with my sfml based engine Kage) with the exe file going into f:\work\kage\bin and the vcxproj is in f:\work\kage\projects\example
Now if my code asks sfml to load a sprite like data\cat.png then it looks for the file:
Running from explorer: f:\work\kage\bin\data\cat.png
Running from VS: f:\work\kage\projects\example\data\cat.png

The easiest fix is to go into the project properties and find Debugging / Working Directory. Change the value from $(ProjectDir) to $(TargetDir).
You'll probably need to move your assets or change your paths in the code as well.

Window / Re: Not clearing window
« on: March 25, 2023, 04:04:22 am »
The display is double buffered.
This means there are two buffers for your rendering: the front buffer and the back buffer. The front buffer is what is shown on the monitor. The back buffer is where drawing happens.
When the program calls the window's display() function, the two buffers are swapped.

If the window isn't cleared each frame, you have to make sure every pixel of the window is overwritten by something. For example drawing a full window background sprite, or a tile map, etc. What you are drawing on top of isn't the last frame rendered, but the second last frame, since the last frame is in the other buffer.
If pixels aren't overwritten, you'll get flickering anywhere the two buffers don't have the same pixels.

General / Re: Whats wrong with my collision detection?
« on: March 25, 2023, 03:04:15 am »
Let's look at the D key case:
        if (sf::Keyboard::isKeyPressed(sf::Keyboard::D))
            if (playerRight >= squareLeft)
                player->move(5, 0);
The logic here is checking if the playerRight is to the right of the squareLeft. That could mean the player is to the left of the square but overlapping it, or the player is entirely to the right of the square and not overlapping. You don't want to move right if the player is to the left and overlapping.
Also there's no Y axis check in that one. It only considers the X positions, it doesn't check if they overlap on the Y.

To do a full overlap test you can do something like this:
bool overlap = (playerLeft <= squareRight) &&
               (playerRight >= squareLeft) &&
               (playerTop <= squareBottom) &&
               (playerBottom >= squareTop);
That will tell if the player and square are currently definitely overlapping.
Although what you really want is to tell if they are going to overlap after a move, not if they currently overlap.

So you could find the desired movement first (don't do the move, just work out what it would be based on the keys), calculate the left, right, top, bottom if the move happened, check if that was an overlap, and don't do the move if overlap is true.

The other way would be to do the move regardless, then correct it afterwards (push the player out of the square). That will make them sit flush a bit better, but it's trickier to implement.

Generally I prefer to just use Box2D and let it deal with everything. :)

General / Re: Failed to load image
« on: March 09, 2023, 08:41:29 am »
The most likely cause is that the path to the image doesn't fit with the working directory.
One annoyance with Visual Studio is that by default it sets the working directory to $(ProjectDir). This means any relative file access will be relative to where your project file is, not where the exe was built.
You can change that in the project properties, under Debugging / Working Directory. I set it to $(TargetDir), which is where the exe goes.

So the things to check:
- where is the exe being placed?
- where is the image you are trying to load?
- what string did you give SFML as the path to the image?

(This setting only has an effect when running from inside of Visual Studio. If you run the exe from explorer, the working directory is set to where the exe is)

C / Re: How sfClock_getElapsedTime() works ?
« on: March 09, 2023, 02:48:17 am »
I built CSFML myself (VS2022) and tried several of the code samples you gave. Everything worked. I left the not working two clock one run for an hour and it was consistently giving around 200 microseconds (mostly from printing to the console).

I see from the error message that you are using the Borland or Embarcadero 32 bit compiler. I wonder if that is part of the issue? SFML on windows uses QueryPerformanceCounter and does some 64 bit maths with it, maybe there's a problem there with bcc32?

C / Re: How sfClock_getElapsedTime() works ?
« on: March 08, 2023, 10:16:42 am »
The SFML and CSFML clocks works on integer microsecond precision (I don't know where that might be documented, I'm just digging through the source code). So for your first bit of code reading the elapsed time is too close to resetting the clock, it would have been quicker than 1 microsecond.

In the next part, the C language doesn't have operator overloading, so it's not possible to subtract sfTimes from each other, you need to get the numeric value out of the sfTime (using sfTime_asMicroseconds as you did further down).

The last one looks like the same as the first one, reading elapsed time less than a microsecond after making the clock.

Pages: [1] 2 3 ... 16