# OpenGL DirectInput equivelant

## Recommended Posts

Hi, I'm sure you've seen this post before, but the search for me isn't turning up anything useful. I'm working on a D3D app, but for some reason I'm getting nervous about DirectX going away or being unsupported in future versions of windows, and contemplating the jump to OpenGL. Its been a long time since I used OpenGL, and I was wondering that since OpenGL would obviously take care of the graphics portion of my app, is there such a thing as an input library to replace DirectInput? I also understand that OpenAL can be used for sound, so I think I would be covered with that. My main concern is finding a free and easy-to-use input manager that gets direct access to keyboard and input device stuff. I'm not particularly interested with using SDL, for various reasons. Thanks for any/all replies. Cheers, roger_hq

www.libsdl.org

##### Share on other sites
Quote:
 Original post by roger_hqis there such a thing as an input library to replace DirectInput?

Unless you want to use the Win32 input, there is not that I am aware of. I know SDL uses DirectDraw on Win32 platforms, but I do not think it uses DI as well. I've looked at the source before and came to that conclusion, but I may be off about the DI. When you go to linux and such, I am not sure what it uses really.

What I reccomend you do is use a OpenGL library that has input built in already. Take a look at GLFW. It has a great input system and is a very nice framework. I will be using that for our game. It's fairly easy to setup and use, but building it has a few quirks they don't really seem to mention. There are of course other libraries, such as GLUT and FreeGLUT, so that is what you would need to look into for a better input system.

As for OpenAL, good luck! I have been working with it for some time now, making my own audio library and it really is a pain. There's a lot to it that is not really explained and you have to figure out how everything works and what you can and can't do the hard way. Nevertheless, it's free and cross platform, so if you need some help with that feel free to PM me.

- Drew

##### Share on other sites
Drew,

I'm intrigued. One thing I'm trying to avoid is using something with a license that says I have to release all of my source code, give away my 1st born, etc. ad nauseum. I'm also very apprehensive about continuing with D3D, as I know microsoft just LOVES to stop supporting API's and with WGF coming out soon I fear that DirectX support will vanish. It looks like its pretty platform independent, which is of course good. I would like that too. So have you developed with it much? Do you know of any real-world games that have used it?

Thanks!

roger_hq

##### Share on other sites
Quote:
 Original post by roger_hq...for some reason I'm getting nervous about DirectX going away or being unsupported in future versions of windows...
Don't.

Quote:
 ...is there such a thing as an input library to replace DirectInput?
No. For Windows, just about nothing has as much low-level access to the hardware as the various DirectX components. Very few input device manufacturers go to the trouble of writing complex device drivers to expose functionality for real-time APIs. DirectInput implements a meta-driver, which the manufacturers write to (it's easier) and everyone lives happily ever after.

Of course, if all you're interested in is the keyboard and mouse, then you didn't really need DirectInput to begin with. The GDI GetKeyboardState API has high enough resolution for your most likely purposes, for example.

##### Share on other sites
Quote:
 Original post by roger_hq...microsoft just LOVES to stop supporting APIs
Actually, that's a very recent development, quite possibly in response to changes in developer behavior. For instance, VC6.0 was frequently blasted for its faulty implementation of the scope of for, but Microsoft took the right approach in maintaining the erroneous behavior as a default, with a switch to correct it, in order to support legacy code. VC7.x inverts that, requiring a switch to restore the incorrect scoping and compile legacy code without modification. There is also evidence of the Windows team having worked around the failings of third-party vendors, including IBM.

The architecture of DirectX and the decision to build it on top of COM was specifically chosen to provide backwards compatibility, and you can still find all the reference information for old interfaces in MSDN (with a warning message at the top of the page that the content has been archived, and may no longer be accurate). Doubtless, the same will be applied to 8.x and 9.x going forward. What more you want, I don't know.

Consequently, it seems that you are falling victim to hype and MS-bashing, causing you unnecessary apprehension and wasting your time. Your projects are suffering while you resolve this non-issue.

To each his own, I suppose.

##### Share on other sites
Sorry for the delay, started typing this and got distracted [lol]. Well to be honest, I have not use GLFW that much. However, I decided to give it a try because I saw a game they have been working on with it - Machinations. It just gave me a sense of awe of how awesome it was. I knew that this library definitly had to be worth while. Here's a simple sample application that I was working woth. All it does is draw a rotating triangle. It also displays the GL video info to the console window.

#include <windows.h>#include <stdio.h>     // For printf(), fopen() etc.#include "glfw.h"		// For GLFW, OpenGL and GLU#pragma comment ( lib, "opengl32.lib" )#pragma comment ( lib, "glu32.lib" )#pragma comment ( lib, "GLFW.lib" )void CalculateFrameRate();void Init(){	int    width, height;  // Window dimensions	// Get window size	glfwGetWindowSize( &width, &height );	// Make sure that height is non-zero to avoid division by zero	height = height < 1 ? 1 : height;	// Set viewport	glViewport( 0, 0, width, height );	// Clear color and depht buffers	glClearColor( 0.0f, 0.0f, 0.0f, 0.0f );	glClear( GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT );	// Set up projection matrix	glMatrixMode( GL_PROJECTION );    // Select projection matrix	glLoadIdentity();                 // Start with an identity matrix	gluPerspective(                   // Set perspective view		65.0,                         // Field of view = 65 degrees		(double)width/(double)height, // Window aspect (assumes square pixels)		1.0,                          // Near Z clipping plane		100.0                         // Far Z clippling plane	);	// Set up modelview matrix	glMatrixMode( GL_MODELVIEW );     // Select modelview matrix	glLoadIdentity();                 // Start with an identity matrix	gluLookAt(                        // Set camera position and orientation		0.0, 0.0, 10.0,               // Camera position (x,y,z)		0.0, 0.0, 0.0,                // View point (x,y,z)		0.0, 1.0, 0.0                 // Up-vector (x,y,z)	);	char* message = (char*)glGetString(GL_VENDOR);	char* message2 = (char*)glGetString(GL_RENDERER);	char* message3 = (char*)glGetString(GL_VERSION);	char* message4 = (char*)glGetString(GL_EXTENSIONS);	printf("Vendor: %s\nRenderer: %s\nVersion: %s\n Extensions: %s\n",message,message2,message3,message4);}void Draw( void ){	if( glfwGetKey( GLFW_KEY_F1 ) )	{	}	if( glfwGetKey( GLFW_KEY_F2 ) )	{	}	if( glfwGetKey( GLFW_KEY_F3 ) )	{	}	if( glfwGetKey( GLFW_KEY_F4 ) )	{	}	if( glfwGetKey( GLFW_KEY_F5 ) )	{	}	double t = glfwGetTime();              // Time (in seconds)	// Clear color and depht buffers	glClear( GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT );	glLoadIdentity();                 // Start with an identity matrix	gluLookAt	(								  // Set camera position and orientation		0.0, 0.0, 10.0,               // Camera position (x,y,z)		0.0, 0.0, 0.0,                // View point (x,y,z)		0.0, 1.0, 0.0                 // Up-vector (x,y,z)	);	glTranslatef( 0, 0, -5 );	// Rotate the triangle about the y-axis	glRotatef( 60.0f * (float)t, 0.0f, 1.0f, 0.0f );	// Let us draw a triangle, with color!	glBegin( GL_TRIANGLES );          // Tell OpenGL that we want to draw a triangle		glColor3f( 1.0f, 0.0f, 0.0f );    // Color for first corner (red)		glVertex3f( -5.0f, -4.0f, 0.0f ); // First corner of the triangle		glColor3f( 0.0f, 1.0f, 0.0f );    // Color for second corner (green)		glVertex3f(  5.0f, -4.0f, 0.0f ); // Second corner of the triangle		glColor3f( 0.0f, 0.0f, 1.0f );    // Color for third corner (blue)		glVertex3f(  0.0f,  4.5f, 0.0f ); // Third corner of the triangle	glEnd();                          // No more triangles...	glFlush();}int main( int argc, char **argv ){	int    ok;             // Flag telling if the window was opened	int    running;        // Flag telling if the program is running	// Initialize GLFW	glfwInit();	// Open window	ok = glfwOpenWindow(		640, 480,          // Width and height of window		8, 8, 8,           // Number of red, green, and blue bits for color buffer		8,                 // Number of bits for alpha buffer		24,                // Number of bits for depth buffer (Z-buffer)		0,                 // Number of bits for stencil buffer		GLFW_WINDOW        // We want a desktop window (could be GLFW_FULLSCREEN)	);	// If we could not open a window, exit now	if( !ok )	{		glfwTerminate();		return 0;	}	// Set window title	glfwSetWindowTitle( "Demo" );	// Enable sticky keys	glfwEnable( GLFW_STICKY_KEYS );	Init();	// Main rendering loop	do	{		CalculateFrameRate();		// Call our rendering function		Draw();		// Swap front and back buffers (we use a double buffered display)		glfwSwapBuffers();		// Check if the escape key was pressed, or if the window was closed		running = !glfwGetKey( GLFW_KEY_ESC ) && glfwGetWindowParam( GLFW_OPENED );	}	while( running );	// Terminate GLFW	glfwTerminate();	// Exit program	return 0;}void CalculateFrameRate(){	static float framesPerSecond    = 0.0f;							// This will store our fps	static float lastTime			= 0.0f;							// This will hold the time from the last frame	static char strFrameRate[50] = {0};								// We will store the string here for the window title	float currentTime = GetTickCount() * 0.001f;					++framesPerSecond;	if( currentTime - lastTime > 1.0f )	{		lastTime = currentTime;		sprintf(strFrameRate, "Current Frames Per Second: %d", int(framesPerSecond));		glfwSetWindowTitle( strFrameRate );		framesPerSecond = 0;	}}

As you can see, that's it! THere's not much you have to do to get up and running. Not only that, I'm sure you could optimize the program flow of it to make it a lot better. That example is just one of those, beginning concept examples. You can greatly expand it.

The main reason I like GLFW is that it takes care of all the details that you would otherwise have to make for your game. Originally I had written my own window class and OpenGL setup code, but it was Win32 specifc. GLFW takes care of it all, much like SDL and GLUT. I personally like this GLFW over SDL already and I've used SDL for quite some time now. It is just a OpenGL wrapper compared to something like SDL that adds in all the SDL specific stuff.

If you have any other questions or comments, feel free to ask. I hope I have covered everything, but I might have missed a few things.

- Drew

##### Share on other sites
Dang you GameDev! That AP was me.

If you are just writing for Win32, take Oluseyi's post into consideration, he's right. I too do not believe that DX will go away anytime soon. It may stop being supported in a few years due to some new break though, but it will not just become useless. Look at DOS - it's had its days yet it still is used, even though WinXP uses it less than previous OS's.

However, I would still use something like GLFW for ease of development and if you were going to have any intrests of going cross platform. I happen to be using DirectInput with my GLFW as a matter of fact. I can get back to you later on during development how it goes with GLFW.

However Oluseyi, when you say
Quote:
 Consequently, it seems that you are falling victim to hype and MS-bashing, causing you unnecessary apprehension and wasting your time. Your projects are suffering while you resolve this non-issue.
I think it is in part Microsofts fault as well. I mean the whole deal with the new Visual Studio 2005 Express not comming with the default Win32 components really has a lot of people wary. I mean look at all the people who freak out because they cannot find "windows.h", even though all you have to do is download the platform SDK. I also believe a thread was started a while back relating how much Win32 will be used in the future and how .NET is becoming the more norm. I don't know, it's just one of those insecurity things. I am not worried about it at all though.

- Drew

##### Share on other sites
Oluseyi:

Your first post was spot on. Thank you for the relevant information.

Drew:

That is very good information, it looks like GLFW is very easy to use. I also want it to be feature-rich, which is one reason I like DirectX. I too am struggling with the "support" with MS products, as you say. With recent releases of DX SDK's, I can't use the Winter DX9 SDK because I use VC++ 6.0. I just happen to like that IDE. So I had to roll back to the october SDK just so I could use 6.0 IDE. That seems like a strange way to support your past products to me. VC6.0 isn't that old, and is the Winter DX9 SDK really that different from the October one? Anyways, thats just one example that comes to mind.

One thing that keeps pulling me back to DX, though, is the number of features, esp. in D3DX support (like meshes, etc). Very nice stuff. I would very much like to hear how using either DInput or the functionality in GLFW goes for you. What type of game are you looking to make?

The main reason I bring this whole thing up is that I would like to work on my game idea long term, and be able to constantly add content instead of rewrite core technologies. I don't relish the idea of having to at some point write up a new core portion of the engine just because the API I chose way back in the "before-time" (now) is no longer in favor. I suppose I could just use that as an excuse to learn a new API, but I'd like to _try_ to avoid it if possible.

Cheers,

roger_hq

##### Share on other sites
Quote:
 Original post by Drew_BentonHowever Oluseyi, ... I think it is in part Microsoft's fault as well. I mean the whole deal with the new Visual Studio 2005 Express not coming with the default Win32 components really has a lot of people wary.
Would you, by any chance, happen to mean Visual Studio 2005 Express Beta? Because, as far as I know, there is no information to suggest that the final release will not either include the Platform SDK or automatically invoke a PSDK download. People are always looking for reasons to freak out when it comes to Microsoft; that some people interpret the minimalistic Express Beta component installs as a sign of a policy shift says nothing of import.

Quote:
 I also believe a thread was started a while back relating how much Win32 will be used in the future and how .NET is becoming the more norm.
Is that supposed to be a bad thing? I mean, do you actually like using Win32?

I think too many people are speaking based on inadequate information/experience, or even ignorance. You try implementing a ReBar control hosting dynamic toolbars in Win32, then compare to doing the same in .NET. Remember, Win32 doesn't exist just to piggyback games (which is why I discard most gripes from GameDev).

You don't see anybody on Experts Exchange, The Code Project or DevX whining about the imminent "demise" of Win32, and with good reason.

##### Share on other sites
*hugs win32* i dont mind it much as i hardly interact with it anymore, its like a friend that you dont really get along with in person but you hardly see them so you two stay friends lol. I just felt the need to chime in to respond to Drew's comment about OpenAL, i LOVE openAL, i personally feel its quite intuitive, but i havent dived into anything too spectacularly complex, just automated handling of buffers, the listener and sources, with control over velocity position and gain (everyones entitled to their own opinion though, i just wanted to defend my friend :-) )

just my two cents
-Dan

##### Share on other sites
@Oluseyi - I understand what your point is, but Microsoft should have made this issue clear. They have done things like this in the past and should have learned from them. From my reading in "Writing Solid Code" by Steve Maguire, he recounts a tale (pg 69 for reference) when MS shipped a beta debug version of Excel to its beta testers. They stopped doing this after a a 'prelease' magazine wrote how great the program was but also how it was "about as fast a a three-toed sloth". In their best intrestes, I would personally like to see a disclaimer that explicity makes the point that this indeed is just a beta so not everything is packaged. I'm not saying I felt that way, its just I saw other people who reached that conclusion on, as you say inadequate information/experience, or even ignorance, so I totally agree, but remember how dumb the masses are [wink].

In all honesty, I have no bad remarks in regards to Win32. I like the windows api features that is provides. I also like using MFC as well, even though it is dismissed as horrible on GD. I use it for quick and easy gui's for testing out various components. I feel that everything does have its uses. Right now I'm using it to test out my audio library. I understand that .NET is probabally better and faster than Win32 and ad infinitum of arguments, but I have not made that change, and probabally will not for a bit, but I do agree with the point that this is GameDev, and is meant for games, not general programming.

Anyways thanks for your feed back and such. I hope I have not come across as a fanatic of any sort. I am more the type to just use what's avaliable and use what I have the most experience with.

@Dan - Don't get me wrong either about OpenAL. I think it's great, but there is a lack of resources that tells how it really is supposed to work. From all of the GD and DevMasters tutorials, I was under the impression that you could have a source and buffer from all your sounds, but only 32 being used at once (source wise). What I was doing, modeling from those tuts, was always creating sources and destroying sources. This worked fine until I was at about 100+ sounds, then the whole thing just died. After 5 rewrites, I have finally found a really nice solution I am looking forward to for using, but I still have some more work to do. Maybe I am the one to blame for misinterpreting everything so saying what I did was unfair to OpenAL, but I misinterpreted it from what was avaliable, which really is not much.

More of the problems I had was the fact that you can only use 16bit or lower sounds for it to work. I did not know this at first, so I was just using 24bit wavs I converted from MP3's. Figured that out after looking at the tutorials again and opening the sound files and seeing how they were all 16bit. I do not know if this was stated somewhere or I just missed it. I did however, print out all the avaliable resources on it and looked for it. Next was the fact that I have to use mono-channel files to get position and spatial coordinates to work. For so long I was using stereo and it did not work, so I looked at the tutorial wav files again and saw they were mono. I do not know if I am doing something wrong with the stereo files, but I thought they *should* work.

That was the main basics of why I said it is a pain, but I probabally should have said it 'was' a pain. I have no problem having to figure things out on my own, of which I have done so a lot. I have also used the mailing list as a reference point to any problems I have had, but I have yet to mail them. That is how I found how the 'AL_SOURCE_ABSOLUTE' is deprecated and was the cause of issuing an unsupported command to alSourcei. Last of my gripes was my issues trying to get alcSuspendContext to work, but never could. That problem has yet to be resolved in all of the refrences I have checked.

I am not trying to start a "bash" Product X discussion, but I'm just sharing my experiences and why I have said the things I have. Hope they make sense, and if not, feel free to tell me [smile].

- Drew

[Edited by - Drew_Benton on February 8, 2005 5:36:17 PM]

##### Share on other sites
Quote:
 Original post by Drew_BentonAnyways thanks for your feed back and such. I hope I have not come across as a fanatic of any sort. I am more the type to just use what's avaliable and use what I have the most experience with.
No problem, and not at all. That's the way it should be.

Cheers.

##### Share on other sites
@Drew_Benton

I guess a few of your problems were down to a case of not RTFM [wink]
I dont know if its relivent now but you really should have a copy of the pdf OpenAL Programmer's Guide.
For example, on the sound positioning problem on page 7 it notes:
AL_ CHANNELS number of channels in buffer, > 1 is valid, but buffer won’t be positioned when played

Granted, the bits arent covered, however I'd have thought 16bit was pretty much the standard *shrugs*

##### Share on other sites
Well that's the thing buddy - I did RTM as well as scoure google for weeks! Not only that I printed it out as well as all of the DevMaster tutorials and read those as well. I will check that page 7 again though, I might just have overlooked it - that or did not make the connection at the time I read it. [wink] Thanks for that heads up though.

 You're right. It's right there [lol]. I'm guessing I did not make the connection that it was referring to mono but rather something else. Oh well, I should re-read this stuff again to see what else I missed [embarrass].

- Drew

## Create an account

Register a new account

• ### Forum Statistics

• Total Topics
627764
• Total Posts
2978976
• ### Similar Content

• Hello! As an exercise for delving into modern OpenGL, I'm creating a simple .obj renderer. I want to support things like varying degrees of specularity, geometry opacity, things like that, on a per-material basis. Different materials can also have different textures. Basic .obj necessities. I've done this in old school OpenGL, but modern OpenGL has its own thing going on, and I'd like to conform as closely to the standards as possible so as to keep the program running correctly, and I'm hoping to avoid picking up bad habits this early on.
Reading around on the OpenGL Wiki, one tip in particular really stands out to me on this page:
For something like a renderer for .obj files, this sort of thing seems almost ideal, but according to the wiki, it's a bad idea. Interesting to note!
So, here's what the plan is so far as far as loading goes:
Set up a type for materials so that materials can be created and destroyed. They will contain things like diffuse color, diffuse texture, geometry opacity, and so on, for each material in the .mtl file. Since .obj files are conveniently split up by material, I can load different groups of vertices/normals/UVs and triangles into different blocks of data for different models. When it comes to the rendering, I get a bit lost. I can either:
Between drawing triangle groups, call glUseProgram to use a different shader for that particular geometry (so a unique shader just for the material that is shared by this triangle group). or
Between drawing triangle groups, call glUniform a few times to adjust different parameters within the "master shader", such as specularity, diffuse color, and geometry opacity. In both cases, I still have to call glBindTexture between drawing triangle groups in order to bind the diffuse texture used by the material, so there doesn't seem to be a way around having the CPU do *something* during the rendering process instead of letting the GPU do everything all at once.
The second option here seems less cluttered, however. There are less shaders to keep up with while one "master shader" handles it all. I don't have to duplicate any code or compile multiple shaders. Arguably, I could always have the shader program for each material be embedded in the material itself, and be auto-generated upon loading the material from the .mtl file. But this still leads to constantly calling glUseProgram, much more than is probably necessary in order to properly render the .obj. There seem to be a number of differing opinions on if it's okay to use hundreds of shaders or if it's best to just use tens of shaders.
So, ultimately, what is the "right" way to do this? Does using a "master shader" (or a few variants of one) bog down the system compared to using hundreds of shader programs each dedicated to their own corresponding materials? Keeping in mind that the "master shaders" would have to track these additional uniforms and potentially have numerous branches of ifs, it may be possible that the ifs will lead to additional and unnecessary processing. But would that more expensive than constantly calling glUseProgram to switch shaders, or storing the shaders to begin with?
With all these angles to consider, it's difficult to come to a conclusion. Both possible methods work, and both seem rather convenient for their own reasons, but which is the most performant? Please help this beginner/dummy understand. Thank you!

• I want to make professional java 3d game with server program and database,packet handling for multiplayer and client-server communicating,maps rendering,models,and stuffs Which aspect of java can I learn and where can I learn java Lwjgl OpenGL rendering Like minecraft and world of tanks

• A friend of mine and I are making a 2D game engine as a learning experience and to hopefully build upon the experience in the long run.

-What I'm using:
C++;. Since im learning this language while in college and its one of the popular language to make games with why not.     Visual Studios; Im using a windows so yea.     SDL or GLFW; was thinking about SDL since i do some research on it where it is catching my interest but i hear SDL is a huge package compared to GLFW, so i may do GLFW to start with as learning since i may get overwhelmed with SDL.
-Questions
Knowing what we want in the engine what should our main focus be in terms of learning. File managements, with headers, functions ect. How can i properly manage files with out confusing myself and my friend when sharing code. Alternative to Visual studios: My friend has a mac and cant properly use Vis studios, is there another alternative to it?

• Both functions are available since 3.0, and I'm currently using glMapBuffer(), which works fine.
But, I was wondering if anyone has experienced advantage in using glMapBufferRange(), which allows to specify the range of the mapped buffer. Could this be only a safety measure or does it improve performance?
Note: I'm not asking about glBufferSubData()/glBufferData. Those two are irrelevant in this case.
• By xhcao
Before using void glBindImageTexture(    GLuint unit, GLuint texture, GLint level, GLboolean layered, GLint layer, GLenum access, GLenum format), does need to make sure that texture is completeness.

• 11
• 10
• 10
• 23
• 14