Other Routines For Setting a pixel onto a Device context

This is a discussion on Other Routines For Setting a pixel onto a Device context within the Game Programming forums, part of the General Programming Boards category; hey i am currently developing a rts game, and for the external resources im using palette and data files (as ...

  1. #1
    Registered User MicroFiend's Avatar
    Join Date
    Nov 2002
    Posts
    80

    Arrow Other Routines For Setting a pixel onto a Device context

    hey i am currently developing a rts game, and for the external resources im using palette and data files (as they are tiny in comparisson to its current 24-bit format) but the problem is the routine im using to read the palette and the data file uses the setpixel procedure, and this has had a huge impact on loading times, before the loading time was barely noticable, but now it takes around 13seconds, so i was wondering whether there is a faster way of setting a COLORREF to an x,y coordination of a Device context, heres my current code:

    Code:
     ifstream File2(DataPath);
     File2.setmode(filebuf::binary);
     for(int y=0;y<iHeight;y++)
      for(int x=0;x<iWidth;x++)
      {
       File2.get(Byte1);
       SetPixel(hDC,x,y,Palette[Byte1]);
      }
     File2.close();
    any help would be great, thanx
    You can stop change as easily as u can drink the sea with a fork

  2. #2
    Crazy Fool Perspective's Avatar
    Join Date
    Jan 2003
    Location
    Canada
    Posts
    2,640
    im not sure about your specific API but a general solution would be to read into an intermediate buffer; than copy to entire buffer to the device context rather than modifying the device contex for each pixel operation.

  3. #3
    Super Moderator VirtualAce's Avatar
    Join Date
    Aug 2001
    Posts
    9,596
    Simple. Wait just a few more weeks and I'll have the source ready that will allow you to do this in Direct3D via a lockable backbuffer.

    Anything GDI is going to be too slow.

    The only drawback to writing directly to a surface/memory is that you must lock the buffer which degrades performance and then you must again unlock the buffer prior to presenting the scene.

    So be patient and I'll have some source here shortly. Right now I've got some people testing it and coding inside of the framework to see if it is going to serve its purpose.

    I coded it just for people like you who want to do graphics but are not sure how to get DirectGraphics up and running.

    PM me and I'll send you what I have thus far along with instructions on how the classes are designed to be used.

  4. #4
    S Sang-drax's Avatar
    Join Date
    May 2002
    Location
    Göteborg, Sweden
    Posts
    2,072
    Quote Originally Posted by Bubba
    Anything GDI is going to be too slow.
    That is not true.
    GDI is sufficient for everything but very demanding graphics.

    I'm not saying that it is better than Direct3D, though. Direct3D is preferable, although a little bit harder to use.
    Last edited by Sang-drax : Tomorrow at 02:21 AM. Reason: Time travelling

  5. #5
    Banned
    Join Date
    Dec 2003
    Posts
    367
    Aren't all the controls in windows drawn with GDI?

  6. #6
    Registered /usr
    Join Date
    Aug 2001
    Location
    Newport, South Wales, UK
    Posts
    1,262
    Also, I think with 2000/XP Microsoft adjusted the internals of GDI to be more reliant on hardware operations (Given that over 90% of video cards have DirectX drivers), so the modern GDI isn't really that slow.

    If you want to see what GDI was like when it was really slow, try Windows 3.1.

  7. #7
    Super Moderator VirtualAce's Avatar
    Join Date
    Aug 2001
    Posts
    9,596
    GDI is still not suited for this. Why use it when you can use windowed Direct3D or DirectX?
    None of the graphics books I've read ever suggest using GDI. In fact they say to avoid any calls that use GDI like the plague. It's meant to be robust, not fast, hence the complexity of many of the calls.

  8. #8
    Used Registerer jdinger's Avatar
    Join Date
    Feb 2002
    Posts
    1,065
    If someone wasn't ready to learn DX yet, and only wanted to use some basic GDI functionality, that would be a valid reason to use it.

    When I wrote my first Windows game, I was just getting comfortable with basic Windows API calls and was definitely not ready to learn D3D (or actually DDraw, at the time).

    I wouldn't have been happy using someone else's code or a wrapper. For me, the fun of programming is not just the finished product, but what I learned in creating the finished product.

    Now that I'm learning D3D, I'm much more happy with the outcome, because I'm writing my own tranformation matrixes, instead of using D3DX. I know some might say that's reinventing the wheel, but that's why I code in the first place: to learn.

    Bubba,
    I don't mean for my comments to knock your offer to share your code. I think that's a great gesture and admirable. I'm only saying that depending on the desires of the programmer, using GDI might be better if it means they can see their idea come to fruition and learn something in the meantime; as opposed, to trying to tackle something they're not ready for and getting frustrated.

    Jason

  9. #9
    Banned
    Join Date
    Dec 2003
    Posts
    367
    Quote Originally Posted by Bubba
    Simple. Wait just a few more weeks and I'll have the source ready that will allow you to do this in Direct3D via a lockable backbuffer.

    Anything GDI is going to be too slow.

    The only drawback to writing directly to a surface/memory is that you must lock the buffer which degrades performance and then you must again unlock the buffer prior to presenting the scene.

    So be patient and I'll have some source here shortly. Right now I've got some people testing it and coding inside of the framework to see if it is going to serve its purpose.

    I coded it just for people like you who want to do graphics but are not sure how to get DirectGraphics up and running.

    PM me and I'll send you what I have thus far along with instructions on how the classes are designed to be used.
    You said that anything GDI is slow. If so, then windows would be dragging along, since the whole interface is drawn with GDI, if I remember right. Which would also make sense if SMurf is right, because I installed Windows XP on my other computer and it ran horrribly slow until I installed my real graphics drivers.

  10. #10
    Registered /usr
    Join Date
    Aug 2001
    Location
    Newport, South Wales, UK
    Posts
    1,262
    Quote Originally Posted by bludstayne
    Which would also make sense if SMurf is right...
    What do you mean, if I'm right? Are you saying I'm fallable?!?

    But yeah, I'm almost certain GDI ops like BitBlt and StretchDIBits are hardware-accelerated these days. Also, ever tried starting out in DirectX programming and trying to debug code involving a locked buffer? It huuuuurts...

    As for doing the mind-bending stuff you do, Bubba, then D3D or perhaps OpenGL is the only way to go.

  11. #11
    Super Moderator VirtualAce's Avatar
    Join Date
    Aug 2001
    Posts
    9,596
    Learning GDI will not help you move to DirectX. GDI is mind-bending trash. Buy a book, get MSVC 6 or .NET and learn DX or OpenGL.

    You guys are just confusing yourselves. Do not pre-judge DX or OpenGL as being so hard that you cannot understand them.

    Do you understand pointers? Do you understand objects? Do you understand object oriented programming? Do you understand lines, points, primitives, vertexes? Do you know how to write to the screen via a pointer to the buffer??

    If yes...then get a book that covers the basics and have at it.

    I'm really just helping but if you want to argue that the GDI is sufficient then you have already made up your mind. But I will say this if you continue to use GDI you are not even close to coding graphics in the easiest way and you are your own worst enemy.

    The locked buffer analogy falls flat since all you must do is every time you lock a buffer you must also unlock it. Not hard.

    Dump GDI guys. It's not easier, it's slower, and it's so convoluted it hurts. I'm sitting here wondering why you guys think you can use the overly confusing obfuscated GDI calls but not the simple Direct3D API?

    I'm amazed that you can get graphics out of the GDI because I can't. I hate the GDI. BitBlt?? What?? StretchDIBBits?? What??

    How about:

    Code:
    IDirect3DTexture9 *Texture=0;
    D3DXCreateTextureFromFile(Device,"tank.bmp",&Texture);
    Now if you draw a box on the screen using pre-transformed vertexes...essentially no 3D transform and set this as the texture you have your scaled bitmap. You can also rotate it, flip it, scroll it, blend it, and do whatever you want to the thing.

    Much easier people and that code will load .bmp, .dds, .dib, .jpg, .png, and .tga. files.

    Just trust me and try either OpenGL or DirectX 9.0.
    Last edited by VirtualAce; 07-12-2004 at 08:40 PM.

  12. #12
    Used Registerer jdinger's Avatar
    Join Date
    Feb 2002
    Posts
    1,065
    Bubba,
    I'm not sure who your comments were directed towards, but if they were to me, then you may have misunderstood what I was saying. I'm not advocating that learning GDI will necessarilly help you learn DX. What I am saying is that years ago when I first started programming, learning DX was beyond me. GDI seemed, and was, a graspable tool I could use at the time. Could I have learned DX at the time? Probably, but I chose to take smaller bites. Having learned GDI, etc. didn't necessarilly lay any graphics foundations for me, but it helped me become more comfortable and confident as a programmer, because I was able to learn something right away and put it to use right away.

    I agree DX and OGL are easy, but they weren't always so easy for me (and I'm sure for you and everyone else as well). I agree with you that DX is better, but to say that everyone has to be on par with you right now is just not fair. I know some people who have written really fun, simple games in Allegro because they weren't ready to learn DX yet. The funny thing is I found setting up and using Allegro (while easy) to be more of a pain than learning and using DX. The point is: to each his own. I can't dictate what will fit the bill for someone else and neither can you. If GDI is what they want to use and it works, who are we to shoot them down?

    Jason

  13. #13
    Super Moderator VirtualAce's Avatar
    Join Date
    Aug 2001
    Posts
    9,596
    The funny thing is I found setting up and using Allegro (while easy) to be more of a pain than learning and using DX.
    Whoa there partner. Allegro and DJGPP are extremely valid libraries to use for graphics and games. That was my next suggestion. Instead of doing GDI use Allegro and DJGPP. All I'm saying is that GDI is so obfuscated and complex that it hides the pure simplicity and principles of graphics programming.

    I would use QuickBasic 7.1 before I used GDI.

    I agree with you that DX is better, but to say that everyone has to be on par with you right now is just not fair.
    No where in my post did I allude to my abilities as a DX programmer or that others somehow had to be on par with me. My comparison was between DX and GDI not between brain pans or talent. I don't know how someone could take my post so personal...but I guess they did.

    Learning GDI will get you nowhere fast in graphics programming.

    Check out these and get something that will help when you move to DirectX and/or OpenGL.

    For DJGPP, allegro, and others:
    www.delorie.com

    For articles related to graphics in general and for very good suggestions on which books to read:
    www.gamedev.net

    For very good articles from the pros on graphics, sound, D3D, OpenGL and just about everything else known to mankind about games:
    www.gamasutra.com

    For a very good intro to VGA mod 13h programming:
    www.brackeen.com

    For a huge repository of tutorials, source code, demos, etc:
    www.programmersheaven.com

    For Turbo C++ version 1.0 and the Borland command line compiler:
    www.inprise.com

    A site to download an excellent editor to use with DJGPP:
    www.rhide.com

    A great place to buy your graphics/game programming books:
    www.amazon.com

    Surprisingly a very good site about graphics programming:
    www.nvidia.com

    Very good site for graphics and game programming:
    www.flipcode.net

    Also look these up on google:

    Randally Hyde's AOA
    NASM or Netwide Assembler
    TASM
    MASM
    Turbo C++ 3.0
    Borland C++ 4.52
    Microsoft Visual C++ version 6 - student edition
    Matrix mathematics
    Lines drawing algorithms
    Scan conversion algorithms
    Bitmap rotation/scaling algorithms
    Fast circle drawing algorithms
    Lighting equations and algorithms
    Level of detail algorithms
    Terrain rendering
    Voxels and raycasting
    Equation of a sphere
    Game programmer's encyclopedia or GPE
    Peroxide tutorials on raycasting and 3D graphics.
    Transformation and lighting equations
    Quaternions
    Bezier curves
    Linear/Bilinear interpolation formulas
    Alpha blending
    Additive blending
    MMX/SSE/SSE2
    Splines
    NURBS - non uniform rational b splines
    Tile based engines
    Isometric engines
    Perspective projection
    Parallel projection
    Programing billboards and imposters
    Transparent pixels
    ...
    ...
    ...

    That should keep you busy for a bit.
    The list goes on and on.

    These will help you with games. I'm not concerned with the age of the tool, my concern here is that you get the basic premises down that apply to all graphics and/or programs...not just the stupid Windows GDI.

    There are mountains of information out there on the internet about game/graphics programming. More than you could browse in one lifetime for sure.

    When you understand what's going on underneath....you understand how to use it at a higher level.

    And to answer your question more succintly.

    Get a pointer to the buffer that the HDC is using and access the buffer directly - don't do it through a GDI call. But again....you might not be able to do this in GDI.
    Last edited by VirtualAce; 07-13-2004 at 09:07 AM.

  14. #14
    Used Registerer jdinger's Avatar
    Join Date
    Feb 2002
    Posts
    1,065
    hehehe. chill, Bubba. Not taking anything personally here and for the record I never said that Allegro wasn't valid. I said that I've known people who made fun games with it. I was just saying that I actually found DX easier to set up. I am in no way trying to say that GDI can stand against anything in DX or OGL. My point was just to each his own. I don't for a second regret the time I spent creating little useless programs with it when I first moved from console apps to Windows. Like I said I write code because I enjoy learning. Even if it's something like GDI that I don't have much use for now. The joy is in the learning. That was my point. Sorry if I didn't make that clear before.

    Jason

  15. #15
    Super Moderator VirtualAce's Avatar
    Join Date
    Aug 2001
    Posts
    9,596
    Well regardless our little rant probably gave the poster enough to think about for years.


Page 1 of 2 12 LastLast
Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Device & Rendering Context
    By hannibar in forum Windows Programming
    Replies: 1
    Last Post: 12-16-2005, 04:28 AM
  2. Device context woes
    By samGwilliam in forum Windows Programming
    Replies: 13
    Last Post: 04-16-2005, 10:01 PM
  3. Replies: 4
    Last Post: 06-30-2004, 03:11 PM
  4. Device Context
    By gvector1 in forum Windows Programming
    Replies: 2
    Last Post: 03-25-2003, 07:38 AM
  5. Replies: 1
    Last Post: 05-09-2002, 07:14 AM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21