No zoom supported when drawing

[ghost]

Please add zoom (with zoom factor for 1 normal size, 0.5 half the size etc... should allow any arbitrary zoom factor >0) to the drawing functionality.

While really old-style RPG maker games probably won't use it, it's very useful for more modern games and especially realtime strategy games with more fast-paced gameplay where you'd want to have large camera movement freedom.

If it's already in there then I apologize, but from examining the code it seems this is not possible right now.

[zachmu]

The drawing functionality of the library is the most primitive part, kind of on purpose. The kind of global scaling operation you're talking about is best accomplished at a layer above, setting some sort of transformation matrix on the batch of sprites to be drawn. I would suggest trying that before trying to plug scaling-specific code into Tiled.cs.

I took ownership of this project since it was effectively abandoned, and left all the drawing code alone because it's so simple. But I think that most people will want to reimplement that part for their own game, and I didn't want to try to make it extensible before understanding how people would want to extend it. As a matter of fact, I've made extensive domain-specific modifications to this project, including the drawing aspect, for my own game:

https://github.com/zachmu/escape-from-enceladus/blob/master/Arena/Arena/Map/Tiled.cs#L356

[ghost]

The drawing appears to do simple culling to the actual viewport (which is a good idea). Won't that all break if I apply the scaling afterwards? It seems more clean to me to handle this inside the drawing code of tiled-xna itself to handle culling correctly.

[zachmu]

Yes, you're correct. You would need to compensate for the culling when you do scaling. In my fork, I'm actually calculating which parts of the world are visible every time I draw the map:

https://github.com/zachmu/escape-from-enceladus/blob/master/Arena/Arena/Map/Tiled.cs#L545

So if you wanted to scale up or down, you would just need to take the scaling factor into effect when you computed the boundary of the visible world.

Hope that helps,

Zach

[ghost]

Can that be done without modifying the draw function itself as you initially suggested? If I already have to modify it, I'm not sure why I should even use matrix stuff afterwards when I could scale right in there (replacing the 1f with the proper scaling factor etc).

[zachmu]

I would have to read the docs or maybe experiment to say for sure, but I think that the scale factor on SpriteBatch.Draw() is independent of any transformation matrix used in SpriteBatch.Begin(). I can't say for sure because I'm only doing translation, not scaling, in my implementation. But I do think that, as much as possible, you want to keep your map classes drawing in game-space and allow a transformation matrix to translate that to screen-space; I don't see why scaling should be an exception to this rule. But as I said, I haven't actually tried this. I've seen SpriteBatch do some counter-intuitive things before, and I would believe you if you said that you have to set the scaling factor in every call to Draw(). Myself, I would try using a matrix first and see where that gets you.

[ghost]

Since the culling is handled in Draw and it needs to know about the zoom, I
don't see how NOT handling the zoom when drawing in Draw aswell makes much
sense.. hence also my suggestion to add it into upstream (that is, here)
because it cannot be done nicely from the outside without modifying the
code. Of course one could use a matrix inside Draw too ;) (but then again,
1f for zoom is already a parameter of the sprite drawing call, so why not
just replace that with the zoom factor)

On Mon, May 6, 2013 at 7:56 PM, Zach Musgrave [email protected]:

I would have to read the docs or maybe experiment to say for sure, but I
think that the scale factor on SpriteBatch.Draw() is independent of any
transformation matrix used in SpriteBatch.Begin(). I can't say for sure
because I'm only doing translation, not scaling, in my implementation. But
I do think that, as much as possible, you want to keep your map classes
drawing in game-space and allow a transformation matrix to translate that
to screen-space; I don't see why scaling should be an exception to this
rule. But as I said, I haven't actually tried this. I've seen SpriteBatch
do some counter-intuitive things before, and I would believe you if you
said that you have to set the scaling factor in every call to Draw().
Myself, I would try using a matrix first and see where that gets you.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1#issuecomment-17497054
.