Close

Enhancing the bitmap conversion

A project log for Unlimited tile world on a Commodore 64

Unfinished childhood project

lion-mclionheadlion mclionhead 08/20/2024 at 18:570 Comments

There were some attempts to make the world map more legible & wider.  Grey scale looked the best of all methods but still terrible. Shades of red were worse.  There could be pseudo colors made of checkboard patterns.  A checkerboard pattern can compress if every other byte is a ROL.

It's pretty hard to make the world bigger in 1 direction.  It seems if the tile buffers underrun, it currently just crashes.  It tries to start a new tile read every time it scrolls 40 columns, but there's no way to interrupt a disk read so it crashes.

A downtown map was similarly bad.  Saturating the image helps, but it seems either the palette is too limited or the color selection is just horrible. 

The image conversion is the biggest area which needs improvement. A problem with the nearest color algorithm could be making grey look better than red.

For a mars based game, another idea is monochrome bitmap mode, using dithering to get 3 shades of red.  The starship would be shades of grey.  Helas, that looked really ugly in "the great escape".

Some guys used genetic algorithms to improve the color matching.  https://www.syntiac.com/tech_ga_c64.html 

For a static mars landscape with shades of red, manual palette matching would be best.  If the palette is just 4 shades of red, color memory can be static.  The commodore had 5 shades of red including black & 5 shades of grey including B & W.  Static color memory could define only 4 colors & would only save 500 bytes.   5 colors could be defined in 500 bytes of color memory if 3 of the colors were fixed.  The non reusable aspect, the limited gain & the loss of color substitutions make the full 1500 byte color memory preferable.  RLE compression would do most of the optimizing.  Experiments would have to be done with 5 & 4 shades of red.

Compared the hardware palette with a custom palette & random dithering.   The custom palette gave the most intelligible results by having less contrast.  Random dithering is required for anything bearable.  The softer pixels of a real CRT might help.

The compression was still 8% in the worst case & 39% for the manely blank tiles.

---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

There was another idea where this type of passive scrolling background could serve a purpose as a timing indicator for a simple racing game.  At certain points in the map, enemies would appear & the player would need to take certain actions.  There would be a finish line indicated by a landing pad.  For now, dodging the enemies & doing a landing flip at precisely the right time would be the key maneuvers.  The enemies would try to push you off the map or ram you.  You'd have a flat spin & landing flip to knock down enemies, sideways movement, drifting, & a final landing flip.  Knockdowns would shake the screen.

Vertical scrolling would have more sideways range & look more intuitive.  It would still be slower.  Lions dream of a liftoff level & a landing level.

 It's a tantalizing idea, but lions are just no good at creating game graphics.  Converting a photo to a bitmap might be attainable but player art was a disaster 40 years ago as now.  There's no AI for commodore player graphics.  Getting enough colors would limit each player to single sprites.  Most games got away with single sprite players.

A spitter post had some low fidelity player graphics.

https://x.com/Flight5starship/status/1830332428206108775/photo/1

That's about all the detail it could have.  It would take 4 multicolor sprites in 2x height mode to define the player & flame.  Another 4 would define an enemy & flame.  2x width mode didn't have useful resolution in multicolor mode.  That leaves just 1 enemy at a time.  It would be a kind of fight game like street fighter, but with spaceships.  Space fighter.

Smooth, sheer free scrolling is the only reason it needs 20,000 bytes for onscreen bitmaps & all the interrupt disables.  It could fit a pretty big 4 tile world in RAM with lower quality scrolling.

---------------------------------------------------------------------------------------------------------------------------

Discussions