Welcome, Guest. Please login or register. Did you miss your activation email?

Author Topic: SFML 3 - What is your vision?  (Read 236110 times)

0 Members and 2 Guests are viewing this topic.

eXpl0it3r

  • SFML Team
  • Hero Member
  • *****
  • Posts: 10800
    • View Profile
    • development blog
    • Email
Re: SFML 3 - What is your vision?
« Reply #60 on: April 28, 2014, 07:19:57 pm »
There's no need to quote 3 other quotes...

Anyways, my question was more going into the direction of: Is there any disadvantage in not having sprite batching for all sprites?

Also yes SFML will not turn into a game engine, but we still like to hear what people want, but again as I said in the beginning, we'd like to hear less about specific features and more about what changes SFML should get to make it a better library. What is currently bothering you most with SFML and would like to see changed?
Official FAQ: https://www.sfml-dev.org/faq.php
Official Discord Server: https://discord.gg/nr4X7Fh
——————————————————————
Dev Blog: https://duerrenberger.dev/blog/

Deathbeam

  • Jr. Member
  • **
  • Posts: 82
  • VB6, VB.NET, C#, HTML, PHP, CSS, JavaScript nerd.
    • View Profile
    • My portfolio
    • Email
Re: SFML 3 - What is your vision?
« Reply #61 on: April 28, 2014, 07:51:42 pm »
There's no need to quote 3 other quotes...

Anyways, my question was more going into the direction of: Is there any disadvantage in not having sprite batching for all sprites?

Also yes SFML will not turn into a game engine, but we still like to hear what people want, but again as I said in the beginning, we'd like to hear less about specific features and more about what changes SFML should get to make it a better library. What is currently bothering you most with SFML and would like to see changed?
What is really bothering me? Different rectangle and vector types, that is really annoying...
Spooker Framework - Open source gaming library
My portfolio
Indie Armory - Small community of a game developers. Everyone is welcome. Bring your friends, family, pets...

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
Re: SFML 3 - What is your vision?
« Reply #62 on: April 28, 2014, 07:57:08 pm »
Quote
Different rectangle and vector types, that is really annoying...
Would you mind explaining what you mean?
Laurent Gomila - SFML developer

Njifra

  • Guest
Re: SFML 3 - What is your vision?
« Reply #63 on: April 28, 2014, 07:57:57 pm »
Sorry giving this idea again, but, I really would like SFML Team to implement DirectX as beckend.
I did some testing with my lib(Simple Tool For Games[STFG] - its not published yet...) and SFML.
DirectX is 10x times faster.
I tested this with drawing some number of rectangles.

[1. TEST]
When I was drawing 10 rects with STFG, fps was from 70 to 80.
When I was drawing 10 rects with SFML, fps was from 320 to 330. (Seems awesome?)

[2. TEST]
When I was drawing 100 rects with STFG, fps was from 70 to 80.
When I was drawing 100 rects with SFML, fps was from 40 to 50. (Getting bad, ey?)

[3. TEST]
When I was drawing 1000 rects with STFG, fps was from 70 to 80.
When I was drawing 1000 rects with SFML, fps was from 5 to 6. (Bad, eh?)

[4. TEST]
When I was drawing 10000 rects with STFG, fps was from 10 to 15.
Didn't want to test SFML with 10000 rects.

[5. TEST - FINAL TEST]
When I was drawing 100000 rects with STFG, fps was 1.
Didn't want to test SFML with 100000 rects.

I don't see why not implementing DirectX as beckend.

Btw, it would be nice to have sf::Array in SFML System Module
« Last Edit: April 28, 2014, 08:02:08 pm by Njifra »

Deathbeam

  • Jr. Member
  • **
  • Posts: 82
  • VB6, VB.NET, C#, HTML, PHP, CSS, JavaScript nerd.
    • View Profile
    • My portfolio
    • Email
Re: SFML 3 - What is your vision?
« Reply #64 on: April 28, 2014, 08:14:13 pm »
Quote
Different rectangle and vector types, that is really annoying...
Would you mind explaining what you mean?
It is uncomfortable for me (and I think I am not alone) to have 3 different vector types (Vector2u, Vector2f, Vector2i) and 2 different rectangle types (FloatRect, IntRect). Imo, Vector2f and IntRect are enought, before I started working on my framework, I was using only that 2 and used casts to convert from rest of rectangle and vector types.
Spooker Framework - Open source gaming library
My portfolio
Indie Armory - Small community of a game developers. Everyone is welcome. Bring your friends, family, pets...

binary1248

  • SFML Team
  • Hero Member
  • *****
  • Posts: 1405
  • I am awesome.
    • View Profile
    • The server that really shouldn't be running
Re: SFML 3 - What is your vision?
« Reply #65 on: April 28, 2014, 08:41:48 pm »
Sorry giving this idea again, but, I really would like SFML Team to implement DirectX as beckend.
I did some testing with my lib(Simple Tool For Games[STFG] - its not published yet...) and SFML.
DirectX is 10x times faster.
I tested this with drawing some number of rectangles.
You write your own lib using DirectX, don't publish the code, come up with a very synthetic benchmark and claim that DirectX is 10x faster than OpenGL?

First of all... unless you implemented your drawing exactly as SFML did, it already isn't a fair comparison, because SFML might be able to do things that your lib doesn't and you wrote the test so it would run using both libraries.

Second of all... I don't know where you got this 10x faster from, but there are other things that are happening which probably have nothing to do with either DirectX or OpenGL. There might be more internal call overhead, driver optimizations, SFML might have more safety checks, perform more housekeeping and so many other things that don't even have to do with OpenGL. Unless you can show that raw DirectX performs any bit better than raw OpenGL, don't claim that one is better than the other based on 2 probably very differently implemented libraries using different APIs.

What people seem to forget when comparing DirectX and OpenGL is that in the former case, you choose which API to use before writing even your first line of code. What happens if your library uses DirectX 11 and you have 10 year old hardware? Yeah... it doesn't work anymore. SFML will work on hardware that runs OpenGL 1.5 which dates all the way back to the last millenium. To make your comparison a bit more fair, you would have to make it use DirectX 7.

If you want to see some more believable numbers, from a bit more credible people have a look at the slides presented at the GDC 2014 in regards to OpenGL overhead. In particular the benchmark results towards the end of the presentation. It seems like... OpenGL can be faster than DirectX... by almost an order of magnitude? You know... in the end both are really just APIs... and when talking about performance, what you really mean is API overhead. More often than not, the API overhead isn't even the limiting factor, it's the code that makes use of the API. It's just that the API has been used as a scapegoat for really horrible code. When people say "XYZ isn't fast enough, we need a better API", what they mean to say is "XYZ doesn't optimize my horribly written code as much as I'd like, please give me a version that optimizes better".

If you get an experienced DirectX programmer and an experienced OpenGL programmer and tell them both to write a high performance application, there won't be that much performance difference, because if you minimize API overhead it will be limited to what the graphics hardware can do in a set amount of time. There is no separate DirectX section and OpenGL section on the GPU although that might be what many laypeople might think... everything goes through the same pipeline.

Now that I have countered yet more OpenGL FUD, I can explain the SFML situation in peace.

Basically, SFML is using some very ancient OpenGL code. It doesn't perform as fast as modern OpenGL code might, but it stays compatible with older hardware, which is of higher priority at the moment. At some point, we might consider modernizing the implementation and even the public interface, but there are more pressing issues at the moment and we want to save API breaking for a major version bump.

I don't see why not implementing DirectX as other beckend.
Sonkun is already working on an experimental DirectX implementation. Whether this is necessary is still up for discussion. The one advantage I can think of is enabling future support for platforms that are prevented from providing OpenGL support. Other than that, I don't see any real advantage DirectX would provide when OpenGL can be used as well.

Btw, it would be nice to have sf::Array in SFML System Module
Have you heard of the standard template library? In particular the containers library. Doing a bit of research before suggesting something that is already a language library feature helps sometimes...
SFGUI # SFNUL # GLS # Wyrm <- Why do I waste my time on such a useless project? Because I am awesome (first meaning).

eXpl0it3r

  • SFML Team
  • Hero Member
  • *****
  • Posts: 10800
    • View Profile
    • development blog
    • Email
Re: SFML 3 - What is your vision?
« Reply #66 on: April 28, 2014, 08:46:08 pm »
It is uncomfortable for me (and I think I am not alone) to have 3 different vector types (Vector2u, Vector2f, Vector2i) and 2 different rectangle types (FloatRect, IntRect).
You're pretty much alone in that regard, I'd say. On the one hand there's just one template version of Vector2 and the ones you listed are just typedefs, on the other hand unsigned integers, floats and integers are not the same types and can't be treated as such, if you care about the precision and most of the people do care about that. So again the integer vector is used for when there are only integers values, float vectors are used for when something can have a decimal part (e.g. a position) and unsigned integer vectors are used when a value can't get negative and is an integer (e.g. window size). The same goes for rectangles.
Official FAQ: https://www.sfml-dev.org/faq.php
Official Discord Server: https://discord.gg/nr4X7Fh
——————————————————————
Dev Blog: https://duerrenberger.dev/blog/

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
Re: SFML 3 - What is your vision?
« Reply #67 on: April 28, 2014, 08:52:51 pm »
We are indeed investigating (even testing) the DirectX backend, so you guys don't need to put so much pressure on it. And more important than enabling XBox development, it will make possible a Windows Phone port.

All high-level game features: I don't think SFML should evolve in this direction. It's goal is to provide a generic abstraction on top of platform specific multimedia capabilities. It's not a game engine, and I think it will never be. However this idea is not irrelevant, since most people here write games and would love to see a SFML-like implementation of their favorite features. But this is rather a job for an extension (I have always wanted to write SFGL, the true Simple and Fast Game Library), or at worst for a separate SFML module.

Quote
It is uncomfortable for me (and I think I am not alone) to have 3 different vector types (Vector2u, Vector2f, Vector2i) and 2 different rectangle types (FloatRect, IntRect).
There are several types of vectors and rectangles for the same reason that there are several types for numbers. Because each type is suitable in a given situation.
« Last Edit: April 28, 2014, 09:00:16 pm by Laurent »
Laurent Gomila - SFML developer

Njifra

  • Guest
Re: SFML 3 - What is your vision?
« Reply #68 on: April 28, 2014, 09:13:03 pm »
Sorry giving this idea again, but, I really would like SFML Team to implement DirectX as beckend.
I did some testing with my lib(Simple Tool For Games[STFG] - its not published yet...) and SFML.
DirectX is 10x times faster.
I tested this with drawing some number of rectangles.
You write your own lib using DirectX, don't publish the code, come up with a very synthetic benchmark and claim that DirectX is 10x faster than OpenGL?

First of all... unless you implemented your drawing exactly as SFML did, it already isn't a fair comparison, because SFML might be able to do things that your lib doesn't and you wrote the test so it would run using both libraries.

You can have part that renders rectangle. I'm not sure if this is anything similar to SFML Code beacuse im not inrested in SFML stuff or even OGL.
Code:
void Window::draw(st::g2d::RectangleShape& recta)
{
        if (this->m_opened)
        {
                VOID* pStored;
                st::Color fillColor(recta.getFillColor().r, recta.getFillColor().g, recta.getFillColor().b,
recta.getFillColor().a);
                        DWORD clr = D3DCOLOR_RGBA(fillColor.r, fillColor.g, fillColor.b, fillColor.a);
                        float m_x = recta.getPosition().x;
                        float m_y = recta.getPosition().y;
                        float m_width = recta.getSize().x;
                        float m_height = recta.getSize().y;

                        D3DXMATRIX trans;
                        D3DXMatrixTransformation2D(&trans,
                                &D3DXVECTOR2(recta.getOrigin().x + recta.getPosition().x, recta.getOrigin().y + recta.getPosition().y),
                                0.0f,
                                &D3DXVECTOR2(recta.getScale().x, recta.getScale().y),
                                &D3DXVECTOR2(recta.getOrigin().x + recta.getPosition().x, recta.getOrigin().y + recta.getPosition().y),
                                recta.getRotation(),
                                &D3DXVECTOR2(NULL, NULL));
                        this->m_device->SetTransform(D3DTS_WORLD, &(trans));
                        st::Vertex drawRect[] =
                        {
                                { m_x, m_y, 0.0f, clr, },
                                { m_x + m_width, m_y, 0.0f, clr, },
                                { m_x, m_y + m_height, 0.0f, clr, },
                                { m_x + m_width, m_y, 0.0f, clr, },
                                { m_x + m_width, m_y + m_height, 0.0f, clr, },
                                { m_x, m_y + m_height, 0.0f, clr, }
                        };
                        this->m_vBufferQuad->Lock(NULL, NULL, (void**)&pStored, NULL);
                        memcpy(pStored, drawRect, sizeof(drawRect));
                        this->m_vBufferQuad->Unlock();
                        this->m_device->SetStreamSource(NULL, this->m_vBufferQuad, NULL, sizeof(st::Vertex));
                        this->m_device->DrawPrimitive(D3DPT_TRIANGLELIST, 0, 2);
                }
        }
 
(I deleted all comments :P)
And there were two projects... Not all in one... Derp...
One used STFG and one SFML, I can post source for both projects if its rly needed...

What people seem to forget when comparing DirectX and OpenGL is that in the former case, you choose which API to use before writing even your first line of code. What happens if your library uses DirectX 11 and you have 10 year old hardware? Yeah... it doesn't work anymore. SFML will work on hardware that runs OpenGL 1.5 which dates all the way back to the last millenium. To make your comparison a bit more fair, you would have to make it use DirectX 7.
It's really easy to check if DirectX 9 or 10 or 11 or whatever is supported. :)

I don't see why not implementing DirectX as other beckend.
Sonkun is already working on an experimental DirectX implementation. Whether this is necessary is still up for discussion. The one advantage I can think of is enabling future support for platforms that are prevented from providing OpenGL support. Other than that, I don't see any real advantage DirectX would provide when OpenGL can be used as well.

Btw, it would be nice to have sf::Array in SFML System Module
Have you heard of the standard template library? In particular the containers library. Doing a bit of research before suggesting something that is already a language library feature helps sometimes...
You must be joking!!! (sarcastic, of course I know that...)
But this really is cool:

#ifndef STFG_ARRAY_H
#define STFG_ARRAY_H

#include <assert.h>

namespace st
{
        template <typename TYPE>
        class Array
        {
        public:
                Array()
                {
                        m_data = NULL;
                        m_size = 0;
                        m_maxSize = 0;
                }
                Array(const Array <TYPE>& a)
                {
                        for(int i = 0; i < a.m_size; i++)
                                this->add(a.m_data[i]);
                }
                ~Array()
                {
                        this->removeAll();
                }
                const TYPE& operator[](int nIndex) const
                {
                        return this->getAt(nIndex);
                }
                TYPE& operator[](int nIndex)
                {
                        return this->getAt(nIndex);
                }
                Array& operator=(const Array <TYPE>& a)
                {
                        if(this == &a)
                                return *this;
                        this->removeAll();
                        for(int i = 0; i < a.m_size; i++)
                                this->add( a.m_data[i] );
                        return *this;
                }
                HRESULT setSize(int nNewMaxSize)
                {
                        int nOldSize = m_size;
                        if(nOldSize > nNewMaxSize)
                        {
                                assert(m_data);
                                if(m_data)
                                {
                                        for(int i = nNewMaxSize; i < nOldSize; ++i)
                                                m_data[i].~TYPE();
                                }
                        }
                        HRESULT hr = this->setSizeInternal(nNewMaxSize);
                        if(nOldSize < nNewMaxSize)
                        {
                                assert(m_data);
                                if(m_data)
                                {
                                        for(int i = nOldSize; i < nNewMaxSize; ++i)
                                                ::new(&m_data[i]) TYPE;
                                }
                        }
                        return hr;
                }
                HRESULT add(const TYPE& value)
                {
                        HRESULT hr;
                        if(FAILED(hr = this->setSizeInternal(m_size + 1)))
                                return hr;
                        assert(m_data != NULL);
                        ::new(&m_data[m_size])TYPE;
                        m_data[m_size] = value;
                        ++m_size;
                        return S_OK;
                }
                HRESULT insert(int nIndex, const TYPE& value)
                {
                        HRESULT hr;
                        if(nIndex < 0 || nIndex > m_size )
                        {
                                assert(false);
                                return E_INVALIDARG;
                        }
                        if(FAILED(hr = this->setSizeInternal(m_size + 1)))
                                return hr;
                        MoveMemory(&m_data[nIndex + 1], &m_data[nIndex], sizeof(TYPE) * (m_size - nIndex));
                        ::new(&m_data[nIndex])TYPE;
                        m_data[nIndex] = value;
                        ++m_size;
                        return S_OK:
                }
                HRESULT setAt(int nIndex, const TYPE& value)
                {
                        //Validate arguments
                        if(nIndex < 0 || nIndex >= m_size )
                        {
                                assert(false);
                                return E_INVALIDARG;
                        }

                        m_data[nIndex] = value;
                        return S_OK;
                }
                TYPE& getAt(int nIndex) const
                {
                        assert(nIndex >= 0 && nIndex < m_size);
                        return m_data[nIndex];
                }
                int getSize() const
                {
                        return m_size;
                }
                TYPE* getData()
                {
                        return this->m_data;
                }
                bool contains(const TYPE& value)
                {
                        return (-1 != this->indexOf(value));
                }
                int indexOf(const TYPE& value)
                {
                        return (m_nSize > 0) ? this->indexOf(value, 0, m_nSize) : -1;
                }
                int indexOf(const TYPE& value, int iStart)
                {
                        return this->indexOf(value, iStart, m_size - iStart);
                }
                int indexOf(const TYPE& value, int nIndex, int nNumElements)
                {
                        if(iStart < 0 || iStart >= m_size || nNumElements < 0 || iStart + nNumElements > m_size)
                        {
                                assert(false);
                                return -1;
                        }
                        for(int i = iStart; i < (iStart + nNumElements); i++)
                        {
                                if(value == m_data[i])
                                        return i;
                        }
                        return -1;
                }
                int lastIndexOf(const TYPE& value)
                {
                        return (this->m_size > 0) ? this->lastIndexOf(value, m_nSize - 1, m_nSize) : -1;
                }
                int lastIndexOf(const TYPE& value, int nIndex)
                {
                        return this->lastIndexOf(value, nIndex, nIndex + 1);
                }
                int lastIndexOf(const TYPE& value, int nIndex, int nNumElements)
                {
                        if(iEnd < 0 || iEnd >= m_size || nNumElements < 0 || iEnd - nNumElements < 0)
                        {
                                assert(false);
                                return -1;
                        }
                        for(int i = iEnd; i > (iEnd - nNumElements); i--)
                        {
                                if(value == m_data[i])
                                        return i;
                        }
                        return -1;
                }
                HRESULT remove(int nIndex)
                {
                        if(nIndex < 0 || nIndex >= m_size)
                        {
                                assert(false);
                                return E_INVALIDARG;
                        }
                        m_data[nIndex].~TYPE();
                        MoveMemory(&m_data[nIndex], &m_data[nIndex + 1], sizeof(TYPE) * (m_size - (nIndex + 1)));
                        --m_size;
                        return S_OK;
                }
                void removeAll()
                {
                        this->setSize(0);
                }
                void reset()
                {
                        this->m_size = 0;
                }
        protected:
                TYPE* m_data;
                int m_size;
                int m_maxSize;
                HRESULT setSizeInternal(int nNewMaxSize)
                {
                        if(nNewMaxSize < 0 || (nNewMaxSize > INT_MAX / sizeof(TYPE)))
                        {
                                assert(false);
                                return E_INVALIDARG;
                        }
                        if(nNewMaxSize == 0)
                        {
                                if(m_data)
                                {
                                        free(m_data);
                                        m_data = NULL;
                                }
                                m_maxSize = 0;
                                m_size = 0;
                        }
                        else if(m_data == NULL || nNewMaxSize > m_maxSize)
                        {
                                int nGrowBy = (m_maxSize == 0) ? 16 : m_maxSize;
                                if((UINT)m_maxSize + (UINT)nGrowBy > (UINT)INT_MAX)
                                        nGrowBy = INT_MAX - m_maxSize;
                                nNewMaxSize = __max(nNewMaxSize, m_maxSize + nGrowBy);
                                if(sizeof(TYPE) > UINT_MAX / (UINT)nNewMaxSize)
                                        return E_INVALIDARG;
                                TYPE* pDataNew = (TYPE*)realloc(m_data, nNewMaxSize * sizeof(TYPE));
                                if(pDataNew == NULL)
                                        return E_OUTOFMEMORY;
                                m_data = pDataNew;
                                m_maxSize = nNewMaxSize;
                        }
                        return S_OK;
                }
        };
}

#endif //STFG_ARRAY_H
 
(Again I removed all comments)
This STFG_Array.h is actually made by my friend who is also in the STFG Team.

ChronicRat

  • Sr. Member
  • ****
  • Posts: 327
  • C++ programmer
    • View Profile
    • My blog
Re: SFML 3 - What is your vision?
« Reply #69 on: April 28, 2014, 09:16:48 pm »
But this really is cool:
This does not look cool. Well, for me. =)

Nexus

  • SFML Team
  • Hero Member
  • *****
  • Posts: 6286
  • Thor Developer
    • View Profile
    • Bromeon
Re: SFML 3 - What is your vision?
« Reply #70 on: April 28, 2014, 09:27:11 pm »
To be honest, that Array class is very badly abstracted -- it doesn't use existing containers, it is non-portable without a good reason, the used types are questionable (int for indices?), it works only for PODs thanks to the raw memory operations, it's not exception-safe (which is less important since we can't use it with classes anyway), it has no iterator support, and the overall implementation looks extremely complicated and error-prone for a dynamic array -- the most simple data structure ever.

Given the methods indexOf, removeAll, setAt, it looks like someone tried to port Java collections to C++ without understanding the latter's concepts. You should really take a look at the STL. std::vector is ten times more reusable, efficient and safe.
Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development:

Njifra

  • Guest
Re: SFML 3 - What is your vision?
« Reply #71 on: April 28, 2014, 09:32:53 pm »
Whatever you say
[EDIT] Deleted.
« Last Edit: April 28, 2014, 09:35:04 pm by Njifra »

Hiura

  • SFML Team
  • Hero Member
  • *****
  • Posts: 4321
    • View Profile
    • Email
Re: SFML 3 - What is your vision?
« Reply #72 on: April 28, 2014, 09:33:57 pm »
I guess it's also 10x faster than std::vector?

anyway, let's get back to the topic, shall we?  ;)
SFML / OS X developer

binary1248

  • SFML Team
  • Hero Member
  • *****
  • Posts: 1405
  • I am awesome.
    • View Profile
    • The server that really shouldn't be running
Re: SFML 3 - What is your vision?
« Reply #73 on: April 28, 2014, 09:56:24 pm »
void Window::draw(st::g2d::RectangleShape& recta)
{
...
}
 
This method is used only to draw a quad, with no textures, no support for binding shaders. If SFML wanted to write separate draw() methods for each and every possible scenario there would be more of them than all the other methods in RenderTarget put together. SFML is designed to be generic. Like I already predicted before, your code is optimized with certain use cases in mind and your benchmark is thus very very synthetic. I highly doubt you will get such a big performance difference in a real world scenario, let alone allow real world usage without having to duplicate code a lot more than is actually required if you tried to stay generic.

Another thing about the way you pass vertex data to DirectX is the fact that you already combine it all into a single buffer. SFML does not do this (yet). SFML passes separate data streams to OpenGL in their own calls which incurs a bit more overhead. This is just one of the many differences between your drawing and SFML's drawing. You can have a look at SFML's draw code to figure out why your lib probably runs much faster in scenarios such as these, but it is still no reason to mandate supporting DirectX purely for a performance increase.

It's really easy to check if DirectX 9 or 10 or 11 or whatever is supported. :)
It is less easy to restrain yourself to an ancient API version just to stay compatible with older hardware. The code you posted probably wouldn't work if you went ahead and made it compatible with DirectX 7 hardware like I suggested.

But this really is cool:

#ifndef STFG_ARRAY_H
#define STFG_ARRAY_H

#include <assert.h>

namespace st
{
        template <typename TYPE>
        class Array
        {
        ...
        };
}

#endif //STFG_ARRAY_H
 
std::vector is way cooler.

If your only intent is to suggest things to make SFML "more like your lib", then this thread probably isn't the right place to post. We care about providing facilities that benefit everyone, even the fans of std::vector. The burden of proof lies on you to show that your lib is usable to a wider audience before coming here and saying SFML should do things that your lib can and SFML can't. The first step of course, would be to make it public... but when that will happen, I don't know.

anyway, let's get back to the topic, shall we?  ;)
Agreed.
SFGUI # SFNUL # GLS # Wyrm <- Why do I waste my time on such a useless project? Because I am awesome (first meaning).

Njifra

  • Guest
Re: SFML 3 - What is your vision?
« Reply #74 on: April 28, 2014, 10:02:36 pm »
This method is used only to draw a quad, with no textures, no support for binding shaders. If SFML wanted to write separate draw() methods for each and every possible scenario there would be more of them than all the other methods in RenderTarget put together. SFML is designed to be generic. Like I already predicted before, your code is optimized with certain use cases in mind and your benchmark is thus very very synthetic. I highly doubt you will get such a big performance difference in a real world scenario, let alone allow real world usage without having to duplicate code a lot more than is actually required if you tried to stay generic.
There is already st::Drawable class. ;)

The first step of course, would be to make it public... but when that will happen, I don't know.
It will happen soon, currently I'm making 3D Shapes(already added cuboid, cylinder...)
After that I have to fix Sound module...
That's all!