Skip to content
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

DX11 support #23

Open
tekgoblin opened this issue Mar 27, 2019 · 6 comments
Open

DX11 support #23

tekgoblin opened this issue Mar 27, 2019 · 6 comments

Comments

@tekgoblin
Copy link
Contributor

tekgoblin commented Mar 27, 2019

DX11 requires every window to have it's own swap chain. #10 may not the right place for it. We could convert windows to handles (unsigned int) and store windows in the context along side driver specific info like the swapchains that could also use this handle to lookup the swapchain of that window. In sdl2_input_provider.h we could also replace the sdlOpenGLCtx with a struct that would contain all the driver specific info and pass that off to the driver to allow specific info like this to be stored/managed. Reusing makecurrent would be able to handle setting the swapchain correctly for both drivers this way as well. You can assign this one to me if you like since I'm already working that out. Right now it's working but only for the main window and I added a global disable for detaching windows atm. We could also just allow a Window struct to store specific data like this and forget a handle, the driver would know it's data stored in the window itself. I would rather go that route. Any thoughts?

@nekitu
Copy link
Contributor

nekitu commented Mar 27, 2019

The library was meant for GL, because I use only that for my projects, Vulkan and DX11+ are a bit more involved to set up, but I will make the necessary changes so the lib and SDL2 provider will enable usage of any graphics backend. Thanks. Btw there is a function that disables undocking to outside native windows, will allow only main window docking: HORUS_API void setAllowUndockingToNewWindow(bool allow); I will probably put it in the context settings as a bool.

@nekitu
Copy link
Contributor

nekitu commented Mar 27, 2019

I have added a SdlWindowProxy struct where SDL_Window* is kept, and acts like a Window handle. You can add any data in the proxy struct, also check the sdl2_input_provider.cpp for the "DX11" string, it has some comments where to add the DX11 swapchain code for init and delete for each newly created window. I presume you have to create the DX11 windows manually. Btw, out of curiosity, why don't you use dear-imgui ? :)

@tekgoblin
Copy link
Contributor Author

tekgoblin commented Mar 27, 2019

That's fine, I don't want to push anything onto it you don't want / need.. I can always keep a branch locally for that. About imgui: I just don't like imgui period. The api for this matches more of my thoughts more, so like attracts like in that case. With DX11 you just need to be able to get the windows os level info to create a swapchain on a window. Much like in gl when you create a context on the window. Difference is GL doesn't technically require a program owned windows to init. I saw the setAllowUndockingToNewWindow earlier before running out lol. Thanks.

@nekitu
Copy link
Contributor

nekitu commented Mar 27, 2019

setAllowUndockingToNewWindow was deleted. Now you can do: hui::getContextSettings().allowUndockingToNewWindow = false; when you don't want to allow undocking.
Ideally the inner panes would be also native child windows, but SDL2 doesn't really support child windows and I think neither SFML. That would help a bit with speed, for example you can update a viewport at a greater fps than the UI, but its a lot of work to basically create a cross platform windowing system for it, and I don't really want to extend SDL2's core code for that... If you check Unity3D they have that, child windows for all panes. I will try to work on it as much as I can, it is an old dream of mine for a proper professional looking cross platform UI system for tool making. Dear-imgui I didnt liked because it has limited theming support, it looks like what it is, a debug UI, plus it feels a bit too bloated in some areas, so I decided to make my own imgui lib. There is a lot of cleaning, documenting. bugs and features to come, so bare that in mind when integrating/extending :).

@tekgoblin
Copy link
Contributor Author

tekgoblin commented Mar 27, 2019

Well I have an opengl retained mode ui I wrote a while ago I was going to fallback on, but wanted to give this a try. That's where I added timing info and it's not bad actually, in it's current state. If you're going to go on the deep dive for native window support beneath it all check out final_game_tech. Just one avenue that could help shortcut if you like. I personally just didn't want to have to dust off my old ui and update it. I would just make one widget/pane type for the native window besides a default panel because that's all that's really needed and keeps the memory lower and used where it would only need to be used.

@nekitu
Copy link
Contributor

nekitu commented Jun 15, 2019

Your remake utility lib is not taking into account that for gcc the linked libraries need to be in a certain order for the static linking of libs. "A library which calls an external function defined in another library should appear before the library containing the function.", you may want to look into that, also it has a problem when creating the /bin folder and copy to it the final exes. Just checkout and verify it in Ubuntu.

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

No branches or pull requests

2 participants