Hi, guys. I've been thinking about something lately, and I'd like to see if anyone else has an interesting point of view on this subject.

If a game uses regular MSX1 rough scrolling (8 pixels at a time) what are the options when working with sprite-based objects? I mean, since the sprites are not affected by scrolling limitations (they can move as smoothly as the programmer wants), games have different approaches when it comes to aligning them to the background.

I've seen some games limiting sprite movements to 8-pixel steps, so that they're aways aligned to the background. That seems rather poor, 'cause the sprites could be used to soften the effect of rough scrolling, instead of making it more obvious.

Other games seem to treat the background as if it had pixel-perfect positioning, and place the sprites accordingly. The background is just placed at the closest possible position. This can look nice in some cases, but if an object requires more precise alignement to the background it can look pretty weird.

Some will use an occasional quick (8 pixels per frame) scroll instead of a constant smaller scroll, avoiding any possible sprite-background alignement problems.

The worst effect caused by bad sprite-background alignment, IMO, is when the sprites are moving in a direction at, let's say, 2 pixels per frame (less than 8 pixels). You'll see the sprite moving forward for 4 consecutive frames, and when the background finally scrolls, the sprite will jump back 8 pixels. When that repeats for a while, the movement looks very jerky.

What are your thoughts on ways to align background and sprites, possibly even trying to soften the effect of the rough scrolling? Do you have any good examples of games that do a good job out of scrolling 8-pixels at a time? Or even examples of games that do a really bad job?

hi !!

You could always move the sprite smoothly, but when checking for sprite-background alignment,
you could always do something like this:
LD A,(SPRITEX)
AND %1111 1000
then the x of the sprite is always 8-fold.
another option is checking if the sprite is left or right of the 8x8 block, like
LD A,(SPRITEX)
AND %0000 0100
JP Z,SpriteIsRightOfBlock
In this case you know that the sprite is at the right side.
Each tile you use could be (visibly) split up into 4x8 and 4x8 pixels.
Then when looking at the MAP(tile)data you could check if the sprite is at the left or the right of that tile.
(the same can be done with top/bottom)

MSX1 huh.... hmmmm, I have no experience with that.
Anyone else some idead ?

I think the issue is rather simple really. If you can get away with it, you will use smooth motion for sprites. Which should be most cases actually. Only when sprites have a direct link the the background (like sprite turrets on a big pattern craft or something), you should scroll with the background. You can select what you need on a case by case basis. I think native MSX games mostly do well in this department.

Yeah norakomi, I know what you mean. There are a couple of ways out, but I really don't know wich should I take.

Edwin, I guess you are right when you say that each case has it's optimum solution. I guess I could do what you said: move some sprites smoothly (enemies and most things that move) but keep others (mainly things that are just sitting there, and will look weird when not aligned to the BG) within the 8-pixel-at-a-time limit.

Usually, in my scrolling projects, I control the position of a "camera" within the level, wich, in fact, is the top left corner of the screen. Every object also has it's position withing the level. Since the position of the camera can not have a high precision, it will be truncated or rounded to the nearest multiple of 8. Some of the sprites (enemies, etc.) will not have their coordinates adjusted in function of that rounding (they will be displayed as if the screen could be smoothly scrolled), but others will.

The problem is that there is also vertical scrolling, and it is easier for objects to appear to be "off" in that case. Mainly because of gravity, you know? If an enemy is moving side by side, it doesn't matter if it goes a little over a ledge or enters a little bit inside a wall, these are acceptable in games. But if it happens to be walking, say, 4 pixels above the ground, that's weird.

I guess vertical and horizontal scrolling should be treated differently. In the kind of game I like, horizontal is more important, so I guess I'll pay more attention to that. Vertical could have a lower resolution, as it'd be less frequent. Because of that, I could also use a "window" that is taller than it's wide, so that the player can move a lot within this window before the screen has to scroll vertically.

I hope this works out OK. It really is a challenge to make a good scroller in a system that does not support hardware scrolling.