Scroll Margins

[Vincent]

Hi guys!

Guess what, I've another question.  I'm wondering, is it possible and / or a good idea to change the scrolling margins of a map at run time?

In my game, the character go go left and right, up and down, etc.  I would like to show about 1/3 of the screen behind the character and 2/3 in front of him.  So if he is heading right, 1/3 of the screen is ont he left and 2/3 on the right.  If he is goind left, I would like it to be other way around.

What do you think?  How would the map behave?

Thanks again!

[bluemonkmn]

I don't think there's an issue with that.  There are two ways to handle that:
1) Make a writable version of the scroll margin properties in a partial class like you did with counter maximum values.
2) Make an invisible sprite that moves in front of the player and scroll to that sprite instead of to the player sprite.  You could put rules on this sprite to make the changing scroll margins transition smoothly (a few pixels at a time) instead of jumping around suddenly; having that all wrapped up in sprite rules could be an elegant way to handle it.  Just make that sprite always head for a point 1/3 of a screen in front of the player's heading.

[durnurd]

I think maybe writing your own scroll function that takes in PlayerSprite (or whatever your sprite is called) would be the cleanest way to do it.  Don't work around the system, work with it.  Base your function on the generic function, but have it check the current state of the sprite, and scroll to the correct location based on that state.

[bluemonkmn]

I think having an invisible sprite would be a good way to "work with the system" because if you write your own function, you'll have to create some variables to track the scrolling progress as it changes from left to right without snapping to the new view instantly.  A sprite seems to me to be a good way to track that.  The sprite rules for that sprite can encapsulate all the code/rules of scrolling to a point in front of the player.  And then if you want to change or disable it, you just change or disable that sprite.

[durnurd]

Well, to me, it seems like adding an extra sprite is working around the system by using an extra sprite to do something that it's not meant to do.  Sprites are for showing a moving image on a map, and interaction between that sprite and the map.  You would also have to either make sure to add that sprite on every map or create a set of rules in the player sprite to create it dynamically if it doesn't exist yet.

[bluemonkmn]

I guess I'm just thinking that the ratio of usefulness to overhead is surprisingly high compared to the average kludge.  The ability to define and encapsulate rules for movement, the tracking of the position, the relationship to scroll margins, and the ability to activate and de-activate are all useful and are all provided by sprites. It might even be handy to be able to make it visible for debugging purposes. And the ability to dynamically create sprites could probably get around the issue of having to put one on every map.  The player sprite could dynamically create a scroller.  Sure, it's not a conventional sprite, and doesn't really fall into the definition of sprite, but in the end, "Sprite" is just a class containing a bunch of code, and it turns out that the code does everything necessary without much more overhead (if any) than the average use of the sprite class (for defining conventional sprites).  I say "if any" because I think you can define a sprite without any frames (just one state-less frame), and then it doesn't do any drawing or allocate any space for the sprite's graphics.  I'm not sure that's true, but maybe I should make it possible if it isn't .  (I know you can define a sprite without frames in its states, but I don't know what happens when you try to compile and use such a sprite).  I know you can define tiles without any frames, I'm just not sure about sprite states.

[Vincent]

Well, I followed bluemonkmn advice and made an invisible sprite for scrolling.  It seemed easier and it works pretty well.  This way, it didn't have to change the source code or add another part to the partial mapbase class.

Thanks guys, it's pretty neat!