Log In  

iOS developer/graphic artist living and working in Tokyo.
Come and go into Pico-8 as inspiration strikes.
For "relaxing with programming as a hobby" it's proven to be my favorite tool so far.

Your Pico-8 has something to say.

The power of MIT's Artificial Intelligence Lab (circa 1966) has been brought to the Pico-8. The software that once took on the Turing Test is now yours to command. Marvel as the illusion of a living computer breaks down within seconds!

ELIZA's creator, Joseph Weizenbaum, once wrote, "I had not realized ... that extremely short exposures to a relatively simple computer program could induce powerful delusional thinking in quite normal people." Maybe you'll be powerfully deluded as well!

Features of this release:

  • An interesting archaelogical look at early AI
  • User-scriptable! (see blog for info)
  • Reproduces precisely a famous ELIZA conversation
  • Not based on the simplified BASIC version; this is the real deal!

While this release implements the most famous ELIZA script called "DOCTOR," I have endeavored to make it simple to create your own script. With Pico-8's 2MiB of RAM and the light footprint of the engine itself, it is theoretically possible to create much more advanced chatbots than could have been achieved in 1966.

More information and downloads available on itch.io now.

Full blog post on how the script works, so you can write your own is also posted.

P#92317 2021-05-21 22:03

Is there any way to do the following?

t = {
  "key 1" = "foofoo",
  "key 2" = "barbar"

We can't use quoted keys when defining a table, but we can use them when adding elements.

t = {}
t["key 1"] = "foofoo"
t["key 2"] = "barbar"

Is this "just how things are?" because it would really be beneficial to be able to do it all inline and build out a complex table structure without having to isolate out special cases and insert them as a separate sequence of setter calls.

(the example above uses spaces in the key intentionally, where it might be a substring paired with its substitution or maybe I just want to make it very clear in the definition that some of the keys represent specific words, like vocabulary words; don't get me wrong, I know lots of workarounds, but sometimes the workarounds are a drag, especially when it looks like we're so close to just having a simple way of doing things)

Clarification here. The first example fails to compile with a "missing {" error when trying to use inline quoted keys. @fred72 shows below that wrapping those in square brackets allows for using the quoted key without resorting to the second method shown.

P#91621 2021-05-07 03:00 ( Edited 2021-05-07 07:55)

(this "bug" may actually be "a feature"... not sure)

In the following code, a simultaneous btn+key method is used.
I am using Player 2 "X" key for this example.

In keyconfig, set Player 2 "X" to be a key, like "\"
You should find that you can hold "\" to get a yellow line drawn on screen.
While holding that BTN down, type "c" and you should see a red circle flash on screen.

Back in keyconfig, set Player 2 "X" to be "Alt"
(I'm on Windows; I think the Mac Option key has the same behavior)

When running this sample program, hold down Player 2 "X" and the line appears as before.
Type "c" and nothing happens.

I can understand not allowing "Ctrl" (for example) but I can't think of any "would interfere with expected system operations" reason why "Alt" would have its use restricted in this way.

function _init()

function _update()
   if btn(5,1) then
      if stat(30) then
         local key = stat(31)
         if (key == 'c') circfill(63,63,20,8)
P#89660 2021-03-27 03:01

According to the manual

:: Special Commands
These commands all start with "\^" and take between none and 2 parameters (P0, P1)

   s set tab stop width to P0 pixels (used by "\t")

However, it appears to me that it isn't in pixels, but rather by characters.

This code snippet

for i = 1,9 do

yields this output

Additionally, if \t is the first character in the string, it seems to be ignored.


outputs exactly as if no tab were included.

P#89606 2021-03-26 10:30

For characters in the Japanese kana range, it seems we must type ctrl + alpha
to get a kana to input. However, ctrl is also used to activate some Pico-8 things like "save" and such.

With poke(0x5f30,1)
we can suppress "ENTER" from bringing up the Pico-8 menu in-game.
Is there a poke I'm failing to see that will suppress Pico-8 from having its "save" function activated every time the user enters ctrl + s to type キ (for example)?

(on another note, backtik-surrounded text to format "code snippet within a line" doesn't seem to work right?)

P#88278 2021-02-28 02:41 ( Edited 2021-02-28 02:47)

Your Pico-8 just got down to business.

The full-featured, high-precision spreadsheet application for the Pico-8 that nobody asked for has finally arrived! PicoCalc is a feature-complete1 clone of the 1979 classic VisiCalc, which introduced the world to an entirely new category of business application. Steve Jobs said of VisiCalc, it's "what really drove -- propelled -- the Apple ][ to the success it achieved."

PicoCalc does everything* VisiCalc can do, with some enhancements over the Apple ][ classic:

  • 18.18 integer/fractional precision vs. VisiCalc's 12.
    Handles numbers as big as 999999999999999999.999999999999999999
  • Granular error reporting!
    Get informed of division by zero, number overflow, and more.
  • Multi-color representation of active/inactive cursor, locked titles, truncated values, and error messages
  • Save and load your work
  • Full arrow-key support (LOL)

To use it effectively, you do need to know how to use VisiCalc.
Here's a manual to help you along.

More information and download available on itch.io now.

*OK, I ran out of tokens and only got 99.5% in; still thinking how to hit 100%

Updated to 1.0.1

Available now. Writeup of bug fixes at itch.io.

P#88099 2021-02-24 12:41 ( Edited 2021-02-28 07:09)

In the new v0.2.2, it seems that "tall" mode for print rendering does not render the final row of pixels.
See in this shot the difference between "tall" and "wide"

Haven’t tried it in “non-inverse” mode yet.
Discovered by using Zep’s “pinball everything” example.

P#87602 2021-02-13 23:41 ( Edited 2021-02-14 00:29)

I have a number of functions which, before doing any real work, need to do the exact same pre-processing routine of the passed parameters. As such, they all start like this...

local p1, p2, error = preprocess(param1, param2)
if (error) return error --early return

Is there a way to use metatables to inject this kind of default behavior into functions, without having to copy/paste that boilerplate code each time?

P#87370 2021-02-08 02:01

Hit a strange bug tonight in trying to compare some values.
Ultimately, I was being told that 0 != 0 (apparently).
In digging in further, I can reproduce the problem in one line.

> print(8.5333-3.7667-4.7667)

I understand that there can be rounding issues, but -0 is not such a useful return value I think.

Edit: Another strange occurrence
I'm doing time profiling on functions in my code. Call time() at the beginning and end of a test and subtract the results.

In the test, I received 37.4667 - 35.6333 = 1.8333

but if I just ask Pico-8 to compute that in the console I get the proper 1.8334

P#74960 2020-04-19 09:45 ( Edited 2020-04-19 11:42)

Purpose: calculating a line-line intersection point

I've been trying to learn physics coding, which also means re-learning math I have long forgotten. Recent studies in vectors, sin/cos, etc. were difficult but successful, so this task seemed like it would be pretty simple. And yet....

I cannot see what I'm doing wrong here.

I've implemented line-line intersection algorithms as transcribed in various places all over the internet, and the resulting {x,y} is always the same. So the answers are consistent, but do not match expectations whatsoever.

Note: I understand this algorithm does not catch all cases, but rather I'm trying to show the simplest form of the problem I'm struggling with. It should be working for the case illustrated, as far as I understand. The line endpoints are chosen specifically to intersect on-screen, but the intersection algorithm will generate negative values in most, but not all, cases (?!?!?)

function line_intersection(line1, line2)
    local p1, p2 = line1.p1, line1.p2
    local p3, p4 = line2.p1, line2.p2

    local a1 = p2.y - p1.y
    local b1 = p1.x - p2.x
    local c1 = a1 * p1.x + b1 * p1.y

    local a2 = p4.y - p3.y
    local b2 = p3.x - p4.x
    local c2 = a2 * p3.x + b2 * p3.y

    local denominator = a1 * b2 - a2 * b1
    local x = (b2*c1-b1*c2)/denominator 
    local y = (a1*c2-a2*c1)/denominator 
    return {x=x,y=y}

--l1 = {p1={x=10, y=25}, p2={x=25, y=10}} --THIS WORKS
l1 = {p1={x=10, y=26}, p2={x=26, y=10}} --THIS DOESN'T
l2 = {p1={x=0, y=0}, p2={x=60, y=60}}

function _draw()
    line(l1.p1.x, l1.p1.y, l1.p2.x, l1.p2.y, 7)
    line(l2.p1.x, l2.p1.y, l2.p2.x, l2.p2.y, 7)
    local intersect = line_intersection(l1, l2)
    circ(intersect.x, intersect.y, 2, 8)

Is there a trick to doing this in Pico-8 that I'm not understanding? Other attempts to translate algorithms (say from Wikipedia or Stack Overflow) were successful, so I thought I had a handle on things. It's frustrating being stumped by something that seems so simple. If anyone can point me in the right direction, I'd appreciate the assist.

P#60617 2019-01-06 07:48

Here I present a method for stroking text and sprites.

In looking through solutions for stroked/filled text, I usually see print()on the string called 9 times; i.e. once at each cardinal location with a 1px offset. I realized if pixels were represented by "fat pixels" outlines of various thicknesses could be simulated.

For example, if a pixel is at (x,y),

rectfill(x-thickness, y-thickness, x+thickness, y+thickness,color)

with a normal pixel draw on top would look like an outlined pixel. I further realized that anything with transparent pixels could be outlined in this same manner, and so applied it to sprites.

This method works in the following:

  1. Video space is "borrowed" for less than a frame (?) to render the text and capture it's pixel data to user data space. (the specific address space used for this caching can be set to wherever you like; sprites are read as-is from sprite memory space)
  2. The bytes are walked and used to draw fat pixels (via rectfill()).
  3. The string is then rendered "as normal" at the location requested. (print()is only called twice: once to grab the pixel data cache, once to draw the string on top of the effects)
  4. Seems to be at 300 tokens currently.

This method has the following benefits:

  1. Visual effects are defined as a table (list) of inner tables, where each inner table defines:
{fill_color, stroke_color, line_thickness, effect_x_offset, effect_y_offset}
  1. Effects in a list are applied in the "painter method" from [1]..[#effect] where each subsequent effect is drawn on top of the previous. This allows for complex stackings of routines.
  2. Effects are just tables, and so can be pre-defined and re-used on other elements, including sprites.
  3. Effects are animatable, by simply swapping colors and offset values.
  4. Uses no sprites, only Pico-8 native text (though it could be pretty easily adapted to work with mini-font libraries that use custom sprites, I think)

Optimization possibilities
Unlike the "draw a string 9 times" methods, this methodology presents an opportunity for optimization. I'm still very new to Pico-8 and Lua, so this really only represents a starting point toward a better algorithm.

For example, I'm sure there are ways to make it more efficient.

  1. I believe the call to peek() could be switched to a peek4()?
  2. I believe the call to rectfill() could be swapped for direct writes to the bytes?
  3. I'm certain there are ways to reduce the token count from the current 300, but for the purpose of this post I tried to consolidate redundant code without sacrificing (too much) legibility.

(P.S. - I don't see how a name can be attached to a cart? @clip didn't use the file name? I see no tools here for setting title, license, etc.)

Cart #56189 | 2018-09-04 | Code ▽ | Embed ▽ | No License

P#56191 2018-09-04 20:03 ( Edited 2018-09-05 11:04)

I've been studying Pico-8 only for about a week now and really having a good time. I enjoy thinking within it's constraints. In particular I like fiddling around with the graphics memory directly to do fun video effects.

With the following code snippet I can move every other video line offscreen to the left or right, giving an interesting "tearing apart" video effect. This works great and is very fast, and gets me to a blank screen where "blank" just means the screen is filled with a chosen "clear color."

if (y%2==0) then

So, now that the screen is clear, I want to do the opposite. Bring in a full screen image (perhaps a map or scaled sprite) onto screen in the reverse. i.e. Odd-lumbered video lines scroll in from the left and even-lumbered lines scroll in from the right.

This would assume that some pre-composed block of memory is waiting from which i do a similar memcpy() from off-screen to on-screen... or at least that is conceptually what i think needs to happen. But i do not understand the possibilities of Pico-8 deeply enough to understand how/where to keep such an offscreen buffer, or if that is even possible.

Any pointers on how to tackle this?

P#55535 2018-08-23 05:48 ( Edited 2018-08-24 08:30)

Follow Lexaloffle:        
Generated 2021-10-20 13:07:38 | 0.096s | Q:25