-- update: fixed a bug where I was still drawing 16x16 sprites from testing that.
Cart showing how to exploit the undocumented multiple display functions to set up extra sprite buffers that can be mapped back into memory for negligible cost.
Use at your own risk ;)
Procedure
Init
-
poke(0x5f36,1) -- enable multidisplay
- write sheet 0 of sprite graphics to screen however you want
_map_display(1)
- write sheet 1 of sprite graphics to screen
_map_display(2)
- write sheet 2 of sprite graphics to screen
_map_display(3)
-
write sheet 3 of sprite graphics to screen
- swap screen and sprite addresses
poke(0x5f55,0) -- map display to where sprites are to start poke(0x5f54,0x60) -- map sprites to where screen mem was
Obviously your cart doesn't get any more storage space for sprites this way so how you fill the extra buffers is a bit of a challenge.
Use sprites
- map in display containing the sprite you want (_map_display seems to map to 0x6000 regardless of whether you've poked the screen or sprites address to somewhere else)
- draw the sprite as normal with spr() (or sspr() or map() or tline() etc.)
Example cart
In the example cart there's a simple wrapper function that takes a sprite number from 0 to 1023, maps in the buffer and chooses the sprite for spr() to use.
This is used to draw 256 sprites across the whole screen each frame. Looking at the performance with ctrl-P on my system, it costs approx 0.02-0.04 per frame compared to reverting to spr() with no mapping.
Background
I've been storing extra sprite sheets in strings that I decoded into packed tables to dump into memory with a line like poke4(0,unpack(sprites))
. This works okay, but took a significant amount of performance each frame. To stay at 60fps with other stuff going on I'd had to restrict changing sprite sheets pretty carefully e.g. twice a frame: background sprites, character/object sprites. Otherwise, I'd tried only mapping portions of the sprite sheet as needed, but it gets fiddly and still hurts performance.
I've also played about with the multidisplay functionality (take my Christmas Chaos game on itch for instance). During dev on that I realised that the different display buffers are persistent and accessible whether PICO-8 is actually in multi display mode or not, but it didn't seem very useful at the time.
I knew we were going to get to change the address of screen and sprite memory with 0.2.4, but I haven't got round to playing with it until now.
Perhaps there's some other fun things to do with this, but I haven't thought of them yet.
I hope zep doesn't mind me posting this :)
Work In Progress:
A tool I made to help learn how fillp() code works as well as the 256 colour combinations.
In future I plan to add a hexadecimal readout as well as a means of changing the colour other than rewriting the colour table in _init(). Comments and better organisation of code is also on the to do list.
I made a little banner for my profile pic, which was 60x10 pixels. I used it, and it was heavily antialiased, looking really bad. I personally think this has to be a BBS bug, because the main product, PICO-8, is a pixel art game. I'd hope to see this fixed at some point
EDIT: my computer might have antialiased it on its own
EDIT EDIT: actually it didn't...
So, for a game, I want to fade everything thats not being recurrently drawn (such as a character) to black. You can see the effect here, in PICO Space. How would I go about doing this?
ello
I made a half working cart about bezier curves and wanted to see what people think about my code, so if you want to pls give feedback
note: you can add points by using the up and down arrow keys then move the points by using the mouse and cycle between them using X and O
--bezier curve time function clone(t)--clone a table return{unpack(t)} end function lerp(s,e,m) return s*(1-m)+e*m end function lerp2d(p1,p2,t)--lerp lx=lerp(p1[1],p2[1],t)--two 2d ly=lerp(p1[2],p2[2],t)--points return lx,ly end poke(0x5f2d,1) --devkit mouse p1={64,64} --first point ptt={ p1} --point table pts=0 --number of desired points ind=1 --index used for selected point t=.5 --time value used across lerps function lerpcheck()--lerp the points po1=lerp2d(ptt[1],ptt[2],t) l=#ptt-2 for i=0,#ptt-1,1 do if(ptt[i+2]~=nil)lx,ly=lerp2d(ptt[i+1],ptt[i+2],t) --lx stands for lerped x [ [size=16][color=#ffaabb] [ Continue Reading.. ] [/color][/size] ](/bbs/?pid=116089#p) |
Things are beginning to come together! I have been working on a new feature: Jumppads. These will be used a lot in level 2, which i am working on right now. I also added a effect for the checkpoints, so its clearer when you have activated one. Thanks to @profpatonildo for suggesting to change the speed up sound, the new one is a lot more suddle and i think you wouldnt even notice it when playing. Now you have 4 lives at the begiing of the game and when you bump into walls, you lose your speed.
Things you may find interesting about this cart set:
Sound Effects
The helicopter rotor sound consists of these four notes:
They play in a loop, and as helicopter throttle and rotor "pitch" change, poke commands are used to alter the speed and tone of the notes:
if heli_sound==10 then -- SFX 10 is the continuous rotor sound -- deltax is used to determine how much -- rotor 'slap' to add local deltax=heli_xspdtgt-heli.xspd -- rotor slap changes the volume -- of the two notes (noise) -- the more tilt the heli has, -- the more pronounced the 'slap' is local rotorslap=({[0]=0x53,0x53,0x55,0x57,0x59})[abs(heli.tilt)] [ [size=16][color=#ffaabb] [ Continue Reading.. ] [/color][/size] ](/bbs/?pid=115670#p) |
Hey there! Ive been working hard on my game Foxpedition. Me and my dad added a death system, checkpoints, better camera and i completed the first level. You can play a demo here, an i woul reaaaally appreciate all feedback. Also, in the future there will be a speedrun timer.
The fox statues are checkpoints, and the sign is the end.
Flags do nothing.
Im starting a new project: Foxpedition. Its a platformer game that looks a bit like Celeste but plays like Sonic. I have the art and general movement in place, but the audio is nothing near done.
Also, its going to be JUICY. ( How did i forget to mention such an important game mechanic!?)
Here is a little sneak peek:
Over the past 4/5 months I haven't done much game development in pico 8, but I've started a new project - the sequel to my adventure game
Adventure game v1.0
https://www.lexaloffle.com/bbs/?tid=47009
(embed didn't work)
It's going to use some of my previous code experience to help me make it. It should be released in 2/3 weeks, and I will make another post if there is delays or bugs I need help with.
Adios!