Log In  

Cart #48271 | 2018-01-17 | Code ▽ | Embed ▽ | No License

Hello everyone, after a Twitter thread of WIPs and half posted routines, I'm releasing this cartridge containing a few routines to allow making basic split-screen scenes relatively cheaply (around 20% of CPU used at max and 8KB of RAM used as back_buffer.

This isn't a pretty scene or sketch, it's at most minimal, but it shows that you can have two scenes drawn and draw them with a non-axis-aligned delimitation. Is anyone remembered of the DBZ SNES/Genesis fighting games? :D

-- Available functions:
- cpy_to_buffer : saves the current state of the VRAM to the back-buffer
- drw_horiz_half : draws the back-buffer on the top part to the screen, with the limit being a line located on ([0;y1],[127,y2])
- drw_vert_half : draws the back-buffer on the left part to the screen, with the limit being a line located on ([x1;0],[x2,127)

Have a nice day!

Addendum : two more things

  • It doesn't do bound check, so beware if you go out of [0;127]
  • There probably is space for optimization, sorry for the ugly code.

Update :
I did an update fixing the horizontal split code, cleaning a bit here and there and applying Felice's array indexing idea (thanks!) And I did a small demo to show a bit better what it could like than just two plain screens.

P#48239 2018-01-16 10:13 ( Edited 2018-01-17 16:48)

I have some thoughts.

First, instead of using a 0-based table for your offscreen buffer, use one that's keyed by address:

-- holding the previous captured screen data
local back_buffer = {}
for a=0x6000,0x7ffc,4 do
    back_buffer[a] = 0

function cpy_to_buf()
    for a=0x6000,0x7ffc,4 do
        back_buffer[a] = peek4(a)

Second, order probably doesn't really matter, so you could use pairs() to restore more efficiently, at least when it's a simple full-screen case:

function cpy_from_buf()
    for a,v in pairs(back_buffer) do

Obviously you're doing something more complex than simply re-blitting the entire back buffer onto the screen, but you could probably still benefit from the altered format somehow. Instead of iterating with x,y positions or indices, just do the math to produce the desired addresses directly and then poke(a,back_buffer[a]) in the inner loop.

Or not. I'm not sure. But it's worth looking into. :)

This is one nice thing about working in a table-based language: your indices don't have to start at any particular value or be contiguous.

P#48242 2018-01-16 12:31 ( Edited 2018-01-18 14:20)

Thanks for the idea, I'm still used to 0-arrays when it comes to low-level / bit-math due to C but it sounds like an interesting shortcut. Thanks! I'll look forward implementing forward that!

P#48248 2018-01-16 18:11 ( Edited 2018-01-16 23:11)

This is awesome.

I just need to make a new game JUST to use this! :P

P#48273 2018-01-17 11:48 ( Edited 2018-01-17 16:48)

[Please log in to post a comment]

Follow Lexaloffle:          
Generated 2023-12-05 21:14:26 | 0.011s | Q:14