The first one is real simple: clipping. Either use the DirectDraw clippers (yuck!) if you're lazy, or in your blitting code do a check to see if the blit is partially off the screen and adjust the source and dest rectangles accordingly.

The second problem is kind of engine specific (depending on how you store your current view location) and I'm too tired (12:30 AM EST) to answer it, so I'll let someone else help you out with that.

- Splat

map coordinates to screenspace coordinates, as was said, is really fundamentally linked to the coordinate system that your map uses.

it is a three part transformation, as well, although it can all be accomplished in a single step.

the first step is to convert from mapspace coordinates into tilespace coordinates.

your mapspace is the map itself. all implementations of a tilebased map that i've ever seen involve a two dimensional array, or a one dimensional array that acts as a two dimensional array.

so, invariably, you have a mapx and mapy, which is a tile. depending on the type of map you are using, you convert this x,y into a tilespace x,y with one of the following methods:

the iso calcs are based on the TILEWIDTH and TILEHEIGHT of a typical tile. the hex calcs are based on the mousemap's width and height. (in all honesty, you can use the mousemap width and height for iso, too, since the tile and mousemap are the same size)

Staggered Iso Map(as in Civ II):

tilespacex=mapx*TILEWIDTH+mapy*(TILEWIDTH/2);
tilespacey=mapy*(TILEHEIGHT/2);

Diagonal(or Diamond) Iso Map(as in AoE):

tilespacex=mapx*TILEWIDTH/2-mapy*TILEWIDTH/2;
tilespacey=mapx*TILEHEIGHT/2+mapy*TILEHEIGHT/2;
(based on a diagonal map where tile 0,0 is the uppermost tile)

for either of these styles for hex, use the MMWIDTH and MMHEIGHT instead of the tile's height and width

tilespace to plotspace

the second transformation is from tilespace (which represents the pixel locations for the entire map) to plotspace, which is a rectangle that is the same size as the area to which you will be blitting on the screen. in many cases, plotspace and blitspace are the same, and you can stop with this one:

somewhere in your program, you store the tilespace equivalent of the upperleft corner of your plotspace, and to convert from tilespace to plotspace, you subtract this coordinate from the tilespace x and y.

if you screenspace and plotspace are the same (meaning the entire screen), you can stop here. otherwise, you just add whatever to the coordinates to give you the proper screenspace coordinates.

this is an odd question, actually, since people seem to have more trouble converting the other way.

so for the first question (about clipping), would it be best to blit the entire map to another buffer that's big enough to hold it, and then blit from that buffer to the back buffer, using a source rect the same size as your screen?

No, you'd definately want to clip the first time around. (And I strongly recommend clipping it yourself, I have so far been unable to see the benefit of DDraw clippers.)

/Niels

In this situation, I don't think there is _any_ real advantage to using DirectDraw clippers (unless, of course, you have no idea how to manually clip on the screen edges. In which case you need to find out, quick!)

The real advantage (and not that big) is when you have complex clipping areas that are made up of many overlapping rectangles. Then, DirectDraw clippers allow you to ignore that complex aspect until later when you profile your game and its deemed that your game is bogging down on the clipping.

- Splat

clippers can be a useful tool in any game. they are easy to make and implement, and are reasonably fast. if you find that performance suffers, you can always change it later.

primarily, though, clippers are used for windowed DX apps, where they are the most useful and update themselves automatically.

I use the directdraw clipper in fullscreen on my backbuffer. I havent noticed any performance loss from it. Thue i do know how to perform my own clipping which is quite easy. Besides really what is the directx clipper using? Probally the same way you do it. Only gain in using your own clipping that i can see is if you think you can custimize it to get better performance than directx's.

Also please forgive any spelling,and lack of grammer its(3am right now and i just got back from a long long day and am tired)

I find it much easier to blit to an offscreen video memory surface the exact size of the window then just blit that surface to the client area of the window on the primary surface. No clipping needed on the second blit, since all simple edge clipping is done on the first blit. Also, this provides a back buffer and "virtual" flipping in windowed mode, and facilitates an abstraction that removes the need to know if you are in fullscreen or windowed mode - since you are always blitting to an offscreen surface that is the correct size.

- Splat

i'm using directx for an iso engine i'm trying to make, and was wondering a couple of things.

1. if my backbuffer is the same size as the screen, how do i blit the current section of map onto the screen without getting errors by trying to blit off the surface

2. how do i convert map coordinates into screen coordinates? do i just do:
sprite.x = spritemap.x-map.x;
sprite.y = spritemap.y-map.y;

thanks in advance

-Delta Rho

But, you can't use BltFast on a surface with a DD clipper attached,
only Blt, right? I used to have a DD clipper attached to my backbuffer,
but I ripped it out and started to do my own clipping. And the framerate
jumped up 10-20 fps. I then started using BltFast and loaded everything
in videomemory and now my framerate rocks at 60 fps.

I will never go back.

And I would guess a good way to do clipping is to separately test your
x,y components. And perhaps check for exclusions first (if bitmap is
not visible on the screen, just return from the function), rather than
checking for equalities and matches.

However, that would only be good for things like units, but probably not
for background tiles since you are always blitting the visible tiles anyway.

Reaver

[This message has been edited by Reaver (edited November 12, 1999).]