Jump to content

The Southsider

  • entries
    81
  • comments
    767
  • views
    136,063

Flicker Fest

Sign in to follow this  
cd-w

1,731 views

This is just a quick update on my Juno First game. I hope people don't mind me using this blog as a beta testing area. However, I find it useful to post these development versions as the folks here are quick to spot bugs and problems that I might not notice otherwise. The previous versions had a number of serious bugs, but I hope that most of these have now been resolved. The main features this time are:

  1. All 20 possible sprites are now displayed on screen. This causes some serious flickering, but this should not be so bad in the final game as the sprites will be moving and the maximum number will only rarely be reached. The flickersort routine uses almost all of the vblank area, so let me know if you see any screen rolling.
  2. I have started to implement the collision detection code, so it is now possible to shoot the aliens. An explosion effect will be added later.
  3. The sprite movements should be a bit smoother, and the spaceship velocity decreases if you do not hold the joystick foward or backwards.
  4. Some of the sprite sizes and colours have been tweaked thanks to suggestions by Nathan.

Anyway, let me know if you sport any problems, or have any suggestions? The source code is included in the ZIP file as usual.

 

Thanks,

Chris

 

 

 

Sign in to follow this  


23 Comments


Recommended Comments

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 :evil:

Share this comment


Link to comment
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 :evil: 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

Share this comment


Link to comment

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. :evil:

 

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. ;)

Share this comment


Link to comment

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

 

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. ;)

Share this comment


Link to comment

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. :evil:

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

Share this comment


Link to comment

This is going to be so awesome! :evil:

 

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.

 

juno.gif

Share this comment


Link to comment

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.

Share this comment


Link to comment

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 :evil: 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

Share this comment


Link to comment

This looks really nice, Chris! :evil:

 

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

Share this comment


Link to comment

This looks really nice, Chris! :evil:

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

Share this comment


Link to comment

I was hoping that nobody would notice the laser :evil: 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 ;).

Share this comment


Link to comment

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. :evil:

 

juno7_layout_1.gif juno7_layout_2.gif

 

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. ;)

Share this comment


Link to comment

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.)

Share this comment


Link to comment

This is going to be so awesome! :evil:

 

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.

 

juno.gif

 

 

 

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

Share this comment


Link to comment

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.

Share this comment


Link to comment

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. :evil:

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

Share this comment


Link to comment

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.

Share this comment


Link to comment
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?

Share this comment


Link to comment
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.

Share this comment


Link to comment

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 :evil:

Share this comment


Link to comment
That, and maybe also 'cuz there's no air in space :evil:

 

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).

Share this comment


Link to comment

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

Share this comment


Link to comment
Guest
Add a comment...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...