Thread: Loading a Bitmap w/ DirectX

  1. #16
    Registered User
    Join Date
    Sep 2011
    Posts
    9
    Hello Binks,
    First off I am not sure I agree with some of the replies to your post. Direct X draw is a good refuge for those who program in C and dont want to use C++. It is far from dead, Microsoft would probably like it to disappear but that is another matter. I also had problems running DD in Visual C, Borland helped out, and now I am doing a project using DD and the free lcc-win32 compiler. My project is ad-infinitum and is housed at https://sourceforge.net/projects/ad-infinitum/
    take a look at the code in the code files of the downloaded project. It uses earlier Direct Draw and is probably compatible with DD3. Compare to what you use. The program itself is deeply complex and is really a mass pointers and linked virtual nodes etc, but I keep the windows direct x bare bones and simple, so you should get a clear picture. Note that one of the changes I made recently was to place ALL the graphics in system memory. There are no graphics cards out there that I know that use Direct Draw. What this means is that Direct Draw will run (it is software operated), it will even place the graphics in the video card memory (it thinks its faster), but that operation is useless and time consuming. In order to manipulate the images they now need to leave the graphics memory, go back to system memory then back to graphics, time consuminting. Cards are now geared to boring 3D, the market in its infinite wisdom love going down the same path so good buy 2D. Bypassing the cards and placing the images specificaly in system memory is now the fastest and best aproach; computers system memory have now increased considerably in size and speed, your 2D will be faster than the 2D in the days they made cards compatiple for DD.
    would be good if you keep me posted on your progress learning DD. I would welcome a bit of help on my project.
    One of the problems you may be up against is placing the images in 24 bits, 32 bits is standard and I remember having problems using 24bits, it is also (when it works) very slow, bits are lined up in groups of 32 (or 64) now days and it is silly in my view to try and save memory here.
    All the best, BB

    p.s. i noticed this in your code:
    *removed*
    update: cancel that, noticed dimentions were for your off screen surface not primary, and your screen dimentions seem set to
    #define WINDOW_WIDTH 1280
    #define WINDOW_HEIGHT 1024


    Last edited by BrodieBrodie; 09-28-2011 at 12:39 PM. Reason: add info on screen size

  2. #17
    Registered User
    Join Date
    Mar 2011
    Posts
    216
    Thanks for the reply. It's good to know that not every solo programmer has gone onto D3D. And I will definately consider teaming up in the future.

    Now to the code, I was wondering exactly what you suggested as well. In a simpler program that just sets DD up, it reported that it failed to set the display mode to 24 bits, and only 8, 16, and 32 bits returned success. But I don't see how that works, so I left it at 32 bits, figuring it would (hopefully) fill the remaining bits with 0's.

    I checked out your code, and it looks as if you use GDI to display bitmaps (correct me if I'm wrong).

    Have you seen my bitmap loading code? Is there anything you can tell wrong with it?

    BTW, I checked your program + source out. It's awesome!

  3. #18
    Registered User
    Join Date
    Sep 2011
    Posts
    9
    Thanks for your comments on my project.
    yep I use the GDI, but not to display bitmaps, but to avoid the part that is causing you headeachs. This code:

    Code:
    BOOL LoadMyImage( LPDIRECTDRAWSURFACE lpDDS, LPSTR szImage )
    {
        HBITMAP         hbm;
        HDC             hdcImage= NULL;
        HDC             hdcSurf = NULL;
        BOOL            bReturn = FALSE;
    
        ZeroMemory( &ddsd, sizeof( ddsd ) );
        ddsd.dwSize = sizeof( ddsd );
    
        if ( FAILED( lpDDS->GetSurfaceDesc( &ddsd ) ) )
     {
      debugfile ("failed to link surface in load.\n",1 );
      goto Exit;
        }
    
        // Try loading the image.
        hbm = ( HBITMAP )LoadImage( NULL, szImage,
                IMAGE_BITMAP, ddsd.dwWidth,
                ddsd.dwHeight, LR_LOADFROMFILE | LR_CREATEDIBSECTION );
    
        if ( hbm == NULL )
     {
      debugfile ("no resourse.\n",1 );
      OutputDebugString( " Couldn't find the resource.\n" );
            goto Exit;
        }
    
        // Create a DC and select the image into it.
        hdcImage = CreateCompatibleDC( NULL );
        SelectObject( hdcImage, hbm );
    
        // Get a DC for the surface.
        if ( FAILED( lpDDS->GetDC( &hdcSurf ) ) )
     {
      debugfile ("no dc.\n",1 );
      OutputDebugString( "Couldn't get a DC.\n" );
            goto Exit;
        }
    
        // The BitBlt will perform format conversion as necessary.
        if ( BitBlt( hdcSurf, 0, 0, ddsd.dwWidth, ddsd.dwHeight,
            hdcImage, 0, 0, SRCCOPY ) == FALSE )
     {
      debugfile ("blt failed.\n",1 );
      OutputDebugString( "Blt failed.\n" );
            goto Exit;
        }
    
     // Success.
        bReturn = TRUE;
    
    Exit:
        // Clean up everything.
        if ( hdcSurf )
            lpDDS->ReleaseDC( hdcSurf );
        if ( hdcImage )
            DeleteDC( hdcImage );
        if( hbm )
            DeleteObject( hbm );
    
        return bReturn;
    }
    uses the GDI to load up the images, but Direct Draw takes over from there. Using the GDI is a bit like going on autopilot: it coverts formats, reverses images (BMP's are upside down on disk and have to be reversed), etc automatically. I see your code is doing the same things but manualy.

    I am not a widows programer, so try to take the simplest option, hense using the GDI to do all the dirty work.

    I cant realy help you on your code as the problem is likly to be windows orientated. When I get into problems when using functions I am unfamiliar with I put debug lines every step of the way (not just where the program may return an error, but everywhere) to see where the program is stoping; i.e.:
    Code:
    debugfile ("Couldn't set cooperative level.\n",1 );
    [....code.....]
    debugfile ("starting to load image.\n",1 );
    [....code.....]
    debugfile ("finished loading image.\n",1 );
    [....code.....]
    debugfile ("now the program is doing somthing else....\n",1 );
    etc
    where debugfile is my little text output device:

    Code:
    // turn on/off debugger
    int Debug_write=true; ///true in on, false is off
    
    int debugfile (char *szMsg, long number)
    {
       if  (Debug_write == false)
       {
      return false;
       }
     FILE *stream;
       //char string[40];
       //char mesg[20];
    
       /* open a file for update */
       stream = fopen("debug.txt", "a");
       if (stream==NULL)
       {
          return false;
       }
    
    
       /* seek to the end of the file */
       fseek(stream, 0, SEEK_END);
    
       /* write a string to the file */
       //fputs(string, stream);
    
       fprintf(stream, "%-8ld %s", number, szMsg);
    
       fclose(stream);
    
       return true;
    }
    this places the info in a handy debug.txt file
    a bit like the inbuilt compiler debugers, but more handy in my view.
    Use this (not just where the program returns an error but also label where the program has passed every step of the way) and tell me where the exact location the program is stoping.
    Last edited by BrodieBrodie; 09-29-2011 at 03:01 AM. Reason: add highlight

  4. #19
    Master Apprentice phantomotap's Avatar
    Join Date
    Jan 2008
    Posts
    5,108
    Note that one of the [...] and save memory here.
    O_o

    *looks sideways at massive stack of clones*

    I hate to be the one to tell you this, but using the "Direct3D" API doesn't mean that you have to abandon the style of 2D games you want to make.

    Slapping an appropriate texture on a simple rectangular plain positioned correctly within the camera's view with the right mode of rendering gives you the same feel as "DirectDraw".

    Soma

  5. #20
    Registered User
    Join Date
    Sep 2011
    Posts
    9

    Wink 2D or not 2D, now that is the question

    Aye, but that would be overkill in my view. One of the things I learnt from programming in C was economy of language. One tries to only load up what is needed (stdio.h, math.h, stdlib.h etc). Using the huge complicated libraries of 3D, and using the advanced mathematics involved in 3 dimensional space, with rendering, points of view, and textures to create a 2 Dimensional universe when libraries exist that not only function, but are very fast and efficient at creating and displaying 2D bitmaps, seems to me a curious way to go about it. My thinking is that it is best to use the tools that are most suited to the task one tries to undertake. Sure, you can hit a fly with a bazooka, but simpler ways are also available. I saw some simple games (e.g tic tac toe) using nothing more than the x and o characters, perfectly appropriate for such a game, but then again I suppose they could have done the same game using 3D, surround sound, vibrating joysticks, explosions....

  6. #21
    Registered User VirtualAce's Avatar
    Join Date
    Aug 2001
    Posts
    9,607
    First off I am not sure I agree with some of the replies to your post. Direct X draw is a good refuge for those who program in C and dont want to use C++.
    What? Since both Direct3D and DirectDraw use COM and are both accessible from C or C++ I fail to see how this has anything to do with what you use.

    It is far from dead, Microsoft would probably like it to disappear but that is another matter.
    It has been officially deprecated. Microsoft does not control when or where DirectDraw is broken or by whom b/c this is up to the driver manufacturers. They simply specify the API and the driver folks implement it. DirectDraw and Direct3D are both interfaces that are implemented by the driver manufacturers. The problem with using deprecated methods is that you are using a shaky platform on which to build your code base. Direct3D is quite adequate for doing 2D graphics and there is no need for DirectDraw. You can also utilize shaders in 2D if you use Direct3D and DirectDraw cannot match the power, speed, or flexibility that shaders offer in a 2D game.
    Having personally played a key role in the design of a 2D system using Direct3D for my current company I can tell you that Direct3D is definitely what you want to be using and is up to the task and will be much simpler than the equivalent DirectDraw code. All of the CoCreateInstance() nastiness in COM has all but been removed in Direct3D and it is now more accessible than it ever has been. You can use Direct3D 9, 10, or 11 for 2D just as much as you can for 3D.

    DirectDraw may function on certain cards or perhaps all of them but it is a poor software development practice to build code bases that use deprecated functions. You can do it but the risk is always there that one day you will turn around and half your code line ceases to function because of one driver upgrade or MS hotfix. DirectDraw was deprecated in DirectX8 if I remember correctly and was integrated into Direct3D to create DirectGraphics. However almost no one refers to DirectDraw anymore and simply calls it Direct3D. Also of note DirectInput is going to be deprecated in favor of XInput and DirectMusic and DirectPlay have already been deprecated. DirectShow has been moved to the Windows SDK and is no longer a part of the DirectX SDK. A lot has changed and it is difficult to keep up but if you want to develop apps that rely on MS APIs it is best to play by their rules and not your own.

    The only deprecated functions I would stand to use in my code are Win32 API functions since MS almost never breaks backwards compatibility in the API. However, if it were my code line I would not pass a review that used deprecated API functions simply b/c there are newer functions that do the same and more and carry less risk.

    Note that one of the changes I made recently was to place ALL the graphics in system memory.
    How is this faster than placing them in video card memory which runs on the video card bus independent of the system bus? The video card bus does not have to wait on the CPU or share the bus with the CPU. Placing graphics and resources on the video card is ALWAYS faster than placing them in system memory. Check the SDK for more information. The more you can get in video memory the better your performance will be. This is why most games will cram as much as they can into video memory during the loading of worlds or levels and it is also why NVidia and ATI are cramming as much video memory on a card that they can.

    Cards are now geared to boring 3D, the market in its infinite wisdom love going down the same path so good buy 2D. Bypassing the cards and placing the images specificaly in system memory is now the fastest and best aproach; computers system memory have now increased considerably in size and speed, your 2D will be faster than the 2D in the days they made cards compatiple for DD.
    This is wrong on many levels except for the statement that cards are geared to 3D. System memory is not faster than video memory for many reasons. While your current system memory may be faster than the old video card memory it is not faster than today's video card memory. System memory is not faster than video card memory. The only chip that may change this is the Intel Sandy Bridge chipset which has the GPU on the CPU and thus has dedicated video memory for the GPU. Since I do not know how this works I will not comment on it further. I work on embedded systems and I can tell you that without a dedicated video card you can cram all you want into system memory or shared memory and will never reach the potential of a dedicated video card with dedicated video memory. Based on our tests our boards performed up to 4x or 5x better with a video card than our fastest system without a card.
    Last edited by VirtualAce; 09-29-2011 at 10:39 PM.

  7. #22
    Registered User
    Join Date
    Sep 2011
    Posts
    9

    the reports of my death are greatly exaggerated

    Quote Originally Posted by VirtualAce View Post
    are both accessible from C or C++ I fail to see how this has anything to do with what you use.
    aye, but I find most of the documentation for Direct3D to be written for C++, whereas DirectDraw has plenty of documentation, books and examples, etc writen in good old C

    It has been officially deprecated.
    aye, and so you keep repeating from 2005 e.g.:

    "Crappy ones. DirectDraw IS deprecated and dead. It has been merged with Direct3D to produce DirectGraphics"

    my thinking is that the reports of DDraw'd death are greatly exaggerated. Still I get the message and will withdraw from this forum as it is not what I originaly thought it to be. Seems this site is dedicated to state of the art games programming. It must anoy you no end to have people like me keep jumping in over the years with all these misconceptions. Sorry about that.

    How is this faster than placing them in video card memory
    well it was DDraw not D3D I was talking about. I understand your confusion. Direct Draw is not just a fancy pixel pump (if I was just pumping pixels you would be correct) but has several useful data maniputlation tools, the most obvious of these is the shrinking bitmap operation. In the old days, cards handled this and it was faster, and if those old computers did not have a video card, DD sofware could do it. This is how it all started. Cards now do not suport Direct Draw (this is probably what you mean by "deprecated") and do not know how to shrink, rotate, mirror image etc a bitmap. What happens on todays cards when using the old DD routines is that the data (or bitmap) is sent back to the system memory, DD sofware takes over and resizes (or mirrors etc) the image, the whole is then sent back to the video card and then displayed, a bit of a pointless journey. I was findind my code was working faster on older machines so checked with microsoft. The solution now for Direct Draw is to keep the data in system memory, it improves the speed by about 25%. Load up my project by putting the grafix in video memory and see for yourself.

    to do this you need to delete the two bit flags, both writen as:
    Code:
      | DDSCAPS_SYSTEMMEMORY
    and both in the .c file.
    the program will then automaticaly place all in video memory, and test the result at the world "CAPITAL" (this world has 47*47 land sprites and about 40*40 structure sprites, and hundreds of manikine sprites pathfindind through thousands of nodes, and all this is also passed throw shrinkinking operations ajusted to the users screens size if the world is viewed from orbit. So this is a good place to measure the speed)

    But then again this is probably just academical to you. Sorry to bother you all. Good buy
    BB

  8. #23
    Registered User VirtualAce's Avatar
    Join Date
    Aug 2001
    Posts
    9,607
    Cards now do not suport Direct Draw (this is probably what you mean by "deprecated") and do not know how to shrink, rotate, mirror image etc a bitmap.
    Yes they do. You shrink the quad and you shrink the bitmap. The bitmap stays the same size in memory regardless which means no more scaling, rotating ,etc. If you take advantage of the rasterizer in the hardware you do not have to do anything with the bitmap b/c when you rotate, scale, etc. it is all handled for you.

    As to wrap, mirror, etc. it those are supported as well through SetSamplerState().

    From the D3D9 SDK:
    D3DSAMPLERSTATETYPE
    Sampler states define texture sampling operations such as texture addressing and texture filtering. Some sampler states set-up vertex processing, and some set-up pixel processing. Sampler states can be saved and restored using stateblocks (see State Blocks Save and Restore State (Direct3D 9)).

    Code:
    typedef enum D3DSAMPLERSTATETYPE
    {
        D3DSAMP_ADDRESSU = 1,
        D3DSAMP_ADDRESSV = 2,
        D3DSAMP_ADDRESSW = 3,
        D3DSAMP_BORDERCOLOR = 4,
        D3DSAMP_MAGFILTER = 5,
        D3DSAMP_MINFILTER = 6,
        D3DSAMP_MIPFILTER = 7,
        D3DSAMP_MIPMAPLODBIAS = 8,
        D3DSAMP_MAXMIPLEVEL = 9,
        D3DSAMP_MAXANISOTROPY = 10,
        D3DSAMP_SRGBTEXTURE = 11,
        D3DSAMP_ELEMENTINDEX = 12,
        D3DSAMP_DMAPOFFSET = 13,
        D3DSAMP_FORCE_DWORD = 0x7fffffff,
    } D3DSAMPLERSTATETYPE, *LPD3DSAMPLERSTATETYPE;
    Constants
    D3DSAMP_ADDRESSU
    Texture-address mode for the u coordinate. The default is D3DTADDRESS_WRAP. For more information, see D3DTEXTUREADDRESS.
    D3DSAMP_ADDRESSV
    Texture-address mode for the v coordinate. The default is D3DTADDRESS_WRAP. For more information, see D3DTEXTUREADDRESS.
    D3DSAMP_ADDRESSW
    Texture-address mode for the w coordinate. The default is D3DTADDRESS_WRAP. For more information, see D3DTEXTUREADDRESS.
    D3DSAMP_BORDERCOLOR
    Border color or type D3DCOLOR. The default color is 0x00000000.
    D3DSAMP_MAGFILTER
    Magnification filter of type D3DTEXTUREFILTERTYPE. The default value is D3DTEXF_POINT.
    D3DSAMP_MINFILTER
    Minification filter of type D3DTEXTUREFILTERTYPE. The default value is D3DTEXF_POINT.
    D3DSAMP_MIPFILTER
    Mipmap filter to use during minification. See D3DTEXTUREFILTERTYPE. The default value is D3DTEXF_NONE.
    D3DSAMP_MIPMAPLODBIAS
    Mipmap level-of-detail bias. The default value is zero.
    D3DSAMP_MAXMIPLEVEL
    level-of-detail index of largest map to use. Values range from 0 to (n - 1) where 0 is the largest. The default value is zero.
    D3DSAMP_MAXANISOTROPY
    DWORD maximum anisotropy. The default value is 1.
    D3DSAMP_SRGBTEXTURE
    Gamma correction value. The default value is 0, which means gamma is 1.0 and no correction is required. Otherwise, this value means that the sampler should assume gamma of 2.2 on the content and convert it to linear (gamma 1.0) before presenting it to the pixel shader.
    D3DSAMP_ELEMENTINDEX
    When a multielement texture is assigned to the sampler, this indicates which element index to use. The default value is 0.
    D3DSAMP_DMAPOFFSET
    Vertex offset in the presampled displacement map. This is a constant used by the tessellator, its default value is 0.
    D3DSAMP_FORCE_DWORD
    Forces this enumeration to compile to 32 bits in size. Without this value, some compilers would allow this enumeration to compile to a size other than 32 bits. This value is not used.
    Requirements
    Header: Declared in D3D9Types.h.
    If you admit that cards do not support DirectDraw then why do you insist on telling others to use it? As well DirectDraw is supported by the cards but there is no guarantee it won't be broken at any moment by updates, etc. Deprecated means future software should not depend on it.

    It must anoy you no end to have people like me keep jumping in over the years with all these misconceptions.
    More like incorrect information than misconceptions.

    The solution now for Direct Draw is to keep the data in system memory, it improves the speed by about 25%
    Sorry, I don't buy that. They wouldn't even assist with a bug in a far more modern part of D3DX so I doubt they even talked about DirectDraw.

    Here is an excerpt from the SDK about memory pools in Direct3D.

    D3DPOOL
    Defines the memory class that holds the buffers for a resource.

    Code:
    typedef enum D3DPOOL
    {
        D3DPOOL_DEFAULT = 0,
        D3DPOOL_MANAGED = 1,
        D3DPOOL_SYSTEMMEM = 2,
        D3DPOOL_SCRATCH = 3,
        D3DPOOL_FORCE_DWORD = 0x7fffffff,
    } D3DPOOL, *LPD3DPOOL;
    Constants
    D3DPOOL_DEFAULT
    Resources are placed in the memory pool most appropriate for the set of usages requested for the given resource. This is usually video memory, including both local video memory and AGP memory. The D3DPOOL_DEFAULT pool is separate from D3DPOOL_MANAGED and D3DPOOL_SYSTEMMEM, and it specifies that the resource is placed in the preferred memory for device access. Note that D3DPOOL_DEFAULT never indicates that either D3DPOOL_MANAGED or D3DPOOL_SYSTEMMEM should be chosen as the memory pool type for this resource. Textures placed in the D3DPOOL_DEFAULT pool cannot be locked unless they are dynamic textures or they are private, FOURCC, driver formats. To access unlockable textures, you must use functions such as IDirect3DDevice9::UpdateSurface, IDirect3DDevice9::UpdateTexture, IDirect3DDevice9::GetFrontBufferData, and IDirect3DDevice9::GetRenderTargetData. D3DPOOL_MANAGED is probably a better choice than D3DPOOL_DEFAULT for most applications. Note that some textures created in driver-proprietary pixel formats, unknown to the Direct3D runtime, can be locked. Also note that - unlike textures - swap chain back buffers, render targets, vertex buffers, and index buffers can be locked. When a device is lost, resources created using D3DPOOL_DEFAULT must be released before calling IDirect3DDevice9::Reset. For more information, see Lost Devices (Direct3D 9).
    When creating resources with D3DPOOL_DEFAULT, if video card memory is already committed, managed resources will be evicted to free enough memory to satisfy the request.

    D3DPOOL_MANAGED
    Resources are copied automatically to device-accessible memory as needed. Managed resources are backed by system memory and do not need to be recreated when a device is lost. See Managing Resources (Direct3D 9) for more information. Managed resources can be locked. Only the system-memory copy is directly modified. Direct3D copies your changes to driver-accessible memory as needed. Differences between Direct3D 9 and Direct3D 9Ex:

    D3DPOOL_MANAGED is valid with IDirect3DDevice9; however, it is not valid with IDirect3DDevice9Ex.


    D3DPOOL_SYSTEMMEM
    Resources are placed in memory that is not typically accessible by the Direct3D device. This memory allocation consumes system RAM but does not reduce pageable RAM. These resources do not need to be recreated when a device is lost. Resources in this pool can be locked and can be used as the source for a IDirect3DDevice9::UpdateSurface or IDirect3DDevice9::UpdateTexture operation to a memory resource created with D3DPOOL_DEFAULT.
    D3DPOOL_SCRATCH
    Resources are placed in system RAM and do not need to be recreated when a device is lost. These resources are not bound by device size or format restrictions. Because of this, these resources cannot be accessed by the Direct3D device nor set as textures or render targets. However, these resources can always be created, locked, and copied.
    D3DPOOL_FORCE_DWORD
    Forces this enumeration to compile to 32 bits in size. Without this value, some compilers would allow this enumeration to compile to a size other than 32 bits. This value is not used.
    Remarks
    All pool types are valid with all resources including: vertex buffers, index buffers, textures, and surfaces.

    The following tables indicate restrictions on pool types for render targets, depth stencils, and dynamic and mipmap usages. An x indicates a compatible combination; lack of an x indicates incompatibility.

    Pool D3DUSAGE_RENDERTARGET D3DUSAGE_DEPTHSTENCIL
    D3DPOOL_DEFAULT x x
    D3DPOOL_MANAGED
    D3DPOOL_SCRATCH
    D3DPOOL_SYSTEMMEM
    Pool D3DUSAGE_DYNAMIC D3DUSAGE_AUTOGENMIPMAP
    D3DPOOL_DEFAULT x x
    D3DPOOL_MANAGED x
    D3DPOOL_SCRATCH
    D3DPOOL_SYSTEMMEM x

    For more information about usage types, see D3DUSAGE.

    Pools cannot be mixed for different objects contained within one resource (mip levels in a mipmap) and, when a pool is chosen, it cannot be changed.

    Applications should use D3DPOOL_MANAGED for most static resources because this saves the application from having to deal with lost devices. (Managed resources are restored by the runtime.) This is especially beneficial for unified memory architecture (UMA) systems. Other dynamic resources are not a good match for D3DPOOL_MANAGED. In fact, index buffers and vertex buffers cannot be created using D3DPOOL_MANAGED together with D3DUSAGE_DYNAMIC.

    For dynamic textures, it is sometimes desirable to use a pair of video memory and system memory textures, allocating the video memory using D3DPOOL_DEFAULT and the system memory using D3DPOOL_SYSTEMMEM. You can lock and modify the bits of the system memory texture using a locking method. Then you can update the video memory texture using IDirect3DDevice9::UpdateTexture.

    Requirements
    Header: Declared in D3D9Types.h.

    See Also
    D3DUSAGE, IDirect3DDevice9::CreateCubeTexture, IDirect3DDevice9::CreateIndexBuffer, IDirect3DDevice9::CreateTexture, IDirect3DDevice9::CreateVolumeTexture, IDirect3DDevice9::CreateVertexBuffer, D3DINDEXBUFFER_DESC, D3DSURFACE_DESC, D3DVERTEXBUFFER_DESC, D3DVOLUME_DESC
    And we are hardly talking state of the art graphics here. Direct3D 9 has been around for almost 8 years and DirectX 8 before it for about 2 to 3. DirectDraw 7 was introduced more than a decade ago. Heck DirectX9 is antiquated by today's standards but we are prob. stuck with it until the consoles can support 10 or 11. Pure PC studios are few and far between and most have moved to DX10 or DX11 but everyone else appears to still be on DX9.

    In graphics if you are touching texels and you are not inside of shader you should be asking yourself why and for how long. Surfaces are normally used as render surfaces but other than that you rarely if ever touch the surface outside of shader b/c of fears of pipeline stalls. Placing graphics and resources in system memory is one sure way to cause pipeline stalls. Granted not everything can fit on the card and this comes down to a judgement call based on the requirements of the project.

  9. #24
    Registered User
    Join Date
    Mar 2011
    Posts
    216
    One question for the D3D Gurus, what functions do I need from D3D to replace the DirectDraw functions I have. To be specific, which functions will create surfaces, load bitmaps, and allow for basic game making necessities? I'm looking for simplified solutions for a beginner of DirectX.

  10. #25
    Registered User
    Join Date
    Sep 2011
    Posts
    9

    Microsoft call it HEL, I call it paradise

    First off Virtual Ace , thanks for taking the time for such a details reply. The thing is that while i use Direct, I don't use D3D, i use Direct Draw, and the way direct draw (for example) mirrors a bitmap is different to the way this is done with 3d textures in D3D. Yes D3D mirrors, shrinks etc bitmaps, only these are done i think in diferent ways to DD. In order to mirror a bitmap in 2 dimensions, in DD all you need to do is read it a different way eg:

    123
    456
    789

    mirrored along the y axis in 2D is

    321
    654
    987

    simple, this can can done by hardware (and curiously, although it is so simple, I believe cards no longer know how to unless it is in 3 dimentions) or direct draw software (when I say "software" I mean a direct draw program that is located and runs in system memory along with one's game's aplication, like a simple call to a function), one can even write a simple routine to do if onself, only why bother, its all waiting to bre used. Why I like Direct Draw (and why I suspect Microsoft cant get rid of it) is that is does not need hardware (hardware beeing GPU, display card, video memory...) to function. This is a weakness in my view of a program written for D3D, they on the other hand need hardware to function. My recent project has specific instructions telling the computer not to use a graphic card, and it works. Microsoft identified the fact that direct draw did not need hardware and often functioned better without as early as 1998 in their publication: Inside DirectX, Microsoft Press 1998, by B Bargen and P Donnelly; pp. 76 “Contrary to what you might reasonably assume, display memory isn’t always the optimal location for a surface. Depending on what functionality DirectDraw emulates and what functionality the specific display card implements, it might be best to place the surface in system memory, where DirectDraw can access it more quickly using the system’s CPU.”. Given that Direct draw is no longer implemented by cards, it is logical, and I have noticed the difference, to place surfaces and buffers in system memory, let software manipulate them and then send them direct to the monitor without passing ones 3d grafics card. In Direct Draw, the sofware (your dd library funtions) can emulate what the hardware does (or rather what hardware is meant to do but no longer in the case of DD does), and with DDraw the program does not need hardware to operate. It is all realy that basic and that simple. in boring technical jargon, I use DirectDraw HEL (Hardware emulation level) Architechture and dont bother with the HAL, Hardware Abstaction Level. I advise this to others as you dont need to keep updating with the new versions of DirectX, nor will your program be dependent on hardware, it will funtion as long as windows exists and on all versions of window that suport Direct X 3.0 or better, (windows 95, Nt, 2000, XP, Vista, 7, etc...) it will even funtion on unix platforms that simulate windows, e.g WINE. ie. ones program become very portable, and is curiously, more likely to survive updates than D3D software (who'se dependence on the HAL will make these programs obsolet very quickly). It is also much, much more simple to program DD than in D3D (at least for a poor lonesome C programmer who doesnt have much time like myself). It is also sort of more logical for me to program in 2d if you want an aplication in 2d, rather than simulating 2d via 3d, i sort of think this way.

    Not sure why you are showing me lots of D3D enumerations, they are interesting, but it is Direct Draw I am trying to address. I suppose I could copy paste and show you Direct Draw’s enumerations, only I don't see the point.


    Look Virtual Ace, I think we both come from different perspectives. I am programing a free game for widows that is designed to function without a sophisticated graphic’s card and is compatible with anything down to and including windows NT (I am using Direct Draw 3.0). I am a lone programmer trying to program for a very wide market. Direct Draw is a logical solution for me. Phantomotap's sugestion of “Slapping an appropriate texture on a simple rectangular plain positioned correctly within the camera's view with the right mode of rendering gives you the same feel as "DirectDraw".” does not work for me, the project I am doing is not a texture on a plain. Like all games since space invaders, the whole is a little more complicated and made up of thousands (to be tens of thousands) of objects moving and/or animated, these objects are often interlinked in none linear fashions and are not always rectangular (e.g. hexes). If I had several lifetimes or a huge team assisting me, and was after serrious money, no doubt Direct 3D would be the right way to go. You on the other had have preconceptions that direct draw games are “crappy ones”. Well they may be crappy but at least those programming them are managing as individuals to complet them in our spare time.

    Thanks for taking the time to respond but I think we both agree this is one of approach. There is nothing wrong with your approach of using the latest developments, but I think there is nothing wrong with using a way that is "outdated" if that way works.

    Yours ever, BB

    p.s. i'm still trying to work out how you think i can cause a pipeline stall. Which pipeline? The pipeline between the GPU and the CPU? If so you have no idea what I am talking about: I do not use the GPU, have you understood eanithing about DirectX? I use DD in the HEL, I only use the CPU, so how an earth could i possibly stall the link between the GPU and the CPU? All very strange. I think the problem is that you have no idea how DD functions and why it is still about. It is very simple, DirectDraw (for the most part ie.e if you dont use overlay or rotate bmps, but lets not complicate the issue) needs only the CPU, system memory, windows, and a screen, all the rest in optional, hence its amazing vitality anfd strengh.
    Last edited by BrodieBrodie; 10-03-2011 at 09:53 AM. Reason: typo

  11. #26
    Master Apprentice phantomotap's Avatar
    Join Date
    Jan 2008
    Posts
    5,108
    O_o

    I think you need to read up on "HAL" and "HEL".

    Specifically, you need to read up on the fact that "HEL" operates by forwarding to the GPU if the particular driver supports a particular part of the interface and how some cards implemented the required interfaces by abstracting the mechanisms implementing the 3D aspects.

    "Direct X" is built on a set of interfaces that depend on both layers; yes, "Direct 3D" has a "HEL" of its own. Different generations of "Direct X" deprecate old feature and require new minimum interfaces be supported directly in hardware.

    In other words, you are championing "Direct Draw" for invalid reasons.

    Now, it doesn't hurt to use "Direct Draw" if that is what you want, but let's not spread your false notions.

    Soma

  12. #27
    Registered User VirtualAce's Avatar
    Join Date
    Aug 2001
    Posts
    9,607
    There is nothing wrong with your approach of using the latest developments, but I think there is nothing wrong with using a way that is "outdated" if that way works.
    DirectX9 is now outdated. It's not about outdated or not its about whether you are building your applications on deprecated technology. If you are then you are shooting yourself in the foot. One day it will get you.

    I showed enumerations b/c it is clear that Direct3D can do all of the things you said it could not. Mirroring textures has been around since Direct3D was developed and yet you said it could not do it. In fact nothing you have said in this thread is at all accurate nor representative of how it all works.

  13. #28
    Registered User
    Join Date
    Sep 2011
    Posts
    9

    To few to mention

    ouch, i've been wasting my time,

    Specifically, you need to read up on the fact that "HEL" operates by forwarding to the GPU if the particular driver supports a particular part of the interface and how some cards implemented the required interfaces by abstracting the mechanisms implementing the 3D aspects.
    Thank you very much phantomotap for your concern, but I do know what the "HAL" and "HEL" are. I'm trying to work out why you think the HEL "operates by forwarding to the GPU" let me guess, you read This on the Direct Draw capability caps and confused the HRESULT GetCaps functions purpose, GetCaps is not "forwarding" it is retriving the drivers and the softwares capabilities, or perhaps you read this and got confused when you reached the word "capability (caps)". The article explains that the HEL emulates those capapabilities; that if the hardware is not instructed, or can not, it does this emulation using the CPU. In the example given the hardware can blit but not use transperancy, so the Hel takes over with the transperancy part, but allows the hardware to do the blitting part. The article also goes in to a bit of detail as to how the software does the transperancy.

    applications on deprecated technology
    hmmmm... this article might be of interest: DirectDraw
    seems to me DDraw 4.0 is getting a new lease of life in phone technology, very interesting, guess my game will be playable on phones soon, now that rings of posibilities.

    VirtualAce, I dont think Binks is planing on running his companie on Direct Draw, so who cares if it is deprecated. As long as it works, and one can use it. I think his intention was to have fun programming a game. Therefor I would, and continue to sugest, using Direct Draw.

    Looking back Binks came wanting help running DirectDraw, he was basicaly told to change and use 3d libraries. I disagreed. I now see over the years this has been this sites policy: that users are told to update if they seek help in deprecated libraries. I am new here but do not think this is the correct aproach. To me one should try and support the programmer with whatever library he or she choses and not critasize his or her choice. I then had the dubious pleasure of having a moderater lecture me on directdraw. I think I know about DirectDraw, I use it and have for many years; I continue to use DirectDraw and if I can, will assist others who express an interest in so doing. However it seems you gentlemen have convinced Binks to use 3D, and I feel my programming knowledge and technichs are not welcome here. That there seems to be insinuation that I am pedling, "false notions" and my reasons are not valid. And all this because I stoped to assist a fellow programmer. I find this site extrodinary.

    So then Binks, back to you, this is the best bet for learning 3D. Good luck, and keep us posted. Oh and Binks, I think you are better of putting your questions at said link's furrum, they are very helpful and do not critasize your programming preferences.

    Yours ever
    BB
    Last edited by BrodieBrodie; 10-04-2011 at 08:11 AM. Reason: typo

  14. #29
    Registered User
    Join Date
    Mar 2011
    Posts
    216
    *Sigh* More complicated concepts, less actual programming happening.

    Thanks for the help BrodieBrodie and you too Virtual Ace.

  15. #30
    Programming Wraith GReaper's Avatar
    Join Date
    Apr 2009
    Location
    Greece
    Posts
    2,739
    Quote Originally Posted by binks View Post
    *Sigh* More complicated concepts, less actual programming happening.
    If you want actual programming, try tackling Project Euler. This will keep you occupied for a while!
    ( Let me tell you this site does not play around! I've been struggling there for a week and up untill now I only solved 12 problems... )
    Devoted my life to programming...

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. loading a bitmap
    By hadi0x7c7 in forum C Programming
    Replies: 4
    Last Post: 06-04-2010, 03:12 PM
  2. Loading a bitmap
    By Homunculus in forum C++ Programming
    Replies: 19
    Last Post: 11-05-2007, 01:24 PM
  3. Loading Bitmap under VC++
    By abu in forum Windows Programming
    Replies: 1
    Last Post: 05-14-2004, 01:07 AM
  4. Loading bitmap in dll
    By Mithoric in forum Windows Programming
    Replies: 2
    Last Post: 12-22-2003, 01:53 PM
  5. No one can seem to help me, loading bitmap
    By Shadow12345 in forum C++ Programming
    Replies: 7
    Last Post: 12-28-2002, 01:22 PM