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

Author Topic: New graphics API ready  (Read 92452 times)

0 Members and 4 Guests are viewing this topic.

Contadotempo

  • Full Member
  • ***
  • Posts: 167
  • Firelink Shrine
    • View Profile
New graphics API ready
« Reply #165 on: December 30, 2011, 09:17:12 am »
Quote from: "Laurent"

Quote
Hi, since I've been using the new API I can't execute SFML applications on my laptop.

Make sure that you made a complete recompile.

I did. Both SFML and every SFML related project. Strangely, the same applications compiled on the laptop work on another computer with an ATI card but not on the laptop. I'm guessing it's an Intel driver problem but no idea how to fix it. Any ideas?

Thanks in advance  :)

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32498
    • View Profile
    • SFML's website
    • Email
New graphics API ready
« Reply #166 on: December 30, 2011, 09:34:18 am »
Which line triggers the null call in RenderTarget::ResetGLStates()?
Is there any message in the console?
Laurent Gomila - SFML developer

Mario

  • SFML Team
  • Hero Member
  • *****
  • Posts: 879
    • View Profile
New graphics API ready
« Reply #167 on: December 30, 2011, 11:13:23 am »
Tracked down the thread creation. It indeed happens outside SFML and for whatever reason calls to "joyGetPosEx()" with an index higher than the first joystick/gamepad spawn 2-3 threads (I've got a wired Xbox 360 controller connected as well as a wireless receiver (Xbox360 too) with no active controller). It sometimes stops after some seconds. Disconnecting the gamepad and the receiver didn't change anything, though.

Edit: It's something caused by my system's openal32.dll. If I copy the one from the SFML2 repository to my working dir, the issue is gone. So still something in the X-Fi drivers which influences all OpenAL usage for whatever reason.

Contadotempo

  • Full Member
  • ***
  • Posts: 167
  • Firelink Shrine
    • View Profile
New graphics API ready
« Reply #168 on: December 31, 2011, 05:30:36 am »
Quote from: "Laurent"
Which line triggers the null call in RenderTarget::ResetGLStates()?
Is there any message in the console?

I was actually compiling in release when I posted that call stack, my mistake. When debugging I get the same error but a slightly different call stack:


I think it's line 274 on myCache.UseVertexCache = false;
There aren't any messages on the console.
I also didn't mention but I'm compiling with the static libs.

Tank

  • SFML Team
  • Hero Member
  • *****
  • Posts: 1486
    • View Profile
    • Blog
    • Email
New graphics API ready
« Reply #169 on: December 31, 2011, 09:20:58 am »
Quote
And if I change the implementation to be GL 2.0 (shaders only) soon, I'll probably be able to put the global color back.

That catched my attention. Can you provide details?

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32498
    • View Profile
    • SFML's website
    • Email
New graphics API ready
« Reply #170 on: December 31, 2011, 11:44:17 am »
Quote
I was actually compiling in release when I posted that call stack, my mistake. When debugging I get the same error but a slightly different call stack

Thanks. Can you try again with the latest revision?

Quote
That catched my attention. Can you provide details?

About the GL 2.0 implementation, or the ability to provide the global color with it?
Laurent Gomila - SFML developer

Tank

  • SFML Team
  • Hero Member
  • *****
  • Posts: 1486
    • View Profile
    • Blog
    • Email
New graphics API ready
« Reply #171 on: December 31, 2011, 02:30:13 pm »
Quote from: "Laurent"
About the GL 2.0 implementation, or the ability to provide the global color with it?

Both. ;)

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32498
    • View Profile
    • SFML's website
    • Email
New graphics API ready
« Reply #172 on: December 31, 2011, 03:48:39 pm »
In order to port SFML to mobile platforms, it needs to support OpenGL ES 2.0, which is shader only (it doesn't support the FFP at all). So eventually I'll switch to a shader only rendering architecture.

And if I use shaders, I can basically do whatever I want, especially add a global color ;)
Laurent Gomila - SFML developer

Contadotempo

  • Full Member
  • ***
  • Posts: 167
  • Firelink Shrine
    • View Profile
New graphics API ready
« Reply #173 on: December 31, 2011, 07:01:50 pm »
Quote from: "Laurent"
Quote
I was actually compiling in release when I posted that call stack, my mistake. When debugging I get the same error but a slightly different call stack

Thanks. Can you try again with the latest revision?


It works! Thank you!   :)

Mario

  • SFML Team
  • Hero Member
  • *****
  • Posts: 879
    • View Profile
New graphics API ready
« Reply #174 on: January 02, 2012, 05:11:38 pm »
Looking a bit over internal sf::Color and sf::Texture related code, I noticed that there are quite some assignments and comparisons done byte by byte.

How about storing the value of sf::Color in a union, while having references providing backwards compatibility and easier access? Especially considering the fact sf::Color uses unsigned byte instead of float.

Essentially something like this:
Code: [Select]
public:
Uint32 &rgba;
Uint8 &r;
Uint8 &g;
Uint8 &b;
Uint8 &a;

private:
union _data
{
    Uint32 rgba;
    struct _components {
        Uint8 r;
        Uint8 g;
        Uint8 b;
        Uint8 a;
    } components;
} data;


This could simplify quite some code (not sure how far this would be optimized by modern compilers).

Current code (color comparison):
Code: [Select]
bool operator ==(const Color& left, const Color& right)
{
    return (left.r == right.r) &&
           (left.g == right.g) &&
           (left.b == right.b) &&
           (left.a == right.a);
}

New code:
Code: [Select]
bool operator ==(const Color& left, const Color& right)
{
    return left.rgba == right.rgba;
}


Current code (creating an image of a given color):
Code: [Select]
   Uint8* ptr = &myPixels[0];
    Uint8* end = ptr + myPixels.size();
    while (ptr < end)
    {
        *ptr++ = color.r;
        *ptr++ = color.g;
        *ptr++ = color.b;
        *ptr++ = color.a;
    }


New code:
Code: [Select]
   Uint32* ptr = (Uint32*)&myPixels[0];
    Uint32* end = ptr + myPixels.size();
    while (ptr < end)
        *ptr++ = color.rgba;


There's still the issue of byte order, but this could be handled changing the order of the struct members (to ensure rgba has the right content).

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32498
    • View Profile
    • SFML's website
    • Email
New graphics API ready
« Reply #175 on: January 02, 2012, 06:59:12 pm »
There's absolutely no point to optimize this part of the code. I don't want to write ugly code for no gain, I prefer spending my time optimizing the real bottlenecks in SFML. Sorry ;)
Laurent Gomila - SFML developer

Lee R

  • Jr. Member
  • **
  • Posts: 86
    • View Profile
New graphics API ready
« Reply #176 on: January 02, 2012, 08:43:34 pm »
I'm not even sure if I'd call it an optimization at all. A few points off the top of my head:

The added reference members increase the Color class' size by 20 bytes assuming 32 bit references, 40 bytes assuming 64-bit references. That is a potential 10x size penalty without even mentioning padding.

Accessing a reference member may incur an indirection (depending on the optimizer).

Copy construction and copy assignment become non-trivial (in the standard sense).

The last "New code" example breaks strict aliasing rules, invoking undefined behaviour (I'm ignoring the issue of union type punning, due to widespread compiler support).

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32498
    • View Profile
    • SFML's website
    • Email
New graphics API ready
« Reply #177 on: January 02, 2012, 08:54:40 pm »
Quote
The added reference members increase the Color class' size by 20 bytes assuming 32 bit references, 40 bytes assuming 64-bit references. That is a potential 10x size penalty without even mentioning padding.

And that makes sf::Color unusable in sf::Vertex, which assumes a strict memory layout.
Laurent Gomila - SFML developer

Mario

  • SFML Team
  • Hero Member
  • *****
  • Posts: 879
    • View Profile
New graphics API ready
« Reply #178 on: January 02, 2012, 09:42:33 pm »
Yeah, okay, forgot about that overhead while adding the references (booh!). :)

Mikademus

  • Newbie
  • *
  • Posts: 31
    • View Profile
New graphics API ready
« Reply #179 on: January 03, 2012, 07:18:08 pm »
The references besides, the union layout seems spot-on. Just put it in public access. There have been some times I could have used an rgba member directly, and a layout like that (but with public members and sans the references) would both be an interface improvement and would allow the writing of more efficient low-level code for those that have a need for such. Also, it serves to document the colour component layout in code, the value of which shouldn't be underestimated.

 

anything