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

Pages: [1] 2
General discussions / Re: PhysicsFS vs an SFML virtual filesystem
« on: January 18, 2019, 09:02:22 pm »
Thanks eXpl0it3r, it was definitely way off-topic. There's a typo in the title though  ;)

FRex, I would argue that SFML is in many ways an abstraction over several other C libraries, providing a cohesive interface into their disparate functions in a way that enables them to easily work together. I don't see the issue with even considering adding PhysicsFS, or a virtual filesystem more generally, to the collection of functionalities that SFML abstracts.

And I hadn't thought of reading different formats with endianness expectations. I was mainly considering serialization for your own data. In this use case, you only ever want or need to read and write one endianness, regardless of the endianness of the native system. So for serializing your own data, it's a huge benefit to set that in one place and have it automated for all reads and writes. Most other data formats you're reading and writing are already handled by SFML already, so I would suggest there's fairly limited utility in broader endian support. A VirtualFile class could easily pass a real filesystem path to SFML's reading/writing utilities in order to handle those resources. Or they could be integrated in the VirtualFile class so you don't need to pass them from one class to another yourself. Such as:
auto file = filesystem.GetFile("file/path/here.ext");
sf::Texture texture = file.ReadTexture();

However, in the case of reading disparate formats that have endianness requirements, I agree that it would have to handle endianness on a file by file basis. In this case, I would suggest using functions in the VirtualFilesystem class, such as OpenFile (for native endianness), OpenFileBig, and OpenFileLittle.
I still think this would be a big improvement over PhysicsFS's functions.

And a virtual filesystem is really a very simple piece of code to write. I've written my own before because I didn't want to deal with PhysicsFS's particulars, and it's about as much work to wrap (usefully, not just a thin wrapper) it as it is to just write your own. So it would be relatively easy for SFML to provide one that's better integrated with other SFML components.

And just to take a moment to address some of the more personal attacks:
It might be helpful to reread what I've actually said, and notice that much of what you accuse me of did not come from what I wrote, but rather what you've inferred far beyond my own words.
For instance, I never said sf::Vector2 was being removed, I said that it's not out of the question to replace SFML types and utilities that are better handled with standards-based analogues, and pointed out that there has been discussion and agreement towards this end with other pieces of SFML.
There are other examples of words being put in my mouth in this way, but I really think it's beside the point of this discussion to go further into that.

General discussions / Re: PhysicsFS vs an SFML virutal filesystem
« on: January 18, 2019, 01:08:28 am »
Come on, it's not OO, it's normal procedural C functions like any other.
Filesystem is just what I called my imaginary virtual filesystem in a proper C++ implementation. In PhysicsFS terms, this would be the "search path" where all chosen real filesystem paths are searched when you try to access a file.

As for what to do when a function fails, I'd say you should throw an exception: if a file is missing a value you expect it's surely corrupt and you'll have to deal with that. Or as you said yourself you could easily return an int bool pair, or you could return an optional. Plenty of ways to deal with erroneous calls.
The nice thing about this is that if the programmer screws something up, or does something silly like:
int = file.ReadUInt64()
they'll get a warning or an error, letting them know very quickly that they need to fix it.

You'd set the endianness for the filesystem because as the developer you know what endianness your data files are. So when the filesystem opens a file for reading, it can automatically convert from that to native, or vice versa for writing.
For example:
VirtualFilesystem<VFS_BIG_ENDIAN> filesystem();
auto file = filesystem.GetFile("filename.ext");
auto num = file.ReadUInt16();
I would suggest that the VirtualFile class be templated using the filesystem template, and appropriate conversion functions used based on the template. This makes all handling of endianness automatic from the perspective of the programmer using this API. Or, for someone who's reading files native to the computer, they might use VFS_NATIVE_ENDIAN or something of the sort to avoid any conversion.

As far as duplicated functionality between SFML and standards, that's all been well-discussed here and in related topics: https://en.sfml-dev.org/forums/index.php?topic=21571.0

General discussions / Re: PhysicsFS vs an SFML virutal filesystem
« on: January 18, 2019, 12:05:06 am »
I'm really not trolling, I am just saying that PhysicsFS is a C library with all the differences in implementation there are between C libraries and object-oriented C++ libraries.
I would prefer having a file class that provides the requisite functions. Perhaps preset to read/write a particular endianness. Like:
class VirtFile
    uint16_t ReadUInt16()
So using it might look something like
auto file = filesystem.GetFile("file/path/name.ext");
auto firstNum = file.ReadUInt16();

Endianness could be set for the filesystem and returned files using configuration options for the virtual filesystem, or better yet template parameters.

And while you bring up sf::Vector2u, there really are quite a few cases where the SFML types can and ought to be replaced with standards. Those have been discussed already elsewhere, but I'd say those are a pain point too. Not where they actually provide useful functionality, but where they simply duplicate the standards, or are actually less useful. But that's mostly down to C++ versions.

General discussions / Re: PhysicsFS vs an SFML virutal filesystem
« on: January 17, 2019, 10:46:28 pm »
I feel like we're really straying from the topic at this point, but most (all?) PhysicsFS functions return their own types, which are typedefed or custom structs, C strings, enums, void*s, etc, that all have better, standardised analogues in C++. Some of that won't matter in many cases, but enough of it matters enough of the time to make interoperating with C++ container types, or C++17 filesystem functions a pain.
I would suggest anyone unfamiliar with PhysicsFS just check the header (https://icculus.org/physfs/docs/html/physfs_8h_source.html) to get a better idea of this.

This is what the docs list for data structures, by the way: https://icculus.org/physfs/docs/html/annotated.html
I would also say that endian-specific functions are worth including in the discussion: they are necessary for cross-platform data handling, and not at all intuitive in PhysicsFS. SFML is a cross platform library, and could do a much better job with this.

General discussions / Re: PhysicsFS vs an SFML virutal filesystem
« on: January 17, 2019, 10:15:03 pm »
Granted, it's it's not the most complex library, but it is complex to use in a C++ codebase by virtue of being a C library with its own, non-standard data structures and conventions. It forces you at the least to create a layer of abstraction to handle that.

The usual way is to do essentially as you said - static tiles in one layer, with animated objects rendered in a second pass.

General discussions / Re: What pain points do you experience using SFML?
« on: January 17, 2019, 09:29:30 pm »
I ended up handling text rendering slowness by rendering to textures for each text block. This works fine for static text, but doesn't help when the user is editing a large text block. Didn't try VertexBuffers there, but I imagine that still wouldn't help for the case where text might be changing.

The thing about sprite batching being opinionated is that implementing sprites in an unbatchable manner is opinionated design itself. It's not just batching ambivalent, it makes sprite batching counter to the design of the built in sprites. I think sprint batching could be done in a reasonably generic way that at least gives the user a starting point to customising a solution to their needs.

After refreshing my memory of SFML's views, by cameras I essentially mean better managing of the relationship between viewports and views. For most applications, games included, you really want an output that will have square pixels, and unless explicitly zoomed, you want 1:1 pixel sizes as well. Right now you have to actively manage a viewport and view to achieve that.

PhysicsFS and libcurl are both fine, but they're also both complex C libraries. They have C++ wrappers out there, but what I've seen are really very thin wrappers that don't make the libraries any easier to use, or require referencing documentation any less. Often using a C++ wrapper for a C library just means checking through two sets of documentation to find what you need instead of one. I would prefer having smaller scoped C++ solutions to networking and virtual file systems with an API that makes sense for a C++ codebase.

In these cases, I usually end up writing my own wrappers that include the functionality I need. And that's fine, but there are a whole bunch of those that I have to set up for every SFML project. So I think that qualifies as a pain point: it's one (or two, or ten) more thing(s) that need to be created, configured, or included before I can start using SFML productively.

General discussions / Re: What pain points do you experience using SFML?
« on: January 15, 2019, 10:06:53 pm »
Inefficiencies are the biggest pain point for me.

Dealing with textures is pretty painful when you don't want to deal in pixel coordinates. For example, converting normalized coordinates into pixel coordinates for every frame of animation, only to have that converted back into normalized coordinates for OpenGL is a big waste.

Having to write your own sprite manager in order to avoid separate draw calls for every sprite is a pain - especially when SFML presents a really inefficient way to handle sprites as the default, so new developers get used to that and have to relearn things with no help from SFML when they switch to batched sprites. I know batching should be implemented on a per-game basis ideally, but even basic batching would get users into the right habits from the start, and then they could inherit from the built in classes to customize the solution to suit their needs.

Built in text rendering is quite slow - I don't know why this is exactly, but it's a big bottleneck for UI rendering.
It's also not very useful for anything but the very simplest case. A rich text component or even just multiline component with text alignment would make a big difference here.

The network functions aren't great - no support for HTTPS is a deal-breaker for me, and even besides that it's quite finicky, so I had to switch to libcurl pretty quickly.

Having no resource manager feels like an oversight - again this would help people get into the right habits from the beginning. A virtual filesystem would also be super helpful here. Most projects that SFML is suited to would benefit from these, and they're pretty generic utilities.

Views are not easy to use or intuitive in the way they could be. It would be much more helpful to design these around the idea of a camera. Aspect ratio should not be as easy to screw up as it is now especially considering window resizing.

General discussions / Re: SFML 3 - What is your vision?
« on: October 30, 2017, 03:08:34 pm »
I think it would only make SFML more flexible to include a layer of abstraction over the graphics back-end. I don't think it makes sense for that to include developing additional back-ends though. There's no reason there should be an official DirectX back-end, but a developer who knows they need such a thing will have the option to create one and ensure it will integrate relatively easily with SFML.

If someone is using SFML more casually, they will surely use the default OpenGL back-end and have the best chance of developing cross-platform code. Besides, with a common abstraction for all graphics back-ends, there's no opportunity for adding DX-specific features without sidestepping the abstraction or building the feature into it.

A clean abstraction should make the code easier to maintain as well, as long as it doesn't mean developing additional back-ends.

Isn't the poor quality of video tutorials out there indicative of people struggling to make sense of the official documentation?
Surely if they understood well the best way to set SFML up, they wouldn't be putting out tutorials that instruct in poor practices.

I think there is a real issue with the initial set up instructions. I personally don't like video instructions for all the previously mentioned reasons (They're slow, difficult to retrace steps, etc), but I think there is a strong case for the need to improve what documentation is provided.

General / Re: Creating standalone of specific RenderWindow
« on: April 26, 2017, 03:32:05 pm »
You probably want to create a separate program that can take as input what the design program outputs. So for example, you might use your design software to write some scripts, include some resources, and set up everything you want the game to do. Then to create a distributable, you would export that data alongside a second program that can read, interpret, and execute those scripts, using the resources, etc.
That's what I would do, rather than trying to write or include a compiler.
This won't be as fast as a compiled project, but I think it will be a whole lot easier to put together.

I have a 4K monitor, and can test it in any resolution up to 4K if you like.

SFML development / Re: sf::Font: Abstraction and Bitmap Fonts
« on: April 11, 2017, 04:17:21 pm »
Yeah, I agree, but at the same time that tool usage is something I'd like to avoid, if possible. You can't just create TTF files out of thin air either, but at least it's standardized and you're free to pick any tool you want.
It's true unfortunately that there isn't a common standard format for describing bitmap font layouts, but having some kind of format is still a necessity. Every bitmap font tool out there generates some kind of layout information because of this necessity, so adapting one of those existing formats seems reasonable. I pointed out the HGE font format because it separates the character layout from the actual texture and it's human-readable and editable. Taking a look at other options out there, BMFont looks like more or less a de facto standard:
Their tool can output XML formatted font descriptions as well, and there's a third party JSON formatted version: https://github.com/mattdesl/bmfont2json/wiki/JsonSpec

There's also Microsoft's .fnt file format, which supports both bitmap and vector fonts: https://support.microsoft.com/en-us/help/65123/windows-developers-notes-font-file-format

There are many other tools with other layout formats of course but many are not well documented online.
The nice thing about the tools out there is that because of this format problem, a number of them support output plugins, allowing the user to output the data in whatever format suits them (And has a plugin), which probably eases the burden of giving users the tools to generate one of the more complex formats. In this way, much like TTF, users have a variety of tools they can use on different platforms to generate the required files. This is especially true if it supports an existing format for which there are already export plugins available.

SFML development / Re: sf::Font: Abstraction and Bitmap Fonts
« on: April 10, 2017, 03:39:54 pm »
I think rather than specifying character size and spacing, it might be better to supply description of the font's layout.
Ages ago I used HGE to develop some games, and what they did for fonts was accept a bitmap and a font description file. You can find some information on their implementation here.

They also supplied a small piece of software to help lay out fonts and automatically generate that description file, but given SFML's cross platform nature that may not be possible.
In any case, I think being able to specify texture coordinates for each character would be useful, and tools can definitely make generating those a simple matter for any developer that cares to use bitmap fonts.

SFML development / Re: Suggestions
« on: March 14, 2017, 03:48:41 pm »
How about the status of Android and iOS as supported platforms? Ideally making them first-class platforms alongside Windows, Mac, and Linux. In any case, clarifying SFML's support of them, as the website and documentation is very poor in this regard.

Pages: [1] 2