I'm currently developing a GameEngine API/framework so far I have an OpenGL 4.6 context where I load all the functions by myself (no OpenGL wrapper). The Engine is still under heavy construction, but some 3D stuff is already possible. Now the Engine was targeted to primarily draw 3D objects, but I'm also considering 2D stuff (though I haven't started yet to implement it).
Right now I'm creating kind of a user interface framework (which can be used instead of the 3D or 2D engine and likewise) "like" MFC, WinForms... you name it. For that, I'm using Windows's OpenGL 1.1 implementation, and that's where we get to my actual question.
Is using such an old OpenGL, or any legacy OpenGL version, considered as a bad practice? I know this question may be opinion-based, but especially in my case, I think it's the easiest way to create reusable controls; besides from that it's super interesting to create controls like a button all by myself, you have to think about everything. And I don't think Microsoft will remove it soon from their API if so, this would mean, we wouldn't be able to get an OpenGL context at all if I'm not completely wrong on that.
Additional information:
The way people/I should use the framework is, you would need to choose one of the types, the Engine can provide, such as 3D, 2D or creating a "normal" user-interface.
The reason I choose Windows's OpenGL implementation for the user-interface is, that it would also be possible to create a user-interface for Windows XP.
I currently use functions like glBegin(), glEnd(), glVertex2f() and glColor3f() to draw a button and wglUseFontBitmaps(), glPushAttrib(), glListBase(), glCallLists(), glPopAttrib() to draw the text.
Regarding the OpenGL context, I use Nehe's way to get a context:
http://nehe.gamedev.net/tutorial/creating_an_opengl_window_(win32)/13001/
So for the user-interface, I don't use the 4.6 context but 1.1
Related
First off, let me just apologize right off the bat in case this is already answered, because I might just be searching it under irregular search terms.
I am looking to draw 2D graphics in an application that uses DirectX to draw its own graphics (A game). I will be doing that by injecting a DLL into the application (that part I have no questions about, I can do that), and drawing my graphics. But not being really good at DirectX/OpenGL, I have a couple of fundamental questions to ask.
1) In order to draw graphics on that window, will I need to get a pre-existing context from the process memory, some sort of handle to the drawing scene?
2) If the application uses DirectX, can I use OpenGL graphics on it?
Please let me know as to how I can approach this. Any details will be appreciated :-)
Thank you in advance.
Your approach in injecting an DLL is indeed the right way to go. Programs like FRAPS use the same approach. I can't tell you about the method for Direct3D, but for OpenGL you'd do about the following things:
First you must Hook into the functions wglMakeCurrent, glFinish and wglSwapBuffers of opengl32.dll so that your DLL notices when a OpenGL context is selected for drawing. Pass their calls through to the OS. When wglMakeCurrent is called use the function GetPixelFormat to find out if the window is double buffered or not. Also use the glGet… OpenGL calls to find out which version of OpenGL context you're dealing with. In case you have a legacy OpenGL context you must use different methods for drawing your overlay, than for a modern OpenGL-3 or later core context.
In case of a double buffered window use your Hook on wglSwapBuffers to perform further OpenGL drawing operations. OpenGL is just pens and brushes (in form of points, lines and triangles) drawing on a canvas. Then pass through the wglSawpBuffers call to make everything visible.
In case of a single buffered context instead of wglSwapBuffers the function to hook is glFinish.
Draw 2D with OpenGL is as simple as disable depth buffering and using an orthographic projection matrix. You can change OpenGL state whenever you desire to do so. Just make sure you restore everything into its original condition before you leave the hooks.
"1) In order to draw graphics on that window, will I need to get a pre-existing context from the process memory, some sort of handle to the drawing scene?"
Yes, you need to make sure your hooks catch the important context creation functions.
For example, all variations of CreateDevice in d3d are interesting to you.
You didn't mention which DirectX you are using, but there are some differences between the versions.
For example, At DirectX 9 you'd be mostly interested in functions that:
1. Create/return IDirect3DSwapChain9 objects
2. Create/return IDirect3DDevice9,IDirect3DDevice9Ex objects
In newer versions of DirectX their code was splitted into (mostly) Device, DeviceContext, & DXGI.
If you are on a "specific mission" share which directx version you are addressing.
Apart from catching all the needed objects to allow your own rendering, you also want to catch all presentation events ("SwapBuffers" in GL, "Present" in DX),
Because that's time that you want to add your overlay.
Since it seems that you are attempting to render an overlay on top of DX applications, allow me to warn you that making a truly generic solution (that works on all games) isn't easy.
mostly due to need to support different DX versions along with numerous ways to create
If you are focused on a specific game/application it is, naturally, much easier.
"2. If the application uses DirectX, can I use OpenGL graphics on it?"
Well, first of all yes. It's possible.
The terminology that you want to search for is OpenGL DirectX interoperability (or in short interop)
Here's an example:
https://sites.google.com/site/snippetsanddriblits/OpenglDxInterop
I don't know if the extension they used is only available in nVidia devices or not - check it.
Another thing about this is that you need a really good motivation in order to do it, generally I would simply stick with DX for both hooking and rendering.
I assume that internal interop between different DX version is better option.
I'd personally probably go with DirectX9 for your own rendering code.
Of course, if you only need to support a single DirectX version, no interop needed.
Bonus:
If you ever need to generate full wrappers of C++ classes, a quick n' dirty dll wrapper, or just general global function hook, feel free to use this lib that i created:
http://code.google.com/p/hookit/
It's far from a fully tested tool, just something i hacked 2 days, but I found it super useful.
Note that in your case, i recommend just to use VTable hooking, you'll probably have to hardcode the function offset into the table, but that's not likely to change.
Good luck :)
I know GLUT's quadrics, I used it in a few programs when I was in school. Now I'm working on a real world application and I find myself in need of drawing some geometric primitives (cubes, spheres, cylinders), but now I also know that GLUT is a no longer supported and it's last update was in like 2005. So I'm wondering if there's anything other than GLUT's quadrics to draw such geometric shapes. I'm asking if there's anything made before I go ahead and start making my own from vertices arrays.
Yes, you can! You can use the native API of the OS to create a window with OpenGL capabilities.
The advantage of GLUT is that is makes this task easier and is a cross-platform solution.
There are other cross-platform libraries that are more complex to work with but provide the same functionality, like Qt.
NeHe has a huge amount of examples that use several different technologies to accomplish what you are looking for. Check the bottom of the page.
Here is a demo for Windows that creates a window and draws a simple OpenGL triangle inside it. This demo removes all the window frame to give the impression that a triangle is floating on the screen. And here is a similar demo for Linux.
GLUT is just some conveniece framework that came to life way after OpenGL. The problem is not, that GLUT is unmaintained. The problem is, that GLUT was not and never will be meant for serious applications.
Then there's also GLU providing some primitives, but just as GLUT it's merely a companion library. You don't need either.
The way OpenGL works is, that you deliver it arrays of vertex attributes (position, color, normal, texture coordinates, etc.) and tell to draw a set of primitives (points, lines, triangles) from those attributes from a second array of indices referencing into the vertex attribute arrays.
There used to be the immediate mode in versions prior to OpenGL-3 core, but that got depreceated – good riddance. It's only use was for populating display lists which used to have a slight performance advantage if one was using indirect GLX. With VBOs (server (=GPU) side vertex attribute storage) that's no longer an issue.
While GLUT has not been maintained, FreeGLUT has. There are still several alternatives though.
GLFW is a cross-platform windowing system which is easy to get up and running, and also provides the programmer with control of the main application loop.
SFML has support for many languages and also integration capabilities with other windowing schemes, in addition to being cross-platform.
Finally, Qt is another, popular, cross-platform windowing framework.
Now I'm working on a real world application and I find myself in need of drawing some geometric primitives (cubes, spheres, cylinders),
Actually, I don't remember anything except glut that would provide generic primitives. This might have something to do with the fact that those generic primitives are very easy to implement from scratch.
You can use other libraries (libsdl, for example, or Qt) to initialize OpenGL, though.
Most likely if you find generic library for loading meshes (or anything that provides "Mesh" object), then it will have primtives.
is a no longer supported and it's last update was in like 2005
Contrary to popular belief, code doesn't rot and it doesn't get worse with time. No matter how many years ago it was written, if it still works, you can use it.
Also there is FreeGLUT project. Last update: 2012.
I'm writing an OpenGL game, and want native looking GUI elements. I was wondering if anyone has successfully hacked GTK+ using GtkOffscreenWindow and gtk_offscreen_window_get_pixbuf to render to an OpenGL texture, and whether this would have reasonable performance, considering repeated re-uploading of texture data every time the GUI is updated
While this is certainly possible, I'd instead use a real OpenGL widget toolkit like Clutter. If you want to render GTK+ with OpenGL, I'd start by creating a new GDK backend (X11/OpenGL or something like that), that (re-)implements all the GDK drawing functions using OpenGL. A nice side effect would be, that all GTK+ windows would allow for ordinary OpenGL rendering, too, i.e. no more need for a GtkGLWidget class.
Eventually, when I've finished the game I'm writing, I'd like to port it to XNA. I'm using C++ and OpenGL at the moment. My question is simply this: does XNA support OpenGL (I can switch from C++ to XNA language if need be)?
No, not directly. XNA is built upon DirectX.
You can spin off a separate window, using a wrapper around OpenGL if you want however. You'll need to use a unofficial binding though, in order to do this. Then use XNA constructs within this. I've worked on a project like this and wouldn't reccommend it. There are two ways to use XNA. The by the book approach, which is too limited for most, or the other way. The 'other' way being not making use of the base game classes and handling your own game logic. With the second approach using another rendering method is too much work for no real pay off.
I'd recommend that for your current game the logic and graphics are separate. If you do decide to port at a later date, the transfer should be easier to convert from C++ to C#.
Also, XNA is not a language. It's a framework built using C#.
The XnaTouch implementation runs on iPhone and so uses OpenGL ES under the hood. It uses C# via the Mono project (specifically MonoTouch for the iPhone). This could conceivably be used as a base to port XNA to other platforms that don't support DirectX (eg: Mac, Linux).
(Note: in my experience the XnaTouch implementation is not very good.)
Obviously the Xbox 360 doesn't use OpenGL at all - it uses DirectX - you don't get an option about this.
And I don't even understand why you'd want to use XNA, but with OpenGL under the covers, on Windows when the existing XNA implementation works just fine.
I want to make some simple 2d games/clones (for Mac), but I have a few questions:
Should I use Quartz 2d or OpenGL (I don't plan to try 3d anytime soon)
There seems to be a lot of typedef'd things like CGFloat/GLfloat, which should I use?
Should I use Objective-C for the game too (classes) or just C? (I assume I'll use Objective-C and Cocoa for window and views.)
Is it fine to redraw the entire view each time? I don't really understand how the NSView's -drawRect dirtyRect parameter works, how does it know what I want to update?
Are there any good tutorials for this?
Thanks.
Quartz or Core Animation vs. OpenGL really depends what you're trying to do. If you want simple drawing and animation, use Quartz or CA. If you want fast/powerful games, use OpenGL. Eventually I'd suggest learning both.
For the typedef'd things, use whichever is meant for the specific system you're using. For Quartz/CA/CG, use CGFloat. For OpenGL, use GLfloat.
Objective-C vs. C also depends on the speed you want. Objective-C adds a little bit of overhead but will (obviously) let you create much more object-oriented games. I'd suggest using Objective-C if you use Quartz and Core Animation, and either Obj-C or C if using OpenGL. However, if you're doing this on a Mac (e.g. not for iPhone), you probably won't see much difference unless you're doing complex fast drawing.
I'm not entirely sure about drawRect, but this question has some information which may answer that question for you.
For an intro to Quartz, I'd recommend this tutorial, and I've always heard the NeHe tutorials recommended for OpenGL.
If you use SDL with either Cairo or OpenGL, you get virtually the same programming model, but you get cross platform compatibility virtually for free. You should even be able to continue using objective C for the bulk of the game, if you want.
How graphically intensive do you want to get? Cairo will probably be easier to just get going with for 2D.