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

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.

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.

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.

Aren't all the controls in windows drawn with GDI?

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. :p

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.

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

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.

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?!? :mad: :p

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. ;)

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.

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

Quote:

---

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.

Quote:

---

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.

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

Well regardless our little rant probably gave the poster enough to think about for years.

:D

* wonders why nobody has mentioned SDL , or GLUT*

When programming full-screen Direct3D, one thing that many has trouble doing is recovering from a minimization/application switch.

Not everything is easier in Direct3D, some things are (like loading images) but not everything.

Quote:

---

When programming full-screen Direct3D, one thing that many has trouble doing is recovering from a minimization/application switch.

---

I agree, it was the one thing I had trouble getting to work even after reading the tech docs; is there even an example in the SDK documentation?

Quote:

---

Originally Posted by Bubba

Allegro and DJGPP are extremely valid libraries to use for graphics and games.

---

Um......last I checked DJGPP was a COMPILER, not a library. Maybe you meant Allegro and SDL?

Quote:

---

Originally Posted by Bubba

Well regardless our little rant probably gave the poster enough to think about for years.

:D

---

hehe. Good point, Bubba. If nothing else, I can definitely say that this board (and the people here) have helped me learn more than any single textbook! :)

Jason

Quote:

---

Allegro and DJGPP are extremely valid libraries to use for graphics and games

---

I meant Allegro combined with DJGPP GCC are a valid combo for learning graphics/game programming because they expose you to how modern graphics are created. Even though scan conversion and texturing are done for you in modern APIs and cards...knowing how to do it in DOS helps a ton.

Yes, there is.

I put this in a seperate post because it is not related to the above.

When someone switches tasks there are several things you must do.

1. You must not present the image.
2. You must un-acquire the mouse.
3. You must not render anything with drawprimitive, direct access, etc.


This is simple to do. You only need to intercept the correct WM_xxxx message inside of your message loop. If your window is losing focus, Windows will send a message to it notifying you that it is about to lose focus. You should stop rendering, un-acquire devices, and only update non-graphical data - in other words only update the game situation in memory but don't present the final image to the user. Once you regain focus....Windows will also send a message letting you know your program is about to regain focus - you should then re-acquire devices (mouse, keyboard, etc), and set a flag that lets your game know it can now render to the primary buffer. You should also not respond to any keystrokes, change mouse cursors, etc.

If you do not do this when someone minimizes your program or alt-tabs or alt-enters it...you will crash your program. This is because D3D attempts to write to a surface that has lost the focus which results in a lot of problems. Check the SDK for more info...they explain it very well in there. Also Andre Lamothe explains this in his book Tricks of the Windows Game Programming Gurus. Even though that info is for DirectX 7, the techniques and principles also apply to Direct3D 9.0 or DirectGraphics 9.0. Switching tasks is not a D3D dependent task and therefore you should be able to respond to it in exactly the same way that Lamothe does for DirectX. Same idea.

Of course if you don't want to do this then simply trap for the right keystrokes and do not perform anything when they are detected. This, however, is not recommended by Microsoft but it is an approach that many games used to take. I'm finding more and more that newer games are able to handle ALT-ENTER and ALT-TABS as well as CTRL ALT DEL. If you are not handling the windows messages any of these will crash your code.

Sample of an D3D app that uses DirectInput to nullify default CTRL ALT DEL behavior
This may also need to be tested for in WndProc when a WM_KEYDOWN message is sent to the window. Simply do not pass control to DefWindowProc() and Windows won't know that CTRL ALT DEL has been pressed.

This can also be done to nullify other key combos as well.

DIKEYDOWN returns true if key <keycode> is set to true in the array keystate which is a member of class CDirectInput. By ANDing the return values we know if all are down. If one key in the sequence is up, it will change the final result since

1 and 1 and 0=0
0 and 1 and 1=0
1 and 0 and 1=0

1 and 1 and 1=1

Code:

---

...
if (DIKEYDOWN(DInput.keystate,VK_ALT) &
DIKEYDOWN(DInput.keystate,VK_CTRL) &
DIKEYDOWN(DInput.keystate,VK_DEL)
{
  //CTRL ALT DEL pressed - do not send to default processing
 
}
...

---