Realtime Scaling in Marble Garden?

Discussion in 'Technical Discussion' started by Noah Copeland, Nov 19, 2019.

  1. Noah Copeland

    Noah Copeland

    Member
    36
    15
    8
    So the boss in the Marble Garden Act 2...when eggman goes into the background.

    It's pretty smooth. Does anyone know if that's software scaling? Or are all the individuals frames bespoke into memory?
     
  2. Fred

    Fred

    Formerly known as 'Neo' Oldbie
    1,483
    42
    28
    Portugal
    Sonic 3 Unlocked
    It's software scaling. Do a search for Init_ArtScaling in the disassembly and you'll find a bunch of unrolled art copy loops. The art is uncompressed in a special format for quicker lookup and is prefixed by 'ArtScaled_' in the disasm. The proto has a test object for the scaling functions, but it was removed in the final S3.
     
    Last edited: Nov 19, 2019
    • Informative Informative x 4
    • List
  3. FireRat

    FireRat

    Nah. Fuck it. Member
    48
    9
    8
    Chile
    Mobius Evolution 2
    The data is stored as 2:1 pixels, yet the routine can output 1:1 pixel perfect versions of original sprites. I'd like to elaborate about it... the reason this "special format" arranges the data like that, is because the VDP does 4 bits per pixel; in other words 2 pixels per byte. You'll have to combine different pairs of pixels according to the scale to display, and if you had 2 SAME pixels per byte, it's much easier to filter out (AND) the unnecessary halves from your 2:1 pixels, and combine them as single pair (OR).

    Pixel #0 (color 0xE):
    combined_pixels = 0xEE & 0xF0

    Pixel #1 (color 0xF):
    combined_pixels |= 0xFF & 0x0F

    Result: combined_pixels == 0xEF

    This is why there's not many instances of scaling sprites throghout the game: Not only the sprites must be stored as uncompressed (no decompression means less CPU/RAM to spend), but this special formatting imply that each file has double length compared to a regular file, spending more ROM space (in favor of faster/easier pixel pairing).

    Besides that, and unlike the queue-based kosinski decompression, the scaler routine is called from the object itself, and the process doesn't get interrupted by the vertical blank (aka not a "background task"), which is why the game slowdowns in every case the routine is called (not when "flying Eggman" object was possibly meant to appear, but... well, scrapped).
     
    Last edited: Nov 21, 2019
    • Informative Informative x 3
    • List