Jump to content

  • Log In with Google      Sign In   
  • Create Account

AlanWu

Member Since 03 Dec 2012
Offline Last Active Aug 15 2015 02:09 AM

Posts I've Made

In Topic: Is OpenGL enough or should I also support DirectX?

16 July 2015 - 12:09 AM

Back to the OP - if I was starting a project right now that had to run everywhere, I would make a renderer with two bavk-ends initially: D3D11 using feature level 9_x, and a port of that back-end to the actual D3D9c API (avoiding all the fixed function parts, and sticking to shader model 2).

Why? Because D3D9 runs on Windows from XP onwards, and Linux via Wine. D3D9 can also be zero-effort ported to GL2 by using toGL, which gets you mac and native linux (that's how Valve ported their Source games). D3D11_FL_9 will run really efficiently and be really stable on modern versions of Windows, plus makes for a great developer environment with good tool support. And lastly, shader model 2 shader code will run on every GPU you care about.
The only missing piece ie you'll later have to write your own gl|ES port.

Microsoft constantly obsoletes its own APIs as well, so really it is a poor decision for anyone who is not part of a big company to bother with using it.

You will be able to use vulkan on windows systems, so really there will be no point to DirectX any more

MS releases new D3D versions on roughly the same schedule as new GL versions appear. D3D9~=GL2, D3D10~=GL3, D3D11~=GL4, D3D12~=Vulkan.
All those old APIs still work fine, despite being obsolete/deprecated.

You can already use GL on Windows systems (Vulkan is basically just GL5), so there should already be no point to DirectX any more... Right?

 

Good idea. However, if I use toGL to change my D3D9 codes into OpenGL, will there be a big drop in performance?


In Topic: Is OpenGL enough or should I also support DirectX?

16 July 2015 - 12:08 AM

I can tell you my experience:

 

I thought that supporting OpenGL would be enough. It wasn't. But it depends on what you want to aim. Our goal was to keep compatibility with DX10 hardware while still taking advantage of DX11/12 hardware features.

 

There are several reasons GL only approach didn't work for us:

  1. Both NV & AMD stopped shipping drivers for anything below GeForce 400 / Radeon HD 5000. Their OpenGL driver versions are outdated (specially AMD's which cut off driver support 6 months sooner than NV); and if they've got a bug or don't support a specific extension you need (even extensions that would normally work on DX10 hardware); don't hope they will get fixed or added in a later release. In contrast, D3D drivers have been historically been more stable, more thoroughly tested and feature complete. As a result, supporting these cards via D3D is easy.
  2. Intel GL drivers sucked for a very long time, and their definition of "old hardware" is anything they shipped older than 1 year. Technically that's the same problem as NV & AMD just aggravated. But GL drivers have only become decent for Intel HD 4400 and newer (in a driver release that was literally... just a few months ago), some of these cards are DX11 level hardware (not just DX10) and Intel's market share is so large and their deprecation is so strict and narrow that it deserves its own point.
  3. There are so many variables that come into play, that sometimes D3D will get you higher performance, and sometimes OpenGL will get you higher performance. It depends on the driver, GPU involved, API calls you've made, and shader syntax you've used. Supporting both lets your users decide which one runs better for them.

 

Of course this is all about your particular case. If you don't have the resources (time) or don't feel you're experienced enough to support both APIs at the same time; or you only care about bleeding edge hardware and software; then you can focus your efforts into just one API.

Thank you for replying. So apparently drivers is an issue. 


In Topic: Using OpenGL/DirectX to build GUI

20 June 2015 - 04:59 PM

 


What I meant by child windows are window components like buttons and edit box(they're child windows in MFC). I personally think it's better just to render the components, instead of creating child windows for them. Actually, what is point of that? That allows other programs to easily analyze my GUI. What do you think?

 

As I said, I think it is perfectly fine to render buttons, etc.. directly instead of creating seperate window elements for them. I wouldn't worry about the other way around though, whats the problem with programs analyzing your UI? The one advantage over having seperate windows is if you really have a window that pops up, like an asset editor, and you want the user to be able to tab between it and your editor. THEN is the time to pop up a seperate window.

 

But again, if you are planning on using this for an editor, I once again like to urge my opinion: DON'T. I did it myself, and its a path of no joy. Do you want to do this as a learning experience? Thats is fine, in this case keep going. Do you want to be productive and create a future-rich editor in no time? Then stop with this approach, and just get Qt. You'll have most of your editor in like 6 months compared to 2 years of pain. I did this myself, and yeah, I still to this day sometimes cringe over the bugs and flaws of the UI system, and having to write a new sort of advanced widget type is always a pain (next up would be allowing windows to be reinserted into the docking structures for me, ugh). Don't worry about factors like external applications being able to analyze your UI then, its a non-issue, since literally every other UI application is built that way, only very few do their UIs themselfes (Unreal Engine it appears, but their manpower/knowledge behind this is also much better).

 

 

 


Are there any disadvantage if I use OpenGL to make GUI for editors/tools? I think the two disadvantages I mentioned above are not really disadvantages. What do you guys think?

 

To put more emphasise on it, the main disadvantage is that its awefully unproductive, even if you need to learn QT, its like 4-16 times faster. Learning a QT widget is like maximum of few hours of reading the (good) documentary and trying it out, writing the same widget can take days, and you'll spend even more time fixing bugs, and polishing. Again, if you are in for the learning experience, its fine, but don't expect to gain anything from doing it other than that.

 

 

 


What I meant by screenshot is the case when other programs try to screenshot my GUI, such as remote desktop. Some of those program uses GDI to screenshot so..

 

I still don't think you have to worry about this. Remote desktop manages to capture all 3D game applications so far (I once was foolish enough to try playing highend games over the internet on my phone, lol). The point is, its regardless of what those applications use, they will most likely capture the content of the framebuffer, and don't even care what application is visible, so you don't need to care eigther. If in doubt, try it. Just render a colored quad in OpenGL and pop in your target capturing program, and see if it works (it should).

 

Thank you very much for your full and detailed answer. I'll consider about that! :)


In Topic: Using OpenGL/DirectX to build GUI

19 June 2015 - 08:39 PM

What are your plans for using this UI? Do you want to use it for ingame UIs, or for editors/tools? I'm asking since you are talking about "child windows". For a game, it is indeed tolerable, if not wanted, to not have a seperate window if ie. an options menu pops up. Imagine this would be a seperate window, you'd have to tab around to get back to your regular game. For editors, its usually wanted/preferred to have a seperate window pop up when you e.g. open an asset editing window. You can bypass this by creating a seperate OS window in this case, with a seperate DirectX-device, and rendering to this instead, if it ever becomes an issue, so this should not be a showstopper. However, if you are planning on really using this for editor-like applications and not for ingame graphics, I'd strongly suggest you use an already existing libary like QT, since the complexity required for building a custom-rendered UI capable of simulating all the widgets needed for editors (window docks, tables, trees, ...) is overwhelming. For ingame UIs, there is nothing wrong with writing the UI renderer yourself, and in this case you should not have an issue with that everything is "one element" and cannot be inspected from outside.

 

Regarding the screenshot problem, I can't really follow. Whats the issue again? I have no problem making screenshots of my own DX/OpenGL-renderer UI. In fact if this was a problem than screenshotting wouldn't work in games at all, which it does 100% of the time. Well thinking about it, I think OpenGL on windows didn't work, but thats a different story... you don't need to fallback to GDI in that case eigther, since you can always just capture the content of the backbuffer at the end of thre frame and output that, just search for the different ways this can be done via google.

Thank you for replying.

I am planning for editors/tools. I guess I didn't express what I meant clear enough, sorry about that.

What I meant by child windows are window components like buttons and edit box(they're child windows in MFC). I personally think it's better just to render the components, instead of creating child windows for them. Actually, what is point of that? That allows other programs to easily analyze my GUI. What do you think?

What I meant by screenshot is the case when other programs try to screenshot my GUI, such as remote desktop. Some of those program uses GDI to screenshot so..

 

Are there any disadvantage if I use OpenGL to make GUI for editors/tools? I think the two disadvantages I mentioned above are not really disadvantages. What do you guys think?


In Topic: Is OpenGL enough or should I also support DirectX?

18 June 2015 - 11:49 PM

Thank you guys very much. I now know what I need to do.

I've never used OpenGL and it seems I need to do much more work with it than if I use DirectX. Since I want to support old computers, I might go with OpenGL 2.1. I'll decide that later. smile.png


PARTNERS