Messages

1

General discussions / Re: Looking to Create a Node Based Programming Language

« on: January 02, 2017, 08:49:39 pm »

It is time-consuming to set up everything in C++. To go from all C++ to all nodes with no code, is swinging from one extreme to the other. An existing engine with scripts on top is the middle of the way - and though I don't have stats at hand, it seems to me the choice of most indie studios.

Part of the project sounds like UI/UX design, catering to your intuition and mindset. It is fine if that is what you wish to pay for, although there will certainly be people who will find the interface/workflow just as unintuitive as you find that of the aforementioned programs.

Personally, I am cautious about anything that sounds like reinventing the wheel. I'm not saying we can't do better, but I believe a better design emerges only after sufficient experience with the current tools and an understanding of their shortcomings.

2

General discussions / Re: Looking to Create a Node Based Programming Language

« on: January 02, 2017, 02:34:40 pm »

There are a number of engines/software out there that are supposed to let you make 2D games with nodes only and no code:

• Construct 2
• Stencyl
• Godot

to name some.

It would help if you clarified what platforms you wish to target and why these existing solutions fail to satisfy.

3

SFML projects / Re: Thor 2.0 released!

« on: July 30, 2016, 03:17:51 pm »

Used Thor to make an animation between two points. This brought up some thoughts:

- Interpolation schemes - I think you have talked about including such in Thor. Is this something we could expect in the short-term, or should we be looking elsewhere?

- Parallel animations - It doesn't look like a single animator can play animations in parallel (only in internal edge cases). Is the only way to do this to compose them manually? Would using two animators be reliable enough?

- Inability to query animator status - The docs state this is by design, however the rationale behind this design isn't so clear. In the example in my post, I wished to ignore the keypress while the animation was playing; so this had to be tracked externally and updated with the callback mechanism. A lot of verbosity that would be eliminated by querying whether there's an active animationn. Meanwhile, internally this looks to be as simple as returning mPlayingAnimations.empty().

I realise the example is simple, however in a larger application one could keep distinct animators - according to the role - and thus still obtain useful information from this query.

Other animation APIs do offer such functionality. Could you clarify why you deem it best not to provide it? Do you have a better design in mind to achieve the intention in the example?

4

SFML projects / Re: Sprite Sheet Manipulator

« on: May 26, 2016, 04:16:48 am »

This looks nifty, there's quite a few spritesheets out there that are laid out in a seemingly haphazard manner 

5

Feature requests / Re: sf::Line(int x1, int y1, int x2, int y2)

« on: April 24, 2016, 05:32:10 pm »

There is one more difference I believe: increasing the outline thickness of a rectangle pads the two edges beyond where the original points are located. A dedicated LineShape can add thickness to the sides only.

It is unlikely one wants a hugely thick line so the difference should not be great visually. But it is there.

6

Feature requests / Re: sf::Line(int x1, int y1, int x2, int y2)

« on: April 24, 2016, 03:36:16 pm »

So, to make it clear, the proposal is to add this:

sf::Line line(x1, y1, x2, y2);
line.setFillColor(color);
window.draw(line);

... to avoid writing this:

sf::Vertex line[] = {{{x1, y1}, color}, {{x2, y2}, color}};
window.draw(line, sf::Lines);

Is it really worth it? (real question, I personally don't know)

That does not have thickness.

To add a line with thickness between two points requires a bit more boilerplate, like here. If I have been missing an obvious way to do that, by all means point it out.

7

Feature requests / Re: Optimize memory layout of SFML classes

« on: April 24, 2016, 03:15:03 am »

Your caches are your very limited system. Thus, good alignment can have a significant impact on performance regardless of the overall memory on your system.

There are two major factors:

i) The smaller objects are, the more can fit in cache
ii) At the same time, the first bytes of an object are its hot zone, where the most used members should be placed. (I cannot rigorously explain why. You can find a relevant SO question. Alexandrescu also mentions this hot zone several times .)

As to the topic at hand, whether it makes a meaningful difference for sf::Transformable can only be gleaned from measurements, though intuitively this may very well be the case when operating on a range of such. Since SFML is a library, such 'micro' optimizations are worth it.
The optimal alignment itself may vary across architectures; that said, getting rid of unnecessary padding is unlikely to be wrong.

8

Feature requests / Re: sf::Line(int x1, int y1, int x2, int y2)

« on: April 24, 2016, 12:31:46 am »

In case you have the Thor library, you can use the class thor::Arrow, which also supports arrow tips (and in the future maybe different line styles). Thor also comes with rotation functions for vectors, in case you need them.

Uh, you have a line function returning a ConvexShape - why not recommending that one?

I'm in agreement with the OP. No this isn't the first time this pops up and yes, we all know it can be coded easily or found somewhere. It still is a glaring hole in the API. A line between two points is a very basic thing to do, particularly when prototyping; it is quite jarring to have to write boilerplate/hunt some dependency/dig up a pre-written snippet.

9

SFML game jam / Re: 5th SFML Game Jam

« on: April 02, 2016, 08:06:37 pm »

Thank you for doing this! I linked it to a friend with a Mac and Tracks at least is working great 

10

Feature requests / Re: Plattform independet File Open / File Save dialogs

« on: March 28, 2016, 07:41:30 pm »

Boost.filesystem + SFGUI to create a dialog is indeed perfectly possible and what I do.
Might share a polished version soon.

11

SFML game jam / Re: 5th SFML Game Jam

« on: March 24, 2016, 02:58:09 pm »

Certainly. In no part of my post was I critical of the organisation - any comments I had on that I made directly on irc.

My disappointment and my hope for future jams is for more forum and irc regulars to participate in the jam.

12

SFML game jam / Re: 5th SFML Game Jam

« on: March 23, 2016, 02:33:25 pm »

Is it just me who's disappointed by the turnout?

This was supposed to be a long jam precisely for all those of us who understandably don't have the time for a weekend jam. I was looking forward to the submissions of several dev team members and other community regulars who had indicated they would participate.

Personally, I was almost not going to complete my entry, because the bulk of the work got pushed on the last day and was sure it would pale in comparison to a 2-week work. But in the end, I think all who submitted did the exact same thing. So I understand that others might have refrained for that reason, but also disappointed that they could not jam something together.

13

SFML projects / Re: SnakeFML

« on: March 07, 2016, 08:52:06 pm »

*gasp*

That's higher than my 4320 - pretty sure that's a new highscore!

Too bad it takes so long - I'm inclined to do fast-paced fork

14

General discussions / Re: SFML 3 - What is your vision?

« on: March 03, 2016, 02:38:40 am »

I am not Klaim

Thanks for pointing me to that topic - I suspected that people would have thought of these things but failed to find that one.
On first impressions, I agree with sf::Angle. I 'll be sure to add any further thoughts there.

15

General discussions / Re: SFML 3 - What is your vision?

« on: March 02, 2016, 05:31:17 pm »

*bump*

Hope you don't mind me bumping this to bring up a (spontaneous) idea on the age-old radians vs degrees issue.

Already, passing a float as an angle leaves a bad taste, considering C++'s emphasis on types. It would be much more fitting to have a type for it.
Doing that would make it trivial address the degrees vs radians issue by an overload.
Furthermore, thanks to the user-defined literals that SFML 3 will be able to use, it will be possible to write something like

rotate(90_deg);
rotate(1.5708_rad);
 

preserving the simplicity that was Laurent's original intent.
(although unfortunately that last bit doesn't seem to work with the M_PI macros).

Feel free to shoot it down.

The strong type safety itself is important in my view.

addendum: Come to think of it, it's already possible to introduce two types without breaking the API, by making Degrees implicitly convertible to from float, while Radians not.