I am much confused about cstore/reload vs cartdata.
If I read correctly - you could replace cartdata with cstore/reload writing to and from the cart file, no?
Is it actually the case that this is true, or am I missing something important? I will note I am unable to currently get cstore/reload to actually work as I think they are supposed to, so I am open to "no, you misunderstand".
For the record - this is what I was trying:
Start Pico-8, do:
POKE(0x4300, 99)
CSTORE(0x4300, 0x4300, 1, "TEST")
Then later, restart Pico-8, and:
RELOAD(0x4300, 0x4300, 1, "TEST")
PRINT(PEEK(0x4300))
And I expect it to return 99 - but it does not.
Is a puzzlement.
PS. Can we get a version() call, or maybe put it in the "About Pico-8" menu? Seems it would be handy.
https://www.kickstarter.com/projects/thewebster/blaze-miniature-powerful-hackable-display-with-tou
"Blaze is a miniature, high-res 1.6" 240x240 display with capacitive touch, a powerful 120MHz Cortex M4 micro with GPIO and storage."

TL;DR - consider making pico-8 free for very inexpensive hardware, as a means to spur community growth and get it into the hands of the next generation.
So - this is easy for me to suggest, it costs me nothing.
I loves me some pico-8. Part of why I am so fond of it is it puts me back in my early teens, on my Atari 400, writing random silly games for the sheer joy of it. (I was fortunate enough to have parents able, and willing, to gamble nearly a grand on what amounted to a toy computer for their kid) But it has other great features - it is small enough to be learnable, it actively encourages sharing of code, and dammit - it's fun. It would be awesome if all kids had that same opportunity. Hold that thought for a moment.
One bit that I would love to see is an actual hardware realization. Yeah, I can play my stuff on OS X, but I crave a handheld, maybe something GBA or Nintendo DS flavored in terms of size. I don't want to carry around a laptop to play pico-8 games, and kids don't really have that option, until you maybe have an iOS/Android version.
I have a half-baked idea that it would be cool to take a Pi zero and do the fiddly work to make that happen; It is not impossible that the costs for such a project might get into the $30 total range, and for a kid to be able to have a handheld game console that they can make their own games on self-hosted, and trade the results - I can't help but think that would be phenomenal.
So - mixing that all together in a bucket:
What I was going to suggest is this; to encourage this sort of thing, offer a reduced (ideally free) license for pico-8, but only for hardware costing less than $N - where N is somewhere around 20 USD, give or take. You would end up included, by default, on EVERY danged distro ever for those bits, and usage would spread like wildfire, especially to schools and to kids who have savvy parents that are simply too poor to run bigger hardware. Also, it would spur development of inexpensive low-end linux-capable hardware to host it - "open source" handhelds, with proper controls and screens pixel-for-pixel suited to run pico-8.
I am not an business guy - but I would think what you lose on direct sales would be made up for by skyrocketing use, and more direct sales from old guys like myself who see that console, and want to develop for it, but would rather do so on our actual desktops.
Just thinking out loud.

Hi All!
Myself and a buddy made a game for the Global Game Jam, first time using Pico-8.
The theme of the jam was "Ritual" and we decided to focus on your morning rituals before you go to work.
It's a little rough around the edges but would love to hear what you thought.
Thanks!

Hello guys,
I'm new to Pico-8, but not new to programming in general. Before, I used Codea, Love2D, Corona, Gideros, Polycode and tried some other frameworks. I managed to code some, more or less, simple apps (mostly for drawing/animating stuff) but no games at all. I want to change that, because I love games and the good ol' days! Pico seems to be quite accessible. - With all its constraints it might be even the right tool and should be able to hold me back from overestimate myself. It might also help me to understand the hardware side of things a little better. (Which is very important to me.)
As of right now, I have a hard time to wrap my head around everything, since I was used to have a handful of helpful little functions, like tweens, meshes, etc. Also the lack of math knowledge seems to fight me also, as I now have to write all these function myself. But I think I get there slowly...
Since ever I dreamed to make a small rpg. Something like Pokemon or a some sort of a [b]survival game
Hello guys,
I'm new to Pico-8, but not new to programming in general. Before, I used Codea, Love2D, Corona, Gideros, Polycode and tried some other frameworks. I managed to code some, more or less, simple apps (mostly for drawing/animating stuff) but no games at all. I want to change that, because I love games and the good ol' days! Pico seems to be quite accessible. - With all its constraints it might be even the right tool and should be able to hold me back from overestimate myself. It might also help me to understand the hardware side of things a little better. (Which is very important to me.)
As of right now, I have a hard time to wrap my head around everything, since I was used to have a handful of helpful little functions, like tweens, meshes, etc. Also the lack of math knowledge seems to fight me also, as I now have to write all these function myself. But I think I get there slowly...
Since ever I dreamed to make a small rpg. Something like Pokemon or a some sort of a [b]survival game

This is my work in progress for global game jam 2016. I decided to go solo this year and give pico8 a whirl. You have to use the available weapons and work with your friends to survive the onslaught. The gun can kill monsters, but their angry spirits will come after you. Use the torch to exorcise the body and banish the spirit. The medikit can revive fallen teammates.

-up and down arrows control character
-character has a fan that clears clouds away
This is a game conceived during Ludum Dare 34. I didn't finish it by the deadline, but I used the two themes presented during the game jam: "growing" and "two buttons". This is the first game I've completion. Let me know what you think!

Every day, Professor Miggles goes to work. And every day he snoozes in bed until the last possible moment. To keep the points you get for snoozing, make sure to head out in time without forgetting to put your trousers on.
v1.1: Fixed high score bug, and added persistent high score (when played from pico-8)

So, it's 1am and this is what is keeping me up.
Boot up pico-8. Bask in it's glory. Hit esc to jump into the editor.
Type something, mess with mouse. Text selection. Go to icon editor, and the mouse is your main tool. So - clearly the pico-8 fantasy hardware supports a mouse.
Why can't my programs read the mouse? Possible answers:
1) The editors are "special" (do not like! seems unfair somehow.)
2) You can, it's just hidden or undocumented (ooh)
3) Because the editors are not written in the language we are using and have special access (probably the real answer, but very unsatisfying. breaks the illusion/metaphor of fantasy hardware.)
Or maybe something else? I noticed that you can poke in values to monkey with screen modes; if there were peeks somewhere that read the mouse x/y and buttons that we have yet to discover, that would be just kinda awesome.
If there are not - would be super cool to see them someday. Even if they were slipped in quietly for the community to accidentally discover via experimentation. Just sayin.
-- Your Friend Biggles

I'm using OSX.
On app startup in windowed mode, I'm seeing every Pico-8 pixel as a square block of N×N pixels, where N is a number the program chooses cleverly so that N*128, plus a variable black border, fits nicely inside the window dimensions set by the "video_mode" setting in config.txt. No matter what size I set in the config (as long as it fits inside the OS desktop) the pixels are perfectly crisp squares.
And that is great!
I wish it would always work like that.
It muddles up if I then manually resize the window - it seems to keep rendering into a buffer that's sized according to the config at load time, and then scales that buffer to fit in the window.
It would be nice if that worked differently (e.g. resizing the buffer according to window size, then recalculating N to fit the new buffer size), but I'm not experiencing it as a problem, so I won't complain much.
I'm not even sure it didn't work that way in a previous version.
What I am experiencing as a problem is the full-screen display. It seems to also render into that same buffer, then scale that buffer to the full-screen resolution, and that generally creates some anti-aliasing between Pico pixels.
There are approximately a total of 1 possible sizes that look crisp: the size must be equal to the vertical screen resolution. But this size can't ever work well in windowed mode, because OS chrome takes up some vertical space, so app windows have to be a bit smaller.
("Approximately" because, technically, using an exact multiple of that size also works, and I guess one could add pedantic footnotes about horizontal size and portrait monitors.)
So in my case, if I set the line in config.txt to anything larger than 852×852, the windowed mode is blurry, because the OS resizes the window to a size smaller than the buffer, so the buffer gets scaled.
But if I set it to (almost) anything other than 900×900, the full-screen looks blurry, because a buffer that's not 900 pixels is being displayed at 900.
There's no setting that lets me switch between them comfortably.
I imagine one quick and dirty fix might be to render the buffer onto the full screen unscaled - just leave the rest of the screen blank. But the ideal fix would probably be to resize the buffer and recalculate the N, either according to the actual screen resolution, or to a separate setting from config.txt.

Hi pico8-colleagues ...
Are you already talked about it, but I still do not understand why the printh function does not work in the pico-8 version for Windows. I do not think so complicated send messages to the console windows.
Debuguer is perhaps a more complicated to implement, but that printh work on Windows, it would help a lot. Do not you think?
Thanks.

I just discovered a bug with Pico8 - in LUA, one can create multiline strings with a pair of [[ ]]s. This works as well in Pico8, but the token count includes all operator signs and brackets. Which is kind of wrong, I think. Too, escapes of quotation marks aren't escaped inside the editor and shown as real marks. This is kind of anoying, would be great, if a fix for this would be possible...





0 comments




