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 ... 719
1
No, SFML doesn't offer such a functionality, but there are various libraries that have implemented this in some way or another.

https://github.com/mlabbe/nativefiledialog
https://sourceforge.net/projects/tinyfiledialogs/

2
Graphics / Re: hello. a question about setTextureRect
« on: March 28, 2024, 07:20:52 am »
There's no support for GL_CLAMP_TO_BORDER indeed.

I recommend to not stick to texture size and draw a border of your own.

3
General / Re: Load Font
« on: March 28, 2024, 07:15:10 am »
Make sure, you're actually linking debug libraries in debug mode (the ones with the -d) suffix.

4
No, they're axis aligned.

If you want to get the rotated points, you can get the local bounds and apply the transformation as you've shown on each point of the sf::Rect. Which still provides a better guarantee than deciding on a specific order of the index.

5
I guess you can check the source code, but the order is not part of the API and instead is an implementation detail.

If you want to know the specific points, you're better off with getPosition() and getPosition() + getSize().

6
General / Re: Final answer for async loading texture ?
« on: March 27, 2024, 08:16:09 am »
Yes, OpenGL didn't change. ;D

The recommended way is to load the image data with sf::Image or similar from disk in a separate thread, which is one of the slowest parts, as you do IO and decompression, and then move the image data to a texture in the main thread.
This should speed up things noticeably.

And of course making sure you generally use texture atlases withe texture rect on a sprite, instead of loading many small textures. This will prevent you from having to load and handle many textures and will reduce texture switches, that are a bit expensive.

7
Audio / Re: Help with running the package
« on: March 27, 2024, 07:41:26 am »
Make sure you're installing the frameworks that SFML ships with, check the getting started tutorial for macOS.

By the way, g++ on macOS will just point to AppleClang, so you might as well use clang to make it clear what compiler you're using. ;)

8
General / Re: How to share assets between the scenes?
« on: March 25, 2024, 11:15:44 am »
Personally, I always recommend using something like a ResourceHolder, that ensure proper life-time of the resources, while ensure that you can easily share it, without having to reload anything.

When sharing between classes make sure you know who the owner is.
From the owner you can then provide access to the resource by passing it as references somewhere else, but you always need to make sure that the life-time is handled correctly.

9
Feature requests / Re: export vertexes from the Shape class
« on: March 25, 2024, 11:01:06 am »
What you're essentially asking for is sprite/shape batching.

I believe it's a feature we will implement eventually, but it requires some underlying changes and API decisions that aren't trivial to solve it in a generic way.

Your best option is probably to build your own class around a vertex array and create your own batching.
But make sure you're actually experiencing performance impacts. Premature optimization is the root of all evil, etc ;)

10
General / Re: Can I use module feature als substitute for header file?
« on: March 21, 2024, 10:18:16 pm »
Hi and welcome! :)

No, SFML 2 is on C++03 and SFML 3 which is still work-in-progress will be C++17 and thus won't support modules.

11
Not sure what "SFML with Installer Project" is, but it sounds like you end up using different DLLs, which can cause odd problems.

Make sure the necessary DLLs are next to your executable that you try to run.

12
General discussions / Re: Can vlc work on SFML window?
« on: March 16, 2024, 10:33:52 am »
I've no idea how VLC can be integrated into other applications.

Have you followed the Getting Started section: https://sfemovie.yalir.org/latest/start.php

13
General / Re: Methodologies on storing/controlling game data
« on: March 12, 2024, 01:16:35 pm »
There's no right or wrong, especially in gamedev. Some sayings even go as far as "There are well written games and there are released games" ;D

As programmers we're drawn to "solving" problems, thus being able to create nice systems that handle game data in an efficient way, seems like a great solution, but this work needs to be balanced against actually creating the game itself.

My personal take on this is that unless something is hindering you on creating the game, I would just continue with the most straightforward way for you.
This not only prevents you from falling into the "engineering" trap, but it will also help you to solve problems that matter, instead of creating things that you think you need, only to realize later that the underlying problem, was actually something totally different.

The reason Lua and JSON are common options to for scripting or storing data, is that they are "simple" formats, have a wide range of available libraries, lots of people know how to work with it.
I'm sure you can use Python for your scripting as well, if you can find a library to help with that.
For file formats, I recommend to use a well-known format, be it JSON, YAML, TOML, etc. as it makes it easier to work with, e.g. if you want to use another application to read it. There are also great libraries out there to parse it and work with it, so you don't have to write a whole parser.

For storage you can also consider using SQLite, which allows you to not only store data, but also define relations, e.g. what weapons are available for which level upgrade while retaining a complete list of the weapons.

Or in the end you can just create a few more lists with the necessary information. Or dynamically filter the wanted weapons from the primary list into a smaller list to display.

14
Graphics / Re: Optimization of hexagon-grid
« on: March 11, 2024, 08:55:30 am »
There are multiple ways you can improve the code.

One simple step would be to not recalculate the shape for every hexagon and each frame.
Assuming the hexagon don't change in size, you'd could calculate the shape points once and then just calculate the necessary translation (movement) to the next position.

You could also store a copy of the ConvexShape in a vector or other container.

And lastly, you could use a VertexArray to handle the vertex data instead of many ConvexShapes, which would cut down on the draw calls overall.

You can find out what best to tackle by using a profiler to see where your bottlenecks are.

15
In a strict sense, math doesn't know the difference between a point and a vector.
A "point" in your definition is just a vector from the origin (0, 0).

I personally don't see the advantage of differentiating between the two, beyond having a "simpler" mental modal at times.
I'd even claim that with more advanced math scenarios, the difference will actually get in the way and you'd have to either use vectors for everything or keep converting between the two a lot.

Pages: [1] 2 3 ... 719