Jump to content
  • Advertisement

d_emmanuel

Member
  • Content Count

    73
  • Joined

  • Last visited

Community Reputation

271 Neutral

About d_emmanuel

  • Rank
    Member
  1. This depends on the platform you're developing for. On Windows you can use the FindFirstFile, FindNextFile and FindClose functions (MSDN has an example).
  2. d_emmanuel

    SetWindowLong & DWLP_USER

    Hi again, the problem is that SetClassLongPtr doesn't actually allocate extra memory for the window structure, it only specifies how much should be available. See the MSDN doc. In order to allocate additional memory you need to specify the number of bytes in the cbWndExtra member of the WNDCLASS when you register your window class.
  3. Does the DLL have its own resource file? In that case you need to specify the name of the DLL in your call to GetModuleHandle instead of NULL. E.g. GetModuleHandle(_T("MyDLL")). If you use NULL it's going to get the handle to the .exe that loaded the DLL and look in its resources.
  4. d_emmanuel

    Bypass WM_* Messages ?

    Subclassing can be used in either DLLs or static LIBs. A HWND can only have a single DWORD of user data associated with it so you won't be able to directly store both the application and input driver pointers using SetWindowLong. There's a couple of ways of working around this though including: (1) Implement your input driver as a singleton (I'm assuming you only create a single instance) so that you can have global access to it from within your DLL. (2) Store the instance of the input driver inside of the application. This way you can access it via the application pointer. Depending on how your system is implemented you may actually want to consider using some hybrid of the two approaches. Hope this helps.
  5. d_emmanuel

    Bypass WM_* Messages ?

    Assuming the DLL the driver resides in has access to the application's HWND, you should be able to do this through window subclassing. The basic idea is to replace the window's message handler with a custom handler inside of your DLL to process the WM_CHAR message. You can find out more about subclassing here. [EDIT] You can also associate a pointer to the input driver with the window by using the SetWindowLong function. [/EDIT]
  6. You can use D3DSURFACE_DESC's Format member to determine the bits per pixel via a switch statement. The MSDN doc for the D3DFORMAT enumeration can be found here. BTW, I see that in your loop you're setting the y (height value) from the read back texture data, but shouldn't you also be setting the x and z values as well, or are you doing this somewhere else?
  7. Without more details, I assume you want BYTE b = 97; float f = static_cast< float >(b); EDIT: Actually the cast isn't even necessary. The variable b will get promoted automatically. What are you trying todo?
  8. The code I posted will work with textures as long as they are not allocated with D3DPOOL_DEFAULT. Any texture created in either system memory or as managed can be locked this way though.
  9. You should probably check out the doc on MSDN, but, assuming texture is of type LPDIRECT3DTEXTURE9 and valid, the following should do the trick: D3DLOCKED_RECT rect; 3DSURFACE_DESC d3dSurfaceDesc; texture->LockRect(0, &rect, 0, D3DLOCK_READONLY)); texture->GetLevelDesc(0, &d3dSurfaceDesc)); const int width = d3dSurfaceDesc.Width; const int height = d3dSurfaceDesc.Height; const int pitch = rect.Pitch; const unsigned char* data = reinterpret_cast< unsigned char* >(rect.pBits); // Process the data texture->UnlockRect(0);
  10. d_emmanuel

    Resource Management

    You'll want to make your assignment operator private in addition to your copy constructor. In both cases, just declare them in the private section of your class and then never define them.
  11. Instead of switch statements or virtual functions, I would suggest the much cleaner and efficient approach of table lookup. You can do this as follows: class Renderer { public: // Define constants for the primitive types supported by all renderers enum PrimitiveType { PRIM_TRIANGLEFAN = 0, PRIM_TRIANGLELIST, PRIM_LINELIST, PRIM_LINESTRIP, PRIM_TYPECOUNT }; }; class OpenGLRenderer: public Renderer { private: // Maps the Renderer defined constants to actual implementation values static const GLEnum m_primitiveTypes[PRIM_TYPECOUNT]; }; Then, in your corresponding cpp file: const GLEnum OpenGLRenderer::m_primitiveTypes[OpenGLRenderer::PRIM_TYPE_COUNT] = { GL_TRIANGLE_FAN, GL_TRIANGLES, GL_LINES, GL_LINE_STRIP };
  12. d_emmanuel

    Data Member Reorganization

    You can assume that x, y and z are sequentail in memory. However, there's no guarentee that z and oldMagnitudeSquared will be. The standard does not require compilers to place data members with different access modifers sequentailly (though most do).
  13. d_emmanuel

    compiling collada sdk

    You need to compile both COLLADA and your own app/library with the same version of the C-runtime library. In VC++, you can change the runtime library as follows: Click on project properties -> C/C++ -> Code Generation -> Runtime Library
  14. From the example you posted, I don't see why this would fail. Could post the schema you're using?
  15. d_emmanuel

    Reading JAR files in C++

    Actaully, storing the compressed and uncompressed sizes in the data descriptor is a part of the .zip format. You can check for this by checking the general purpose bit flags in the local file header. If the specific bit is set, then the compressed and uncompressed sizes will be 0 in the file header and you'll need to get the values from the data descriptor. See the link I posted to the zip format spec.
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!