I created a Visual C++ Project as win32 console setting, and I made a triangle successfully.
I'm using Visual studio 2010.
I wonder why there is no glOrthof function but only glOrtho function.
Is that an OpenGL version matter?
I used to use glOrthof function when I developed a game on the Android platform.
In OpenGL you only have the one version of glOrtho, the one taking floating point values. In Open GL ES there are two versions, one taking floats (glOrthof / GLfloat) and one taking fixeds (glOrthox / GLfixed).
One might argu that glOrtho in OpenGL should have the possibility to also use GLdouble, but since glOrtho orgins from back in time when only floats where used and today its depricated/removed there I see no reason to implement that.
Related
I am converting my OpenGL engine to DirectX11. I used GLM in OpenGL, and will continue in Directx if possible. One problem I have however is constructing the perspective matrix using the glm::perspective
OpenGL maps [-1, 1] whereas DirectX maps [0, 1]. Is there any easy fix for this? I'd rather not switch math library just because of this.
See this http://msdn.microsoft.com/en-us/library/windows/desktop/bb205350(v=vs.85).aspx This is a built in function for Direct3D/X for constructing the matrix
You either use DirectXMath's XMMatrixPerspectiveFovRH (for right-handed view systems) or XMMatrixPerspectiveFovLH (for left-handed setups). With the Direct3D 9 legacy fixed-function pipeline you have to use LH. For programmable shaders, it's up to you by DirectX apps are often LH, while OpenGL apps are often RH. See the DirectXMath programmer's guide for more on this.
If using the legacy DirectX SDK without the Windows 8.0 SDK or Windows 8.1 SDK, you can make use of XNAMath which is very similar to DirectXMath.
I have been working on a small hobby project for over a year now. Its written in C++, using SDL/Image/Mixer and Minizip. It uses OpenGL for rendering.
Till July of this year I had been maintaining and testing both x64 and x86 versions of the code. Both compiled without any changes to the original code and ran exactly the same.
However, around August i moved the code upto SDL 2.0 from 1.2.15 and started only maintaining and testing the x64 version. Now when i try to build a x86 version I am getting the below problem.
Correct Output
Incorrect Output
-
Things I have tried:
gDebugger: both version of the code create the same type of context.
However accumulate buffer is 64 bits in both. Cannot find a way to
disable it.
ran it through drmemory: no alarming memory or heap corruption
check contexts on creation: both version create the same value
context in SDL, both generate the same "No OpenGL context has been
made current" even after calling SDL_GL_MakeCurrent, but the x64
version works, the x86 debug version gives a black screen, and the
x86 release version gives the above output.
Both the x64 and x86 version are the same exact code, which used to compile and work properly before SDL 2.0. I am not sure if its a bug in SDL, or something i did wrong. Let me if you need more information on this.
Update:
I am using pure GL 1.1 code only, so no shaders or vbo's. Using only glVertexPointer, and associated glColorPointer and glTexCoordPointer functions. all arrays are defined as GL_types, with the gl functions given the pointer to the client memory. All textures are rendered as quads.
GLfloat vertex_array_3f[12];
//Initialize array
glVertexPointer(3, GL_FLOAT, 0, vertex_array_3f);
//set color and tex pointers
glDrawArrays(GL_QUADS, 0, 4);
The context type I am requesting is 2.1, but instead i get a backward compatible context. Doesnt cause any issues in the x64 version.
I also changed over the from VS2010 express to VS2012 express during the same period. But i do remember it compiling succesfully for x86 for VS2012 express.
edit: Has any one experience anything like this before? I am doing some testing in the meanwhile, if i find anything will post the findings below.
I'm creating a simple computer games framework using SDL, and am still deciding between using SDL's software renderer (Which is also much easier to use than OpenGL), or the supposedly faster OpenGL, despite the fact that in Visual Studio 2008 I'm having troubles linking the OpenGL libraries. Any suggestions for which graphical interface to choose?
The answer is .. depends.
You should ask yourself :
What is the number of polygons you will render per frame ?
What is the rendering rate (number of frames per second) that you wish to get ?
Do you expect the number of polygons to render increase in future ?
About Visual studio and linking problems, please find a sample project here that uses OpenGL. OpenGL Example.
I've been looking for OpenGL version 2.0 or higher, but I haven't found anything I could use so far. There is no download section on the official website and google finds mostly stuff like OpenGL Viewer or OpenGL Screen Saver, but I am looking for OpenGL to develop games/graphics/vizualizations ( precisely version 2.0, but I know that higher versions are also compatible with 2.0 then they are also OK ). Could someone please give me a source, which I could get appropriate OpenGL for my project from? I've managed only to download one, but it didn't work, because it was created for 32bit OS, and I use 64bit windows 7. Does anyone know how to handle this problem as well?
this is my graphic card : NVIDIA GeForce 9600M GS
You don't have to download an SDK to use OpenGL in 64-bit applications on Windows. All you need is a 64-bit capable compiler, and the Windows Platform SDK (which comes bundled with Microsoft Visual Studio).
But there is a catch: Microsoft's OpenGL implementation hasn't been updated since OpenGL 1.1, and to use functionality from later versions OpenGL, you need to use OpenGL-extensions. Luckily, some nice people has made GLEW, a library that does the extension-work for you and allows you to simply compile OpenGL 2.0 (and later, as GLEW is updated) source code for Windows. Perhaps this is what you're looking for?
kusma is completely right, but maybe you'll need more precise directions.
First you'll need OpenGL libraries. These will be given with your Visual Studio / mingw / whatever installation.
Then you'll need to create an OpenGL window. You can do it with windows functions, but it is a nightmare. You should go for something like GLFW.
Then you'll need something to deal with openGL extensions ( as kusma said, you don't want OpenGL 1.1 only ). Use GLEW.
You will also need some math stuff : create a vector ( on the C++ side ), compute your projection matrix... GLM can do that for you.
Last but not least, you may want to use Cg for your shaders (but you can use GLSL instead, which is "built-in" in OpenGL)
Here's the OpenGL SDK site. LINK Is this what you are looking for?
The easy way to tell is if your using glBegin/glEnd statements you using old context methods (good for quick demos and prototyping, bad if your looking to do something that needs to look professional). When you start dealing with opengl topics that cover buffers and hint to VBO- vertex buffer objects and FBOs - Frame buffer objects your in the area of more modern opengl methods. If you want to get up to speed in the shortest amount of time, start with buffers and keep working your way forward. Just remember when your dealing with device contexts (methods to create your windows) if you stick with OGL 2.1 or lower your limiting yourself ( Think roughly DirectX9/early DirectX10) . Your video card handles DirectX10 and OpenGL 3. Best bet start there. Check out NVidia's developer site, http://developer.nvidia.com/ And, take a look at http://opengl.org site check out the forums - http://www.opengl.org/discussion_boards, the guys there are helpful (be careful not to re-post old questions).
Also check out http://swiftless.com - its a good start - and he labels his tutorials by ogl versions.
I am working on a gaming framework of sorts, and am a newcomer to OpenGL. Most books seem to not give a terribly clear answer to this question, and I want to develop on my desktop using OpenGL, but execute the code in an OpenGL ES 2.0 environment. My question is twofold then:
If I target my framework for OpenGL on the desktop, will it just run without modification in an OpenGL ES 2.0 environment?
If not, then is there a good emulator out there, PC or Mac; is there a script that I can run that will convert my OpenGL code into OpenGL ES code, or flag things that won't work?
It's been about three years since I was last doing any ES work, so I may be out of date or simply remembering some stuff incorrectly.
No, targeting OpenGL for desktop does not equal targeting OpenGL ES, because ES is a subset. ES does not implement immediate mode functions (glBegin()/glEnd(), glVertex*(), ...) Vertex arrays are the main way of sending stuff into the pipeline.
Additionally, it depends on what profile you are targetting: at least in the Lite profile, ES does not need to implement floating point functions. Instead you get fixed point functions; think 32-bit integers where first 16 bits mean digits before decimal point, and the following 16 bits mean digits after the decimal point.
In other words, even simple code might be unportable if it uses floats (you'd have to replace calls to gl*f() functions with calls to gl*x() functions.
See how you might solve this problem in Trolltech's example (specifically the qtwidget.cpp file; it's Qt example, but still...). You'll see they make this call:
q_glClearColor(f2vt(0.1f), f2vt(0.1f), f2vt(0.2f), f2vt(1.0f));
This is meant to replace call to glClearColorf(). Additionally, they use macro f2vt() - meaning float to vertex type - which automagically converts the argument from float to the correct data type.
While I was developing some small demos three years ago for a company, I've had success working with PowerVR's SDK. It's for Visual C++ under Windows; I haven't tried it under Linux (no need since I was working on company PC).
A small update to reflect my recent experiences with ES. (June 7th 2011)
Today's platforms probably don't use the Lite profile, so you probably don't have to worry about fixed-point decimals
When porting your desktop code for mobile (e.g. iOS), quite probably you'll have to do primarily these, and not much else:
replace glBegin()/glEnd() with vertex arrays
replace some calls to functions such as glClearColor() with calls such as glClearColorf()
rewrite your windowing and input system
if targeting OpenGL ES 2.0 to get shader functionality, you'll now have to completely replace fixed-function pipeline's built in behavior with shaders - at least the basic ones that reimplement fixed-function pipeline
Really important: unless your mobile system is not memory-constrained, you really want to look into using texture compression for your graphics chip; for example, on iOS devices, you'll be uploading PVRTC-compressed data to the chip
In OpenGL ES 2.0, which is what new gadgets use, you also have to provide your own vertex and fragment shaders because the old fixed function pipeline is gone. This means having to do any shading calculations etc. yourself, things which would be quite complex, but you can find existing implementations on GLSL tutorials.
Still, as GLES is a subset of desktop OpenGL, it is possible to run the same program on both platforms.
I know of two projects to provide GL translation between desktop and ES:
glshim: Substantial fixed pipeline to 1.x support, basic ES 2.x support.
Regal: Anything to ES 2.x.
From my understanding OpenGL ES is a subset of OpenGL. I think if you refrain from using immediate mode stuff, like glBegin() and glEnd() you should be alright. I haven't done much with OpenGL in the past couple of months, but when I was working with ES 1.0 as long as I didn't use glBegin/glEnd all the code I had learned from the standard OpenGL worked.
I know the iPhone simulator runs OpenGL ES code. I'm not sure about the Android one.
Here is Windows emulator.
Option 3) You could use a library like Qt to handle your OpenGL code using their built in wrapper functions. This gives you the option of using one code base (or minimally different code bases) for OpenGL and building for most any platform you want. You wouldn't need to port it for each different platform you wanted to support. Qt can even choose the OpenGL context based on the functions that you use.