Xybots - how did they do it?

[dipdop]

hihi friends ?

 

I've been picking apart games I used to play as a kid to learn how they work. I noticed recently that in both the arcade and lynx version of Xybots, there is a smooth, animated, transition when the player turns or moves to a new location. This caught my attention because other games that had similar psuedo-3d effects didn't have that transition. when you moved or turned the effect was an immediate cut to the new perspective.  See this video of Dungeon Master for an example. 

 

I know the lynx had specialized hardware to handle sprites and perform certain manipulations in hardware. I also know there are games on the lynx like Stun Runner that used sprites to achieve a 3d-like effect. Am I right in thinking the walls, ceiling, and floor tiles in Xybots for the lynx are all sprites that are being manipulated to produce the transition animations? 

ty!


EDIT

I just noticed that in the lynx version - the animations happen only when the player moves forward or backwards. In the arcade version, the animations happen also when the player turns... 

Edited October 4, 2021 by dipdop

[sage]

just a simple zoom.

[dipdop]

35 minutes ago, sage said:

just a simple zoom.

ok - I can buy that. you think that's why the turning animation wasn't in the lynx version? it would have involved more than zooming? 

[LordKraken]

1 hour ago, dipdop said:

ok - I can buy that. you think that's why the turning animation wasn't in the lynx version? it would have involved more than zooming? 

Yep it's totally why. Note that Stun Runner on the lynx achieve some sort of convincing 3d effect exclusively based on the zoom capacity, but that's also why the camera doesn't turn at all and always show the same perspective.

 

Although since all angle seems to be 90 degrees, it could be possible in theory to have precalculated 3d animations with just a few frames. Which they do on the arcade version I believe.

 

edit : watching some more footage of the arcade game, there are very different situations where the rotation is triggered, so I still don't think it's real 3d (otherwise it would be more than 3 frames, see the post below), but they def. have a trick to reconstruct this animation based on the wall configuration.

Edited October 4, 2021 by LordKraken

[LordKraken]

It's actually a 3 frame animation on arcade, it looks ok because it's super fast.

 

[dipdop]

3 minutes ago, LordKraken said:

It's actually a 3 frame animation on arcade, it looks ok because it's super fast.

 

I wonder if they created animation frames for every possible configuration of walls or if it's done dynamically somehow... 

either way - it'll be fun to explore this with the lynx. ty friends for the quick answer !

 

[LordKraken]

I found one of the original programmer of the arcade game on linkedin, he's still active and spent most of his career in game development at EA. I'll try to connect and ask him directly

[dipdop]

I can't stop thinking about this ?‍♂️

I did some back of the napkin math. Please feel free to correct me if I've got my numbers wrong 

given:
* a "unit" is a single square in which the player can be in or move to 
* the playfield has a depth of four units (the first "row" is the one in which the character is in) 
* the playfield has a width of thee units 
* walls may only be placed along the border of a unit 
* the playfield is presented in a third person pseudo-3d perspective wherein the vanishing point is in line-of-site with the character 
    * this also means that when the player turns some of the playfield elements that weren't in view may become visible and visa-versa 

then: 
* the player can see some portion of 12 units when not turning 
* the player can potentially see 49 units they make four complete rotations 
* there are 281,474,976,710,655 possible configurations of walls for 12 units 
* there are 100,433,627,766,186,892,221,372,630,771,322,662,657,637,687,111,424,552,206,335 possible configurations of walls for 49 units 

I arrived at those numbers by summing the binomial coefficients for every value of k between 0 and the number of wall segments. The numbers may be slightly off due to certain configurations occluding other segments from view.

here is the python I used:

 

>>> sum = 0
>>> for i in range(0, 48):
...    sum += scipy.special.comb(48, i, exact=True)
...
>>> sum
281474976710655
>>> sum = 0
>>> for i in range(0, 196):
...    sum += scipy.special.comb(196, i, exact=True)
...
>>> sum
100433627766186892221372630771322662657637687111424552206335
>>>

 

If I've got my maths reasonably correct my thinking is that they must have done sprite manipulation in the arcade version that wasn't possible/feasible on the lynx. There's way to many possibilities to have done it naively... 

 

[LordKraken]

I'm impressed by the mathematical effort

 

Now have you considered that they could simply reconstruct the scene using a simple painter algorithm (from the back of the to the front), just by using sprite that are scaled and deformed accordin to that angle. Maybe they dont even have to store those sprites if their sprite engine can apply transformation effect to the sprite.

 

Programmers are by nature lazy, they always cheat

[dipdop]

14 minutes ago, LordKraken said:

I'm impressed by the mathematical effort

 

Now have you considered that they could simply reconstruct the scene using a simple painter algorithm (from the back of the to the front), just by using sprite that are scaled and deformed accordin to that angle. Maybe they dont even have to store those sprites if their sprite engine can apply transformation effect to the sprite.

 

Programmers are by nature lazy, they always cheat

if I'm understanding you correctly that means you'd need one sprite per wall, floor, and ceiling segment yes? 

[LordKraken]

Yes, actually even less. There are 3 steps of animation but if you look at the floor you will see that step 1 and 3 are just mirrored.

 

Now strip our all the walls and just keep the floor. Count how many edges you have in step 1 and 2 (as step 3 is mirrored), that's the number of wall sprites you need to recreate virtually any configuration. They could be handmade tailored sprite or sprite tilted and scaled by the machine hardware.

 

Technically, and apart from memory consideration, this rotation is probably doable on the lynx too.

Edited October 5, 2021 by LordKraken

[dipdop]

Quote

Technically, and apart from memory consideration, this rotation is probably doable on the lynx too.

can Suzy handle sprite rotation natively or would this have to be done manually by the programmer? 

 

[LordKraken]

no, only tilting and stretching but that should be enough here.

[Fadest]

@LordKraken

 

Congratulation, seems you just made :

number_of_project++

 

[LordKraken]

3D TPS on an 8-bit console? Of course you can't say no to this challenge

[dipdop]

7 hours ago, LordKraken said:

no, only tilting and stretching but that should be enough here.

Makes sense. I have a long way to go in groking the maths. I conceptually see how that would work but if I am being honest pulling that off is beyond my present ability. Someday though I want to do this - even if it is just a demo. There is a lot of juice in the idea...

 

Ty friend for the help - it's appreciated! ?

[LordKraken]

I can sketch up something up so that you can see it's not as hard as it sounds, well if you cheat obviously  I'm curious to see how many sprites we would need to keep up in memory to  get that effect on the lynx, that might be the problem here (although using 1 sprite with stretch and tilt could save us here)

[dipdop]

Dude that would be amazing!

[sage]

On 10/6/2021 at 9:17 AM, LordKraken said:

no, only tilting and stretching but that should be enough here.

yes, if you turn the screen by 90deg you can use the hardware 3d fp. BUt the sprite-math resolution is not enough to make this look good.

[LordKraken]

Yes I actually looked closely at the arcade version (frame per frame) and they might be using hardware transformation, since it's a higher resolution and better math (I guess...).

 

Now since there is only one single kind of wall there is probably a good reason for that, and I'm fairly confident that they simply store all the possible walls per rotation frames as individual sprites in RAM, and then simply reconstruct the scene on the fly. It's only a 4*4 square you have in front of you so there's just a limited amount of walls you can see.

[+karri]

9 hours ago, LordKraken said:

Yes I actually looked closely at the arcade version (frame per frame) and they might be using hardware transformation, since it's a higher resolution and better math (I guess...).

 

Now since there is only one single kind of wall there is probably a good reason for that, and I'm fairly confident that they simply store all the possible walls per rotation frames as individual sprites in RAM, and then simply reconstruct the scene on the fly. It's only a 4*4 square you have in front of you so there's just a limited amount of walls you can see.

The Lynx is fast enough to stream the wall sprites from cart.

 

I encountered a similar problem when I wanted to have many animations for my character. It is actually possible to read in every animation from cart when you need it. Here I load in a new animation for every direction, jump, fall etc.

 

[LordKraken]

@laoo could confirm, but I think the only reason MK is doable at this level of quality on the lynx is because all animations are streamed from cart!

 

So yeah I'm more and more confident the rotation as seen in the arcade game are achievable on the lynx too

[dipdop]

13 hours ago, LordKraken said:

Yes I actually looked closely at the arcade version (frame per frame) and they might be using hardware transformation, since it's a higher resolution and better math (I guess...).

 

Now since there is only one single kind of wall there is probably a good reason for that, and I'm fairly confident that they simply store all the possible walls per rotation frames as individual sprites in RAM, and then simply reconstruct the scene on the fly. It's only a 4*4 square you have in front of you so there's just a limited amount of walls you can see.

1. Is there not, on rotation, also the walls that come into view as you rotate?

 

2. Overall what you are saying makes sense to me. While there are a gazillion possible configurations of the walls, there are a small numer of possible perspective-states for a given segment of wall. As such you can store those states and use them to build whatever scene you need to build on the fly

[dipdop]

4 hours ago, karri said:

The Lynx is fast enough to stream the wall sprites from cart.

 

I encountered a similar problem when I wanted to have many animations for my character. It is actually possible to read in every animation from cart when you need it. Here I load in a new animation for every direction, jump, fall etc.

 

That graphic looks rad!!

 

Does loading animation data from the cart impact performance?

[+karri]

19 minutes ago, dipdop said:

That graphic looks rad!!

 

Does loading animation data from the cart impact performance?

Thanks. There is a noticable delay when the data is loaded. So I would like to put the delays in logical places like mounting a broom, turning, shooting. In this way it is not disturbing.
The interesting thing will be to see what happens when I have three players on the screen at the same time and a few enemies. They may all shoot at the same time. Will there be a visible glitch in gameplay or not?