Messages

1

General discussions / New strategy for the internal rendering code in SFML 2

« on: January 24, 2010, 06:57:05 pm »

... how is this any different from what I was talking about before?  You went out of your way to prove me wrong, and now you go back to IM? :roll:

Anyways, why are you transforming the vertices on the CPU?  I have a hard time believing that's faster than just using glLoadMatrix() for what it's meant for :roll: ... For example, you can load the View matrix as the projection matrix and every object's world matrix as the modelview matrix, and tada, free GPU matrix transformations.

That, and I still believe that using a VBO per-object would be faster.  I remember reading somewhere that OpenGL draw calls weren't slow like D3D's DrawPrimitive()

2

General discussions / Benchmark : SDL vs SFML

« on: January 13, 2010, 12:59:47 pm »

But, and that is my personal uber-mega-super-power-argument-but, when you enter the SDL Nissan, you'll find out that the wheels are not completely round, that the steering wheel goes strong, that the security belts are week, that the gas it needs is antique, that features like lights, windscreen wiper, heating and radio are extras you have to buy and install yourself and that the final driving experience absolutely and totally feels like a fight against the car itself.

Your SFML metaphor sounds correct but your SDL one does not.  It seems that the driver is someone who has never stepped in the driver's seat of a car ever before and simply does not know what to expect.

SDL may be slower than SFML (moot argument for reasons I've previously pointed out), but it is definitely not a fight against itself - it has its uses.

3

General discussions / SFML 2.0

« on: January 12, 2010, 01:09:13 pm »

Same shader, same texture, same blend mode, same viewport. Then what?

Then they will belong to the same batch.

Code: [Select]


rt.Draw(blue);
rt.Draw(red);

How is the draw order guaranteed if both end up in the same batch, if the batch is rendered as a whole?

I believe that filling up a giant VBO with all the objects every frame is not efficient.

Well, it's obviously a lot more efficient than immediate mode rendering.

Actually it's not that obvious at all.  Thus why I asked for profiling results.  I'll look into it myself.

You shouldn't bother with this discussion, automatic batching will probably be removed soon, I'm currently working on it.

And replaced with what?

I think I might have a go implementing my own ideas and benching that when I find the time.

4

General discussions / SFML 2.0

« on: January 12, 2010, 12:20:36 pm »

It is handled so that the current batch is stopped whenever a state changes. Even if the same states are set again later, the corresponding geometry will not belong to the same batch. This way, the drawing order still has the priority.

Right, I noticed.  However, consider two objects qualify for the same batch, as so:

Code: [Select]


// Check if the current batch differs from the new render states
    if (!myCurrentBatch || !myCurrentBatch->Matches(myCurrentTexture, myCurrentShader, myCurrentBlendMode, myCurrentViewport))

Same shader, same texture, same blend mode, same viewport.  Then what?

What are you talking about, that's how high performance 3D renderers work. Batching is left up to the user via a BatchDrawable or something that will combine VBOs of other Drawables. See above as to why auto-batching everything won't work.

High-performances 3D renderers work with models, not with 2D quads. It's very different, and it can't be handled the same way. Optimizing a generic, low-level 2D API is not straight-forward.

No they don't.

Code: [Select]


    ////////////////////////////////////////////////////////////
    // Member data
    ////////////////////////////////////////////////////////////
    std::vector<Point> myPoints;           ///< Points composing the shape


Of course I did.

Right now you're filling one giant VBO (more if objects vary in texture/shader/etc.) every frame.

What's wrong with that?

I believe that filling up a giant VBO with all the objects every frame is not efficient.  I'd love to see your profiling results that say otherwise.

5

General discussions / SFML 2.0

« on: January 12, 2010, 03:37:55 am »

This is intended, SFML doesn't expose its internal states to the outside. Like I already said, you'll have to setup your own OpenGL view to match SFML's one. Any other solution would be a hack, and my break any time after an internal modification.

Why not add View::applyProjectionGL() or something like that?

The current implementation takes this issue in account properly. The order of drawing is not modified.

How?  Consider 2 objects that qualify for a single batch (same shader/texture/etc.)  If they are overlapping, their triangles will be part of a single draw call - thus, regardless of the Draw() order, the actual order in which they will appear over each other would be up to the GPU.  There is no clever trick or anything in the code (such as using the ZBuffer), so how is it handled?

I can't assign a single VBO to every drawable. This would be inefficient,

What are you talking about, that's how high performance 3D renderers work.  Batching is left up to the user via a BatchDrawable or something that will combine VBOs of other Drawables.  See above as to why auto-batching everything won't work.

and make drawables not sa lightweight as they are currently.

... They already hold their all vertices, what "lightweight" are we talking about?

Have you actually profiled it against what I'm suggesting?  Or really against anything else?  I'm willing to bet that the old immediate mode code is faster than the current code for a lot of scenes.  Right now you're filling one giant VBO (more if objects vary in texture/shader/etc.) every frame.

6

General discussions / Benchmark : SDL vs SFML

« on: January 12, 2010, 03:24:03 am »

SDL isn't meant for computers with hardcore graphics accelerators (AKA modern GPUs).

Just like a Nissan Quest is a family car, not a sports car for some rich guy.

SFML is meant for computers with decent if not hardcore GPUs.

Just like a Lamborghini Gallardo.

Yes, the noob will take a look at both cars and say, "of course I want the Gallardo, it's so much faster and cooler looking!"

That doesn't mean the Nissan Quest is now useless, which is essentially what you're trying to show in this benchmark.

7

General discussions / Benchmark : SDL vs SFML

« on: January 11, 2010, 11:09:51 pm »

An obvious conclusion, but some people don't know about this. So what's wrong with it?

What's wrong with it?  Exactly what I pointed out.

Same thing as comparing a Nissan Quest to a Lamborghini Gallardo and concluding that the Gallardo is faster.

8

General discussions / SFML 2.0

« on: January 11, 2010, 09:45:12 pm »

It wouldn't work if it was a reference. References can only be initialized at declaration, so this would still be a copy anyway. To keep a reference instead of copying the view, the myCurrentView member would have to be a pointer (that was the case before).

Oh yeah I'm just being stupid.  Comment is a bit misleading.

Why? The purpose is that you don't have to care about what SFML does internally, it never impacts what you do with OpenGL outside. I could tell you about the internal details, but there's no point for you to know that, it should even change in the next days.

Because I want to render with OpenGL under SFML's view transformation.  For example, now there is no way for me to draw 1-pixel-wide lines, for, say, a grid.  Now I have to manually push SFML's view transformation back onto the OpenGL state.

It allows batching, which is much faster.

I don't see any batching, every drawable seems to make a new batch every frame.  Besides, you can't just batch any N drawables together because they might be overlapping, in which case you will get inconsistent behavior (one might show on top of the other even though you want to draw it first).

It would be much more efficient for every drawable to create its own VBO at time of creation or modification, and keep that VBO until it dies.  If the user wants to batch things together, he can use a BatchDrawable which takes the VBOs of N Drawables and puts them all into a single VBO which then moves as a whole.

This is how high-performance 3D engines do it, and it is no different in 2D.

It also reduces the number of states changes from N (number of drawables) to 1 per frame.

I don't understand how reducing the amount of state changes has anything at all to do with the queue.  You can have a list of random objects and still have a single state change, regardless of a queue.

9

General discussions / Benchmark : SDL vs SFML

« on: January 11, 2010, 09:29:43 pm »

I don't understand the point of this test.

It's like testing a software renderer vs. Direct3D and concluding that Direct3D is faster.

10

General discussions / SFML 2.0

« on: January 11, 2010, 12:27:12 pm »

What's the point of RenderTarget keeping a reference to the view when you need to call SetView() every time you Reset() it? (otherwise the changes have no effect for me)

It doesn't keep a reference to the view anymore, it was changed recently to store the view by value so that you have to call SetView everytime the view changes.

Code: [Select]


////////////////////////////////////////////////////////////
/// Change the current active view
////////////////////////////////////////////////////////////
void RenderTarget::SetView(const View& view)
{
    // Save it
    myCurrentView = view;

    // Send the view's viewport and projection matrix to the render queue
    myRenderQueue.SetViewport(GetViewport(view));
    myRenderQueue.SetProjection(view.GetMatrix());
}

This is from branches/sfml2, HEAD revision.  Edit: Wait, myView is not a reference?

Your OpenGL objects are drawn with the matrix that you setup, SFML doesn't alter the OpenGL states.

Could I get a little breakdown of what exactly SFML does during the rendering process?  Not too specific but I want to see how it handles all the transformations and renders from a higher level.

Note that SFML 2 doesn't actually draw when you call Draw, it stores everything in a render queue and renders everything when you call Display. So if you want to draw something on top of SFML objects, you have to force rendering with Flush.

This is why I want the higher level breakdown I mentioned, because from what I can see, the queue essentially filled and cleared every frame?  That has no advantage over immediate mode, in fact, it should be slower.

11

General discussions / SFML 2.0

« on: January 11, 2010, 12:23:53 am »

SetRect has been replaced with Reset. SetViewport sets the viewport, which is a completely different thing.

Thanks, that (semi) fixed it.  What's the point of RenderTarget keeping a reference to the view when you need to call SetView() every time you Reset() it? (otherwise the changes have no effect for me)

Also, is the OpenGL state for the matrices pushed and popped for every single object that is drawn?  I rendered some 2D objects in the same coordinate system as everything else via raw OpenGL - however, now that does not work, the OpenGL-drawn objects are always drawn with an identity matrix.  What exactly changed here and why?

12

General discussions / SFML 2.0

« on: January 10, 2010, 11:08:19 pm »

Any porting notes for 2.x?

What displays in 1.6 does not display in 2.x (blank window), the only change of code I've done is replace View::SetRect() calls with View::SetViewport() calls since SetRect() is gone.

13

General discussions / Design and documentation

« on: December 31, 2009, 05:41:57 pm »

Come back with some profiler results and I'll consider your argument.

You can also think a bit about performance without using a profiler. It is a fact that the windows heap that is used through new in C++ is optimized for bigger and slow for small objects.

If you're so worried about your heap being slow, you shouldn't even be using the default heap allocator.  Use nedmalloc.  And, obviously, don't allocate primitive types on the heap, that's just stupid.  The whole point was to keep the mutable members in an internal structure, not all the members.  If all the members need to be mutable then I believe a major redesign is in order.

But if you don't share the memory you should not be using shared pointers to begin with.

How is that any different from my original statement??  Like I said, "The whole point of shared_ptr is for ... shared objects. Not just memory management in general."

14

General discussions / Design and documentation

« on: December 31, 2009, 04:48:22 pm »

You should know even reset on the shared_ptr and clear on the container are not guaranteed to free the memory.  Because if the ref count is not 0 the memory will remain allocated when you call reset().

[edit]
The point being those calls are not 100% reliable.  Like I said shared_ptr's are great to use but they defiantly should not be over used.  They are not the end all be all.

The whole point of shared_ptr is for ... shared objects.  Not just memory management in general.

If you don't want to share the memory, then don't.  shared_ptr's don't just sneak in some references out of no where so you can't free the memory...

15

General discussions / Design and documentation

« on: December 31, 2009, 04:30:34 pm »

They care about that just typing #include<boost/shared_ptr.hpp> increases the compile time of a already 3 day long compiled application.

That's true, however, shared_ptr doesn't make that much of a slowdown.  I'd worry more about the preprocessor library.

A lot of game dev's avoid shared pointers because it does not allow them to explicitly control the life time of their heap allocated objects.

somePtr.reset(); // magic

When you are creating resources and destroying resources at 60fps for say particle effects, maybe arrows that fire from a bow or bullets flying from a gun shared_ptrs are death to the code base because the objects linger long then the should linger.

theContainer.clear(); // magic

There is a whole article about it in general.  At the end they give some reflections on shared_ptr and games.

http://www.gamasutra.com/view/feature/4015/managing_data_relationships.php

The whole point of shared_ptr is for ... shared objects.  Not just memory management in general.