Understanding ENVIRONMENTS
Inherited from native LUA, _𝘦𝘯𝘷 (NOTE: type it in PUNY FONT, won't work otherwise! For External editors, write it in CAPS _ENV so it transfers as PUNY FONT inside PICO-8) can be a tricky feature to understand and use (abuse?). There's been some talking around this subject and as I am actually using it heavily in my coding style (very OOP I'm afraid...) I thought I could share some knowledge around it.
If we take the information directly from LUA's manual what we are told is the following:
As will be discussed in §3.2 and §3.3.3, any reference to a free name (that is, a name not bound to any declaration) var is syntactically translated to _ENV.var. Moreover, every chunk is compiled in the scope of an external local variable named _ENV (see §3.3.2), so _ENV itself is never a free name in a chunk.
Despite the existence of this external _ENV variable and the translation of free names, _ENV is a completely regular name. In particular, you can define new variables and parameters with that name. Each reference to a free name uses the _ENV that is visible at that point in the program, following the usual visibility rules of Lua (see §3.5).
I leave here in the forums a copy of my entry to lowrezjam 2022, Aztec. Code ended up being really messy and there's a lot of things to fix/improve post-jam, but I thought it would be a nice addition to the BBS. It's multicart (has a loader companion) as I needed a bit of extra space in the main cartridge to fit everything.
Tonatiuh, the Sun God is angry! The High Priest Tonauac has decided to invoke the Tanatiuh Cualo, the ritual that will eat the Sun God and placate his wrath, but to achieve it he needs the Jewel skulls to be placed in their right places in Tenochtitlan's Templo Mayor.
While he prepares for the ritual, he sends you, the Aztec prince Guatemoc, into the temple to search for the sacred skulls and place them in their pedestals. Beware the traps and misteries that protect the sacred grounds of the Temple!
Code, SFX & Art by SlainteES
Music & SFx by: VavMusicMagic
Find this game on itch: https://slaintees.itch.io/aztec
Issues and bugs to fix:
- Jumping whlie climbing continuously reattach you to the ladder if pressing a directional button
- Some issues with "top of a ladder" state detection can cause you to drop from the top of a ladder
- Some performance issues randomly due to suboptimal collision detection
- If dying mid-air ocassionally the game does not make you land before actually dying (rare to happen)
- Minor sync issues detecting activable objects (particularly Obsidian mirrors, that can be activated a bit earlier than they should)
- Some more (yes... those again...) ladder issues can end up pushing you inside walls... 1 bugreport so far, but a nasty one... (Really... who decided ladders are cool?)
Fixed Issues:
- Reset DX velocity to 0 before respawn, you could "move" while respawning because it was not set to 0
XOR Must Be Revealed
His many faces are scattered through 15 levels. Acquiring all the faces on any level will enhance your knowledge of Xor.
Beware Xor controls his world and doesn't give up his personality easily
Rediscover this classic from 1987, originally released by Astral Software under Logotron. This is still a very early WIP (first playable alpha actually), a few levels can be played but still missing levels, sound and probably some graphical polishing. The game will provide the original 15 levels and several extra ones once complete and ideally (if sticking to plan...) a level editor so you can create your own levels and puzzles.
Take control of Magus and Questor and beat all the levels in Xor's world by picking all his many faces and exiting through the door. Switch between Magus and Questor with X and see a level map with Z. You can quit a level if you get stuck from the map screen.
I've been doing some experiments with LZW compress/decompress lately to retake some work on my Isometric engine so I could manage bigger tilesets (compress on string or memory, spr bank switching, etc). Reasonably happy on how this is working... it's a straight forward LZW with 256 dictionary size and 16 root symbols (a.k.a. 16 colour indexes). Works quite well for moderately big images but fares quite badly the moment it runs out of dictionary entries as dictionary is not optimized but generated dynamically both in compression and decompression and it potentially wastes entries with low re-usability or even foldable into later entries (f.e. long single colour runs that would do better on RLE)
Unsure if this will help anyone as there's already other compression solutions through the bbs, but here it goes in case you feel like it can be useful.
See the code for info on how to use it, the compression generates a small header (2 bytes for width/height) and the compressed string. The decompression can use pset/sset/mset or an internal pxset function that can write screen-format blocks at arbitrary memory addresses (lower performance than native funcs if you are writing to spr,map or screen though).
This is my entry for LOWREZJAM 2021, still incomplete and it will be mostly a POC of a complete game.
The game is a tribute to the Natsume's SNES classic "Wild Guns" and is inspired by the gameplay in that game.
In "Golden Star Sheriff" as the new sheriff in Dodge City your duty is to chase and get rid of a big band of thieves that have taken over the city and it's sorrounding areas.
Current state of the game (JAM Version) is going to be a tweaked version of the full game as there's been not enough time to have multiple levels in place, so it will take place only in the first level, Dodge City streets, chasing for "Perro Loco", the lowest ranking bandit chief in the band. The game is tweaked so you can play several times the phase with increased odds rather than actually advancing phases...
So I decided to go for a platformer... my first in PICO8. Building it on top of my OOP game model (which maybe was not that good an idea...) so it is a code nightmare. Already at version 4 with a few discarded prototypes in the middle and for sure require some cleanup and refactoring... but kind of works and it would be great to start getting feedback.
Torches are an application of an old experiment, it's been a while I wanted to include them in some project (and for sure require fine tunning, as they are map cannot scroll as they are poke'd in place with additive blitting)
Still a very early WIP, no screen boundary control so if you fall off an edge you will fall forever :)
I am parking this for a while but I will come back to it very soon, I relly like where this is going
So LOWREZJAM 2020 comes to an end... I finally submitted a playable project but with a lot of unfinished features. For a start there is no AI, In the remaining time I would not have been able to add a proper "smart" AI so I prefered to leave the game as 2p game only (or for those wanting to challenge themselves balttle yourself!). Sound is totally missing... I will be welcoming sfx and track contributions... that area is not my best. You can check it also in it's itch.io page
Future plans
At this resolution (mode 3, 64x64) and with the constraints in time for the JAM I "abandoned" that cart and started focusing on rewriting things on a 128x128 more organized cart (keeping all the good things in this one) so expect to keep hearing from Fantasy Tactics HD ;)
I am working on a project for URL LOWREZJAM 2020 and I think it is time to present it here to get some comments maybe.
The cart is quite far from being playable but as there's been some expectation around it I've dediced to keep the wip cart here so ppl can comment and try it. Don't expect too much out of it, still very early
CART UPDATED
Updated with a bugfix... using potions broke unit release
It's going to be a "tactics" like game (tactics ogre, final fantasy tactics...). Still plenty of work to do and not sure if I will be able to put everything up for the Jam but for sure I am gonna keep working on this to a point it becomes a playable game. For now working on 2 carts... the game itself and the editor and probably I will release the editor/isometric renderer on it's own cart in case someone wants to experiment with it once it's kind of "complete"
Project is in MODE 3 as the jam is 64x64 and I am using some odd sizes around (my general sprite/object box is 10x16) even though I am adding full support to custom sprite sizes for the renderer itself.
I've tried to upload several times a new version for a cart but seems something breaks that cart in particular... everything runs fine locally (windows machine) but the uploade version gives a syntax error in an odd place (inside one px9 generated string)
I saved the cart a few times but results are the same... any idea on the reason and a potential fix?
cart is
(and a few of the previous ones... 14+) In terms of changes against version 13 there's a few extra lines and some extra bin data in the map area. Not htting any of the limits (compressed at 98%,7253 tokens, 48153 chars)
Probably everyone has one of these... sharing in case you don't and need a quick wrapper around the mouse support.
The library implements an OOP like MOUSE object that supports 2 buttons and provides the following methods:
- enable() : Enables mouse suport
- disable() : Disables mouse support
- pressed(<num>) : true/false if button number <num> is pressed in current frame
- clicked(<num>) : true/false if button number <num> is pressed in current frame but was not in the previous
- released(<num>) : true/false if button number <num> is not pressed but was in the previous frame
- inside(minx,miny,maxx,maxy) : true/false if mouse is inside the defined rect boundaries
Would be quite easy to extend, mouse cursor can be set to any spritesheet index and would be easy to handle animated cursors, bigger cursors and such...
The demo cart shows how it behaves... pressing buttons changes background color, clicking and releasing draw some points on the screen (in green hues for btn 1, blue hues for btn 2.. brighter for click, darker for release)
Took me a while to debug and identify why this was happening...
I was taking advantage of RESET to clear clipping and palette and as a side-effect RND() started to misbehave returning always the exact same number. I guess that RESET also sets a fixed srand seed and that's why the pseudo-randoms go stale... Probably worth documenting that RESET also does that or if this was unintentional fix it...
Will post here my experiments with particle effects...
Experiment 1: Fireworks... basic explosions
version 1: very basic approach
version 2: added gravity pull and callback update/draw for particles to operate multiple particle types (f.e. rocket and spark in the test)
Experiment 2: Additive blit particle fire
version 1:
While starting work on my little deflektor project I decided to have classic 7 segment led style numbers, my first iteration (the one currently in the game...) is based on sprites but I wanted something a bit more versatile. This is a basic line drawing small library to handle 7 segment led like any digit length display. It should be fairly easy to define a text set and draw 7 segment text desplays (just need a table with the segment mapping for every letter and put up a wrapping function that receives a text and not a number)
It supports background displaying of segments ("off" segments), color configuration and segment width configuration. The cart includes the library and a very basic demo on what it can do
I might be working on reducing token size a bit (library itself is around 300 tokens) and I think there's some salvageable space there, but don't count on it for now
Hope it helps someone out needing a 7 segment style display
I've invested some time working on a demake for one of my favourite games from the 8-bit era, Deflektor (by Costa Panayi). Your goal is to guide a laser to the receiver on each of the levels, access to it is blocked until you destroy all pods on the level. Laser overloads when it hits mines or if the emitter gets feedback.
HOW TO PLAY (you can go through this tutorial in the game itself)
CHANGELOG V0.5.5
- 1 MORE LEVEL (now totalling 8)
CHANGELOG V0.5.4
- 1 MORE LEVELS (now totalling 7)
CHANGELOG V0.5.3
- 2 MORE LEVELS (now totalling 6)
- ADDED safety pre-check so levels don't start on full-reflection or overload status