-
Notifications
You must be signed in to change notification settings - Fork 210
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SDL2 platform #239
base: master
Are you sure you want to change the base?
SDL2 platform #239
Conversation
} | ||
|
||
// 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); |
There was a problem hiding this comment.
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"); |
There was a problem hiding this comment.
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; |
There was a problem hiding this comment.
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); |
There was a problem hiding this comment.
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 #ifdef
s in the code to use BGR/RGB depending on the platform I don't see how to avoid it.
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!