I want to do a de-make of "Another World", this game is built of many static screens (no scrolling) and the backgrounds are drawn using very creative, data efficient, free-form "polygons".

To increase the number of screens I can have, and match the free-form polygonal art style, it seems better to discard the tile map, and use the map data to store "screens" and each screen would store "polygon info". So it would just be the points for the polygons, or something simpler - maybe just indexes of known shapes and a colour value to apply to them, something like that.

However it's stored - it would be expensive to re-draw the entire thing every frame, so I would have to use the old school technique of;

• draw the background once,
• capture the area behind a sprite,
• draw the sprite,
• then to re-draw, paste the captured area back over it, adjust the sprite x,y and repeat

How do I prevent the normal re-draw, and how do I capture an area of the screen?

Any thoughts on my approach?

I just did it on my ldjam entry

on each frame I load my screen then modifiy it then save and draw sprites for the final display.

I saved the screen with memcpy. You need 0x1FFF space for that so I first used 0x1000 adress ( = sacrifice 50% gfx and the whole map )
Then I had to use the 50% gfx so I moved a part of the screen on the user-defined part at 0x4300 ( infact I dont know what it's used for )

Here's the code you need

function load_scr()
memcpy(0x6000,0x1000,0x1000)
memcpy(0x7000,0x4300,0x0fff)
end

function save_scr()
memcpy(0x1000,0x6000,0x1000)
memcpy(0x4300,0x7000,0x0fff)
end

It's the first time I use memory this way and I'm not really used to hexadecimal so maybe there's a better way to achieve this...

I actually spent a good deal of time on actually reimplementing in AW in the pico-8, but hit the memory barrier pretty fast. The game engine uses 4 screen buffers (one is the active display), and one was a 'copy' buffer (used for a special displacement polygon mode)

to get around this, I was keeping the 4 screens in cartridge memory (cstore/restore) and swapping them out with the 0x0000 / 0x6000 depending on the active pointer mode.

Note: AW contains a LOT of polygon information. it comes out to around ~100k on average of shape information per stage (there are like 8 stages in the game)

Very little of the game is static bitmaps, only like 7~8 screens in the entire game are prerendered (mostly high detailed stuff like the pool scene with the stained glass)

I wrote this polygon library a while back, which works from strings, but can also read from other memory regions. After drawing to the screen, it stores into a temporary buffer so that it can be redrawn without drawing all the polygons again.

There's also a program to create the illustrations as well.

Feel free to take anything that you can use.

https://www.lexaloffle.com/bbs/?pid=15569&tid=2630&autoplay=1#pp

https://www.lexaloffle.com/bbs/?pid=15535&tid=2598&autoplay=1#pp

Thankyou Benjamin. I would have thought you just draw to the screen and then only redraw the parts that change, so why does the whole screen need to be copied?

asterick really?? You had the same idea as me? Can you show me what you did?
Yes I figured I'd run out of polygon data by storing each vertex, so I was toying with the idea of having set shapes or clusters of shapes hardcoded and refer to them by index to re-use them, and make the screens out of that. It would be a simplistic, approximation of the AW screens, but so are all Pico de-makes :D

electircgryphon, wow, thanks! I will definitely be trying that out.

I've heard how helpful the Pico community is, it's all true :)