I had this same problem when using my own customized routine to project vertices. It wasn't until I set the Y coordinate to -Y that it finally worked right. Tbh, I've never actually had to unproject a vertex as of yet, but I'm quite sure that it's similar to projecting a vertex in OpenGL w/ RH matrices. So, given that, I'm not 100% sure how you should do it in your code, but I suggest trying this:
mouse.Y = -( viewport- y );
mouse.Y = viewport+ y;
I assume the first one would do the trick.
Also, I'm assuming this might not apply to you, but I had to invert one component of my modelview matrix as well in order for it to work.
modelview = -modelview;
So, like I said, I'm familiar with your problem, just not 100% sure what order the steps need to be taken to fix it. I gave it my best shot, so let us know if this works.
^lol, no worries. I started C++ before .net and ended up picking up many bad programming practices. Back then, I was very smug and thought I knew everything (mostly because I stayed in a small town in the midwest where there was no one to challenge what little skill I had, or call me out on my BS). Even then, I had no excuse. That what you guys are for.
What if I used the stack instead?
Nope. First, you can't delete things on the stack. And second, even if you manually called the destructor, it's still undefined behavior. If you use the non-trivial destructor in any way before returning from the constructor, it's undefined behavior.
Well, I'd never call delete on a stack object. >.<
I was thinking of changing it to this so the constructor returns and the lifecycle begins:
game_app_t* app = new game_app_t();
app->kick_off(); /* Start the main loop */
Dear C++ newbies, experts and all of you people in between,
Today, I ended up doing something really stupid, and I don't want any of you doing what I did today. If breakpoints and debugging features are part of your IDE, please, for the love of God, please use them!
While working on a new game concept I thought of a couple of days ago, I stopped and thought to myself "I'm going to use C++ this time and not use pure C to avoid the mistake of letting my cross platform code base getting messy again now that I'm more comfortable with the various mobile and desktop APIs and what not". So I start writing my basic application classes with portability in mind. For reasons I don't feel like getting into, I made my decision to use OpenGL via GLUT on MacOSX. I know, I know, I've never recommended GLUT in the past, but this time, I felt like using it since the game only uses either a mouse or a touch screen anyway (except for the old fashioned exit procedure; the escape key).
I don't know about you, but I have a tendancy to think about how I want my app to execute! I liking having my main() function contain as little code as possible. With that in mind, I ended up writing my main.cpp file to look like this:
game_app_t* app = NULL;
if( app )
// Name: main
// Desc: Program entry point.
int main( int argc, char* argv )
atexit( exit_func );
app = new game_app_t;
Okay, hold on, I promise you the problem with this code is NOT that obvious! You're probably thinking "Yeah, no s@#% sherlock! You didn't call delete or your game loop function!" Actually, I did. The class constructor calls the initialization function where glutMainLoop is called upon success. Instinctively, I check my code to verify that everything is uninitialized properly, even more than I check for successful initialization. So I put a breakpoint inside of exit_func to verify that it's being called (well, I knew the function works, but I habitually check anyway). Just in case you're wondering, the code for my class (the initialization stuff) looked like this:
And yes, the event callback functions were declared as static, so I needed an extra copy of my this pointer. Since there only needs to be one instance of this class, it doesn't really matter, IMHO.
This is where I found my REAL problem: app is still NULL! I was kinda dumbfounded when I realized that the class instance didn't get uninitialized (hence my deconstructor was never called). I spent a few minutes going over the code to see why this wasn't working. The last thing I wanted was to be leaking memory every launch. After a few more moments of scratching my head, I realized that the problem was that it the call to "new" doesn't return anyway. So the logical thing to do was to use the copy of my this pointer and delete that explicitly instead. After that thought, I added another function:
/* Added after setting all the other callbacks */
atexit( this->exit_func );
So, I added a breakpoint, ran my app in debug mode, and this time, my class instance not only gets deleted properly, but now my deconstructor gets called, and calls the uninit function. Bam, problem solved! Now my main function looks like this:
int main( int argc, char* argv )
So short, so sweet. Isn't C++ great once you use it properly?
So, the moral of the story is- "Don't be as stupid as Shogun?" Yeah, that too, but please, use your breakpoints and always, ALWAYS, cover your digital butt! I've seen a handful of rookie game programmers who have never learned to use breakpoints (I was one of those). What I did was dumb. I made this mistake for you, please don't do it for yourself.
Portability is something to consider BEFORE you begin coding a project. It's best to plan out a wrapper class or function(s) to suit functionality for both APIs. Create something fairly high level so that changing it would be simple enough to do with minimal hassle.
I do agree with Joyal to a certain degree, but I'd propose a slightly different approach. If you're using Windows, I recommend instead of compiling Direct3D and OpenGL code in the same binary, create seperate .dll files that you load manually to support whatever API the user needs or requires. This is what the Unreal Engine does (or did, at least). In a .dll, you can explicitly export classes, functions and variables and load them manually using ::LoadLibrary and GetProcAddress. It's also convenient if you plan on supporting multiple versions of Direct3D, because it helps prevent naming collisions and what not. I just see it as less hassle to do it this way, unless you're under another platform besides windows that uses only one API like OpenGL, or a custom API for consoles.
Just make sure you think things through before taking action. It will save you much trouble in the long run.
My opinion, until you actually apply what you have studied, how do you really know if you've learned anything?
As you study, continuously try to put that new found knowledge into practice somehow. If you are reading a book or tutorial, feel free to deviate a bit by tinkering with the code to see what changes can do what. You'll never know when you find an interesting way of doing things.
One thing I like to do is read the MSDN documentation on certain functions (assuming you're on Windows). This way, not only do you understand how the functions work and what different paremters you can use, but at the bottom of the page, Microsoft usually lists some closely related and similar functions. I've learned much by doing this. You can do this for Win32 APIs and DirectX. Win32 is alot of fun once you really get into it (especially multithreading; I enjoy the potential challenge and nightmare of multithreaded code).
My final bit of advice is the same advice I give everybody. Don't rush yourself or bite off more than you can chew. Study at your own pace, a pace that works best for you!
I don't know what type of 2D game you're creating, but for level design, I'd recommend creating a level editor, if you haven't already. First you need a clear definition and a list of what your game's levels will contain, then create your tool to save level data defining where walls, doors, enemy respawn points, whatever, into a scripting file like .xml or a custom format. Using your own level editor would make your life much easier. This way, you can put the relevant data in the right places upon load time.
I myself am just getting started learning CUDA. Currently, I'm reading the book known as "CUDA C by Example". Like MJP already stated, it's very much like C and I haven't used OpenCL yet either.
I'd say they are both a bit overkill for a simple particle engine (unless you're massively drawing and updating millions of particles like rain or snow). I've seen raytracing done using shaders many times before, so it depends on what scale you're doing it on, I guess. Like I said, I'm still learning this myself. ^^
I wondered this for a time, but I think that it doesn't really matter which one you use. Tbh, I even put it to the test with OpenGL and OpenGL ES. Each and every time, the same result... it worked!
Now, when you have two or more different extensions (i.e. GL_NV_texture_rectangle vs GL_ARB_texture_rectangle vs GL_EXT_texture_rectangle), then chances are you have a vendor specific extension, where using the ARB version is optimal.
Question, how new are you to OpenGL? I have the feeling you're getting a bit ahead of yourself; trying to take on a project that may be a bit too large for your current skill level. Sorry if I'm wrong, but that's sorta the vibe I'm getting.
If you already have your chess pieces exported from 3dsmax, what you need to do is export them to a 3d file format that's easy to read/parse. 3DS, MD2, LWO, OBJ, etc. are good formats to start off with. If you have never written a 3D mesh file loader, then you need to start there. After you've chosen your file format, you need to read in the vertex data and then you translate the meshes to their respective positions. If you know the size of your chess board, then putting the chess peices in their respective squares just requires you to translate them by multiplying the square size by the number of squares from the origin.
I prefer to avoid using ID3DXSprite to avoid confusion and portability (I found out the hard way that the 360 XDK didn't support it). What I ended up doing is writing my own 2D sprite rendering code with an Orthographic projection and HLSL shaders. Then you won't have to worry about state blocks, implement your own batching code, renderstates are a bit more straight forward, etc.
I can share it if you'd like. Right now, I'm on my Macbook again, so I have no Direct3D code on it's HDD.
Can I ask you a question? Is there a specific reason you choose PSP over PS Vita? Or maybe it's because you already have a PSP. I also assume that you don't plan on selling anything you create for PSP. If you do, you're better off targeting PS Vita.
Anyway, I agree with Frob here. I started to touch PSP homebrew before, but didn't get too far into it.
Keep in mind, that when programming for consoles (especially handhelds), you should familiarize yourself with the hardware as much as possible. Unlike PC, Xbox1, as well as the upcoming 720 and the PS4, they generally don't have x86 processors. You have to know how to optimize your code to utilize the hardware's chipsets, and let me tell you, it's nothing like dealing with PC! Example, PSP has what's called a VPFU, which is a vector unit with a very specific instruction set. Afaik, you can't program for that directly with C++; you have to use it's customized assembly language. If you've never used assembly language for any specific processor, be warned, it's not easy. And if you're going to use C++, I recommend keeping it simple. Going OOP crazy isn't very optimal on such hardware. I'd rather just use pure C.
Another thing you need to remember is that unlike PCs, developing for consoles (once again, especially handhelds), your memory and other system resources are VERY limited! The PSP is a prime example. The PSP only has 32Mb of system memory, and 2Mb of video memory. That's not much, so your games have to be memory efficient; tight down to the very last byte! So you'll find yourself optimizing your resources to fit within those memory constraints. Don't expect things like texture and audio formats to be the same or even similar to PC either. A few 32-bit textures will chew up that video memory in an instant.
I'm all for you pursuing this if it's what you really want, just don't expect it to be as simple as programming for PC. There's a site I want to link you to, but I don't know if it's against the rules or not, so I won't risk getting into trouble.
Question, are you using the latest DirectX SDK? Or are you using the actual DirectX 8 SDK? There's a chance you might be getting the DX9 version of those interfaces which is likely changed since DX8. I've had this problem before, and it can get annoying sometimes. Be sure that you're only linking against the DX8 versions.
If I were you, I'd be looking at the MSDN documentation of those interfaces you are having problems with. I understand that you are new to all of this, but eventually you will need to learn to look to the API documentation when things of this nature arrive. So, from here, I recommend at least opening up the DirectX 8 SDK help file along side of the DirectX 9 SDK help file to see what the COM interface differences are so you can pinpoint your problem. If you don't understand what the different parameters are for, then let us know. Since I have both SDKs installed on my Windows machine, I'd be glad to do a little searching myself for you, but I'm on my Mac right now, which doesn't use DirectX.