I wondered if it was practical to save tokens and do more "visual" editing of palettes, color ramps, etc. by embedding a palette in the sprite sheet.
The answer is "no", but it was an interesting experiment:
This cartridge contains two different formats for reading a palette out of a sprite sheet: as a pair of 4x4 blocks (total space 8x4) and as a pair of rows (total space 16x2). One 16-pixel unit is the "palette" part, the other is "control bits". The control bits are:
0x1-- "high color" (add 128 to the color)0x2-- transparent: mark this color as transparent in sprites0x4-- opaque: mark this color as not transparent in sprites0x8-- colorless: do not include this color in the palette
Row position from 0 to 15 represents the palette index in row format; it's packed into four rows of four columns each (starting at 0 in the upper left, same as the layout in the sprite editor) for the box format. The control bit box is to the right of the palette box; the control bit row is under the palette row.
Flag 0x8 means the color and value of flag 0x1 are ignored, but the index is still considered for transparency palettes (control bits 0x2 and 0x4). If neither 0x2 nor 0x4 is set for any color in the palette, then palette:do_palt() (including do_both) uses a loop of palt calls and skips the color that has no transparency specified; if every color has an explicit transparency (no "do not change previous value" setting) then the transparency bits are merged into an int at load time and do_palt calls palt only once with a complete transparency mask. There's no comparable optimization/pessimization based on whether there are any skipped colors (flag 0x8) in the set, since pal with a table argument exists and is perfectly happy to skip colors.
This hasn't been through token squishing - this is intended to be legible, not efficient -- but it convinced me that there are basically no circumstances where this is better than just writing out palettes. It's slightly unfortunate that there's no way to force split to start at index 0 but the loop to shuffle everything down an index is still shorter and more performant than any plausible "read palette out of sprite sheet" loop, and moving cell 16 to position 0 is even more efficient at the cost of slightly more confusing representation of the palette in the code.
Anyway, this is here as a curiosity. I'm definitely open to the idea that I have underestimated just how much optimization is possible and this might actually be viable in some cases! (Especially with control bit mechanics and square-shaped palette support removed entirely. Control bits came in mostly because I needed the "high color" bit and then decided what to do with the remaining three bits.)
The cartridge itself is a palette demo; use X to switch between draw and screen palettes, and Z to switch between blocks mode and rows mode. The row and block palettes are not the same, I was just experimenting some. You're encouraged to open up the cartridge in the editor and replace the palettes, maybe it's still a useful tool for visualizing those in some way. The palette example display is just color bars (from 0 to 15) with a "zigzag" sprite in each color drawn in a stripe over it, finished with a "color pattern block" sprite. This isn't intended to show dithering or anything, it just points out how the transparency color works. The 0-colored sprite column has a 5-color outline (dark gray by default) because 0 is the background color for all the other zigzags and it would just be an all-zeroes sprite otherwise; maybe I should have left it that way, dunno.
2 comments
So I wanted to experiment with Pico-8's bitplane drawing features (see https://www.lexaloffle.com/bbs/?tid=54215) and specifically to see if I could make a palette that worked sort of like the idea behind 16-color CGA: four-channel (one bit per channel) RGBI color. (Pico-8 doesn't have quite enough blue for this to work comfortably but I'll keep experimenting.) But to play with it, I wanted to be able to scribble with the palette, drawing "with specific bits".
So I threw together a thing!
This mouse-driven cart lets you scribble using a velocity-sensitive pen. Left four checkboxes in the tool panel set the high four bits of the palette mask, right four set the low four. (For some reason this made more spatial sense to my brain for where "color" and "mask" go even though it's backwards from the bits.) Click the "explosion" button to clear the drawing area. I have been too lazy to implement a KABOOM sound effect but patches are welcome.
Left click to draw, move faster for a thicker line. It's not a real art app, so the lines are really blobby. X/Z to cycle palettes (both buttons do the same thing) -- additive experiment, subtractive experiment, classic palette, secret palette; palette changes will overwrite the top 8 pixels of the drawing area with a display of the current palette.
No save feature, this is literally just drawing to VRAM (with some save-to-sprite-sheet shenanigans to restore stuff otherwise overwritten by the cursor).
Feel free to use this as a crude basis for other mouse driven drawing apps, make it do interesting things with the other mouse buttons, try more palettes, just experiment with bitplanes, etc. Code is un-minified so it should be reasonably legible.
So, @Nyeogmi and I have been tinkering with @Vanessa's PicoTetris. I've been giving it more and more mechanics inspired by Tetris: The Grand Master, and Nyeogmi has been finding ways to keep the game running at 60FPS despite the stuff I've done to it. So, together, we present: Extreme Tetrom! Immensely more TGM-like and 100% less trademark-infringing.
Updated 2023-9-12 - Ver. 7.5 - Save-Compatible to 7.0 or later
Extreme Tetrom is a homage to Tetris: The Grand Master, Arika's series of Tetris games designed to become very difficult, providing new challenges to experienced players. It isn't a clone of any TGM game - it has its own difficulty curves, grading system, and surprises - but it should feel familiar to TGM players. Using a variation of Super Rotation System - the "normal" Tetris rotation system in modern games - it should feel familiar to Tetris players who have never played a TGM game, too!
If you're used to other versions of Tetris, watch out for the special rules around "floor kicks" (pieces getting popped up so they can rotate when they're on the ground) and lockdown. Floor kicks can't pop a piece back up into the air anymore, and the only way to reset the timeout before a piece locks down is to move it to a lower row than it's been in before - moving, rotating, or "climbing" the piece upwards won't help. Think fast!
Think very fast indeed - once gravity is instantly spawning pieces on the floor of the well, the game still finds ways to get faster and faster, reducing the delay between piece spawns and giving you less time to maneuver on the ground.
This is Extreme Tetrom. Can you master it?
Controls
L/R: Shift piece to the side
D: Soft drop
U: Hard drop
X,Z: Rotate
X+Z together: Hold piece
Modes
- Marathon: A classic mode for players who want a traditional Tetris experience. How quickly can you clear 150 lines? Game speed follows a curve similar to "standard" Tetris games.
- Sprint: Marathon, but for only 40 lines.
- Infinite: Played for a high score, this mode also uses a standard Tetris speed curve - although it starts doing some very TGM-like things to try to force the game to end once you've been playing for a very long time...
- Grandmaster: Inspired by Arika's TGM series, this mode's speed fluctuates throughout play (until it reaches 20G, at which point it only gets harder). You're playing for a grade rather than a score; combos, clearing more lines at once, playing quickly, and making it further into the game will all help your grade. Can you survive to Level 1024? Can you achieve the grade of Grandmaster? There may be some surprises along the way...
- Intermediate: For players who are not ready for Grandmaster mode yet, but want to get there. Designed as a training mode, ramping up the speed more slowly.
- 20G Trainer: For players who are ready for the first half of Grandmaster, but aren't ready for 20G speeds! It starts out at 20G with very forgiving lockdown time. It gets less forgiving, and ends where Grandmaster starts its own 20G play.
- Intense: Inspired by TGM2+'s "T.A. DEATH" mode, and TGM3's "Shirase" mode, this mode starts at 20G and gets harder. The only thing you need to do is survive. How far can you make it? There is a last level. Can you get there?
- Grandmaster+: A more challenging variation of Grandmaster mode for people who want their game spiced up! Garbage rows will appear with increasing frequency throughout the game.
- Intense+: Similarly, this adds garbage rows to Intense.
- Extreme: For people who thought Intense+ was too easy. There is a last level, but I do not believe it is within human capability to get there. Prove me wrong.
- Lightning: A race to 40 lines - in the dark. You'll get a brief glimpse of your well every time you drop a piece. For a while, at least - then you'll have to clear a line to get that flash of light again...
- Invisible: And if you prefer your darkness to be absolute, here you go! The ghost piece is useful for tracing out the shape of the top of your well - right until the ghost piece itself disappears.
- Blitz: How high a score can you get with only 128 tetroms? Watch out -- this game gets very fast, very quickly!
- Impossible: "'Impossible' doesn't mean 'very difficult'. 'Very difficult' is winning the Nobel Prize; 'impossible' is eating the Sun." --Lou Reed, in Penn & Teller's Smoke and Mirrors
Notes
I hope folks have fun with this game! I have always been fascinated by the TGM series and have wanted a home release of the games in the USA; no luck yet, despite hints by Arika last November. I was impressed by Vanessa's "Pico Tetris 1.1" game, and saw its existing references to TGM - "secret grade" mode and unique piece entry sound effects per shape - but I wanted to go much further, and make it into a true homage to TGM inside Pico-8. There are a few rough edges here and there, but I consider myself to have succeeded.
If you'd like to add your own modes to the game, check out tab 5. Speed rules are pretty much spreadsheets. Note that the engine interpolates linearly between gravity speeds (but not between ARE/DAS/lockdown speeds - those are stepwise, and only at section breaks), so you'll need to add an explicit "endpoint" at the same speed if you want the game to hold a speed for a while. Gravity is measured in frames per line, so 0.05 is 20G mode. In the actual speed curves, I'm using 0.005 instead - 200G - because rounding errors made 20G not quite behave like 20G, but way-more-than-20G works just fine.
I'd love to see folks' highest grades in the GM modes and furthest sections in Intense and Extreme! If there are bugs I haven't caught, they might be in the late parts of Intense or anywhere past level 2 of Extreme - they seemed okay when I tested them with the difficulty turned way down, but I have not been able to genuinely test the higher levels of these modes with their real difficulty curves enabled. I'm no grandmaster.
Are you?
added 2022-8-21:
Extreme Tetrom is not a "clone" of TGM -- it's not intended to be. It's my reimagining of what a "modern" TGM game could be, using modern piece movement and scoring, but not easing back on the difficulty in the slightest. TGM3 and the Xbox version have "move reset" on their SRS modes, which dramatically pulls back on the extreme difficulty that TGM is supposed to achieve. I've reinstated it -- lockdown timers only reset when a piece moves down to a lower row than it has ever occupied before. Floor kicks are legal, but they can no longer pop you back up into the air.
Extreme Tetrom is intended to stand up to very serious play. In my shower fantasies, a bored TGM player takes the game seriously and it develops a genuine, competitive following. That's very unlikely, of course, but a dubiously-human lizard monster can dream, can't I?
Changelog
Hey all,
I've built a shoot-em-up game engine inspired by Tyrian, a classic of the genre released for MS-DOS in 1995. I'm stuck for now on my lack of artistic skill for graphics, art, a title screen, a menu...
I'm a fan of declarative programming, so I've gone pretty far down that path. The base implementations of ships, guns, and bullets handle clamping to the screen space, autoscrolling, acceleration + momentum + drag, damage, regenerating shields, limited power from a generator (which your weapons and shields both draw from), moving in straight lines (for bullets), limited ammo (optional), and poorly-animated explosions.
I've implemented powerups for recovering health and switching weapons. Weapons can have limited ammo.
I've implemented a general engine for progressing through a level. A level is a table from "distance" to 0-argument functions, which will typically spawn enemies (or powerups, or start events). A level can be "frozen", which stops it from incrementing distance or executing new level events, allowing for boss fights and the like.
Collisions between player bullets and enemy ships are optimized by breaking the screen into a grid of regions; a ship only checks for collisions with bullets in the regions that its own hitbox intersects with. (Ship-ship collisions and enemy-bullet on player ship collisions are brute force because there is usually only one player ship and the overhead of calculating the grid is pure dead weight.)
I've got a bunch of documentation in tab 8 - I hope it's enough for folks to develop their own ships, weapons, and levels with! In retrospect, I think I need to document that ship and event lifespan is managed as follows: when an event, move(), hitship(), or hitbullet() call returns true (or true-ish), it's dropped.
The example level is just a sandbox I was testing stuff in. The graphics are very distant from anything I'd really want to release. But the engine is there, and I think it's cool, and I'd be really excited to see anyone else using it to design a shmup of their own. It's a Tyrian-inspired shmup engine that doesn't have quite enough pieces to be a shmup kit, but I hope to get there.
