Sorry to bother you guys.
What's wrong with shmups when sprites move independantly from the background.
For instance a tank that's been shot down. You see the blown up tank on the ground, but while the game scrolls, it scrolls an instance too late with the background.
When this occurs is this a sign of emulation?
I can't from the top of my head tell which games have this, but some do have it.
If you know what I'm talking about perhaps you can shed some light on the matter and list game(s) that have these 'faults'.
Some of you dveloppers must've noticed this and some may even have an explanation for it.
scrolling in shmups
-
gamingjustin
- Posts: 109
- Joined: Tue Jun 14, 2005 9:42 pm
- Location: New York
I know exactly what you mean. I think I saw this happen in ESP Ra.De. Sometimes it's not just the explosion-craters that do this. I noticed some guys sitting/standing ontop of buildings that scroll at tad too late.
This is a "problem" in the development of the game. My theory is that the character/ship in a shmup does not physically scroll forward through the level like in a platform game. I think it's the opposite. I think everything (backround, sprites) scrolls and revolves around your player to create the illusion that your ship is going in a forward direction. Maybe it's tough for developers to keep everything in sync with constant scrolling/speed changes.
That's just a guess though...
This is a "problem" in the development of the game. My theory is that the character/ship in a shmup does not physically scroll forward through the level like in a platform game. I think it's the opposite. I think everything (backround, sprites) scrolls and revolves around your player to create the illusion that your ship is going in a forward direction. Maybe it's tough for developers to keep everything in sync with constant scrolling/speed changes.
That's just a guess though...
It's even more notable when running emulators on slow computer and leave framskipping of, so everything moves extra slow mo.gamingjustin wrote:I know exactly what you mean. I think I saw this happen in ESP Ra.De. Sometimes it's not just the explosion-craters that do this. I noticed some guys sitting/standing ontop of buildings that scroll at tad too late.
This is a "problem" in the development of the game. My theory is that the character/ship in a shmup does not physically scroll forward through the level like in a platform game. I think it's the opposite. I think everything (backround, sprites) scrolls and revolves around your player to create the illusion that your ship is going in a forward direction. Maybe it's tough for developers to keep everything in sync with constant scrolling/speed changes.
That's just a guess though...
I also posted this topic in the shmups chat forum here:
http://forum.shmups.com/forum/viewtopic.php?t=3828
-
licksweets
- Posts: 4
- Joined: Wed May 11, 2005 6:52 pm
Usually it's just one frame of lag between the movement of the background and the application of that scroll move to the sprite positions. Caused by not having your program subroutines in the right order, wether it's movement routines in a game, or rendering routines in an emulator. I find it's mainly lazy programming that causes it.
Ugg- I know exactly what you mean. That's one of my pet peeves. It's also sometimes present when a complex object is made out of multiple sprites (the individual sprites jitter a bit as the object moves).
Rounding can cause this type of wiggling movement. Say sprite 1 is at height 3, and sprite 2 is at height 6.5. Sprite 2's location will be rounded to 7, and the gap between the two will be 4.
If the screen scrolls .5 pixels, sprite 1's new height will be 3.5. This will get rounded to 4. But sprite 2's height will be 7, and the new gap between them will be 3 (instead of 4).
If the screen keeps scrolling at this rate, sprite 1 and sprite 2 will jitter in relation to each other.
I hope that made some kind of sense- I'm afraid that wasn't a very good explanation.
Rounding can cause this type of wiggling movement. Say sprite 1 is at height 3, and sprite 2 is at height 6.5. Sprite 2's location will be rounded to 7, and the gap between the two will be 4.
If the screen scrolls .5 pixels, sprite 1's new height will be 3.5. This will get rounded to 4. But sprite 2's height will be 7, and the new gap between them will be 3 (instead of 4).
If the screen keeps scrolling at this rate, sprite 1 and sprite 2 will jitter in relation to each other.
I hope that made some kind of sense- I'm afraid that wasn't a very good explanation.