Zooming

Well, in all your algorithms, instead of having the tile size as a constant (e.g. tilewidth = 64; tileheight = 64 you just have them as a variable. The much tougher part is actually the blitting if you''re using a 2D library - first of all, to make it look good, and secondly to make it fast enough. You might want to write your own blitting routine in assembly language.
About determining the tile size - just increment/decrement every time the user presses the according button. Of course, you can make it go faster from a certain size on, so possibly have a "zoomlevel" variable that is set to 0,1,2,3,4, etc. and then set the actual tile size using some function, like zoomlevel sqared.

- hillip@xenoage.de''>JQ
Full Speed Games. Period.

Why not use Direct3D or OpenGL?

quote:

---

Original post by Gandalf
Why not use Direct3D or OpenGL?

---

Sure it''s possible, but it''s not absolutely necessary - you can do it in 2D too, many people nowadays seem to forget about that. You know, "back in the old days" when noone had 3D hardware, they did this stuff, too.

- hillip@xenoage.de''>JQ
Full Speed Games. Period.

It shouldn''t be too hard to calculate the new tile sizes.

What I would do is track a zoom factor, and just multiply your existing tile size by it.

Then you''d have a source and destination tile size. When blitting you''d fill the source rect with the normal tile positions like you''ve been doing, and fill the destination one by the scaled versions.

One cool thing is that when zooming in, even though you''re doing a stretch blit (which I''d imagine is a bit more expensive than a regular one) you''re drawing less tiles to fit the same screen area.

---

Helpful links:
How To Ask Questions The Smart Way | Google can help with your question | Search MSDN for help with standard C or Windows functions