I have encountered some strange behaviour when using pod() with keys that are tables.

This code snippet prints {} (it should print nil if it were to be consistent with other pod behaviour)

local a = {}
a[a] = 1

?pod(a)

This code snippet also prints {}

local a = {}
local b = {}
a[b] = 2

?pod(a)

But now, the strange part. This:

local a = {}
local b = {}
a[a] = 1
a[b] = 2

?pod(a)

causes an error, it reads simply attempt to compare two table values. No error location, just this!

 

tile_stress_test

by Soupster

Cart #tile_stress_test-0 | 2025-01-04 | Embed ▽ | License: CC4-BY-NC-SA

1

Just a little test to see if the implementation works.

Controls:

LMB: Place
RMB: Pick tile

Left/Right arrows: Cycle through tiles

S: View stress
M: Change stress mode

Have fun!

Edit: Also, each tile has different properties, so you'll want to be careful what you build with.

Here is a list of bugs/annoyances in the BBS:

Important:

• Code preview is broken, if you click on the code button under the pico-8 web player, it doesn't show the code. (It's the right size now, but still no code. Definitely an improvement!) Fixed!

Minor:

• The padding around the pico-8 web player is too big.
• The featured buttons at the top of the BBS don't show the author, it just says "by ".

There are a couple more, but they're not really issues, so I've omitted them.

When clicking the play button on the Picotron web player, it stays as a grey screen. Checking the console shows an error, that it can't find https://www.lexaloffle.com/play/picotron_0101.js. After some digging, I believe it should be https://www.lexaloffle.com/play/picotron_0100h.js instead.

Edit: Wait, does this hint at Picotron 0.1.1?

FIXED!!!!

Text gets "buffered" if no text editor is selected, and upon selecting it, it types the text.

How to reproduce:

1. Start Picotron
2. Type something
3. Open up filenav
4. Select the navbar
5. The text appears where you click instantly.

This is a maze generator in 191 characters.

maze_gen_191

by Soupster

Cart #maze_gen_191-0 | 2024-07-03 | Code ▽ | Embed ▽ | License: CC4-BY-NC-SA

3

t={-2,2}function g(x,y)if(pget(x,y)<7)return
line(x,y)::l::r=rnd(t)if(rnd(2)>1)then
g(x+r,y)else
g(x,y+r)end
line(x,y)if(rnd(99)>1)goto l
end
cls(7)g(0,0)pal(7,8,1)pal(6,7,1)::_::flip()goto _

This is my first time doing this, let me know if it could be improved.

rgb_transition

by Soupster

Cart #rgb_transition-0 | 2024-06-07 | Embed ▽ | License: CC4-BY-NC-SA

5

This is a simple transition, that should be fairly easy to use. All the code is in rgb_transition.lua. Simply call rgb_transition_setup() when starting the transition, and then on each frame, after the game is drawn, call rgb_transition(). It takes one argument: Whether the transition should be fading in or out. True fades out. In this test cart, press X to reverse the transition.

3D Rendering with depth buffer!

by Soupster

Cart #dbuf_test-2 | 2024-06-07 | Embed ▽ | License: CC4-BY-NC-SA

10

This is mainly a tech demo for a 3d engine with a depth buffer. This is not finished, but I wanted to share it.

TODO:

• Optimisations maybe?
• BSP - currently model faces aren't sorted, so concave models will work weirdly. The depth buffer is only for interactions between models.
• Maybe lower the resolution for better performance?
• Some sort of culling?
• Better use of depth buffer resolution, make it more linear maybe?

(The depth buffer works with the use of colour tables, in a few passes. If anyone wants more detail, I can provide it.)

Oh yeah, controls:
WASD: Move
QE: Up/Down (relative to look dir)
Arrows: Rotate camera

Z/C: Toggle depth rendering

Thanks @freds72 and @Maeve for advice on the memory issue, I hope it's gone once and for all! (Memory still rises rapidly, so I'll look into what could be causing that too)

I've encountered a bug where vectors and f64 userdata doesn't get saved in the pod format.

This code:

local foo = vec(10, 10)

print(tostr(foo), 10, 10, 7)

print(pod(foo), 10, 20, 7)

print(tostr(unpod(pod(foo))), 10, 30, 7)

local bar = userdata("f64", 2)
bar.x = 10
bar.y = 10

print(tostr(bar), 10, 50, 7)

print(pod(bar), 10, 60, 7)

print(tostr(unpod(pod(bar))), 10, 70, 7)

prints:

(10.00000, 10.00000)
userdata("f64",2,"")
(0.00000, 0.00000)

(10.00000, 10.00000)
userdata("f64",2,"")
(0.00000, 0.00000)

You can see that pod() doesn't save the values for the userdata.

When switching to picotron or pico-8 by clicking on the icon when it's in fullscreen mode, I encounter a short freeze. Only about a second, but it's pretty annoying. @zep, do you know why this happens? Is it possible to remove?

Hello. I was playing around with pods, and I noticed that create_diff isn't defined. here's the code (I'm 99% sure I didn't do something really stupid):

local a = {"a", "b", "c"}

local b = {"a", "c", "d"}

local pa = pod(a)
print(pa)

local pb = pod(b)
print(pb)

local pd = create_diff(pa, pb)
print(pd)

@zep was the function removed? it's in https://www.lexaloffle.com/dl/docs/picotron_pod.html#POD_Diffs, but maybe that's outdated.

EDIT: Never mind, it's called create_delta!

Conway's Game of Life

by Soupster

Cart #cgol-2 | 2024-04-23 | Embed ▽ | License: CC4-BY-NC-SA

6

Here is Conway's Game of Life in Picotron, using the colour tables as a fast way to count all the pixels at once.
This version does not work in the web player, because input is not detected ( @zep pls fix!)

Controls:
Up: Increase simulation speed
Down: Decrease simulation speed
Space: Pause
F: Step one frame
C: Clear screen
R: Randomise screen
L-Click: Draw pixels
R-Click: Erase Pixels
L: Toggle large cursor

Basic code:
[hidden]

function _init()
	frame = 0

	-- Set up userdata so we can draw the screen to itself
	-- by using memcpy() to a memmapped region of memory.
	-- The userdata is now the contents of the previous frame,
	-- and it is now possible to modify the current frame.
	-- We can also call spr() with userdata
	-- to draw the previous frame to the current one

	screen = userdata("u8", 480, 270)
	memmap(0x30000, screen)
end

function set_col_table(new, current, col)
	poke(0x8000 + 64*new + current, col)
end

function _draw()
	frame += 1

	if frame == 1 then
		-- Randomise the screen for the first frame.
		for y=0,269 do
			for x=0,479 do
				if (rnd() < 0.2) pset(x, y, 7)
			end
		end

		-- Copy the current screen to the buffer, just for the first frame
		memcpy(0x30000, 0x10000, 0x20000)

	end

	--if (frame % 32 > 0) return

	cls()

	-- White cells drawn onto colour 0 will set the colour to 1, white onto 1 will be 2
	-- and so on. This counts the number of neighbouring cells very quickly
	for i=0, 7 do
		set_col_table(7, i, i+1)
	end

	-- Draw the screen 8 times in a ring, for each neighbour. The colour tables
	-- do the counting
	for y=-1,1 do
		for x=-1,1 do
			if (x!=0 or y!=0) spr(screen, x, y)
		end
	end

	-- Set up colour tables to turn the "counted" screen into the next frame
	-- Set every colour to black except for drawing black onto 3 (brought back alive)
	-- and 2 or 3 neighbours for alive (stay alive)
	for i=0, 9 do
		set_col_table(0, i, 0)
		set_col_table(7, i, 0)
	end
	set_col_table(0, 3, 7)
	set_col_table(7, 2, 7)
	set_col_table(7, 3, 7)

	-- Draw the screen to the "counted" version, with the rules set above
	spr(screen, 0, 0)

	-- Reset the draw state to make sure we have a predictable next frame
	reset()

	-- Copy the screen to the buffer for the next frame,
	-- before we pollute it with the FPS counter
	memcpy(0x30000, 0x10000, 0x20000)

	-- FPS counter
	if key("x") then
		rectfill(0, 0, 44, 8, 0)
		print("FPS: "..stat(7), 1, 1, 8)
	end

end

[ Continue Reading.. ]