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

Pages: [1] 2 3 ... 9
1
General discussions / Re: SDL2 Speed vs SFML?
« on: March 21, 2016, 05:43:17 am »
For the most part the performance is more or less the same.

If you want an exact answer for your situation, you'd have to port your engine to SFML and benchmark it. Alternatively, do like Laurent said and make a small benchmark (wont give you exact results, but close enough).

2
Feature requests / Re: push Events...
« on: February 29, 2016, 08:53:52 pm »
1) Add a Event::UserEvent enum , a void *userData field, which is deallocated in the ~Event destructor.
 Then you just need to event.userdata = static_cast<void*> new MyEvent (stuff); I agree it's not very sexy.

That solution is too.. C-ish.

2) Make "Event" a template parameter. Constraint this template parameter to be a subclass of Event (this can be done even with C++-98). This is not an easy solution in a library though

The problem here is that that would require either:

- Your custom event structure to be compiled alongside the SFML source.
- Any SFML source that uses the event structure to be moved into header files.

3
Feature requests / Re: push Events...
« on: February 28, 2016, 11:44:18 pm »
A click is a click. I see nothing wrong.

SFML's event system is simply to forward events from the OS to your application. If you want to support some non-standard device as well, you're going to have to create your own event system.

Plus, and I have yet to see any suggestions yet, how could you possibly go about implementing such as a feature? For custom events, the size of sf::Event needs to be known when SFML is being compiled, which means we aren't left with many options (and all of the options are sub-optimal). And I can't see any realistic use of pushing an event such as MouseButtonPressed/MouseButtonReleased, which would make real mouse clicks and controller "mouse clicks" ambiguous, which is also a bad idea.

4
Feature requests / Re: push Events...
« on: February 27, 2016, 10:08:16 pm »
You have user data streams, you have custom audio streams

And it makes sense. Why limit the ability to load resources to just whatever kinds of files SFML can decode? The underlying APIs support it. It's also fairly easy to implement.

you have the capacity to create your own Drawable and Transformable object

Again, there's nothing about the underlying APIs (in this case, OpenGL) that prohibits custom shapes, and it's pretty easy to implement custom shapes.

I dont see any good reason why you shouldn't have custom events

What limitation is SFML imposing on you by not letting you create your own event type? And it's not like there's any demand for such a feature.

or at least a smart way of making them

What do you mean?

not involving reinventing the wheel every time.

It's really not too terribly difficult to implement a simple event system. There is no clean way to achieve what you want, so you'd be much better off making your own anyways.

5
Feature requests / Re: push Events...
« on: February 27, 2016, 09:22:03 pm »
Why? Because I already have 7000 lines of c++-98 and I dont want to mix them with -11 just to have a lambda function. And also because I master -98 programming but never really got interested in the new stuff. But I will...

The only benefit to using C++98 over C++11 is support for outdated compilers.

Indeed it's exactly what I do.
The goal of this topic is to propose new features in the SFML library so people with the same needs dont have to write again and again the same thing on top of the library, right ?

Just adding a pushEvent function, and maybe adding a customizable field in the Event structure, would do the trick just fine

I disagree. SFML events should be used solely for events generated by SFML, not by the application.

Also, there is no clean way of doing customizable events. You're pretty much stuck with creating your own event system if you want custom events.

6
Feature requests / Re: push Events...
« on: February 26, 2016, 10:57:33 pm »
No kidding?  ;D

You know what I meant: C++ 98.

No, I didn't know what you meant. You sounded to me like you thought Lambdas were a compiler extension or something.

But more importantly, why would you only want to use C++98?

It's not a fake mouse press, it's a real mouse press but the signal was not generated by sfml.

Could you explain further?

7
Feature requests / Re: push Events...
« on: February 26, 2016, 01:22:44 am »
Yes, I know. But I'm stick with plain old C++

Lambdas are part of the C++ language.

8
Feature requests / Re: Vulkan Support
« on: February 18, 2016, 09:45:18 pm »
None. :| However, I'm talking about SFML capabilities.

Using SFML is more inefficient and less powerful  than directly using OpenGL (not to mention if you use OpenGL directly, you can access some of the newer features). And I'd think that with any significantly complex application, the developers would be capable of using OpenGL directly (or write a finely-tuned wrapper for their specific usage).

Obviously, whether or not it's worth using OpenGL directly over SFML is really up to whoever is writing the application. The performance of SFML may very well be fine for their usage (after all, 2D isn't very demanding).

Obviously SFML is still a good choice for 2D graphics, I'm not saying that it isn't, in fact, that's my point. You don't need Vulkan. But if you need the performance so badly don't use SFML.

Can I ask why? If I remember everything properly it already worked on GPUs for which OGL ES was designed.

Momentum. It's been around for a long time, libraries and applications use it. Almost all mobile devices already support it. Many tutorials for it. It's also easier for beginners.

OpenGL 1.x is still used, even though it should have died out long ago.

9
Feature requests / Re: Vulkan Support
« on: February 18, 2016, 07:51:32 pm »
SFML2 isn't designed for 'drawing a few sprites', it can be used to write huge and very powerful applications. And in cases like that Vulkan can be one of best SFML's features since years.

Ok, maybe that was an exaggeration. But I'm not quite certain about the "huge and very powerful applications" part. What applications are you referring to?

Btw Vulkan can also replace OGL ES so it will be easier for SFML devs to support mobile platforms like Android or iOS.

It wont replace OpenGL ES for some time.

10
Feature requests / Re: Vulkan Support
« on: February 18, 2016, 06:44:42 pm »
Drawing from multiple threads is a neat idea, but in practice it's a next to useless feature (i.e. nobody will ever need it, let alone use it) outside of serious 3D applications who absolutely need the extra performance.

Most of the people who use the graphics module aren't looking for some awesome library that meets the performance needs of the most demanding 3D AAA games, they just want to draw a few sprites.

Adding Vulkan would be a huge task, and for what? An unnoticeably faster graphics module?

11
Feature requests / Re: Vulkan Support
« on: February 18, 2016, 02:18:54 pm »
One benefit that Vulkan has is that its API doesn't have 20 years of cruft. This is mostly irrelevant for SFML however, since SFML abstracts the details of the rendering process away.

I think this would be purely a reason for the developers of SFML to choose Vulkan, not the users, since, as you've said, SFML hides away all this stuff.

Besides, SFML uses a very old version of OpenGL that lacks any of the newer efforts to streamline the API. I'm led to believe the team doesn't really care about all this "20 years of cruft".

I would think it'd be cool to see it support opening a Vulkan window, but it appears as if the next version of GLFW will do that, so if you're simply wanting to try out Vulkan it's not all that urgent.

1.)One benefit Vulkan brings is that it inherently reduces CPU workload for rendering. A Vulkan powered app will likely require less time for the CPU to spend handling the overhead than an OpenGL counterpart.

Very true. But that's really only an issue with (high end) 3D graphics, not 2D.

And also consider, like I've said, that SFML uses a very old version of OpenGL, I'd think it'd be more important to start using a newer version of that before deciding if Vulkan would actually help (and it probably wouldn't).

2.) Vulkan is better designed for multi-threaded applications. Unlike OpenGL, Vulkan has been born in a time of multi-threading computing, and is better designed for multi-threading.

So? I'm going to go out on a limb here and assume that most games using SFML aren't multi-threaded.

Vulkan is also compatible with less GPUs than OpenGL 1.1.
Well if you could supply some evidence for that would be cool. Since what I read about Vulkan, it's supported on every hardware OpenGL is currently running on, it just depends if you get a Vulkan driver for that stone age GPU only supporting OpenGL 1.

Vulkan wouldn't be able to run on a GPU that only supports OpenGL 1.x because Vulkan requires shader support, among a great many differences between it and modern hardware that could easily prove to make Vulkan impossible to run on those devices.

Besides, if there's no driver support why does it matter?

12
Feature requests / Re: Vulkan Support
« on: February 18, 2016, 04:22:45 am »
What benefit would Vulkan bring to SFML?

13
General / Re: Timebased movement not working..
« on: February 08, 2016, 02:46:32 am »
Imagine if you had a loop that looked like this:

while (!quit)
{
    //Do stuff

    clock.restart();
    float delta = clock.getElapsedTime().asSeconds();
}
 

The goal of delta is to measure the time it takes to complete //Do stuff. The clock gets reset to 0 and then you measure it. delta will always be 0 or near 0.

In order, you're basically doing:

- Do stuff
- Restart clock
- Take amount of time since the restart of the clock

Of course, in your code, you do poll events between the time you restart and the time you get the time elapsed, but your goal is to measure the entire game loop, not just the time it takes to poll events.

But if you rearranged it like this:

while (!quit)
{
    //Do stuff

    float delta = clock.getElapsedTime().asSeconds();
    clock.restart();
}
 

Now delta is the amount of time it took for whatever is in place of //Do stuff to occur. In order, you're now doing this:

- Restarting clock
- Doing stuff
- Taking amount of time since clock was restarted

As Hapax suggested, it may be easier to just do:

while (!quit)
{
    //Do stuff

    float delta = clock.restart().asSeconds();
}
 

Because sf::Clock::restart returns the time elapsed on the clock before it was restarted.

But as I mentioned earlier, you may want to do something like this:

const float timestep = 1.0f / 60.0f; //Update at 60hz
float accumulator = 0.0f;
while (!quit)
{
    accumulator += clock.restart().asSeconds();
    while (accumulator >= timestep)
    {
        accumulator -= timestep;

        //Do stuff
    }
}
 

And just move your circle at a fixed speed (100.0f/60.0f per update).

As for why you'd want to do this, look at:

http://gafferongames.com/game-physics/fix-your-timestep/
http://gameprogrammingpatterns.com/game-loop.html

14
General / Re: Timebased movement not working..
« on: February 07, 2016, 11:36:56 pm »
Try resetting the clock at the same time you get the time elapsed. You're currently measuring just the time it takes to poll events, not the time it takes to complete a full game loop.

Also:

- sf::Time::asSeconds returns a float, sf::CircleShape::move takes a float, why are you using a double?
- It's preferred to update a fixed amount at fixed time intervals rather than multiplying by the time passed.

15
General discussions / Re: will SFML support 3D?
« on: February 05, 2016, 03:08:33 pm »
Will SFML support 3D?

The problem with 3D is that it's so diverse that it's difficult to have a single implementation that pleases most people. That's why there are several existing libraries to choose from (and if you don't like them, you can always make your own or just use OpenGL/Direct3D directly). SFML is more general-purpose, so tying in a largely preference-based library would just turn people away. And even if it were to be implemented in SFML, the 3D support alone would be so incredibly large and complicated that it would overshadow pretty much the rest of SFML.

I wait or start extending SFML for 3D rendering.

If you want to try to add 3D support to SFML, go ahead. However, it doesn't make a whole lot of sense. Most of the API would not "integrate" into SFML (3D isn't as simple as adding a new window.draw overload), and would mostly have to be separate, so there's little reason for it to not be a standalone graphics engine from the start.

Pages: [1] 2 3 ... 9
anything