This call, with only one arg after the string:

print("hello world", anything_even_a_table_or_function_or_nil)

Behaves oddly and in a way that is not documented in the manual. It renders the string at the cursor and then exits without updating the cursor. It doesn't seem to use the extra argument at all.

The only thing I can see this being useful for is a text countup display, as seen in oldschool memory tests during BIOS startup on PCs. I can't imagine anyone has ever actually used it this way, though.

It'd be far better if this case were treated as if the user wanted the text colored, but didn't want to specify x,y coordinates because they wanted it to work like a regular, scrolling print():

print("I'm blue, da ba dee, da ba die", 12)

Not a bug. The PICO-8 manual says:

print str [x y [col]]

See how x and y are within the same brackets? It means they are optional TOGETHER, not separately. You cannot supply x without y.

What you are experiencing is human error :)

I don't know a lot about Lua, but if I had to guess, print() checks first if y is non-nil to determine if coords were given and then if col is non-nil to determine if color was given.

It would be nice if it did the check you're talking about, but probably would make for a few weird bugs, too - I think the standard way to get that print behavior is with color() to set the print color.

@packbat @Xii It certainly looks like a bug.

If print() looked for both x and y, and ignored x if it didn't find y, that would make sense per the manual where x and y are bracketed together as optional. However, that's not the observed behavior.

If you try, say, print("hello") and print("hello",12), they do different things.

print("hello") will put hello on the screen and move the cursor down 6 pixels.

print("hello",12) will put hello on the screen and then leave the cursor at the exact same x,y coordinates. So the extra argument is doing something.

@Felice is suggesting that having a single argument after the string should act as the [c] parameter instead. (And I'm assuming also still wanting to move the cursor down 6 pixels after printing.)

I'll quibble with "bug" and claim "undefined behavior." :) I wouldn't consider it mandatory that this have defined behavior, and it's arguable (or at least a matter of style) how often a PICO-8 API should throw a runtime error.

It's interesting that print(str, x, y) changes the cursor position to x,y then does not advance it a line after printing. The next print(str) takes place at x,y, and advances the cursor position using x as the new left margin.

From this, I expect that the implemented (but undefined) behavior in this case is to fail to update the cursor position then attempt a positioned print at the current cursor position, thereby not advancing the cursor.

@dddaaannn

If that were the case, it would default the missing y arg to 0 as it does everywhere else in the API and print at (x,0) instead of the current cursor position.

(I don't know about you, but I frequently take advantage of that feature with other stuff, e.g. clamping to 0 with max(v), clamping to 0,n with mid(v,n), stuff like that.)

I will grant you that it would be a marginally useful change to make it legal. Save two tokens here and there, right? :)

@All

It ought to be either consistent with no coords, consistent with having coords and write to (x,0), consistent with functions that throw an error to let the user know they have screwed up, or documented. This is an OS-level call, the most basic of which that a new user writes in their first app.

(The tweak I suggest isn't expected behavior, as much as I and multiple users I've seen in the past have thought it might be or should be, I'll give you that. But I think I was pretty clear about that part being a suggestion.)

@Xii

Yeah, that's my thinking.

Still kinda hoping to see this one added to the bounty of 0.2.0. :)

Hah -- it seems there is semantically a big difference between behaviour that is undefined by design (>> with negative numbers in C) or because of no design at all (I just never decided what print(a,b) should do). Bugs are normally defined as deviation from intended behaviour, but in this case there was no intention (oops)

I like the 2 parameter form, and it is similar to line()'s new 3-parameter form (x1,y1,col). For 0.2.0d I've changed print(str,col) to be equivalent to color(col) print(str)