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

Pages: 1 2 3 [4] 5 6 ... 638
Graphics / Re: Is it possible to reduce the size of a VertexBuffer?
« on: June 16, 2020, 08:37:54 am »
You'll have to call create on the VertexBuffer with a different size.
See also the example in the documentation: https://www.sfml-dev.org/documentation/2.5.1/classsf_1_1VertexBuffer.php#details

Graphics / Re: Undefined References
« on: June 16, 2020, 08:35:07 am »
What's your linker command look like?

If you can use a recording device as an input, then it's probably best to write your own recorder class, where you can access to the samples as they come in: https://www.sfml-dev.org/tutorials/2.5/audio-recording.php#custom-recording

You can use the setProcessingInterval (default 100ms) to get a lower latency, but you also need to keep in mind that the OS/OpenAL has limitations, so just setting it 0ms doesn't mean, that you're application will now have no latency whatsoever. ;)

Graphics / Re: The right approach to movement and time.
« on: June 15, 2020, 11:36:53 am »
There are different ways to achieve the goal of framerate independent movement.

The simplest and for a lot of cases sufficient approach for me is multiplying the delta-time with your movement calculation (your second approach).
In order to figure out the right units, you go back physics calculations: s = v * dt
And then replace the meter units with pixels or similar and you get [px] = [px/s] *

So something like this should do:
auto frame_time = clock.restart();
// ...
entity.move(velocity * frame_time.asSeconds());

Personally, I also recommend to use a normalized direction vector, that way you get the diagonal movement speed correct and can basically pick whatever direction you want.

entity.move(normalize(direction_vector) * velocity * frame_time.asSeconds());

Also once write a normalize function, not sure how efficent and precise it is, but it covers some edge cases.
(click to show/hide)

Now for more advanced games and certain micro stutter prevention, you'd use a fixed time step and do interpolation calculations.

Graphics / Re: Trying not to draw all RenderTextures at every frame
« on: June 14, 2020, 07:33:26 am »
Can you provide a minimal example without pseudo code?

General discussions / Re: Better keyboard handling
« on: June 12, 2020, 12:27:59 am »
I have added some questions regarding scancode key names to the PR.
Please have a look and provide feedback :)


General / Re: Cmake error on RPI
« on: June 11, 2020, 12:04:56 am »
You'll have to install X11 to compile it. There are currently efforts being made to provide alternatives, especially regarding RPI: https://en.sfml-dev.org/forums/index.php?topic=27102.0

General / Re: Failed to create input context for window
« on: June 08, 2020, 10:01:17 pm »
Ah, I forgot that you said you're using Conan :)

Given the stack trace, that would mean, that it isn't really crashing in regards to anything X11, but something in sf::String...

Can you try the following program:

#include <SFML/System.hpp>

int main()
    sf::String myString("Hello World");

If that still fails, then I question the Conan recipe or the binaries downloaded. A crash in std::basic_string is often an indication of a runtime version mismatch...

General / Re: Failed to create input context for window
« on: June 08, 2020, 09:13:26 pm »
Run it through a debugger (e.g. gdb) and when it crashes, retrieve the stack trace (e.g. in gdb with bt).

But if you use Ubuntu 18.04 and the SFML version provided by the package manager, you're actually using SFML 2.4.2, so maybe the typo was with the 5 and not with the 2. ;D

General / Re: Failed to create input context for window
« on: June 08, 2020, 08:56:38 pm »
Any reason you're not linking to the official SFML repository?
Also SFML 2.5.2 is not a thing, do you mean SFML 2.5.1 or do you have a modified copy of SFML?

What's the stack trace for the crash?

General / Re: Failed to create input context for window
« on: June 08, 2020, 08:36:45 pm »
An error message isn't equal to a crash. Do you get an actual crash or just the error shown?

Since you're building in debug mode, did you also link the SFML debug libraries (-d suffix)?

What a lot of video creators and video consumers don't seem to grasp, is that in order to learn something, you actually have to understand it. So I think you're on the right path to notice, that typing someone else's code or copy pasting it from somewhere, isn't very effective in learning its meaning.
I can second Paul's suggestion of trying to build clones of classic games such as Pong, Tic Tac Toe, Tetris, etc. while going through the official tutorials.
And again, don't just copy the code and try to move pieces around until it maybe works, but actually understand what the parameters mean and why you need to create a window and what events do and how to apply the clear(), draw(), display() steps, etc.
If you're new to C++ as well, it will be a bit harder to understand these concepts, that's why we usually suggest to learn the basics of C++ without SFML.

After you've understood the basics of SFML, I can recommend the SFML Game Development book, which will give you some more tips on how to structure a game, among other things.

If the loadFromFile function doesn't return true, then SFML will output something to sf::err() which by default is redirected to std::cerr, so what does the console say why it failed?

What's your working directory and where have you placed the assets?

Window / Re: Hitching and Crashing with multiple sf::Window handles
« on: June 07, 2020, 11:43:57 pm »
You should really be focusing on one thing at a time.

If pollEvent() "hangs" for a long time, it has nothing to do with OpenGL and setActive, because non of that is involved in pollEvent(). What's more likely the cause is some faulty input device driver.
Check that you have the official drivers installed for your input devices and that you're not using any weird gamepads/joysticks that identify themselves oddly.
Measuring and breaking after it happens is fine to detect that issue, but if you really want to figure out what's going on, you should use a profiler. It's still tricky to capture it, but it may give you an insight where it spends a lot of time.

As for your multiple sf::Window handles. What do you mean with multiple sf::Window handles? What's a handle for you?
Don't forget that you can process events only in the thread that created the window.
Also remember that writing multi-threaded code introduces a lot of complexity and with it a lot of hard to understand and hard to debug problems. Don't do it unless you have a good reason and enough experience.

Pages: 1 2 3 [4] 5 6 ... 638