The Southsider

The flickersort routine is now uses almost all of the vblank area, so let me know if you see any screen rolling.

 

One tip I have is ending the VBLANK timer like this:

 

LDA INTIM
BMI TimerExpired
BNE WaitIntimReady
RTS

TimerExpired
BRK

 

A bit brute force, but you *will* notice if you exceed VBLANK time

The flickersort routine is now uses almost all of the vblank area, so let me know if you see any screen rolling.

One tip I have is ending the VBLANK timer like this ...

 

Thanks - I hadn't though of that, though I will probably just change the background colour rather than crashing the machine Incidentally, the first version that I posted had a bug in the laser beam positioning, so if you were the person who downloaded it then you might want to download again.

 

Chris

Lookin' good - I'm not seeing any rolling, and as much as it flickers, it's still nothing like Pac-Man.

 

That's an impressive amount of stuff onscreen. A nice side-effect of the way Juno First is laid out, is that as the enemies get closer to the player, they spread out, so they flicker less at the larger sizes.

 

The sprite colors look better, too. The dark blue doesn't disappear anymore.

 

Is the score going on the bottom of the screen now? I noticed everything is shifted up.

 

The only obvious glitch I'm seeing is the ship's laser is offset to the left.

 

Edit:

Incidentally, the first version that I posted had a bug in the laser beam positioning, so if you were the person who downloaded it then you might want to download again.

Nevermind.

Hehe... I'm not that quick downloading things. (Especially when I'm still at work )

Ah... I also see you've added a dividing line below the player's ship since the previous juno7. That helps.

 

This is going to be a fun game when it's all done. It's already remarkably close to the arcade game's "feel". Even at this stage, I'm enjoying playing it to the degree that I can. I think that's the mark of a good game. Reindeer Rescue was like that. Even early on, it was fun making Santa run around and jump over stuff. The same goes for Colony 7. Except, of course, Santa isn't in that game.

Lookin' good - I'm not seeing any rolling, and as much as it flickers, it's still nothing like Pac-Man.

That's an impressive amount of stuff onscreen. A nice side-effect of the way Juno First is laid out, is that as the enemies get closer to the player, they spread out, so they flicker less at the larger sizes.

 

There is definitely a lot of flicker, but I hope to be able to minimise the impact of this on the game by spawning the alens with suitable gaps where possible. I think I have fixed the screen rolling problem, but I need to calculate the worst case performance of the flicker sort by hand to check that it will never exceed the available time. Manuel was certainly right when he warned that the object handling would be a killer task (I still haven't removed the sprite index as it essentially comes for free now with the flicker sort routine).

 

The sprite colors look better, too. The dark blue doesn't disappear anymore.

Is the score going on the bottom of the screen now? I noticed everything is shifted up.

Ah... I also see you've added a dividing line below the player's ship since the previous juno7. That helps.

 

The score is now going at the bottom of the screen as it needs the same memory that is used to display the aliens. I might put the lives and time-remaining indicators at the top (using the PF), but I haven't decided on this yet. I am a bit worried that the screen looks lopsided in the current version? From an atristic point of view, do you think I should center the screen vertically and add lines above and below, or keep it as it is?

 

This is going to be a fun game when it's all done. It's already remarkably close to the arcade game's "feel". Even at this stage, I'm enjoying playing it to the degree that I can. I think that's the mark of a good game. Reindeer Rescue was like that. Even early on, it was fun making Santa run around and jump over stuff. The same goes for Colony 7. Except, of course, Santa isn't in that game.

 

I think it does capture the feel of the original quite well (so far). However, I'm not sure about the inertia of the ship as it feels like it slows down too quickly? The game is certainly pushing the 2600 close to the limit which is always good, and I don't think there are too many other 2600 games that have a similar feel (Beamrider and Solaris are probably the closest).

 

Chris

This is going to be so awesome!

 

I was wondering if it might be possible to tweak the speed of the lazer beam a bit to maintain perspective as it goes across the terrain? As is, it doesn't seem to give the same illusion of depth that the enemies and terrain do. Maybe I'm nuts, but it almost looks as though the lazer is shooting straight up into space.

 

An idea might be to change the lazer color gradient as it moves across the terrain, as well as have it shorten in length as it is moving. Here is a quick animation to give an idea of how I mean.

 

An idea might be to change the lazer color gradient as it moves across the terrain, as well as have it shorten in length as it is moving.

Good point. And the speed should also be reduced.

An idea might be to change the lazer color gradient as it moves across the terrain, as well as have it shorten in length as it is moving.

Good point. And the speed should also be reduced.

 

I was hoping that nobody would notice the laser Changing the length will be difficult, but it will be possible to change the speed, and may be possible to change the colour. I will experiment will various options for the next version.

 

Chris

This looks really nice, Chris!

 

I love the massive number of sprites; I think it looks absolutely fantastic! Flicker is fine.

This looks really nice, Chris!

I love the massive number of sprites; I think it looks absolutely fantastic! Flicker is fine.

 

Thanks - I'm quite pleased with the way the kernel worked, and all the sprites are 1LK (unlike Beamrider). Do you think the sprite movement for the aliens is smooth enough now as I think it it has improved a lot over the previous versions? I am hoping that the kernel will not require much more work as it is getting very difficult to make changes and the code is a real tangle (like all the best kernels )

 

Chris

I was hoping that nobody would notice the laser Changing the length will be difficult, but it will be possible to change the speed, and may be possible to change the colour. I will experiment will various options for the next version.

Then make the laser full length (like real lasers would be anyway .

There is definitely a lot of flicker, but I hope to be able to minimise the impact of this on the game by spawning the alens with suitable gaps where possible.

On the levels with symmetrical attack patterns (every what... third level?), could you use sprite multiplexing for some of the aliens? Would that even be of any help here?

 

I am a bit worried that the screen looks lopsided in the current version? From an atristic point of view, do you think I should center the screen vertically and add lines above and below, or keep it as it is?

Well, let's take a look.

 

 

I don't know - splitting it "balances" the screen, but the other way gives you all of your important info in one place, and looks a little cleaner.

 

I think it does capture the feel of the original quite well (so far). However, I'm not sure about the inertia of the ship as it feels like it slows down too quickly?

I agree - it feels a little bit like you're flying through mud.

I was wondering if it might be possible to tweak the speed of the lazer beam a bit to maintain perspective as it goes across the terrain?

 

An idea might be to change the lazer color gradient as it moves across the terrain, as well as have it shorten in length as it is moving. Here is a quick animation to give an idea of how I mean.

 

That's a good point - the arcade game does that as well, although not quite to the same degree. (It doesn't change color though - but it does break-up into smaller pieces.)

This is going to be so awesome!

 

I was wondering if it might be possible to tweak the speed of the lazer beam a bit to maintain perspective as it goes across the terrain? As is, it doesn't seem to give the same illusion of depth that the enemies and terrain do. Maybe I'm nuts, but it almost looks as though the lazer is shooting straight up into space.

 

An idea might be to change the lazer color gradient as it moves across the terrain, as well as have it shorten in length as it is moving. Here is a quick animation to give an idea of how I mean.

 

 

 

 

Check Radar Lock to see the most convincing perspective on shots.

To avoid the flicker, I think you should really look into having some enemies be drawn via double or triple copies. It doesn't make sense to have two enemies of the same type on the same vertical position next to eachother flickering like crazy.

On the levels with symmetrical attack patterns (every what... third level?), could you use sprite multiplexing for some of the aliens? Would that even be of any help here?

 

Unfortunately not, as this would cause the missile sprites to be multiplexed also. I guess I could use just one missile sprite on these levels, but this would complicate things - I might revisit this later though.

 

Well, let's take a look.

I don't know - splitting it "balances" the screen, but the other way gives you all of your important info in one place, and looks a little cleaner.

 

I think that keeping all of the information at the bottom looks better, and it will be easier to implement also

 

I agree - it feels a little bit like you're flying through mud.

 

Yes, I need to think of a better technique - the current version is too linear.

 

That's a good point - the arcade game does that as well, although not quite to the same degree. (It doesn't change color though - but it does break-up into smaller pieces.)

 

Splitting into pieces isn't feasable with the current kernel, but I will try the other techniques.

 

Thanks,

Chris

On the zone where you have the 2 or 3 copy sprites, don't use the matching missile and instead use more flicker on the alternate missile. When you get beyond that zone then go back to flickering both missiles.

 

It should also be possible to force vertical separation between missiles easier than sprites to avoid flicker.

Yes, I need to think of a better technique - the current version is too linear.

I suppose you are subtracting a fixed value from the speed, right?

 

Assuming you are using a 16 bit variable here, how about subtracting a fraction of the speed itself from the speed?

Assuming you are using a 16 bit variable here, how about subtracting a fraction of the speed itself from the speed?

 

The normal approach (assuming velicity is positive) is to use V=V-a-bV, clipping at zero. Using only the 'a' term (setting 'b' to zero) will make the vehicle feel like it's being driven through mud; using only the 'b' term will make the vehicle feel too 'slidey'.

 

An alternative approach would be to use a table to get the adjustment value for any current velocity. This would allow a somewhat improved V=V-a-bV-cV^2 (since air friction increases with the square of velocity). Not sure if you'd want to use the ROM for that, though.

An alternative approach would be to use a table to get the adjustment value for any current velocity. This would allow a somewhat improved V=V-a-bV-cV^2 (since air friction increases with the square of velocity). Not sure if you'd want to use the ROM for that, though.

That, and maybe also 'cuz there's no air in space

That, and maybe also 'cuz there's no air in space

 

That is true, smarty-pants. On the other hand, the table-driven approach may have advantages anyway. Among other things, it may allow the programmer to better adjust the "feel" of the ship than would be possible by just changing a couple numbers. If one has different adjustment tables depending upon whether the controller is being pushed, one can give the ship a maximum speed without it feeling like a "hard" limit (i.e. the faster the ship goes, the less thrust it has; continued thrusting forward will get the ship closer to terminal velocity, but there's no clear time when it gets there).

That is true, smarty-pants. On the other hand, the table-driven approach may have advantages anyway. Among other things, it may allow the programmer to better adjust the "feel" of the ship than would be possible by just changing a couple numbers. If one has different adjustment tables depending upon whether the controller is being pushed, one can give the ship a maximum speed without it feeling like a "hard" limit (i.e. the faster the ship goes, the less thrust it has; continued thrusting forward will get the ship closer to terminal velocity, but there's no clear time when it gets there).

 

This sounds like a great idea. I am already using tables to determine the movement and speed of the aliens in the various screen regions, and I recently gave up on the idea of fitting the game in 4K.

 

Chris