Hi, I've got the following code:

Blitting is very slow...the same code in full screen mode is so fast that I can't see the circle moving, while in windowed mode it moves very slowly.

Does anybody know something about this?

All I can imagine is it's hardware accelerating video-video in fullscreen, and not in windowed?

Maybe add some acquire/release bitmaps calls?

Marcello

Never acquire video bitmaps if you're doing vram->vram blits. You should only acquire bitmaps if you're going to do non-accelerated operations on them.

Just about the only circumstance in which you should use acquire_screen()is if you're doing a memory->vram dirty rectange system.

EDIT: in other words, drop the acquire()/release() calls.

Are you trying to use page flipping? If so, where do you flip the pages at? Why don't you look at Shawn Hargreave's examples since he has something very similiar to this in the double buffer and page flipping examples.

Even if I drop the acquire/release, the problem remains.

I am not trying to use page flipping, but buffering from vram.

I think maybe the problem is due to pixel conversion...because If I reduce the color depth to 16, then the speed is more than doubled.

What's your desktop colour depth?
In windowed mode, the actual colour depth is the desktop colour depth. If you set anything else using set_color_depth, you will get colour conversions, which are slow.

Is there a way to get the desktop color depth?

Yes.
Try your friend the manual.

If you put the circlefill itself outside the inner loop, does that give you a significant speed up?

32 bpp, as it is in the code.

The circlefill is already outside of the inner loop.

while (!keypressed()) {
        circlefill(page2, x, SCREEN_H / 2, 64, makecol(255, 255, 255));
        acquire_screen();
        for(int j = 0; j < SCREEN_H / 32; ++j) {
            for(int i = 0; i < SCREEN_W / 32; ++i) {
                blit(page2, screen, i * 32, j * 32, i * 32, j * 32, 32, 32);
            }
        }
        release_screen();
        ++x;
    }

You are drawing the circle every frame, and drawing directly to video memory is known to be pretty slow.

If you could just blit the circle (but time the frame rate) you would have a better idea of how slow the blitting is..

I don't think so. Only translucent drawing is slow on vram.

The same code in full screen runs so fast you can not see the circle moving; all you see is a big white stripe.

Maybe there is conversion of pixels between RGB (which vram uses) and BGR format (which Windows uses); allegro devs could confirm this.

If your hardware is accelerating some primitives like GFX_HW_LINE then you might get fast drawing. Otherwise it could be the cause of the slowness.

All I'm saying is it could be worth testing to see if it is this than spending a lot of time on the blitting and gfx mode side.

No, I've already said that: if you do the test in full screen mode then it is so fast you don't see the circle moving, just a big white stripe. So it is definitely not the drawing.

If you also remove the for loop and do the blitting with one call, speed is good. The trouble is with tiled blitting.

If they knew about Windows programming and the innerworkings of the DirectX driver... maybe.
Anyway, Allegro should use the native RGB ordering used by the video mode (which is why you load bitmaps aftercalling set_gfx_mode()).

Axilmar:

Ah, I misunderstood. My apologies!

If things are that slow it sounds like the display is being converted or emulated in software somehow. Do AllegroGL programs also run slowly for you in a window?