How does X2:Megablast parallax with all that colors?

[roondar]

Originally Posted by mcgeezer

Would you get any gains by multiplexing the background layer with sprites (similar to Risky Woods?) I know RW points to the same graphics data per sprite but due to only needing 4 colours does it not make it possible?

Pretty sure you covered this in one of your cool videos about a free-form sprite layer.

I did cover a free-form sprite layer, yes
And you're right that it could display a background like the one Xenon 2 does.

However, there's an issue with that particular approach which might make it a bit less useful here: it is really DMA heavy. You're looking at over 8400 copper moves (plus some 200 copper waits) per frame*, plus the cost of updating the graphics in the layer. This really limits the number of bobs you can still display (my example managed only 9 bobs@32x32 pixels per frame).

The idea I posted above will also have a fairly high DMA cost (an extra bitplane and a full mask of a bitplane every two to four frames or so), but the advantage it has is that you still have the hardware sprites left to offset this a bit. I haven't done any calculations, but my gut feeling is that it'll end up being more efficient than my sprite layer.

*) I did later have an e-mail exchange with someone and it does appear the effect can be done somewhat more efficiently. Even so, it's still going to be a lot.

[sandruzzo]

@mcgeezer

You can, but you'll bite out a lot of dma slots

[Master484]

Maybe the best way to create the feeling of smoothness and speed would be to make the player ship with sprites, and then use an interrupt to move it.

This way the player ship will always move at 50 FPS, no matter how slow the game gets.

So 4 sprite channels for the ship, and the remaining channels can be multiplexed to make some of the bullets.

This change alone would probably improve the game speed to a more or less steady 25 FPS, with the player ship moving at 50 FPS.

Many of the best Amiga shmups run in this kind of 50/25 FPS combination mode: Battle Squadron, Project-X, Blastar, R-type, and so on, and all of them feel smooth, because the Player Ship moves at 50 FPS.

[sandruzzo]

If you're willing to reduce a little bit screen area, It could be done by sprites.

[DanScott]

Originally Posted by Master484

So 4 sprite channels for the ship, and the remaining channels can be multiplexed to make some of the bullets.

what about all the cannon attachments ?

[chb]

Originally Posted by mcgeezer

Hybris and Apidya don’t use parallax scrolling.

Just on a side note: Apidya does have parallax scrolling in the last level (the one with the cogwheels in the bg), and it's pretty impressive - a multiplexed 4 color sprite background, which is even animated. Plus a lot of action going on in the foreground, but probably not X2 level.

The animation is really clever btw - as you need shifted copies of your background for the sprite layer anyway, you can as well make an 8 frame long animation at no additional memory cost. Works of course only if scrolling speed is constant, as animation frame rate is coupled to scrolling frame rate. You see this is Apidya: when scrolling slows down, the bg animation does so, too.

[mcgeezer]

Originally Posted by chb

Just on a side note: Apidya does have parallax scrolling in the last level (the one with the cogwheels in the bg), and it's pretty impressive - a multiplexed 4 color sprite background, which is even animated. Plus a lot of action going on in the foreground, but probably not X2 level.

Yes, I'll let agree with you that Apidya does have parallax, but the parallax doesn't span more than 128px wide which would not be suitable for Xenon 2.

[chb]

Originally Posted by mcgeezer

Yes, I'll let agree with you that Apidya does have parallax, but the parallax doesn't span more than 128px wide which would not be suitable for Xenon 2.

Yes, you can have only 128 individual background pixels, at least if you don't reload the SPRDAT registers (roondar's approach), which is totally flexible, but costs you quite some performance.

Still, there are important differences between a horizontal scrolling game and vertical scroller like X2:

With a h-scroller, the sprite content "spills over" to the next sprite, so you're tied to an "1234567812345678" arrangement (whole 128pix patterns repeats). When you scroll vertically, that's not the case, so in principle you can have more complex patterns, like "1234111112345678" or the like - still having only 8 individual 16-pix patterns per line. Or less, if you choose to retain some sprites for the star field or other stuff.

Addionally, X2 has quite often large black gaps in the background, which makes a sprite background more efficient. As you scroll only vertically, every bg line is completly static and can be optimized.

In the end, you might end up with something that's not 100% identical to X2, but looks good enough and is quite efficient. Not easy to do tho for sure.

[Hewitson]

Originally Posted by Galahad/FLT

Both also don't have remotely as many things going onscreen either.

When Xenon 2 gets hectic, it gets VERY hectic.

If the game slowed down when things got "hectic" that would be one thing. But the fact is that the game runs like a slideshow even when absolutely nothing is happening. It is honestly one of the worst examples of coding available on the Amiga.

[Master484]

what about all the cannon attachments ?

Indeed, those small parts that attach to the player ship would be somewhat tricky to implement in my idea. I guess they would either need to be part of the player sprite, which would generate a lot of chip mem eating extra animation frames, or then the remaining sprites would need to be used for them.

[sandruzzo]

For Oldtower Porting for Amiga, I'm using Sprites to do parallax. I have 13 colum to fill with them attached. Using them is helping to do faster blitting since background is allmost black. Even Sprites Parallax scrolling is very easy: just by changing sprites' pointer, and control words!

[mcgeezer]

Originally Posted by Hewitson

It is honestly one of the worst examples of coding available on the Amiga.

It's not the worst or the best so a bit of an over-reaction giving that the coders in the thread are mulling it over given the game design it is certainly outside of the Amiga's (A500) comfort zone.

You don't have to convince me though about the game play as I hate it, but I'm starting to appreciate what they (The Assembly Line) did and why they did it, more importantly I'm beginning to understand why they didn't improve the Amiga version over the ST version.

This isn't your typical lazy ST port for sure.

[Tigerskunk]

Originally Posted by mcgeezer

This isn't your typical lazy ST port for sure.

But isn't it basically the same?

Why isn't it faster the the ST version if they used the Blitter, I wonder?

[mcgeezer]

Originally Posted by Steril707

But isn't it basically the same?

Why isn't it faster the the ST version if they used the Blitter, I wonder?

I can't say for sure but I suspect the game slows down less on the Amiga.

[Tigerskunk]

If I were to try to remake this, I'd probably go for 5 bitplanes and 25 fps.
4 bitplanes for the foreground, and then do that trick used by James Pond where the 5th bitplane is parallaxing.
That plane would only have 1 colour, but maybe you could make that look good enough, since it's pretty heavy on contrast anyway.

Plus triple buffering should give you enough objects on screen.
Not sure though if you had enough RAM then for all animations and tiles.

[mcgeezer]

If you triple buffer then u have to do it with everything, background and foreground. Add that 5th bitplane and it probs doesnt fit into 512kb chip ram.

[DanScott]

I would be interested to know what they used the blitter for, as from what I can tell it runs identically to the ST version (perhaps the ST version slows down more, but the base speed appears to be the same or similar).

I think it's a fact that this game could have been running much quicker.. probably at a constant 25fps given that it's only in 16 colours.

[mcgeezer]

Originally Posted by DanScott

I would be interested to know what they used the blitter for, as from what I can tell it runs identically to the ST version (perhaps the ST version slows down more, but the base speed appears to be the same or similar).

I think it's a fact that this game could have been running much quicker.. probably at a constant 25fps given that it's only in 16 colours.

It uses the Blitter for just about everything.

Try this poke in WinUAE to turn it from the pile of shit it is into a super top notch shooter:

Break into Winuae with Shift + F12

W 1835 00
W 185d 00
W 7adc 4e 71 4e 71 4e 71 4e 71
x

Break into Winuae again
W dff180 00 00 00 00 00 00 00 00
x

Enjoy.

[Tigerskunk]

Originally Posted by mcgeezer

If you triple buffer then u have to do it with everything, background and foreground. .

Maybe I am missing something here, but couldn't you just blit the foreground tiles into the triple buffer and restore blit only 4 planes instead of 5 in BLTSIZE?

Seems pretty straight forward to me (unless I am wrong )

[mcgeezer]

Originally Posted by Steril707

Maybe I am missing something here, but couldn't you just blit the foreground tiles into the triple buffer and restore blit only 4 planes instead of 5 in BLTSIZE?

Seems pretty straight forward to me (unless I am wrong )

I think I see what you mean now.

You mean just have a separate 5th plane and vertical scroll that, yeah should work.