Where do your bullets live?

[Lord Satori]

I love the phrasing you guys are using of where the bullets "live". (hence the silly post I made earlier)

[S20-TBL]

I love the phrasing you guys are using of where the bullets "live". (hence the silly post I made earlier)

My bullets live in Alaska where Rob hangs out. They keep seeing his Gunbird 2 replays and going "Lightnin' fast bullets? Hey Billy Joe Bob, we gotta try that." So they end up flying at 4-5 pixels per frame in a 60fps environment. Must be the cold weather.

[DrInfy]

You're all making this unnecessarily complex

Sorry, you just forced my hand…

Actually, I lied. Bullets in Saviors do not in fact live in world space, nor are they in screen space.

In Saviors “space” is represented by a coordinate system that holds the following
- 4x4 matrix that represents the coordinate system rotation
- inverse 4x4 matrix of the previous that allows for converting other objects to that space
- 2 Quaternions that allow rotating other matrices to and from the coordinate system
- Vector3 that represents the coordinate system position

Let’s call world space identity space, as it would be represented by a 4x4 identity matrix. Identity space would require a coordinate system that holds an identity matrix and a {0, 0, 0} position vector. There is no such thing in Saviors. Player resides in screen space (obviously), which is represented by a single global coordinate system that is stored as a static property. While enemies can also use screen space coordinates, they rarely ever do so (few enemies that come from behind use it, as they would be too slow otherwise to ever get inside the screen space). Spawning enemies use each their own coordinate system that is a copy of the current screen space, which means that the space does not move, but the rotation and position is the same as the screen space was when the enemy spawned.

When enemies shoot projectiles, the projectiles use a copy of the coordinate system of the shooter. As the copies of coordinate systems are static and not moving, the end result looks to the player as the bullets would live in world space and this was one of the design goals in Saviors. Because 32 bit float numbers are rather limited in accuracy, using local spaces for bullets allows physics to stay accurate regardless of the current screen space location.

Collision checks are done either by moving one object from one space to another or by moving both of them to identity space. Sphere to sphere collisions use identity space as the world position is cached for each collidable sphere each frame. More advanced collision algorithms, like cuboid to sphere and cuboid to cuboid convert one collidable object to cuboid identity space. Cuboid identity space here means the space where the cuboid exists without rotation. Due to Saviors using full 3D physics, doing this greatly simplifies the complexity of the collision algorithm.

Camera position in Saviors is calculated by determining forward, left and up vectors from the current space matrix and using something like cam.pos = up * 700 – forward * 30 + left * player.pos * 0.1f; So in fact the camera never moves in Saviors (other than sideways based on player position in its own space), but the screen space is what moves. Now if I wanted to move the background faster, I would need to either give the background a coordinate system that moves by itself, or move all the background models. This technique is used in stage 4 when the player flies away from the planet. It was required as the background was taking way too long to get out of sight otherwise.

[ptoing]

You're all making this unnecessarily complex

Bullets should live in the world space, along with all the other things in the game. When the camera pans, the bullets should move naturally, not stick. Using screen space for nearly anything (HUD elements obviously not included) is silly, dumb, and bad.

"Sticking" bullets are a sign of a kusoge.

What exactly do you mean by "sticking"? Can you point out some examples of games which you think do this, or some which do bullet handling right. (arcade or console games I mean)

[S20-TBL]

What exactly do you mean by "sticking"? Can you point out some examples of games which you think do this, or some which do bullet handling right. (arcade or console games I mean)

He's referring to Bullet Wobble, one of Rob's terms that hasn't gone on the Shmup glossary yet (still up for discussion).

Bullet Soul: Infinite Burst has it. The bullets and bonus coins retain their relative positions on the screen when you pan left or right. Also, many early 90s shmups like Thunder Dragon.

Here's a sample: https://www.youtube.com/watch?v=_KQTgsxirEs

[ptoing]

Oh yeah, that is ass. To me that looks like it has to do with how the bullets are not locked to the background layer. Basically the bullets and the background parallax relative to each other.

If you look at Cave games the bullets are locked to the background layer and the far background hardly ever parallaxes horizontally.

I think also that this is the reason why Ikaruga for example has no horizontal scrolling, since this kind of thing is hard to avoid in 3D (If at all without using some kinda funky orthographic camera setup) and since Bullet Soul does have horizontal scrolling it has this issue.

[S20-TBL]

Yep. This is why, at least personally, I prefer to generate my bullets relative to "world-space" instead of the viewport: I love designing shmups with screen wobbling and panning so it doesn't make sense to lock them onto the viewport like you would a single-screen game, scrolling or not.

[ciox]

I think also that this is the reason why Ikaruga for example has no horizontal scrolling, since this kind of thing is hard to avoid in 3D (If at all without using some kinda funky orthographic camera setup) and since Bullet Soul does have horizontal scrolling it has this issue.

I doubt it, G.Rev who handled Ikaruga's graphics made 3d shmups with sideways scrolling like Border Down and Under Defeat that don't have wobble, most likely it was a design decision for that game.
Don't see why it's so complicated to fix in 3d really, seems like it was already covered in this thread.

[ptoing]

I think also that this is the reason why Ikaruga for example has no horizontal scrolling, since this kind of thing is hard to avoid in 3D (If at all without using some kinda funky orthographic camera setup) and since Bullet Soul does have horizontal scrolling it has this issue.

I doubt it, G.Rev who handled Ikaruga's graphics made 3d shmups with sideways scrolling like Border Down and Under Defeat that don't have wobble, most likely it was a design decision for that game.
Don't see why it's so complicated to fix in 3d really, seems like it was already covered in this thread.

Does Border Down have vertical movement that is controlled by the player? I watched some videos, did not seem so. In that case, same as Ikaruga.

Under Defeat DOES have some bullet wobble, but it is mitigated somewhat by the slanted perspective. You still get the bullets parallaxing relative to the ground. That parallax is what I would reckon is hard to get around when using 3D with actual perspective (ie not some kind of ortho projection).

As far as screenspace goes, to me it seems that at least all the Cave stuff does the bullet handling in like that. As someone pointed out it is quite obvious in games like DFK. But someone who actually messed with Cave code like trap15 might know better.

[BPzeBanshee]

ESPRade had bullets in screen space rather than world I'm pretty sure, and it wouldn't be the only Cave game. I distinctly remember putting that one to the test and noticed bullet wobble, but because of the very little horizontal movement it's barely noticeable when playing, unlike Raiden games where the horizontal length is approximately parallel to the height of the screen (320x320).

[ptoing]

In all the Cave games that are 240x320 I am positive the space to which the bullets are locked is 320x320 (320 being the width of the backgrounds generally), and they also get affected by the camera in that they will get deleted if they go outside of the currently visible 240x320, which I think you can see in a few games with very fast movement like Dangun Feveron.

Wobble has nothing to do with how wide the play area is at all, and everything to do whether the bullets are locked to the background layer or parallaxing relative to the bg (which would cause the wobble)

[ptoing]

The BG on BD boss 5 is pretty much flat and the bullets are locked to the same plane, hence no issues there. Raiden 4 has quite a bit of wobble for example. I don't think I have seen a 3D shmup that had player controlled movement perpendicular to the forced scrolling direction that did not have wobble.

Just watched some Strania footage. It does not look like there is any scrolling the player affects from what I have seen, BG just does it's thing, like in Ikaruga. Hence wobble would be not an issue.

[ciox]

Interesting, it's possible they all have wobble then, all 3d shmups seem to either drag everything through the world along with the camera or possibly have bullets in screen space.

In my setup it's easy to deal with if I decided to add scrolling (not needed because 4:3 vertizontal), since I have a fake "screenspace area" setup somewhere in world space where the real action takes place and the background is just a 2d plane that the 3d rolling and zooming background is rendered on, so it works like a 2d game and panning the main camera that floats above the "screen space area" should have no ill effects because the camera used to render the 3d background does not affect bullets in any way.

[ptoing]

I think that if your backgrounds are actually 3D with perspective (as in if you had a tower that sticks up the amount of the sides visible changes and such) and you would add player controlled scrolling, you would have wobble too. Because it would automatically result in a parallax effect between bullets and background. I really do not see how you could get around this problem.

A really bad example of handling bullets (and everything else) is Banshee on the Amiga. In that bullets are affected by the scrolling of the screen and it seems stuff like lines of planes coming in from the side as well.

If you look at games like 1942 where you got lines of planes coming in from the side, the bg scrolls but the planes always come in at the same coord in screenspace.

Code: Select all

o  o  o  o

In Banshee they are offset due to scrolling.

Code: Select all

o
  o
    o
      o

[ciox]

I think that if your backgrounds are actually 3D with perspective (as in if you had a tower that sticks up the amount of the sides visible changes and such) and you would add player controlled scrolling, you would have wobble too. Because it would automatically result in a parallax effect between bullets and background. I really do not see how you could get around this problem.

Hmm that shouldn't happen, though I can't visualise this stuff well either! Basically the secondary camera that renders the 3d perspective background does not move at all when horizontal scrolling happens, it always just renders the same view with a big FOV and when the player tries to scroll horizontally it's only the primary camera that moves left or right to show a different part of the 2d plane that displays the 3d background and that world space bullets are flying over.

[ptoing]

Ah OK, so if the perspective of the 3D does not change when you move, then yeah, there should not be a problem.

[ciox]

I was feeling it would be ok but really have trouble explaining stuff, I don't actually need that technique yet but it's good to keep in mind if i ever want to make a 3D shmup with a traditional 3:4 aspect ratio and horizontal scrolling without bullet wobble... which might happen.

[ptoing]

Do you have a build of your game somewhere for testing?

[ciox]

Not right now but I might put something together later on, there's an old video here that shows the 3d background pretty well https://www.youtube.com/watch?v=x9JpkpftDrU

[ptoing]

Someone likes Psyvariar. Looks pretty cool. And yeah, with that "video" approach to a 3D background all is well.