GDI+ Painfully Slow?

I was really hoping that the Frameworks GDI+ would prove to be fast enough to build small windowed games without the use of external API's or DirectX. I figured it was improved upon from VB6 but this doesn't appear to be the case. I try to tile small 32x32 graphic tiles in a 352x352 square (11x11 grid) and I can squeeze a frame out every 2-4 seconds. I'm drawing the tiles onto a buffer then pressing the buffer onto the window surface. Has anyone here been able to make the GDI+ perform half way decent? Using DX9's DDraw I get 200+ FPS rendering this size grid, I don't expect the GDI+ to get 200 FPS but I did expect it to get more than 1 Frame per 2-4 seconds.. That's pathetic...

Well, I remember a project of mine to help another programmer here render 1 million lines on the screen from an array of x,y coordinates...

Anyway, the skinny was... the API versions of LineTo etc... worked 50% faster than the VB.NET versions.. But of course, there is always the possiblity that it was simply my lack of programming experience in VB.NET that may have caused those putrid results...

Your not coding it right. I'll bet your using Image/Bitmap objects everywhere, right?

Image/Bitmap objects are good for image manipulation (Making a color transparent, for example). However, if you need speed, create TextureBrush objects from those Image objects. The TextureBrush object really draws hundreds of times faster.

Oh, and dont draw onto a buffer. .NET has double-buffering built in, which is much faster than what you can do with your image objects. In your form's constructor (the New method, where it says to put initialization code), put the following 3 lines:

SetStyle(AllPaintingInWmPaint, true)
SetStyle(DoubleBuffer, True)
SetStyle(UserPaint, True)

Now, draw all of your graphics in the Paint event (use the Form.Invalidate() or Form.Refresh() methods to force paint to fire. One is slightly faster than the other, but I forgot which.)
Only after the Paint event executes do the graphics appear.

The .NET GDI+ is easily fast enough for 2D games (platform games/shoot'em up games). You just need to know some of these not-so-well documented tricks. (I havn't even mastered the GDI+ yet, so I'm sure there are some more useful tricks to find, if we'd just experiment some more).

I'm designing a shoot-em-up game with GDI+ (well, was designing one. College is taking up so much of my time now.). It really doesn't do much yet, but you can move a ship around through space, and the stars in the background are scrolling at 2 different speeds. If you want to take a look at what I have so far, just tell me.

If you need a more in-depth description of what I said, just tell me.

EDIT:

Oh, one more thing, the TextureBrush object can do tiling!

Thanks Hu Flung Dung,

I just read your post and I'm on top of it, going to try these techniques you mention, I'll let you know how it comes out. And yes I would be interested in seeing your what you have so far of your project, do you have a link?

I'm glad you understand it all!

My game designs are only on paper right now. However, this attachment is my GDI+ testing project. Umm, you'll probably need a tutorial to know how to use it.

On the main form, button 1 starts the 'ball bouncing' animation. Button 2 pauses it. Button 4 exits out of the application. Button 3 loads the second form (push button 3 only after pausing this animation).

Once you push button 3, the first form closes and the second form loads. Push R (resume) to start the 'game'. Push P (pause) to pause it. Push Q (quit) only after pausing to exit the application. Once the animation is going, you can use the cursor keys to move the ship around.

About the spaceship demo:
Sorry that this example isn't commented, and poorly coded. I used it only to test out TextureBrush objects. Right now, it uses 99% processing power because there are no pauses in the main loop. You can tweak performance/quality by adjusting the number of pixels the ship can move in each loop iteration, and how long the application sleeps (use threading.thread.sleep) in each iteration (proper tweaking can possibly half the required system resources). Its the 'Me.Refresh' or 'Me.invalidate' calls (I forgot which method I'm using to force the Paint event to fire) each iteration that take up 98% of the CPU power. Everything else has a very minute impact on system resources. As I said, since its only a test, it wasn't very well coded, and definately not what I'd base the game on. But it does give you an idea of the speed of GDI+ (so long as you tweak it properly), and how you'd go about rendering graphics for games.

Notice that I use a while loop rather than a timer as the main loop. In my opinion, it gives you a lot more control.

EDIT:

As I said, since it wasn't coded well (my bad, I know, but it was only a test), if you dont pause the animations, my program could still 'linger' in the background. Always look in your task manager for 'GDIAnimTest' to make sure it has completely exited.

Excellent Hu Flung Dung,

I appreatiate the information and code. I converted my map editor over to use TexturBrushes and tweaked it a bit and now I am tiling a 11x11 Grid with 32x32 tile at 34 to 36 FPS on my slow 500mhz machine on a backround thread. A buddy of mine with his 1.4Ghz was getting well over 100FPS which makes me a happy GDI+ user now :p . I'm glad M$ finally did something about the built in painting as I love DX9 as much as the next guy but If I can squeeze out a playable framerate using nothing more than the Framework, I choose to go that route. Anyways thanks again and if you know of any more tips and tricks using the GDI+, don't hesitate to share'em..