|
ultra-inquisitor posted:I presume that it also runs in plain debug mode, rather than only in the debugger? If this is the case, then it could be a whole number of things. My money's on uninitialised variables - see this page for more info. I would agree. Looking through the code, you have no initialization for m_bIsEnabled for BreakoutBox. You also never call your Enable function. But you do check IsEnabled in BreakoutApp in your Update function. That'd be where I would start with.
|
#
¿
Oct 3, 2008 20:22
|
|
|
|
| # ¿ May 5, 2024 10:44 |
|
|
I honestly don't know if this question should go here, its own thread, or some other thread that I have missed. It is a setup question. I use vs2008, and I just installed the directx sdk (august 2008). This set the environment variable, DXSDK_DIR. I had to manually point visual studio to the include and lib directories (tools > options > projects and solutions > vc++ directories). I would have thought the sdk installer would have done that itself, but oh well. So, now I just wanted to check out some of the samples (as well as verify that the sdk, did, in fact install correctly). So, I install a couple test projects (specifically, Direct3D10WorkshopGDC2007 and PIXGameDebugging were my quick tests), build the _2008 solutions, and am just greeted with unresolved externals. Not the most unresolveds I have ever seen, but at least in those cases I knew the system well enough to figure out what was wrong. Here I am a little stumped simply because I was expecting an installed project to work straight off the bat, and because I do have the lib and includes pointed to their proper spots. I have spent time trying to google this, but damned if I can find just basic, complete install directions - preferably from microsoft themselves (and watch me have missed it in a completely obvious location). The only cases I found were people asking for help as well, although their solution (adding the pointers to the lib and include directories) has obviously not worked for me. So, my question is simply: what am I missing? Please tell me I have just missed something completely minor so that I can get along. Below is a sampling of the errors, if it helps. code:
|
|
#
¿
Oct 14, 2008 01:23
|
|
|
OneEightHundred posted:Did you include the D3DX libs in your project? Yes. These are just the samples, which already have the necessary libs included in the properties. But yes, I had double checked and they are listed.
|
|
#
¿
Oct 14, 2008 11:30
|
|
|
So, I feel pretty stupid at the moment trying to solve what I figure is a simple problem. I have two points, which can be used to make some vector leading from one point to the other. I simply want to place my camera such that it is positioned at one of the points (easy!) and looking along the vector path (I thought it was easy?!). What I need in terms of the rotation to look down the vector path is HPR (heading, pitch, roll). I am using OSG and Delta3D, but really I just want to know what I need to do in my math. I had thought I could simply create a look-at matrix and then retrieve the HPR from that. OSG has utilities to do both: osg::Matrix::lookAt(position1, position2, up) where conceptually position1 is the eye position, position2 is the center of the view desired, and the function returns a lookat matrix. From that, I thought I could retrieve my HPR values and set them to the camera - but this does not in anyway yield what I am looking for. The camera does move around, but only by coincidence does the lookat sometimes match what I want. I would also be greatly interested in good 3D math/linear algebra type books that are slanted toward programming for their examples.
|
|
#
¿
Aug 11, 2009 14:08
|
|
|
I can get the values for HPR from a matrix fine. I am just not sure if I am actually making the matrix correctly (and given I am not visibly seeing the results I am looking for, I have to go with a "no, I am screwing it up in some way"). (or if I even need a matrix, in the case of magicalblender's math!) I am not sure how else to describe it. Let's say you are driving along and come to an intersection. You turn left. This is point 1. You drive to the next intersection on this road. This is point 2. At point 1 you can look toward point 2 by looking down the road. Pretend you are now a camera in the same space, and you see that in order to look down the road, you have to have some rotation such that you are looking along the vector defined by point 1 and point 2. I am trying to figure out that rotation. re: magicalblender - this seems to have better results than what I was doing, so I think it is on a usable path. The simplified case is to just make the heading of the camera follow the vector. IE, vector from point1 to point2 defines some heading where point1 is the origin, so in theory just applying that heading to the camera would see the camera looking along the same heading. And yet, my camera trips out like it's a groove machine!
|
|
#
¿
Aug 12, 2009 15:52
|
|
|
|
| # ¿ May 5, 2024 10:44 |
|
|
Spite posted:Right, but it's not _really_ what's being run on the card. That's just a representation of it. You can't just compile once, because it doesn't work that way. Every driver on every card will recompile shaders based on state to bake stuff in and do other optimizations. You'd need a huge number of different binaries to cover all possibilities. Turned on sRGB? Your fragment shader will be recompiled. Using texture borders? Recompile again, etc. Do you really not understand what OneEightHundred is saying? Or are you just trolling him? You should have just stopped at your very first sentence. If options change that would cause a need for recompilation, then it would be recompiled. However, if not, then keep using the stored built version. I'm not sure why caching appears to be an alien concept to you. Maybe you're just being all goony semantic about it, or something.
|
|
#
¿
Jul 20, 2010 14:11
|
|