shmups.system11.org

Shmups Forum
 
* FAQ    * Search
 * Register  * Login 
It is currently Sat May 08, 2021 10:34 am View unanswered posts
View active topics



Post new topic Reply to topic  [ 10 posts ] 
Author Message
 Post subject: How the scrolling is managed in a Shmup ?
PostPosted: Thu Mar 11, 2021 2:13 pm 


User avatar

Joined: 13 Jan 2020
Posts: 27
Hi,
I wonder how the scrolling is managed in a Shmup
(let's take R-type as an example because i need obscacles across the level)
Thanks

1.
CAM : fixe, Stage : scrolls to the left, Player : With bounds to stay visible by the CAM


2.
CAM : scrolls to the right, Stage : fixe, Player : child of the CAM with bounds to stay visible by the CAM


3.
none of them ! (please specify in comments)


Top
 Offline Profile  
 
 Post subject: Re: How the scrolling is managed in a Shmup ?
PostPosted: Thu Mar 11, 2021 2:26 pm 


User avatar

Joined: 18 Feb 2011
Posts: 6194
Location: Denmarku
Technically, what's the difference between 1 and 2?
Reads to me like it's the same thing, but a matter of perspective.

On a totally abstract level, of course you want to create the illusion that the stage is standing still, while the player is moving through it as the camera scrolls along a set trajectory (maybe with some panning).

But on a hardware level, obviously the screen doesn't move, and it's all the graphics you're seeing that gets offset according to scroll values.


Top
 Offline Profile  
 
 Post subject: Re: How the scrolling is managed in a Shmup ?
PostPosted: Fri Mar 12, 2021 12:47 am 


User avatar

Joined: 22 Jun 2019
Posts: 24
Location: California
I think I understand your question and where you're coming from. However, I think there is a slight misconception on the notion of 'camera', mainly due to current programming packages such as Unity, which are 3D packages.

For 2D shmups, they used to directly write to the frame/screen buffer, so there is no notion of camera there. All the sprites are in the local space of the screen and the background is on a sort of "treadmill" where you have to offset the screen buffer and then draw new lines of pixels/scenery.

For 3D shmups, then yes, there is a notion of camera because you are dealing with a 3D world and you need to do a 2D projection onto the screen buffer of that world in order to see it. This is, I believe, your question - should you have a locked camera and move the world, or should the world be static and you move with the camera?

Both options work, but in the case where you move the world then try not to do that on each frame because this can dramatically affect your performance. Games that use that technique usually do it after the player moves N units, or every N seconds. In the case where you keep the world static and move the camera (which would be my preferred solution), make sure you don't go too far from the origin. I know Unity can have floating point precision issues if you do...

I hope this helps :)
_________________
Squidbeam Games | Video Game Den


Top
 Offline Profile  
 
 Post subject: Re: How the scrolling is managed in a Shmup ?
PostPosted: Fri Mar 12, 2021 6:46 am 


User avatar

Joined: 18 Feb 2011
Posts: 6194
Location: Denmarku
Yeah, if you're relying on a ready-made engine where coodinates are handled as floats (ew), definitely don't move your gameplay-centric objects too far from the lower numers :D


Top
 Offline Profile  
 
 Post subject: Re: How the scrolling is managed in a Shmup ?
PostPosted: Fri Mar 12, 2021 7:34 am 


User avatar

Joined: 13 Jan 2020
Posts: 27
Sumez wrote:
Technically, what's the difference between 1 and 2?
Reads to me like it's the same thing, but a matter of perspective.


In '2', there is a strange feeling about enemies bullets because they are affected by the scrolling.
Imagine that the scrolling speed is 2 and enemies bullets speed is 1.
While the level is scrolling, a bullet that goes to the right and a bullet that goes to the left seems to have different speeds.

In '1', every speeds are visualy correct.


Sumez wrote:
In the case where you keep the world static and move the camera (which would be my preferred solution), make sure you don't go too far from the origin. I know Unity can have floating point precision issues if you do...


I didn't specify it but i'm in Unity in 2D. As i respond to Sumez, I think that '1' is better to deal with speeds of enemies ans bullets. e.g if i want an enemy goes left and then exit to the right, it has a lower (visual) speed when it goes to the right because it has to go against the scrolling speed.

First, i used '2' because i followed platformers tutorials where the cam is following the player acroos the level.

It's not easy to explain :)


Top
 Offline Profile  
 
 Post subject: Re: How the scrolling is managed in a Shmup ?
PostPosted: Fri Mar 12, 2021 7:51 am 


User avatar

Joined: 18 Feb 2011
Posts: 6194
Location: Denmarku
You did not mention bullets in your first post, and that definitely makes a difference in a shooter, so that's a good question. :)

In the way I've done it in the past, I have two separate scrolling variables - once a bullet has been fired, it's not affected by the stage scrolling, but it's still offset by player-controlled scrolling (panning). I like having immediate reliable feedback for dodging patterns like that.

If you look at games where the background suddenly changes scrolling speed, you'll usually notice that any bullets on screen at that time won't suddenly zoom off the screen either.
You may also want to make a difference between enemies that are tied to the stage scroll (such as ground units), and enemies that are free from it (flying enemies, like the player and projectiles).


Top
 Offline Profile  
 
 Post subject: Re: How the scrolling is managed in a Shmup ?
PostPosted: Fri Mar 12, 2021 8:16 am 


User avatar

Joined: 13 Jan 2020
Posts: 27
Sumez wrote:
You did not mention bullets in your first post, and that definitely makes a difference in a shooter, so that's a good question. :)

In the way I've done it in the past, I have two separate scrolling variables - once a bullet has been fired, it's not affected by the stage scrolling, but it's still offset by player-controlled scrolling (panning). I like having immediate reliable feedback for dodging patterns like that.

If you look at games where the background suddenly changes scrolling speed, you'll usually notice that any bullets on screen at that time won't suddenly zoom off the screen either.
You may also want to make a difference between enemies that are tied to the stage scroll (such as ground units), and enemies that are free from it (flying enemies, like the player and projectiles).


I didn't mention bullets to avoid a messy question :)
My bullets are not affected by the scrolling and also not affected if i decide to change the scolling speed.
I guess i was on a good way ! :)


Top
 Offline Profile  
 
 Post subject: Re: How the scrolling is managed in a Shmup ?
PostPosted: Fri Mar 12, 2021 5:46 pm 


User avatar

Joined: 22 Jun 2019
Posts: 24
Location: California
9uile wrote:
I didn't specify it but i'm in Unity in 2D. As i respond to Sumez, I think that '1' is better to deal with speeds of enemies ans bullets. e.g if i want an enemy goes left and then exit to the right, it has a lower (visual) speed when it goes to the right because it has to go against the scrolling speed.


Well, all of this is relative, really. You could still use '2' and have all your flying enemies and bullets in camera space instead of world space :)

At the end it all depends on the kind of shooter you're making. You mentioned R-Type and bullets in such games are more connected with the background - they can collide with it or even crawl around it. So if you exclusively use '1' then it may be difficult for enemies/bullets and background to live in the same world. If you make a game like Crimzon Clover, then '1' is definitely the best approach because it is about having a zillion bullets on screen and you save a matrix transform per bullet in order to keep them in camera space. And well, who can actually see the background in games such as Crimzon? ;)
_________________
Squidbeam Games | Video Game Den


Top
 Offline Profile  
 
 Post subject: Re: How the scrolling is managed in a Shmup ?
PostPosted: Mon Apr 05, 2021 8:45 am 



Joined: 25 Sep 2019
Posts: 155
Some random observations I've made. Might help someone out:

3D shmups simulate a camera looking into a 3D world.

2D shmups do the same, only much more approximately, and obey some rules contrary to the mathematics. The following relates to 2D shmups:

All objects move on the screen.

Objects may also "scroll" i.e. move on the screen as if due to the movement of a "camera" capturing the scene.

Scrolling may be:
+ automatic, or
+ due to the player "pushing" against an implicit box (most horizontal shmups along y), or otherwise
+ a function of the player's position (most vertical shmups along x)
separately along x or y.

Objects are drawn using the painter's algorithm i.e. in an order.

Objects drawn over other objects are understood to be closer to the camera than others.

If the player may be drawn over an object, that object is understood to be further away from the camera than the player.

These objects are called background objects.

Some objects may never overlap the player as this would result in a collision.

Such objects are understood to be on the same plane as the player.

These objects are called foreground objects.

Bullets are foreground objects, but are (usually) drawn on top of all other foreground objects.

Mathematically, when a camera moves, still objects further away from the camera will move less in the image captured than closer objects.

Generally, 2D shmups follow this rule when scrolling is automatic.

However, when scrolling is due to player movement, players expect all objects to scroll the same.

E.g. if bullets scroll at a different rate to the background, players will complain about "wobble".

But bullets are foreground objects.

i.e. players expect a contradiction where foreground objects are expected to scroll at the same rate as background objects, when the scrolling is induced by their movement.

Most games follow this contradiction. Refer to:
+ Garegga stage 1 (observe how the far background scrolls in relation to the near background when the player moves left and right)
+ Thunderforce 4 stage 1 (i.e. "strite", observe the clouds when the player moves up or down)

N.B. If an object is moving /slower/ than an object it's drawn over, it's understood to be in motion relative to that object.

If an object is moving /faster/ than an object it's drawn over, it may be understood to be stationary relative to that object and the difference explained by parallax.

Same!^3 and Kyuykyoku tiger backgrounds scroll ~30 pixels per second.

Image fight foregrounds scroll ~20 pixels per second.

So, if an Image fight foreground appeared over a Same!^3 background, and scroll speeds were maintained it would be understood as in motion.

Same!^3 does not seal bullets if a foreground object overlaps a background object.

In stage 3 of Mahou daisakusen large foreground objects are scrolled at the same speed as the background. Visually, the foreground objects are the tops of the background drawn in perspective.

As a result, any background enemies would never be obscured by the large foreground objects. Nevertheless, there are also no background enemies in this stage.

Thunderforce 4 features background enemies in stage 4, but no large foreground objects.

Examples of shmups with large foreground objects and background enemies appearing simultaneously are hard to find or do not exist.

However, both Mahou daisakusen and its sequel shift between the formats and also the "top" background layer.

Other observations:
+ Examples where enemies appear on background planes further than the first are hard to find or do not exist.
+ Push scrolling is avoided on axes with automatic scrolling
+ But Thunderforce 4 switches between automatic and push scrolling on the same axis e.g. in stage 1.
+ 2D graphics hardware scrolled tiles, so looping scrolling (e.g. Gradius 2 level 1) was trivial to implement without concerns about duplicating objects bigger than one screen e.g. one background quad in a modern engine.


Top
 Offline Profile  
 
 Post subject: Re: How the scrolling is managed in a Shmup ?
PostPosted: Thu Apr 15, 2021 7:23 pm 


User avatar

Joined: 07 Feb 2008
Posts: 4800
There's no contest between these two. It's better to have a camera frame and move it around. I can't even fathom doing the equivalent by altering the base value of stationary terrain, that's absolute madness. It'd make everything so much more complicated than it needs to be; this is the first time in my life I've ever thought about it.

Camera. Around five variables needed, max. CurrentX, CurrentY, MoveToX, MoveToY, and Speed. Add the current offsets to everything that's being currently drawn. Simple and clean.


Top
 Offline Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 10 posts ] 

All times are UTC


Who is online

Users browsing this forum: No registered users and 4 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
Jump to:  
Space Pilot 3K template by Jakob Persson
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group