Messages

1

SFML development / Re: sf::WindowBase vs sf::Window vs sf::RenderWindow

« on: April 23, 2022, 11:39:50 am »

Nice that you finally start cleaning up the codebase for SFML3.

I think, there was too much mixed into the Window.
A cleaner API may be to have a Window, which only cares about the basic window settings and input.
Then have an abstract Context class providing a hopefully future-proof abstraction. The first derived class from this could then be the OpenGLContext. Later other APIs could have their own.
I'd hope it can be avoided and just the Context used, but if necessary make a Graphics class that is given a Context, which is used for everything that the SFML Graphics package additionally needs.

2

Feature requests / Re: sf::Texture::Texture(std::string file)

« on: December 28, 2014, 10:53:44 am »

Variables wont cost $. They make you think of a good name, helping you a few months later understanding your code.

3

General / Re: The application was unable to start correctly (oxcooooo7b).

« on: December 22, 2014, 11:04:07 am »

It does use SEH in 64bit mode: http://tdm-gcc.tdragon.net/quirks
I would clean the system and then only install one version of the compiler, library, dlls.

4

Graphics / Re: Loading in small graphics

« on: December 21, 2014, 12:44:02 pm »

To find out whats wrong you should step through your code with the debugger and watch the values of all relevant variables!

PS: I would only use / for paths, as these need no escaping.

5

General / Re: The application was unable to start correctly (oxcooooo7b).

« on: December 21, 2014, 12:30:40 pm »

Did you accidentally put an -m32 switch when building your app, making it behave as 32bit compiler?

6

General discussions / Re: SFML 2.2 tagged in repository

« on: December 11, 2014, 05:16:53 pm »

Now would be a good time to create a stable maintenance branch where only all bugfixes go and which gets merged to master regularly. That would prevent new features from delaying a maintenance release again.

7

Audio / Re: How to play another music after a music finish playing?

« on: December 09, 2014, 06:47:15 pm »

And you should google "event loop" and "game loop", because starting with a convoluted mess of control structures where input and output code is needlessly repeated is a typical beginner mistake.

8

Graphics / Re: Does SFML support partially refresh/redraw?

« on: December 09, 2014, 06:35:04 pm »

On a boardgame without animations you could use waitEvent after display, then poll remaining events. This prevents useless redrawing when there are no new events and therefore no need to draw something different.

9

SFML wiki / Re: Settings parser

« on: December 07, 2014, 11:42:35 am »

You don't initialize all members in the constructor. That means the locale gets default-constructed from the currently active global locale that someone could have set to anything: http://en.cppreference.com/w/cpp/locale/locale/locale . Then the stream could use a different locale (internally copied from the global locale at time of its construction) than your later calls to isspace, if it got changed inbetween.
It would be best to not use any function that can depend on a locale (especially when parsing files that should never depend on one), but if you can't help it explicitely construct a "C" locale and use it for everything.

I also don't like how you read and parse the file again on a therefore mislabeled write method, possibly using a different locale and if the file got changed meanwhile you mix in some possibly old settings.
There I would just read the whole file in binary mode into memory with a single read call to the stream inside your read method, do in memory parsing and keep all data for writing it later without reading it again.
Then you could also have a save method taking a filename to make it also useful for the case of writing a copy of the settings somewhere else, to prevent partial overwriting on errors or have a backup or construct a new settings file without loading it first.

10

Feature requests / Re: Make CircleShape, RectangleShape, and ConvexShape only be shapes. Not drawables.

« on: November 28, 2014, 12:19:26 pm »

I dont like that idea, because it is really backwards. Currently Sprite is there to be the simplest possible thing to be drawn, where it just puts a texture on screen as it is (often with a 1:1 mapping of texels to pixels), with the textures alpha determining the perceived shape.
The Shape classes are for complicated uses, can have any number of vertices determining the draw area and have outlines with a different color. Bloating the Sprite class with all kinds of rarely used extraneous functionality will result in loosing the simple class that is probably used more often and complicating that usecase.

I would think if a change is done its more useful to add the possibility of putting all Drawables into a VertexArray or Batch class and only then actually drawing everything at once. Maybe direct drawing could then even be removed to simplify porting to modern OpenGL using VBOs.

11

Window / Re: 32 bit to 64 bit

« on: November 23, 2014, 08:05:34 pm »

That error means you made the mistake of using a library that was compiled with a compiler using a different type of exception handling.
You have to use the same compiler for everything, that means, recompile the library and your code!

12

Window / Re: 32 bit to 64 bit

« on: November 22, 2014, 06:41:43 pm »

Or even simpler: just remove those options that the compiler/linker does not know, as TDM already links statically without them.

13

General / Re: [Solved] Input tied to frame rate.

« on: November 12, 2014, 12:05:05 pm »

I would value correctness over a convenience of not having to add a few variables. The problem with checking the current status of keyboard/mouse is that its from a single point in time, that is dependent on the random time fluctuations of the update loop, and asking for 2 keys they would already be checked on a slightly different point in time. With events the whole timespan is covered without the chance of missing keypresses in some cases.
For many things its actually better to only react to changes, so there would be no need to remember the status. For other things it may be better to only remember what should be done (for example, accelerate) and give this info to other parts of your game, otherwise too many parts have to know about keys and how they are translated.

14

General / Re: Input tied to frame rate.

« on: November 11, 2014, 09:54:13 am »

Nothing is preventing you to poll for input events once per call to update, by moving it into the inner loop, and then setting/resetting the acceleration only on keydown/keyup events, without automatically resetting it every update.

15

System / Re: limker error when using sf::time operators

« on: November 02, 2014, 01:25:26 pm »

Because they were compiled that way. (You would need to recompile all libraries with the same setting to make them compatible, but thats much pain for a tiny or possibly even negative gain. You better dont waste time on such microoptimizations.)