Dear Pico-8 Community,
The darker colour palette should be available without fiddling with memory or coming up with detour functions.
Palette switches were cute,
but this whole schebang has flopped into an inefficient knot (as far as I can tell).
...I wish that first-time-carts from total amateurs (like me) could also use "dark-brown", lol.
...And that expert carts don't all use ~double the amount of available colours.
Perhaps I don't understand the memory limitations.
And I do appreciate (and want to preserve) the elegance of "0-15"/Proof of concept/Simplicity didactics etc..
But the cats' been out of the bag for a while.
@zep could you please greenlight "night mode" [EDIT: in the UI or functions].
Maybe its impossible at this rate. Maybe it wasn't intended this way.
Dunno. Shäre ur thoughts...
Trying to be constructive. Or did I miss something?
It's a super interesting subject, feels almost political.
Happy new year.
I'm making a sexy little 16x16 sprite editor with playback and more that should rely on the D-Pad and Buttons. Doing so mainly for use on the Retroflag-GPi case, or any other handheld.
SAVE FUNCTIONS STILL VERY BASIC
Give it a go!
Any help/advice/ideas appreciated.
Wanted to share my first proper pico project.
About having only one cigarette left (or not...? what?!)
I used this to make a music video for my band (see youtube embed). DISCLAIMER->GERMAN MUSIC
At the moment it's more of a demo/screensaver, but I would like to turn it into a minigame, or a system of mini games ; if there's fun in it somewhere. So i'm open to ideas :-)
Was thinking of the trope of an "alien brood mother" spitting out mini enemy's. (pack -> cigarettes)
And chaotic controls like only being able to apply gravity/momentum to all objects.
The physics engine is relatively sturdy, except for the lack of Separating_Axis_Theorem, some minor tunnelling and items getting trapped in each other.
I used Chris Heckers impulse physics articles from the 90s and a dynamically subdivided "intra-frame-crawl-while-loop-thingy" to resolve collisions chronologically. and the "Pool hall lessons" article on gamasutra for early false returns (which should be followed by an S.A.T. check which I have yet to write...) So could be waaaay more efficient.
Glad to share some cleaned up functions if anyone needs them (though the code is pretty legible).
important: USES METATABLE CHANGES FOR VECTOR MATH!! (see tab 4 / --metatables--)
Shoutout to the community for the amazing and helpful threads, and specially to lazydev @Krystman for his fantastic (and very funny) youtube series (LG aus Kölle).
Hope you get a giggle out of this one.
Hallo Pico People,
Loving it here. First post!
So i'm working on a 2D physics based collision engine.
...Imagine a whole bunch of polygons flying around, wrapped in AABBs (axis aligned bounding boxes)...
And I was wondering if this was a legit/efficient way to check if Two Edges/Line-Segments Intersect.
1. Treat them as AABBs and check if those overlap, is so keep the "resulting mini rectangle".
2. Treat them as Linear-Functions (infinite strait lines) and check if they are parallel, if NOT determine the resulting "point of intersection"
3. check if the "point of intersection" is inside the "resulting mini rectangle".
--return that point, otherwise abort
--do segments intersect? if so where? function segments(a,b) local r=overlap(to_rect(a), to_rect(b)) if(not r)return false local pt=intersection(a,b) if(not pt)return false if(in_rect(pt,r))return pt return false end
Lets assume the sub-functions (which I haven't included) are squeaky clean, its more about the idea...
Have to say it works a charm at the moment, even on weird concave polygons. But I could be going mad.
Any tips? Would it be easier on the CPU to use dot/cross product stuff? Am I missing something?
ps. here's a drawing