I'm not quite sure this is a bug and not intended behavior, but I can't see why it would be intentional; at least for my use case, it's quite an annoying quirk that I really can't come up with any good workaround for.
Here's an example of where this gets in the way:
I started using one-off characters to insert 5x5 icons into text, but it seems that as soon as the line has ANY one-off characters, print thinks that since it could theoretically take up to 8x8 pixels, the line height should be increased to 8.
For the width of the characters, I actually just add \-e at the end of each icon, so that the icon takes up 6 pixels horizontally; but I wasn't able to find any way to correct the line height - this behavior seems to completely override \^y as soon as a one-off character is present.
(in fact, bizarelly, setting line height to lower than 6 reveals that print will actually crop away the pixels of all characters EXCEPT for one-offs, while the vertical spacing remains at 8:)

Oil spill simulator!
This implements the Fast Marching Method for the Eikonal equation to calculate the spread of waves - puddles - on a plane where the propagation speed varies according to a simplex noise function.
Randomly varying amounts of puddles will be created at once; as they collide, they form a kind of Voronoi diagram. Where a puddle goes, it will also draw some new noise for the next generation of puddles, and each puddle chooses its own palette and possibly dithering method to display it.
A (barely) unfinished game I made a few years ago. Like 2048, but instead of numbers, you have chess pieces! They will move in the direction you press, but they'll choose at random if there's multiple options. A piece can capture a piece of the same type and upgrade!
Pieces upgrade as follows:
Pawn -> Rook -> Knight -> Bishop -> Queen
Two White Queens combine into a Black Pawn. Black pieces upgrade similarly, but with a twist: a black piece can also capture a white piece of the same type, and it simply destroys it with no reward!
The win condition wasn't implemented, but you should consider it a victory if you manage to create and combine two Black Queens.
A simplex noise implementation that I grabbed from Github (https://github.com/weswigham/simplex) and made it work in Picotron (only had to replace bit.band with native & bit operation, and made the simplex variable global since picotron doesnt seem to support return values from files). Performance doesn't look super great (?) - I tried converting it to use userdata for vector operations but it didnt seem to improve much.
For example, the main cart code is this:
include "simplex.lua"
local colors={0,1,19,3,27,11,26,10,7}
function mapcol(t)
t=max(0,min(1,t))
local n=#colors
return colors[flr(t*n)+1]
end
--n will be the "seed"
n=0
function noise(x,y)
x+=n*10000
return simplex.Noise2D(x,y)
+ 0.5*simplex.Noise2D(2*x,2*y)
+ 0.25*simplex.Noise2D(4*x,4*y)
end
function _draw()
cls()
flip()
for x=0,479 do
for y=0,269 do
local t = (noise(x/50,y/50)+1)/2
pset(x,y,mapcol(t))
[ [size=16][color=#ffaabb] [ Continue Reading.. ] [/color][/size] ](/bbs/?pid=154380#p) |

found a bug in 0.2.1b (also current bbs version) while using tline() to shear rectangles
see the cart
observe that there's only 2 configurations that get chopped incorrectly (one where the startpoint is below the screen and one where the endpoint is above the screen) (although others also have ugly artifacts)

An attempt to cross Tetris and Super Meat Boy. Or something like that.
You can control the Tetris with arrow keys, and the Meat Boy with ESDF. You can challenge your multitasking skills, or try playing with another person, either cooperatively or competitevely, either might be fun.
Gravity increases linearly as you clear lines in this version.
There's no proper fail state yet, if Meat Boy dies, he disappears, if the well fills, it keeps spawning new pieces in crazy ways.

...but you might not like it. Here it is:
Here's a video: https://youtu.be/C2ui4anDwBc
The idea is very simple: make 2 versions of the cart, called A and B, running essentially the same game, but have them display different parts of the game (in this demo, based on Jelpi, I simply shifted the camera); cart A is the one you actually play on, it receives inputs and sends them to cart B, which uses them, ensuring that exactly the same thing is going on in both. (as long as the game is deterministic, otherwise you'll have to send over the random seed or something)
I first had this idea a few months ago, but couldn't figure out how to send the data from one cart to another in real time; I hoped to accomplish this using the system clipboard, but it turned out that it can only be read whenever the user presses Ctrl+V, so you can't just do it every single frame.
With the release of PICO-8 v0.2.1 it became possible to (easily) do this using the serial() function, because it now allows you to use stdin and stdout IO streams of the current PICO-8 process. Stdin is 0x804 and stdout is 0x805. All you need to do is create a linking program that will launch both carts, connect to the stdout of A and to the stdin of B and pass the data. I wrote the following Python script:
Prototype of a chalkboard simulator/math scratchpad. (I might add special characters for that later)
Controls:
- LMB to draw, RMB to erase
- Shift+LMB to draw harder, Shift+RMB to erase more
- Arrows to move cursor
- Tab to move cursor to the mouse position (note: tab is also detected as shift, I don't think there's much I can do about that)
- Keyboard to write
- Enter, Space, Backspace work but slightly unconventionally
- Shift+Up/Down to move cursor half a line up or down - this makes subscripts and superscripts possible
- Mouse wheel to scroll the board (it's infinite downward, but performance is not great yet)
 (1).gif)





1 comment



