Skip to content

Conversation

@Arcnor
Copy link
Contributor

@Arcnor Arcnor commented Jul 10, 2022

Hi there!

This is a new platform for MyGUI using SDL2. It requires SDL >= 2.0.18 because that's the version that added the required API for this to actually work (direct geometry rendering).

There are some issues that can hopefully be worked out before merging, I'll add some comments inline.

I have another platform in the works (for BGFX) but I'll finish that one once we finish merging this one, as I think some of the issues will be present there as well.

I hope this is useful, and thanks!

}

// TODO: Why do we need this? We need to understand why SubSkin::doRender() multiplies the size of the quad by 2
// SDL_RenderSetScale(mRenderer, 0.5, 0.5);
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is the main issue with the platform. I wrote this many months ago, so I don't remember the details, but basically, without scaling the SDL2 output, it appears wrong (too big). I've removed this in the meantime because by enabling HiDPI support in SdlManager.cpp and passing the real framebuffer size this gets mitigated somehow.

However, there are 2 issues with this:

  • I'm almost sure this will look wrong on a non HiDPI system (although I don't actually have any to compare, sad but true :D).
  • There is actually no HiDPI rendering, it looks exactly like a non-HiDPI one but it requires 2x the pixels to look right, which obviously means there is an issue somewhere.

To see the problem, just compile this branch without the changes in SdlBaseManager.cpp.

void BaseManager::resizeRender(int _width, int _height)
{
// TODO: Maybe we need to resize the renderer?
printf("Resized\n");
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  • I actually need to verify if SDL2 takes care of this automatically or we actually need to manually do it

newFormat = SDL_PIXELFORMAT_RGBA32;
break;
case 3:
newFormat = SDL_PIXELFORMAT_RGB24;
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Texture loading is done in RGB but manual texture creation is done in BGR (it seems MyGUI uses BGR for color processing?) so this probably needs changing to adapt to that as well.

auto &vertex = mVertices[j];
auto &otherVertex = mInternalData[j];
vertex.position = {otherVertex.x, -otherVertex.y};
*(uint32_t*)&vertex.color = fromBGRA(otherVertex.colour);
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It will be nice if we didn't have to do this, but other than adding some #ifdefs in the code to use BGR/RGB depending on the platform I don't see how to avoid it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant