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 ... 623
31
SFML projects / Re: Gravity in the 2D-Universum
« on: November 19, 2019, 09:22:10 pm »
I will check this. The game must ended ever when all targetcircels arrived. The bonuscircles are not necessary. Can you tell me the levelnumber, please.
It's certainly the case in level 7, which is a bit annoying as I already completed it, but then failed to get the bonus stuff.  ;D

It was also the case once in a previous level, but I forgot which one.

Btw. is there a logic to when the bonus points get destroyed?
Like sometimes when you pick up one bonus point, the other one will get destroyed. Or if you "collect" the first circle, some bonus point gets destroyed.

32
SFML projects / Re: Gravity in the 2D-Universum
« on: November 19, 2019, 06:25:06 pm »
I quite enjoyed playing this, even if it can be a bit slow given the de-/acceleration.

There are a few issues I noticed:

  • In some levels the game doesn't end unless you also collected the bonus points. As they are just bonus points, the game should IMHO end when you reach the last circle.
  • The ESC key for exiting the game doesn't work when you're in a menu. You should always be able to quit the game.
  • The text input doesn't seem to be using sf::Event::TextEntered but probably some text input detection based on keyboard events or real-time input. For text input always use sf::Event::TextEntered
  • When entering your name, the mouse cursor is positioned to the next character place. The mouse should not be programmatically moved.
  • The input dialog lists some commands for 0+I, 1+I and 2+I. I have no idea what kind of input that is. Pressing the button 0 and the button I did nothing.
  • When I retry a level, I don't necessarily want to keep closing the help dialog every time.

Either way, very much enjoyed the game and might try to beat the one I got stuck on at a later point. :)

33
Graphics / Re: Sprites and problems with a onboardgrafic ..
« on: November 19, 2019, 06:17:16 pm »
Seems to work fine on my AMD GPU card. :)

34
Graphics / Re: Sprites and problems with a onboardgrafic ..
« on: November 19, 2019, 01:33:29 pm »
I think you're comparing apples and oranges here.

Your full game with the installer and everything is what most people are trying, I tried the RAR file you provided here, which is just some stripped down demo.
As soon as I move my mouse this demo shuts down.

35
General / Re: setting SFML on Clion
« on: November 18, 2019, 04:49:02 pm »
Since you're using GCC 6.3.0 did you build SFML yourself?

See also the red box on the download page: https://www.sfml-dev.org/download/sfml/2.5.1/

Also please use [code=cpp][/code] tags when posting code or  [code][/code] for logs.

36
General discussions / Re: Did I say thank you, yet?
« on: November 17, 2019, 08:05:02 pm »
Glad to hear that SFML has been a tremendous help and enjoyment. :)

37
General / Re: Space Invaders - Enemy Movement Logic
« on: November 17, 2019, 08:04:08 pm »
Is there a question to this thread or are you simply showing your progress so far?

38
General / Re: Font finding problem
« on: November 17, 2019, 07:54:10 pm »
It's always recommended to provide your solution, so if ever someone else has a similar issue, they can at least try to understand/apply yours.

39
Graphics / Re: Help with sf::View and Origin
« on: November 17, 2019, 07:52:51 pm »
view.setCenter(sprite.getOrigin()) is certainly wrong, as the origin is in local coordinates while the view center is in world coordinates.

With such problems it's always a good idea to print various values (position, origin, etc) and compare them to the expected values (potentially calculated by hand).
If you notice the difference in values, you can the set break points and step through your code step by step, while constantly checking values. That way you should be able to find the "bad" logic.

40
General / Re: setting SFML on Clion
« on: November 17, 2019, 07:46:57 pm »
Your order of SFML modules is wrong, should be listed as X depends on Y, thus X comes before Y.

Also this uses old CMake and won't necessarily work with SFML 2.5. See this thread: https://en.sfml-dev.org/forums/index.php?topic=24070.0

I recommend you spend some more time on learning CMake and understanding how the linker works.

(I removed your duplicate topic)
(Cross post: https://stackoverflow.com/questions/58902447/setting-sfml-on-clion)

41
Maybe you're using an older version of SFML or you didn't update your header files?

Also is that really the code you're using, or does your code actually look different?

42
Graphics / Re: Thread separation
« on: November 13, 2019, 12:18:32 pm »
It seems that there is a global shared context, that threads can use and access the state without the need of switching. All you need is an active SFML context on each thread. Please let me know if this is incorrect. I plan proper measures that guarantee no opengl location is written by two threads at the same time.
As far as my understanding goes from past conversations this is mostly a correct assessment. My point was mainly with regards to the SFML context per thread. You will have to handle the activation of said context in each thread yourself and AFAIK this still causes context switches.

My personal recommendation still remains that it's okay to do CPU-bound work with multiple threads (or potentially std::async or some task pool implementation), while keeping all OpenGL operations in one thread, given that the OpenGL commands will be added into a single queue anyways.

For example, if you want to load an image from disk in the background without blocking the application, you'd do the whole disk access and image decompression with sf::Image, so you end up with the pixel information in memory and do the slow disk operations in a separate thread, but then on the main thread, you create an sf::Texture from the image, which will load the data into the VRAM, this operation isn't the fastest, but should in most cases not cause any performance issues.

Or another example, if you're trying to render a fractal, you can split the calculation of the image data into multiple threads and serve the final image (or chunks of it) to the main thread to be rendered. (Then again that would probably best done in a shader anyways).

43
General / Re: OpenGl Tutorial Compile Issues
« on: November 13, 2019, 10:02:33 am »
As mentioned it's most likely just gl that you need to link, but since Linux is such a diverse ecosystem, it's impossible to define specific library names and it's assumed that people using their flavor of Linux distro will know what needs to be used.

44
Graphics / Re: Thread separation
« on: November 13, 2019, 01:01:34 am »
The general advice that you'll also find in similar topics is: don't do it.

It might seem like a great idea when you have little insight on multi-thread programming and how OpenGL works, but once you do realize that running in multiple threads requires you to sync shared objects (e.g. a shape: updating position vs drawing), thus requiring some sort of lock/mutex, thus making the logic and rendering thread pretty much synchronous again, you'll start to understand that this approach won't give you any gains, instead it will add a lot more complexity and overhead, most likely making your application slower.
Additionally, OpenGL is not multi-thread capable, so you'll have to switch context a lot and then OpenGL calls will be queued on one thread anyways, again making this whole setup cost more than it actually helps.

There are enough similar posts on the forum if you search a bit, you'll find more detailed answers as well.

Finally, SFML does not guarantee anything with regards to multiple threads, i.e. SFML is neither thread-safe, nor does it handle OpenGL context activation with multiple threads for you.

45
Graphics / Re: Sprites and problems with a onboardgrafic ..
« on: November 13, 2019, 12:54:21 am »
I'm pretty sure you have some bugs in your code there.
The game instantly closes when you move the mouse or input anything, which sounds to me like you're not implementing a proper event loop, or rather than you're reusing event instances even though they're not valid anymore.

At least it renders stuff for me.

Without code, it's near impossible to say what's going on, but I'm pretty sure it's something in your code.

Pages: 1 2 [3] 4 5 ... 623
anything