Super Alien Galactic Space Base, or something...

[vintage-mike]

Some work in progress footage of a top-down vertical scrolling space shooter thing that I'm having fun developing at the moment. At this stage I've no idea if this will ever get to be released, so here it is courtesy of my custom ZX emulation engine running on Linux (complete with obligatory CRT shader with screen curvature etc etc) enjoy.

[media]https://www.youtube.com/watch?v=NkU3FSceJ9M[/media]

[R-Tape]

Some work in progress footage of a top-down vertical scrolling space shooter thing that I'm having fun developing at the moment. At this stage I've no idea if this will ever get to be released,

That looks brilliant, and smooth as silk. Throw in some big end of level bosses and you've got a customer here.

[4thRock]

Looks great! I'd just add some minimal colour to better distinguish between walls and sprites

[Joefish]

Looks pretty slick. Is the idea that it loops until you've cleared the level?
Also, I presume you're using Up/Down to control the speed, rather than moving the player up or down on the screen? Does it scroll at a default speed if you're not pushing the stick?

With the empty space up the centre of the level, that suggests to me that the blocks are to be avoided - yet your ship seems able to fly over them, and even come with a shadow, so I presume you don't collide with the scenery? In which case, I'd suggest some sort of light background pattern rather than empty space as it could be confusing.

[vintage-mike]

Looks pretty slick. Is the idea that it loops until you've cleared the level?
Also, I presume you're using Up/Down to control the speed, rather than moving the player up or down on the screen? Does it scroll at a default speed if you're not pushing the stick?

Thanks - yes it loops around the current level / sector until you've collected all the 'power crystals' positioned at various points, and then cleared the current wave of aliens. The aliens spawn in small groups, so if you dispatch them all quickly enough you get a short break before the reinforcements arrive. Forward on the stick is thrust, causing the ship to speed up, and when you release the stick it eventually slows down and comes to rest. Its a similar mechanic to defender. I don't think the video properly does justice to the game physics at the moment - but it can be tweaked and refined a bit too.

You just fly over / above the tiles. Basically this came into being because I always liked the arcade version of defender, but found it ridiculously difficult - all I really wanted to do was enjoy flying the ship a crazy speeds over the landscape - without getting instantly killed by aliens - so I thought what if it was possible to do a top-down shooter with the same idea.

You can't crash into the background but you can just enjoy flying over it at breakneck (well, for a 3MHz Z80 anyway) speed. The aliens and collectables provide some distraction and a 'mission' - in true ZX game style, the main game 'effect' comes first, then some vaguely plausible plot to justify it (something about aliens stealing the power crystals for their base, which you need to retrieve before destroying the base etc etc... I'm still working on that bit... )

[Hedge1970]

Looks very nice, I’d be very proud of that.

[Ivanzx]

Indeed, it looks quite nice, with a very smooth scroll. Like someone said, now put a bit of an effort in the gameplay design, some good bosses and this will be a hit for sure!

[jorgegv]

Is this wonder open source? I'm really interested in seeing the workings of the scrolling routines...

[vintage-mike]

Is this wonder open source? I'm really interested in seeing the workings of the scrolling routines...

Its not open source (its not even released yet) but I'm not overly precious about guarding how it works - its a ZX Spectrum game after all. The graphics are drawn in an offscreen buffer. Scrolling is the most CPU intensive part - scrolling the offscreen buffer itself would require an extra copy in addition to 'blitting' it to the screen every frame, which would be too slow, so the scrolling is accomplished by moving the pointer to the offscreen buffer before each frame is copied to the screen. Conceptually its like one of those chalk boards that roll around, only in this version the code is drawing new stuff on the back of it before it scrolls into view. As all the drawing is buffered you can chose a more conventional addressing layout, and do the translation to the spectrum's 'display file' addressing during the copy. That helps with keeping the other overheads of moving sprites etc reasonably low too.

[Ralf]

It definitely needs to be completed. The movement is great, very smooth. I can see a potential for a very playable game.

And if you managed to add some colour it would be even better.

[Joefish]

As a personal opinion on the gameplay, I think if you slow down and come to a halt, as you say, like Defender, then the player might expect to be able to flip round and go the other way. Whereas if you can slow right down but not stop completely, there wouldn't be that expectation.

Also, if you make the default to move forward at a medium speed, then back lets you run slow and forward lets you run fast, with neutral returning you to medium speed, that again feels more like a one-way scrolling game. You might even be able to squeeze some gameplay out of some sort of gauge that only lets you stay in slow or fast mode for a limited time. But, whatever works. As I say though, I think if you can come to a complete stop on a wrap-around map, some players will be asking why they can't turn round too.

[Morkin]

Looks very slick..!

I'm not sure how my growing-ever-older reactions would cope with the aliens materializing that far down the screen, but time will tell..!

I like the sound effects, the shots remind me of Arcadia (in a good way).

[vintage-mike]

And if you managed to add some colour it would be even better.

I'll certainly consider that - it was kind of a conscious design decision to go with the monochrome style (I was / am a huge fan of the isometric Ultimate games - so maybe at some level the monochrome thing resonated with me). The other reason is purely a technical limitation. Everyone I'm sure is aware of the Spectrum's infamous 'attribute clash' - and in the other games I've done I just let it go - its part of the charm, and what I remember about my first encounters with the machine - but with this, the scrolling varies continuously from 1px to 8px and at finer resolutions, the 8px attribute block alignment caused things to just look a mess. I realise there are clever ways to minimize that, and there are other things I could try, such as fancy attribute switching but again, for me the trade-off in performance wasn't acceptable.

As a personal opinion on the gameplay, I think if you slow down and come to a halt, as you say, like Defender, then the player might expect to be able to flip round and go the other way. Whereas if you can slow right down but not stop completely, there wouldn't be that expectation.

That's a good point - I wasn't really aware of that when playing it - but obviously that's partly because I know what to expect. I didn't think of it as a continuous scroller - so, more like scramble than defender? (to push the analogy with side-scrollers to breaking point perhaps...) but it might add some extra challenge to the gameplay (that's mostly how I play it anyway - the video is a bit different because I wanted to better show how the scrolling / control mechanic behaves)

[presh]

Scrolling is the most CPU intensive part - scrolling the offscreen buffer itself would require an extra copy in addition to 'blitting' it to the screen every frame, which would be too slow, so the scrolling is accomplished by moving the pointer to the offscreen buffer before each frame is copied to the screen. Conceptually its like one of those chalk boards that roll around, only in this version the code is drawing new stuff on the back of it before it scrolls into view.

Ah, cool... I've been planning something similar (just in my head at the mo!) for an 8-way scrolling idea. Any pitfalls to watch out for?

The most obvious one to me is that any sprites which would overflow the end of the screen buffer will need splitting (essentially drawn as 2 sprites - top section near the end of buffer memory, then the bottom section near the start of buffer memory). Something like this?

Code: Select all

sprite_bottom_y = buffer_offset_y + sprite_y + sprite_height - 1

if sprite_bottom_y >= buffer_height 

  sprite_lower_y = 0
  sprite_lower_height = sprite_bottom_y - buffer_height

  sprite_upper_y = sprite_y
  sprite_upper_height = sprite_full_height - sprite_lower_height

  draw sprite_upper
  draw sprite_lower
else
  draw whole sprite

(Probably got some off-by-one errors in there, haven't checked it properly!)

Also wouldn't be able to use an SP-based display file blitter with hard-coded src/dest values, as the source address of the buffer is variable. I'm less concerned about this though... I've not used this method in any "production" code so far due to the amount of memory required! And I've never figured out a way to use PUSH/POP with a variable SP that would be faster than just using an LDI-based equivalent...

[vintage-mike]

The most obvious one to me is that any sprites which would overflow the end of the screen buffer will need splitting (essentially drawn as 2 sprites - top section near the end of buffer memory, then the bottom section near the start of buffer memory). Something like this?

Essentially the offscreen buffer is only ever one screen high (+ one row of tiles, in my case the most it will scroll by is 8px so one row of tiles is 8px high) and anything that draws onto the offscreen buffer has to be aware that the current pointer address is the 'top' of the screen (when translating from x,y to buffer address) and if the drawing code overflows the buffer (e.g. the lower most part of the offscreen area) then it just wraps back around to the beginning of the buffer.

Then all you have to do is adjust the pointer by n pixel lines (to create the scroll effect), then prepare the offscreen buffer (redraw sprites etc, which is a bit more involved - but if you think about it, redrawing the sprites relative to a new 'top of the screen' address, because the pointer has been moved, will ensure they stay correctly positioned relative to the scrolling background) - and then do the blit using the current pointer address as the source. Once again while doing the blit, make sure that if you run off the end of the offscreen buffer your source (read) address wraps back around to the start of the buffer.

At the appropriate scroll interval you can draw in the new row of tiles - the tile map doesn't have to loop, it could be infinite if it were procedurally generated for example.

As for the blit operation - I tried a few different methods, including SP based methods, but in practice, unless you can unroll all the loops (which isn't practical in this case) then the overhead of manipulating / swapping registers to allow the stack pointer to be used, preserved and manipulated correctly is worse than just using a naive LDIR. However, using an unrolled LDIR as separate LDI transfers, does seem to be the most efficient.

[presh]

Essentially the offscreen buffer is only ever one screen high (+ one row of tiles, in my case the most it will scroll by is 8px so one row of tiles is 8px high) and anything that draws onto the offscreen buffer has to be aware that the current pointer address is the 'top' of the screen (when translating from x,y to buffer address)

Cool, this fits with what I had in mind so far!

and if the drawing code overflows the buffer (e.g. the lower most part of the offscreen area) then it just wraps back around to the beginning of the buffer.

It sounds like you are checking for overflow after every row.

In my mind, it could be quicker (less cycles) to calculate if a sprite is going to overflow the end of the buffer, and split any sprite which does in two - that way, I never have to check for buffer overflow, as it will never occur. Whereas I guess the overhead for checking after each row depends on a) how tall most sprites are, multiplied by b) how quick it is to check for overflow after each row? I suppose if you cleverly choose the location of the buffer (at the tail-end of an appropriately sized "block"), it would only involve checking a single bit of the "write" address... hmm!

My proposed implementation does require some extra overhead at the start, and probably a lookup table to JP to the part of the (unrolled, with a label at the start of each pixel row) sprite drawing routine which will transfer n rows, so it could very quickly become more cumbersome than simply checking for overflow after each row. I'll have to do some more digging on this, it seems!

The rest of your post all seems in line with what I was thinking, so it's great to know that you've achieved a working version of this already

[presh]

Once again while doing the blit, make sure that if you run off the end of the offscreen buffer your source (read) address wraps back around to the start of the buffer.

I suppose there could also be a case for splitting the blit into two non-overflowing chunks - in my mind, that surely has to be quicker than having to check for overflow after each pixel row?

Sorry for all the questions - I always find it beneficial to listen to others who walked the path before

[vintage-mike]

I suppose there could also be a case for splitting the blit into two non-overflowing chunks - in my mind, that surely has to be quicker than having to check for overflow after each pixel row?

Damn, and I was trying not to give away *all* of my secrets (a man's got to - try to - make a living after all... )

I always find it beneficial to listen to others who walked the path before

Very wise... (And similarly, I was once told that before you criticise someone you should walk a mile in their shoes, because that way, if you *do* criticise them you'll be a mile away, *and* you'll have their shoes... but that's another story entirely...)