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
4 comments
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.
7 comments
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.
7 comments
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
Introducing the Alpha Version of "Crazy Craftbeer Tapper" - a game about serving craft beer.
Keep your customers happy and your counter clean!
TODO:
- fix: reset after internal restart
- half implemented: introduce level with "craft beer nerds"
0 comments
Hello everyone,
Does anyone know of an easy way to export music from one cart and import it into another? I got someone to make some music (thanks Pizza!) for a game I'm nearly finished but I can't really think of a way to get it into my cart.
I know copying and pasting the data to/from the .p8 file as text works in theory, but I already have sound effect/music in my game, so I know they won't really transfer properly because the indexes for the sound effects will be off.
Any advice would be much appreciated! Thanks!
5 comments
I've grown quite fond of Pico-8, and am hoping to use it in a future Ludum Dare. To familiarize myself with the tool, I created an enhanced version of my LD33 entry.
Tapping Z and X at the same time toggles the music.
All feedback is welcome. If you find a level particularly difficult, please let me know.
Update 8/10/16 - Finally got around to fixing a bug with the tank.
Update 9/28/20 - Fixed a typo. Also, updated the behavior of the arrow to better indicate the player's off screen position.
32 comments
What is the method to introspect on exact floating point values with pico8's fixed point system?
x = 3.8 y = 6.8 x += 0.2 y += 0.2 rectfill(x*15,y*9,x*15+1,y*9+1,9) rectfill(4*15,7*9,4*15+1,7*9+1,12) print(x) print(y) |
Running this produces two squares that do not overlap, although print() of x or y shows that the value is equivalent to an integer. Is there a way to print the fractional section more accurately?
1 comment
Hello there gentlemen!
And laaaaaadies... ;)
I have a Tumblr account! Why am I telling you this? Because I'm gonna be posting voxatron related content regularly starting yesterday! I aim to make at least 1-2 posts per day of progress I'm making in two games I'm in the process of making. One of which is an arcade-y shooter inspired by the likes of mechwarrior. The second is a single player story driven exploration action puzzle platformer! (Wow that was a mouthful...) Anyways, just thought I'd drop by to say that! :) I'll try to post to the lexaloffle forums as much as possible as well... Thanks for reading!
0 comments
I just missed the Screensaver Jam, but this is in the same spirit. A simple, silly thing—the cart creates endless permutations of the artist Josef Albers' 'Homage to the Square' paintings. Of course 'endless' meaning variations of sixteen colors and four composition types.
0 comments
This is not coded in Pico 8 ( I had no time, and Construct 2 feels way more comfortable ), but the music is tracked in Pico8 and the graphics are made in Pico8 and fit in a cartridge.
A demo for #screensaverJam
2 comments
I continue to make things that serve only to entrance.
Here, stare at this.
If you like you can press Z to randomise the parameters until everything goes crazy.
11 comments
.jpg)
This is our first PICO-8 project, made in a little game jam with some friends!
Our prompt was generated by the Cowface Games Ludum Dare theme generator: Underworld and Retreat!
The story goes:
You are Jonathan, a meek demon spy sent to collect Heaven's magical relic. When combined with the one in Hell, it will create the ultimate weapon. The game starts after Jonathan has already infiltrated Heaven and stolen the relic - now take a leap and make your way back home!
This is unfinished so far, but collecting the purity from innocent beings (rainbows, butterflies, etc) will add to your strength in the second half of the game (which doesn't exist yet).
0 comments
This is a very work-in-progress game for my weekly games blog. Lots of copy and paste from my first week project. [My blog]( http://www.quidditycode.com/week-7/)
Run around with the arrow keys, jump with z, throw shuriken at nothing with x. And now grapple around by pressing up+x
I'll be making this into an actual game by Saturday, so look forward to seeing what becomes of it.
0 comments
Jetpack - PICO-8 edition, 30 hot levels and various enemies
Jetman does not know how to jump.
Jetman uses his jetpack if you press C.
Jetman can not have more than 4 lives.
Level restart (if you get stuck and can not die) - press X
That's me playing level 12:
Level 1 to 12 - if you get past level 12, it gets easier ;)
Have fun!
7 comments
Made as part of DMG Toronto's Pico-8 workshop and based off of the "Grave Digger" cartridge! Run around a graveyard full of a pizza's worst nightmares to dig up treasure all while avoiding hungry mouths.
0 comments
Hi,
first off, Pico8 totally blasts me - developing games with it is like a flash back into the 80ies, only with suitable tools. Great work! Too, I like the idea of the strict limitations of the system, but there are some things which may extend them without breaking the idea.
At the moment, the rom in the cartridge supports space for all built in editors. There is sprite space, map space, sound and music space. They are all sufficient for the general "hardware" of Pico8. But the rom lacks of one thing - user space! There is a user space in the ram, following the rom mirrors for all the build in editor data. But why isn't it possible to use the user space in the rom?
This leads to the situation, that one has to initialize all user data in code space. This seems to me a waste of space and tokens. True, from adding the user space to the rom, one problem arises: How to fill it? I spent some thoughts on this with the premise to keep the general idea of Pico8 and its workflow. So, how about this:
1.) Add the user space to the rom. Shouldn't be much work and shouldn't break existing cartidges, although some version tag might be necessary.
2.) Add a general function _build aside to _init, _update and _draw. As you obviously have access to the tokens, I would remove this one from the export versions and wouldn't count the tokens in this function (Including the function itself), but leave the 256kb limit.
This would allow to poke data into the user space without wasting any tokens. One could even preprocess the data, like adding preprocessed line feeds to string data, create lookup tables and such. Further, this would allow us to store an initial titlescreen into the screen ram on boot time... This would be a simple, but great extension of the general build process without touching any of the grounding principels.
A hex editor as an additional tool would be pro, but not required.
Another bigger feature I would love is bank switching. As the "CPU" is definitly an 8 bit one, it could address 64kb of ram. Sure. Virtual ram space is expensive in our imaginary 80ies development world, in which Pico8 exists. But as Pico8 tries to mock up an 8 bit console system, there always was the possibility, that the cartridge-rom was bigger than the system ram. So, how about picking this up by adding a banking space at $8000-$8fff, which is read only and maps to one or more rom banks within the cartridge? They should be limited, up to max 32kb, no doubt, but I think adding bank management would add some extra spice to this retro style development and this wouldn't break anything else either. Initialization would work with the _build function as well. A nice addition to this would be a _switch(a,b) function, which is called, if f1-f4 are pressed and which handles copying editor specific data between the banks, leaving the risk to handle this correctly to the developer him/herself.
Some other features, I would wish for, which are simpler to explain:
a) Add a ceil function, that one is missing painfully.
b) Add some kind of tooltip if you are over a function with the cursor, which shows the token count of that specific function.
c) A simple find with ctrl+f would be great. Currently, I'm using NotePad++ beside Pico8 constantly open for that...
d) Reading the character value as numeric from a strings position. I know, requested several times and there is a workaround, but I don't think this workaround should be needed...
e) Would be nice to be able to set the border color and the background color (e.g. for cls). Could be either background(col) and cls(col) or color(drawcol,clscol,bordercol).
f) Hidden directories are never a good idea to store things, the user shall access or copy by hand. Maybe an extra document directory for cartridges would be nice...
g) Anonymous Functions? Would be great to be able to write code like
h) A modulo function. Needed, writing an own is a waste of space and tokens.
i) The ability to call a function or other code from a string. Maybe something like eval("myfunc(3)")?
startscrolling("Hello World",10,begin cls() end)
Reading, this would trigger a scrolltext with Hello World scrolling over the screen and calling the anonymous function when finished, clearing the screen.
h) A goto line with ctrl+g. Bonus: Accept the name of a function as input.
These are my suggestions so far, maybe they are of some use :)
Keep up the great work!
1 comment
