Hm!

Not quite sure what you're asking, so if this reply sounds weird, I probably misunderstood something, anywayz:

Reg. Lock/Unlock. The general rule is that you can't use blit on a locked surface. If your source surface is never changed, you can lock it, get a memory pointer and then unlock it, but continue to use the memory pointer (I don't know if this is legal, but I seem to get away with it ). Locking one surface should not prevent blitting to/from other surfaces.

Reg. different size front and backbuffers: I assume the reason you're talking front and back buffer is that you intend to use flip() in which case different size buffers doesn't make much sense. There's nothing stopping you from creating an offscreen surface with a different size than your primary surface (In either V-Mem or sysmem)...

The rectangles weren't displayed right. The reason I want to do this is that I don't want to lock the primary surface memory all the time when the program runs (players can't use CTRL+ALT+DEL this way).

The reason that I want to have a bigger back surface is this: I will use a tile based system. This way I have to place all 32x32 (or 40x40) pixel sprites each frame (one layer). But why the bigger surface you may ask.
Well I want to do some scrolling. When you place the sprites on the screen there are 'half' sprites shown on the edges of the screen (when the screen scrolls). I don't want to put pixels out of the screen boundaries. Then I want to flip the backbuffer to the primary surface (/w hardware acceleration).

doesn't the ALLOWREBOOT coop level flag allow for ctrl+alt+del, or is that just in certain situations?

------------------
--Orion McClelland

I believe in this circumstance that Lock()ing the surface will grab the Win16 lock and thus really mess up normal machine operation while the surface is locked. I KNOW you can't debug when the Win16 lock has been taken.

As for your problem with using a bigger back buffer, I do not believe a back buffer can have different dimensions than the front. However, let me say that for smooth scrolling (which is what you seem to want to do), you should have a larger offscreen surface where you blit your tiles and stuff, then from that you should blit to the back buffer, then flip. Either that or blit partial tiles to the borders of the back buffer, then normal blit the rest. Either way should get you the effect you want.

- Splat

Oh yeah.

Niels: Keeping that pointer to video memory after Unlock()ing it is a "Bad Thing." Just think, the video card could decide to optimize its memory and rearrange the blocks of memory. Or you could be accessing memory that was being Blit()ed to and get unexpected results. Etc. I realize that dealing with debugging with DirectDraw is difficult when using your own blitting routines, so maybe you should only use Unlock()ed pointers in debug mode and turn them off when you want to compile a release version of your game.

- Splat

I can use system memory as an offscreen surface (which will be bigger) and pass it to the primary surface.
But I thought that if I could make the attached backbuffer larger I could get a speed increase (using hardware acceleration). But I guess I have to do it with system memory.

I think the answer is simple. Instead of making a bigger back surface, simply clip your tiles when you draw them. A good clipping routine will likely be faster than sending all that unnecessary data to the video card anyway.

Regards

Starwynd

That's the catch!
It CAN be faster to send the extra data using assembler (using 32 bits memcopying). I don't have to use color keying 'cause it's the base layer.
These compares take a lot more clockticks than moves.

I think the speed difference between clipping the edges and copying the entire tile is pretty minor, and could swing either way (faster or slower) depending on how much is clipped. But since it sounds like your image will be aligned, and is small and 8bit, you're probably right.

However, you're still missing out on a much bigger speed increase. If you threw away your big surface approach, and DID clip the edges, then you'd be able to keep all the surfaces in vid mem, use hardware blitting to copy tiles to the back page (which will be much faster than drawing to your system surface), and then just flip video pages instead of copying your sys surface to the video card, which is generally VERY costly.

Rock

I know how to lock the surface memory and access the video memory directly. Now I need to know is if you can get a pointer to the attached backbuffer. This way I don't have to lock/unlock again (I can use blit right?).

Now the next question:
I have a 640x480 screen (let's keep it simple: 256 colors). Can I make the backbuffer bigger, let's see 680,520? Then it would look like this:
_____________
| _______ |
| | | |
| |_____| |
|___________|

The big rectangle is the backbuffer and the little one is the screen. Can you use blit to copy only the part that's in the screen to the primary surface?