logicomacorp/witchcraft

Checklist

yupferris opened this issue · 0 comments

So we don't forget stuff :)

  • Initial track + graphics
  • Start project/framework
  • Get graphics in place
  • Set up scroller display (with hw stretch trick)
  • Scrolltext
    • See the scroller_text label in witchcraft.asm
  • Font
    • Needs to be 8px by 8px (or less) and contain all the chars we'll use for the scrolltext
  • Updated music.prg
    • Needs to loop and perhaps contain some additional fun fx
  • Scroller stretch/bounce/color fx
    • Currently thinking to go through a set of these that get progressively more complex, and then just loop, with a simple fade in/out effect. Easiest fade effect would be some kind of "wipe", where we fill up the color table with black scrolling in from the bottom, or both bottom/top, or interleaved.
    • Scroller effect transition
    • Static, centered scroll
    • Y-sinus scroll
    • Repeating y-sinus scroll with different colors per repetition
    • "Layered" scrolls, with a few different y-sinus scrolls with different colors overlapping each other
    • TODO: Come up with a few more (eg. x-rotator with "lighting" simulated in the colors, perhaps some layered/scaling rasterbars mixed in if we end up with a 7px high font, some plasma/sinus distorted stuff.. and maybe also some more interesting color cycle stuff)
  • Graphics fade/wipe color fx
    • Simplest version of this is going to be simply fade in from black and back out to black again, with different colors each time. I'm hoping to do some more interesting wipe effects with a video compression-like setup which will keep per-frame writes low, but might expand the dataset size prohibitively. Perhaps a mix with a single nice fade in/out cycle but with swappable colors (zp?) could work nicely.
    • Since the sprites share 2 of their 3 colors, it's probably easiest to fade them in after fading in the other gfx, and fade them out before fading out the other gfx. Need to look into this a bit.
    • BG
    • Sprites
  • Look into compression
    • Currently the .prg is going to end up being a bit large. This isn't a huge deal with fastloaders etc, but it might be nice if we get the extra time to look into compressing things.
    • Initial quick test just running it through admiral p4kbar resulted in a ~10kb binary, which is not bad at all. Depending on how the picture fades compress, we might even be able to squeeze this into 16kb, which would be rad :)