Hi Im updating 800*600 pixels 32bits using windows bitblt. On any machine under 1.6GHz AMD, geforce 2 MX, the application cannot run without lag. Just the update consumes all CPU (I draw using CPU). The game is in 30FPS and contains no 3d /(thats way of my competence at the moment). Is there no way to do this faster? Do you really need such a fast computer just for blitting or am I just doing this badly? Whould be greatful for any suggestions.

Are you talking about directx or something similar? What I do at the moment is drawing to memory and once every tick this memory gets "sent to the screen" updating the entire 800*600.

If I flip, wont I have difficulties accessing colordata already on the screen for multiply/add effects? My friend said something about that but i didnt quite get it...

As a rule of thumb, blitting 2D graphics can quickly chew up the CPU because there''s little to no hardware acceleration you can take advantage of. Transluscy or other effects WILL kill your performance so fast your head''ll spin. It''s pretty sad but true: if you use a 2D API, you''ll have worse results than if you use a 3D API because you''re doing this in the software. Here are a few hints though.

1- "Precompile" everything, graphic-wise. If you have text windows à-la RPG and they''re all the same size, store an image of the whole window instead of the corners and sides to "build" it every frame. It takes more juice to draw a bunch of small images than it does to draw just one big images because of all the unecessary calls to your blitting function.

2- In SDL, make sure all of your surfaces are compatible with the display surface. Converting from 8bpp to 32bpp can cause one heck of a performance hit, especially if pretty much all of your resources are the wrong format.

3- Stay away from special effects unless you need them. It may be cool to have that fullscreen fireball spell go transluscent but your performance will be crap.

4- Try to avoid overdrawing. DirectDraw has some sort of reverse colorkeying function where you can blit only to a specified color (as opposed to blitting only from a color different from the specified one; color-keying). That aside, some careful planning can help avoid or reduce this.

5- Graphics may not be your bottleneck. Your algorithm may be a problem too. In an older project in VB, I used to draw a 3-layer tilebased map by looping through my map data and blitting the right tile. This meant I was also blitting a fully transparent tile for every place on my map where there wasn''t a tile. Adding a simple "if MapData(x,y,layer) then..." to my code dramatically sped things up.

6- Switch to a 3D API. OpenGL is very easy to use and can take as little as a weekend to set up and use for 2D. DirectX may take a little more effort, but is more flexible. I sugget OpenGL since the added flexibility is mainly towards 3D stuff. You''ll be able to use hardware acceleration fully then and it''ll run fast enough to be decent even on my PIII 650. ;P

You should be getting better than 30fps, I would think. Have you tried using DrawDibSection() instead of BitBlt()?

Ultimately I would think this is limited by the speed of the AGP rather than your CPU speed.

DrawDibSection seemes to not be included in win32 API. I found one reference when searching google, but that fuction called BitBlt.

So now im lost.

Aaaargh, sorry, my bad. The API you want is not DrawDIBSection(), but StretchDIBits(). It''s standard Windows API, and according to this article on Animation in Win32 that I just found, it''s implemented in the video driver rather than through umpteen layers of virtual this and device-independant that.

use directx9 and the d3d, d3ddevice ,sprite and texture class and you are set

I did something like this before too..and I had no problems with windows bitblt..what i did..is...
HDC backbuffer;
HDC theScreen;

then every tick I would draw everything to the backbuffer..then with just *1* Bit block transfer..copy backbuffer to theScreen, and I could even make smooth animation and all...worked great..If your already doing this, there must be some calculations or something that are eating up your cpu resources