paniq [Lexaloffle Blog Feed]

Megacolors

Sun, 16 Sep 2018 08:25:45 UTC

I was wondering if it would be possible to use structured temporal dithering to fake more than 16 colors, and it is indeed possible!

at 60hz, 1:2 mixes look fairly natural, but 1:4 mixes are a little too noisy.

gradient palettes

Mon, 18 May 2015 02:43:52 UTC

I've been designing some gradient palettes for various materials and wanted to share them here for inspiration.

got anymore ideas what to do? It seems especially blue leaves very little options...

Feature request: x-mirror in map editor

Mon, 18 May 2015 01:46:42 UTC

While experimenting with translating some "Zelda - Link From The Past" tiles into pico, I noticed that a lot of sprites save memory by mirroring the left half to the right one.

While the API allows drawing sprites mirrored along the x-axis, the map editor only permits one tile direction.

Would it be possible to add the ability to mirror sprites to the map editor as well?

Ideas for a GPU implementation

Sun, 17 May 2015 04:06:36 UTC

I've been thinking about how PICO-8 could provide very primitive 3D software rasterization capabilities that remain within the spirit of the system. These are just goofy ideas, please feel free to bury them if they're too far outside the project scope, but I had to at least write it down once.

In any case, it should be possible to implement nearly all of the features below in a cartridge.

Following things need to be implemented in order for this to work:

Mesh ROM
Mesh editor
API functions
Z-buffer

Mesh ROM specs:

128 meshes (or less? animated meshes are considered here)
per mesh: 16 vertices, 16 quads (96 bytes)
index of 8x8 sprite to use as texture / colormap
Vertex format: 3x(0..7) position
Quad format: 4x(0..15) vertex index, 2x2x(0..7) uv rect (x1,y1,x2,y2)
0 = no quad

The editor would get a new page with an editing view (64x64) that supports two modes: mesh editing and uv editing.

mesh editing:

The view supports free (orthogonal) rotation to preview the result and select obstructed vertices/faces.
An extra label displays the index of the selected vertex or face.
A toggle switches the view mode: textured / wireframe.
left-double-click creates a new vertex.
left-click selects a vertex or a face (depending on proximity of cursor to edge of face).
right-click on a vertex begins to build a face; 4 vertices of which at least 3 are unique need to be right-clicked in succession to complete the face; right-clicks that don't hit vertices are ignored. a left-click will abort. If the 4 vertices already comprise a face, the operation has no effect.
left-drag moves the vertex or face (all vertices of the face) along the orthogonal plane that's best facing the camera (dot product of view normal and plane normal closest to -1). That way no explicit orthogonal view is necessary. If a vertex is moved onto the position of another vertex, the vertex will be reset to its original position. That way, overlapping vertices are avoided.
right-drag orbits the camera around the center, and implicitly selects the plane along which vertices and faces will be moved when editing.
DELKEY removes the selected vertex or face. face removal does not remove vertices.
the mesh can be copied/pasted to other slots in order to facilitate the creation of animations.

uv editing (allowed when a face is selected):

The view shows the default 8x8 texture for this mesh, with a rectangle indicating the region that the active face will be mapped to. If only three vertices of the face are unique, the face will be a triangle (x1,y1 - x1,y2 - x2,y1).
Per default, the face is mapped to the entire texture.
x1,y1 are rounded to the upper left edge of the texel, x2,y2 are rounded to the lower right edge. That way, a single texel can color the entire quad.
An extra panel allows selecting the default texture this mesh will use.
left-drag draws a new rectangular bounding box for the quad. A simple left-click selects a single pixel as the quads texture.

The API gets 6 new functions:

clsz()

clears the z-buffer to 0 (see Z-buffer notes further below)

zget(x,y)
zset(x,y,z)

get or set the z-value of a z-buffer pixel.

camera3d(<x>, <y>, <z>, <m00>, <m01>, <m02>, <m10>, <m11>, <m12>, <m20>, <m21>, <m22>, [<orthogonal>])

configures the camera (view) matrix for subsequent mesh drawing calls.
x y z: origin of camera
m00-m22: orientation of camera as a 3x3 matrix; (1,0,0,0,1,0,0,0,1) would describe an identity matrix.
orthogonal: if true, an orthogonal projection will be applied instead of the default perspective projection, which is analog to an infinite far plane projection matrix.

model(<x>, <y>, <z>, <m00>, <m01>, <m02>, <m10>, <m11>, <m12>, <m20>, <m21>, <m22>)

configures the model matrix for subsequent mesh drawing calls
x y z: origin of model
m00-m22: orientation of model as a 3x3 matrix; (1,0,0,0,1,0,0,0,1) would describe an identity matrix.

mesh(<mesh index>, [<texture>], [<flags>], [<face mask>], [<mesh 2>, <blend>])

rasterizes the triangles of a mesh with model, camera, projection transformations applied.
mesh index: the index of the mesh to rasterize (0..128).
texture: index of the sprite to use as the meshes texture (0..128). If omitted or nil, the default texture will be used. If texture is -1, the mesh will be rendered as wireframe.
flags: Sets various render flags: bit 0 = read & test depth; bit 1 = write color; bit 2 = write depth; bit 3 = cull backfaces. The default flags are 0xF.
face mask: a set of 16 bitflags, indicating which faces should be rasterized/skipped. If omitted, all faces will be rasterized (face mask = 0xFFFF)
mesh 2, blend: if specified, blends the vertices between this mesh and another by factor <blend> (0 = 100% mesh A, 0.5 = 50% mesh A, 50% mesh B, 1 = 100% mesh B). This way,
smooth keyframed animations can be rendered.

Z-buffer:

To facilitate order-independent rasterization (depth culling), a 128x128 Z-buffer must be available. The minimum required precision is unclear, but I assume half-float or 16bit precision is needed at least (= 32k). The Z-buffer ranges from 0 to 1, where 0 is infinitely far away and 1 is the near plane. This configuration is appropriate when transforming triangles with an infinite far plane projection matrix. In this entire setup, the near plane is fixed to a system default, e.g. 0.1 or 1.

Here is exemplary GLSL code that describes how to do the projection transform:

// transform a vector v by an infinite projection matrix so
// that z is projected to the range 1..0 after the vertex shader.
// aspect is usually vec2(1, w/h) or vec2(h/w, 1)
vec4 projection_transform(vec2 aspect, float near, vec4 v) {
return vec4(v.xyaspect, v.wnear, v.z);
}

// do the inverse of projection_transform(), with baked-in divide by w
vec4 inverse_projection_transform(vec2 aspect, float near, vec4 v) {
float w = near / v.z;
return vec4(v.xyw/aspect, v.ww, 1);
}

HSL2RGB example

Sat, 16 May 2015 17:49:05 UTC

HSL2RGB example 1.0

by paniq

[Click to Play]

An approach to dither the colors of the HSL colorspace with the 16 built-in colors. I settled for a randomized dither. You can download the source by clicking on the icon & saving the png.

3D Cube

Sat, 16 May 2015 00:29:19 UTC

3D Cube 1.0

by paniq

[Click to Play]

A very simple 3D rasterizer that renders a rotating flat shaded cube.

Duangle 2015 Intro

Fri, 15 May 2015 19:34:31 UTC

Duangle 1.11

by paniq

[Click to Play]

This is kind of a parody of old amiga cracktros from a parallel universe, where duangle is a demoscene group, and so are all the people in the greetings!

1.1: added new greetings

Demovibez

Fri, 15 May 2015 13:11:42 UTC

Demovibez 1.0

by paniq

[Click to Play]

This is my first cartridge, a tiny self-running intro with music that does a dithered sinus effect. This started as a fullscreen effect but I had to reduce the amount of pixels to fit the CPU limit.

ph34r!

PICO-8 first impressions

Fri, 15 May 2015 12:58:47 UTC

So I finally had some time to play with Pico-8 yesterday, and wrote two tiny cartridges, and instead of spamming zep on Twitter I thought it would be more useful to post my thoughts here, in order of appearance.

Jelpi is a pretty impressive demo, i love everything about this handheld console that never existed :D
There should be a version of the manual that looks like a 90's devkit manual black & white hardcopy, with a serious layout like the devkit cost $10k. But this is a bootlegged copy of the manual, so it got xerox smudges, is not fully level and is obviously copied right out of a bound book, and right on the first page it says stuff like "FOR YOUR EYES ONLY. YOU ARE CONTRACTUALLY BOUND TO NOT DISCLOSE ANY INFO" etc. On the second page there's a pompous introductory text from the company founder that flaunts the pico-8's luxurious capabilities, telling you how you can be proud to be able to develop for this console and how it's lightyears ahead of the competition. The manual is not even a full copy, it seems like it's just the most important pages copied out; the pages are numbered like 110-112, 351, 430, with paragraphs that make reference to appendixes that don't exist ("see Appendix E for chipset layout").
It's obvious that this pico-8 firmware is the devkit, which starts with a prompt. I imagine a "consumer device" would boot right into the cartridges. :-)
First I thought Lua's numeric type had been downgraded to signed short, but then I realized it's actually fixed point 16bit for both integer and fractional part. Very cool.
I'd remove all references to Lua and give this language a different name, e.g. Picoscript or Picolua; otherwise I'd just expect everything to work the same way; it's sufficiently different, i think. Considering how all the commands are named, PicoBASIC seems most fitting.
I thought that it would be more useful to arrange the palette in a way that makes the 4-bits more significant (e.g. LRGB), similar to how the default EGA color palette is arranged. In EGA, bit 3 effectively changes brightness (sort of) without altering hue, that allows for very easy lighting tricks. The numeric bits correspond to RGB, so you can fake additive light effects with simple bit twiddling. Here, i'd ultimately do it with a lookup table; I guess it's too late to change it anyway.
I missed a few important math functions, in order of importance: sqrt(x), atan(y,x), exp(x), log(x)
The very first thing I attempted to write was a simple per-pixel fullscreen effect, and I ended up with a CPU usage of > x4. I have absolutely no clue which operations are how expensive, and it would help tremendously to have some sort of clock cycle table that shows which operations eat how much time. Do graphics and sound run on separate chips like with the SNES? I hope yes.
The sequencer and tracker lack a copy function. It seems also despite the game controller correctly recognizing my german keyboard, the note editor does not take keys by scancode, and so Y and Z are swapped there. I can imagine french keyboards have it even worse.
I missed file system operations for file rename and deletion.
There's no quicksave shortcut, which made me very nervous. Ctrl+S has no effect. I hoped "save" without arguments would save the module to the last saved file but it had no effect either. I'm a "I need to save every 3 minutes" kind of dude, so that got annoying very quick.
It would be cool to be able to load two cartridges, so one can act as an editor for the other one, so people can write alternative editors; The idea being here that the built-in editor could be implemented as a separate cartridge that makes no use of secret system functions.
It would be useful to have primitive support for keyboard and mouse peripherals, like the editor has. Maybe as a special "devkit" mode that won't work on "consumer devices".

I'll also shortly post the first cartridges I did.

Cheers