I am developing a Mono/GTK# application. I need to have a "visualizer" that will display an opengl drawn area within the GTK# form. The two projects I have found myself don't seem to be maintained anymore,
http://sourceforge.net/projects/gtkglext/
and
http://sourceforge.net/projects/glwidget/
Do you know of any other projects that allow an OpenGL area within GTKSharp?
Alternatively, is there a better way to have an application use both opengl and GTKSharp?
I've never tried to use the GTK# integration, but OpenTK is by far the best OpenGL C# bindings I have ever used in C#. I highly recommend you look into it, and give the GTK# widget a shot.
I agree with Robert. I've been using OpenTK for a while and haven't had any major snags with it. Because of this, I would recommend glwidget.
Related
I'm Using the SDL library in C to learn some game dev , however i'm quite confused as to what SDL_RenderClear does and when do we use it. I did check the SDL documentation about the same , however i still wasn't able to understand where exactly we would use it and what is its use.
It's like rendering background color to color you have set via another API namely SDL_SetRenderDrawColor as you already found on documentation online.
Imagine you have rendered several things on screen. To begin again, you need to clear it to start over. Underlying of SDL_RenderClear wraps specific native platform your application runs on top, it can be OpenGL, DirectX, etc. It helps in communicating with such specific function that platform provides in order for you to flexibly clear your screen without a need to know low level functions, and use SDL2 for other things else like windowing, inputs from keyboard/mouse/joysticks, sound, and even utility functions related to rendering to aid your own rendering implementation.
To add a few more, SDL2 provides minimal but optimized rendering capability. SDL_RenderClear is one of those several functions you can use in rendering category. Anyway, you can decide to go on integrating with what you prefer i.e. OpenGL, DirectX, Vulkan etc. yourself.
As I mentioned in a question before, I am trying to make a simple game engine in C++ with OpenGL.
I am currently using GLFW for drawing the OpenGL context and I chose it because I heard it's one of the faster ones out there. However, it doesn't support widgets and I really don't want to write them myself. So I decided to get into Qt a bit, because it would allow me to have a pane for the render context and different handy bars as well as all the fancy elements for editing a world map, setting OpenGL rules, etc.
I want to use GLFW on the exported version of that game, though. Is that possible without an abstraction layer of some kind?
Thanks in advance! :)
Yes it is definitely possibile, infact I'm writing a 3D engine that is not coupled to any windowing library and can be used with Qt, SDL or whatever.
You of course have just to wrap regular GL calls into a higher level layer, this require you don't call "SwapBuffers" inside your GL code.
If by abstraction layer you mean "inversion of control" so, you don't want to override a "Render/Update" method that's exactly what I done. If by "abstraction layer" you mean you want to use GL directly than it is still possible.
Basically every windowing system have "some place" where you can make your GL calls (between MakeCurrent and SwapBuffers). Just read documentation of your windowing system.
I plan to embed an unmanaged C++ OpenGL viewer in WPF. The requirements are (apart from robustness and ease of development)
proper resizing
context menu for the OpenGL viewer area (only for viewer related actions)
events (e.g. triggered by selection of an object in the OpenGL viewer)
WPF dialogs should be drawn on top of the OpenGL space
So far I've found some blogs and discussions about using a hosted WinForm control (via C++/CLI wrapper), but it seems to be bit tricky (even a bit tinkery) to get all my above requirements done (if possible).
How about creating an ActiveX control? Despite having no experience with creating an ActiveX control, one advantage would already be that it runs in its own process.
Is it a good idea or would I run into even more tinkering?
EDIT: I should be clearer about the OpenGL viewer. It's an existing app based on an C++ 3D engine which only supports OpenGL. Porting to an DirectX capable engine is considered as last resort.
Although I didn't use ActiveX, I've accomplished what I believe you are trying to achieve. Two pieces of information helped me down this road.
Mixing Managed and Unmanaged code
It turns out, that managed C++ compiles completely differently than unmanaged C++, and data is stored on a completely different heap. Luckily you can mark sections of code as managed or unmanaged by using...
#pragma managed
#pragma unmanaged
See more info at this article
OpenGL context management
I followed a method similar to what's described in this article
wglMakeCurrent and wglShareLists will be your buddy if you need to manage multiple OpenGL windows
Good Luck!
Why you want an activex? There is some managed PInvoke based wrappers as SharpGL doing the job you need easyear.
But also, since you are using WPF and you have a Viewport3d object,why don't use it? If you are familiar with 3d engines you will appreciate the semplicity ( even if there is some drawback in term of speed).
Another point, since as per this question here I was forced to abandon WPF 3d rendering in favor of OpenGl due to the fact that Opengl can render in session 0, by using pure software mode. This is a requirement if you are planning to render something in off-screen bitmaps from a service or an asp.net application.
As a hobby, I've been working on remaking an old video game, and I want to avoid reinventing the wheel where possible. The game is heavily GUI-based, but the GUI needs to be customized in terms of look-and-feel, and also needs to work with 3D OpenGL rendering for a few game screens.
To give you an idea, here's a screenshot from the initial prototype:
There's a lot of animation used, and 3D also, but the GUI widgets behave much the same as in a standard desktop application.
Thus far, I've been using my own GUI library (it's not robust or complete, and I've been running into some problems).
I've been considering migrating to Qt given it's reputation and impressive features, and some of the nice screenshots on the Qt website. But I've never used Qt before, so I don't really have an idea of what it's capable of, or what kind of time investment would be required to learn it. (Note I've used FLTK).
My question is: would it be possible / practical to use Qt in this situation?
UPDATE: After mocking up some game screens in Qt, I've decided not to use it. While it supports many of the features I need out-of-the-box (particularly through Style Sheets), I need to support custom bitmap-based pre-rendered fonts (I can't convert/replace them). And I can't subclass QFont, or reimplement it without it breaking in future Qt releases. That said, I was extremely impressed with Qt (both in its ease of use, and good documentation). I will be borrowing some of its features for my own engine. Thank you to all who provided input.
It's hard to know everything your game needs to do based on a screenshot; however, I will echo the sentiments of other posters here and provide a couple of avenues for you to look at.
One, is that you might want to consider QtQuick over the GraphicsView Framework, but this REALLY depends on what you need to do. I just want to throw it out there as an alternative so you don't miss it. This tutorial uses QtQuick to put together a really slick looking connect four style game. This may be more simplistic than what you want to go for, but then again, maybe it isn't, it depends on what you need to do.
Second, before writing custom paint events for all of your buttons, I would consider using Qt Style Sheets and style your widgets in a CSS like syntax. This will allow you to change the look and feel of your GUI in a very flexible way really quickly. Based on your screenshot, I think you can get what you want out of style sheets much faster than subclassing and rolling your own setup. But once again, it's hard to know based on one screenshot. Here's an example of a dark and orange GUI that was implemented using only Qt Style Sheets. The border-radius property of QPushButton's style sheet would give you the rounded buttons (ref).
The simple answer has been given above but to throw some more thoughts in: yes it's possible, you probably won't need to fight against Qt too much. For the most part the recommended advice for going to heavily customised widgets like that is subclass and implemented the paint event yourself.
You can then use a load of basic drawing primitives to get the basic shapes for the elements and expand from there. There's actually a couple of questions on here with really good resources about how to do it.
I have been using a few cross-platform GUI libraries (such as FLTK, wxWidgets, GTK++), however I feel like none fulfil my needs as I would like to create something that looks the same regardless of the platform (I understand that there will be people against building GUI's that don't have a native look on the platforms but that's not the issue here).
To build my controls, I usually rely on basic shapes provided by the library and make my way up binding & coding everything together...
So I decided to give it a try and do some opengl for 2D GUI programming (as it would still be cross-platform. With that in mind, I couldn't help to notice that the applications that I have written using wxWidgets & FLTK usually have a average RAM consume of 1/2MB, whereas a very basic openGL window with a simple background ranges from 6 to 9 MB.
This brings me to the actual question for this thread,
I thought that all the rendering of the screen was made using either opengl/direct (under the covers).
Could someone please explain or link me some sort of article that could give me some insight of how these things actually work?
Thanks for reading!
These multiplatform toolkits usually support quite a lot of backends which does the drawing. Even though some of the toolkits support OpenGL as their backend, the default is usually the "native" backend.
Take a look eg. at Qt. On Windows it uses GDI for drawing for its native backend. On linux it uses XRender I think. Same on Symbian and Mac. Qt also has its own software rasterizer. And of course there is an OpenGL backend.
So why the application using some of these GUI toolkits can take less memory than a simple OpenGL application? If the toolkit use the "native" backend, everything is already loaded in memory, because it is very likely that all visible GUI uses the same drawing API. The native APIs can also use only one buffer representing a whole screen in which all applications can draw.
However when using OpenGL you have your own buffer which represents the application window. Not to mention that an OpenGL application usually has several framebuffers, like z-buffer, stencil buffer, back buffer, which are not essential for 2D drawing, but they take some space (even though its probably the space in graphics card memory). Finally, when using OpenGL, it is possible that the necessary libraries are not yet loaded.
Your question is exceedingly vague, but it seems like you're asking about why your GL app takes up more memory than a basic GUI window.
It's because it's an OpenGL application. This means it has to store all of the machinery needed to make OpenGL work. It means it needs a hefty-sized framebuffer: back buffer, z-buffer, etc. It needs a lot of boilerplate to function.
Really, I wouldn't worry about it. It's something every application does.