Log In  

Fading Stars Demo

Cart #fading_stars-4 | 2021-01-12 | Code ▽ | Embed ▽ | License: CC4-BY-NC-SA

Demo showing the combination of the stars and fade effect I'm using in my current space game project (link TBD).


The stars are just simple particles that have x,y,z coordinates.

In this demo I use a couple of sin functions to give them some movement combined with a divide by the z coord for a bit of parallax. In game, I feed in the player's position.
Then I clamp the resulting x,y values to the screen with the modulus operator so they're always visible (%128). It does mean that the same stars go past constantly, but otherwise I was processing a lot of particles that don't get seen very often (not aiming for realism here).

Fade Effect

This works by mapping the colour of every pixel on the screen to another colour that tends to a target e.g. 0/black.
You can use a similar mapping with the pal(x,1) function to e.g. do fades to black between screens etc. but that fades everything including anything drawn that frame.

In this demo I process the pixels already in screen memory so that the screen is faded by a step, then draw fresh stars on top of that.

It's pretty expensive to do the whole screen (IIRC about 90% of performance at 60fps) so I've set it up to do every fourth scan line, starting from a different point each frame so that effectively a quarter of the screen is faded at a time. It takes 4 frames to fade the whole screen one step.

I initially tried fading in quarter strips top to bottom, but the tearing on bigger objects like planets looked pretty bad.

Using the order 0,2,1,3 for the scanlines does some rough dithering to make the effect look a bit more uniform. A random value flr(rnd(4)) works quite well too, but is messier looking.

Since I found using poke4 to work on 8 pixels at a time was fastest (not surprising really) dithering horizontally is limited and isn't in the demo. Nevertheless, I keep meaning to try a "Z" pattern i.e.


I'm concerned it might cost too much more in performance/tokens for too little visual improvement.

Of course, as soon as I write about it the old subconscious starts working away and it takes 5 minutes to implement just that - a reverse N pattern as it turns out. Same performance, same tokens. See the new cart.

Pros of Effect

  • You can draw whatever you want really and the effect essentially "just works" as a replacement for a cls().
  • Cross-fading out from a scene just happens "free".
  • very simple particles look much more complicated than they really are


  • You can't draw anything that moves without the fade effect "catching" it. It can be mitigated by drawing around your objects (e.g. black borders), but if the view moves more than the width of the border you're out of luck.
  • Conversely, the effect only works where you don't draw that frame - so if your game has e.g. a full-screen scrolling background that's drawn every frame then you won't see any effect at all. For a space game this isn't a huge problem, but it's still visible here and there.
  • If nothing moves then there's no effect - try hacking the stars to be still in the demo.
  • Performance cost is approx 21% at 60fps.
  • Obv costs some tokens.
P#86396 2021-01-12 15:57 ( Edited 2021-01-12 19:20)

[Please log in to post a comment]

Follow Lexaloffle:        
Generated 2021-01-18 04:24 | 0.019s | 4194k | Q:32