Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

166 Neutral

About LilithAnn

  • Rank
  1. LilithAnn

    Texture2D and GraphicsDevice

    I think I am at the moment. That's not to say that something won't pop up later, but for now I think I can further my progress. Thanks for your help. I appreciate it greatly. Lil
  2. LilithAnn

    Texture2D and GraphicsDevice

    Got it. I've revised this post since I played around with the code, trying to make my thoughts clear before answering and finally got it to compile successfully. Strangely enough I still seem to be passing what was is a type but it's not complaining now. Thanks for your help. Lil
  3. Seems I can't find a clear explanation of this. In trying to create an impromptu texture on which I can draw . I'm finding several examples but one thing remains unclear. texture = new Texture2D (GraphicsDevice,....... When I input my code based on the examples I see "GraphicsDevice" and input it exactly that way despite the fact that I was pretty sure GraphicsDevice is a type. And sure enough, that's what the compiler says too. Other code shows "graphicsDevice" which otherwise doesn't seem to be declared in the code but it may be buried in a parent class somewhere. Regardless, this doesn't appear to be in scope for the class I'm creating nor can I seem to coerce it out of the Game class. Notably the example deals with a Texture2D object declared in the Game class. So, let me ask.... Does a GraphicsDevice object have to be declared for each texture within the scope of the code that creates the texture? In all my reading on Windows programming (of which I'm a very poor student/researcher) it seems the literature always talks about graphic devices and device contexts as if the programmer knows what they are exactly but I've never seen a basic description of what they are from it's relationship to the graphic system. Color me unlearned.
  4. LilithAnn

    Understanding clocks for frame rates

    That's exactly what I meant. I just have trouble expressing it so concisely. Thanks very much. This gives me some confidence to proceed.
  5. Hopefully I can word this well enough to make the question clear. I'm looking at setting up clocking functionality for a game I'm working on. I've read several articles on the subject and I understand the theory behind it. However, for a practical understanding I have some questions. Typically I see something at the top of the loop that checks for the time passed since the last pass through that point. Following that, calculations are made for movement of the various elements of the display then the rendering is done. I guess my question is, where is the most time expected to be spent? It seems that between the time spent in calculation and drawing the scene it's the time involved with those operations that really determines where the elements should be placed. My perception is that the relative displacement should involve the time required to perform at least the calculations and that that can't happen. Is the time required to calculate and render considered to be minute enough not to make a difference or will the rendering be a frame out of sync? Clear? I didn't think so.
  6. LilithAnn

    Writing text to an image

    Kind of what I was hoping to avoid but I'll look into it. Most of what I'm pursuing here is an attempt to avoid drawing the text to what the GDK refers to as a bitmap and then copying that to the image. I'm guilty of being overly concerned with things that add time to the process. AAR, you've given me something to think on and a direction to go. I offer my thanks for your help. Lilith
  7. LilithAnn

    Writing text to an image

    Quote: The debug runtimes will still be able to tell you if there's a D3D call failing though. Running through debug I'm getting a strange result with the statement result = device->SetRenderTarget(0, pSurfaceLevel); On the two previous calls I received S_OK in return. On this one I got a value returned that didn't get back S_OK or D3DERR_INVALIDCALL. Instead I got 0x8876086c. So I assume that it's failing in some sense there but I can't imagine what the return value indicates or why it would fail. Lilith
  8. LilithAnn

    Writing text to an image

    I'm unable to comply. The Dark GDK API creates the texture and, for my purposes, I need to let them since its relationship to the sprite involved is dependent on their system. They provide code to load the image from file but there are some undocumented functions in their image header file for creating "empty" images. LPDIRECT3DTEXTURE9 dbMakeImage ( int iID, int iWidth, int iHeight ); LPDIRECT3DTEXTURE9 dbMakeImageUsage ( int iID, int iWidth, int iHeight, DWORD dwUsage ); LPDIRECT3DTEXTURE9 dbMakeImageJustFormat ( int iID, int iWidth, int iHeight, D3DFORMAT Format ); LPDIRECT3DTEXTURE9 dbMakeImageRenderTarget ( int iID, int iWidth, int iHeight, D3DFORMAT Format ); I've used an image that I've let their code load from a file and I've also allowed for using the dbMakeImage() function to create an empty. The int iID identifier is their internal numbering for the image which I provide when I make the function call. They provide LPDIRECT3DTEXTURE9 dbGetImagePointer ( int iID ); in order to return a pointer to the image object, which I assign to "data". Lilith
  9. LilithAnn

    Writing text to an image

    Yes. I'm sorry about the brevity of my naming conventions. It's one of my weak points. I use it to lock the area and set imgPtr to the beginning of the pixel area. This is my locking method. void Image::Lock(void) { data->LockRect(0, &imgData, NULL, 0); imgPtr = imgData.pBits; pitch32 = imgData.Pitch / sizeof (DWORD); bytes = (DWORD *) imgPtr; locked = true; } Lilith
  10. Scenario: Using Dark GDK for game development. It's drawing capability is limited to bitmaps and the screen (simplified statement). Dark GDK is a C++ interface to DirectX functionality, though I see more procedural code than OOP in their approach. So I'm working on an OOP wrapper for its 2D functionality to enhance my ability to inherit. I've created an Image class which has as some of its private data the following: DWORD width; // visible width of the image DWORD height; // visible height of the image DWORD depth; // color depth in bits DWORD size; // size of image in bytes UINT pitch8; // number of bytes across in the image, regardless of width UINT pitch32; // number of DWORDs across in the image, regardless of width UINT8 bpp; DWORD *bytes; // pointer to image data for DWORD-sized data IDirect3DDevice9 *device; LPDIRECT3DTEXTURE9 data; // pointer to image object D3DLOCKED_RECT imgData; // locking rectangle ID3DXFont *font; // pointer to font data UINT cursorX; // cursor x position for printing UINT cursorY; // cursor y position for printing UINT printW; // print width UINT printH; // print height void * imgPtr; // void pointer to the pixel data LPSTR pData; I've been able to develop some fucntions for drawing directly to the image, which is then displayed in conjunction with a sprite as needed. What I've found is that, whereas I can use the GDK to write text to the screen and a bitmap, I need to provide that capability directly to an image. The text may not need to be displayed immediately but whenever the image is displayed it needs to be there. After "borrowing" some code I've come up with the following for establishing the font. Some of it is hardcoded but that's only for developmental purposes. It still returns S_OK. bool Image::SetFont(int h, UINT w, UINT weight, bool italics, LPCTSTR pFacename) { if (font != NULL) font->Release(); HRESULT result = D3DXCreateFont (device, h, w, weight, 0, false, DEFAULT_CHARSET, OUT_DEFAULT_PRECIS, DEFAULT_QUALITY, DEFAULT_PITCH, pFacename, &font); return (result == S_OK); } Below is the code I use to "try" to draw the text string to the image. In my test environment the image starts out blank white and the color I'm passing for the text is black. The code I was borrowing had a clear statement that I used initially but decided to remove since it wasn't necessary. The code also had pSurfaceLevel->Release(); statement, which I left in, but I'm not certain where the locking is being done, if it was in the code at all. void Image::Print(LPSTR text, DWORD color) { RECT rct; IDirect3DSurface9 *pSurfaceLevel; // pointer to surface IDirect3DSurface9 *pSurfaceSave; // pointer to current render target device->GetRenderTarget(0, &pSurfaceSave); data->GetSurfaceLevel(0, &pSurfaceLevel); device->SetRenderTarget(0, pSurfaceLevel); rct.left = cursorX; rct.right = cursorX + printW; rct.top = cursorY; rct.bottom = cursorY + printH; D3DCOLOR prtColor = color; if (font == NULL) return; font->DrawText(NULL, text, -1, &rct, DT_CENTER | DT_VCENTER, prtColor); device->SetRenderTarget(0, pSurfaceSave); pSurfaceLevel->Release(); } The text doesn't appear on the image. Could someone advise me if this code has any merit or if I'm totally off base? Any advice regarding the proper approach? Thanks, Lilith
  11. LilithAnn

    How is a lock level used

    Hmmm. That simple, eh? My gratitude. Lilith
  12. My immersion in DirectX is relatively new, so please bear with me. I'm using DirectX 9 but my documentation is for 8. I'm looking at the locking of a texture in preparation to writing to it. One of the parameters is a locklevel for which I've used a value of zero to this point and which works fairly well. But my drawing routines may become sub-nested and so I'd like to look at this parameter to see if I might end up stepping on my own routines and if this value can be used to avoid double locking. Any help is greatly appreciate.
  13. LilithAnn

    dark gdk

    A bit late here but I'll still put in my tuppence worth. I won't swear as to what it's actually written in but it ostensibly is intended to provide a C++ API in which to create. However, it seems that they were very careful to make everything seem to be in alignment with the API from Dark Basic. Aside from some function parameters having different footprints there isn't much of C++ or object orientation about it. Things we would consider to be objects are actually numbered items within, say, the sprite workspace or the image workspace. There are also some problems with documentation and a certain clinging to the BASIC paradigm. Some documentation indicates that something that returns the address of some memory space actually returns an int. Yet Intellisense says it returns a DWORD. I hesitate to cast something like that to a pointer. Having said that, I still find it useful and am in the process of creating some simple-minded encapsulation to ease some of my 2D game programming. It provides some things that required more attention to detail in other APIs I've tried. The version for C# .NET is due out soon which may remove some of the remnants of BASIC. There are some problems that seem to arise when trying to compile in debug mode if you include some of the standard library #includes but an adjustment in the project usually takes care of that.
  14. LilithAnn

    problem with SDL

    I'm pretty bad at following other people's code, so I'll hazard a guess. Any possibility that you may be reassigning surfaces regularly without freeing them first?
  15. LilithAnn

    Game classes

    Quote:Amoung other things, building a test harness around your app just got lots easier. [snip] There are a bunch of reasons. They may not be convincing -- but they can help. Quite a bit to consume there and I'm not sure I'm going to see it all in one glance. I may have to try this two or more ways to see what works and if I can warp, uh, wrap my head around it. Thanks for your input. Lilith
  • Advertisement

Important Information

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

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!