Particle theory, the ability of creating particles in a programing language and then deleting them from a list, is a pretty new concept for me.
http://natureofcode.com/book/chapter-4-particle-systems/
I'm more apt to creating an array of a fixed size of elements I need and then using zero (0) for X or something to flag particles that do not appear.
However, PICO does support LISTS, which enables you to create all kinds of data constructs and store them literally like trays at a cafeteria.
Adding an item to the list is easy. Instead of keeping track of the last place where you inserted an item, just use the ADD() command with your parameters and sub-class variable definitions.
When you are done with it, instead of changing one of the numbers to zero, you can literally DELETE the whole sub-class set and it and your list is that much shorter and faster to run.
You can do this by using the DEL() command.
To keep track of them all, you use the function "IN ALL()" I.E.: [b]FOR I IN ALL(BIT)

Hi. I'd really like to build some games for Pico-8, maybe Love2D as well, but I'm hopeless at coming up with an idea for a game and It doesn't interest me to just make some kind of clone. I'd be very happy to let someone else do the art and game concept and I could concentrate on the coding. Would that interest anybody here?
I want to make something genuinely fun to play and polished with nice presentation and spot-on controls.
I could also handle music - I'm not experienced in making chip-tunes but I know how to write and arrange music.

There are all kinds of maze generating algorithms out there. This one of mine uses a pretty simple premise.
[1] Choose a random spot on the map
[2] If not first time, must be connected to existing corridor
[3] Choose a random direction to go (up, down, left, right)
[4] Is it "free" there ?
[5] Yes, cut a line from original to this place.
[6] No ? Try a different direction ?
[7] No directions are good ? We are completely stuck ? Exit here and GOTO [1]
[8] Line was cut, if not complete with maze, GOTO [3]
[9] Completed maze ? Mark entrance and exit and loop forever.
Written in only a little over 200-tokens, this is compact maze making code indeed. Oh, and if you check it carefully, you will see that it guarantees only ONE way through. No way to reach the exit from two-different paths at all.
Press CTRL-R to make a new different maze each time.
Source code gives option to show maze being carefully drawn.
A very short game put together in about three hours over a couple of days. Finding your best shirt can be tough with all these receptacles around the place.
I ended up putting a lot of time into the boilerplate of this game, going beyond my usual 3-state if-else block and adding a table of functions for updating and drawing, ordered by state. Also worked on an SSPR-based entity model. Not bad, I think.
INSTRUCTIONS:
Find your sweetest shirt! It's in there somewhere! Arrows move, Z opens a potential shirt receptacle.

To become a knight, Nils must first defeat the fierce dragon demon.
But on his quest he was caught off guard and captured by goblins.
Stripped from all his equipment, Nils must now escape from the situation and regather the
strength and supplies he needs to complete his quest.
Controls:
Z: Left Hand
X: Right Hand
Arrows: Movement
Arrows in combination with Hand button: Use
Arrows in equipment mode: Switch equipment
Hold down a Hand button and press a direction to use the item in that hand.
Hold down a Hand button for a longer period to switch to equip mode. (A white box appears around hand icon).
It is popular with some programs to POKE directly into the graphic tile space either temporarily for storage or to save off some new generated tiles.
cls() poke(0,255) spr(0,64,64) recover(0,1) |
My question is - is there a way or command to 'recover' the tiles (or any other memory location you've messed with) WITHOUT creating or using a separate array of prior storage ?
These memory locations are after all ROM in every sense of the word in that when the program ends and you are back to the editor, all your tiles or mapping, etc. are untouched despite you using their space during run-time.

I am new to Pico-8 so apologies if I'm missing something...
I'm writing a game using the _UPDATE() and _DRAW() functions which scrolls vertically a pixel at a time. It scrolls smoothly most of the time but every now and then it seems to 'stutter' briefly. Note that the sound/music isn't affected.
I have tried it on 3 systems and the problem is apparent on all of them, to some degree. From best to worst:
Mac i5
Raspberry Pi (1) B
PocketChip
I have used STAT(1) to find out CPU usage, and it never goes above 0.38 (on the Mac and Pi at least, I think slightly higher on PocketChip), so I would not expect frames to be dropped. I've put the STAT(1) at the very end of the _DRAW() function - is that the right thing to do?
I've noticed slowdown (particularly on PocketChip) on other carts too, but couldn't say what the CPU usage is.
Similar thread: https://www.lexaloffle.com/bbs/?tid=4089
Any advice appreciated!

It is true, so much can be done even in it's unfinished state. I was able to get so much out of it. I know that I say it a lot, but I mean it 100%, 110% if you may. It was great but now I have moved to other things.
It is me. I have decided that since I haven't been on voxatron for a while I might as well post the unfinished projects I have. To show others what I have accomplished.
I See
Advanced Bowman
Voxlings
Sorry to say but these games will not be finished.
I have apparently moved on. It was fantastic, the 5 years I stuck with Voxatron. Believe me when I say it's not because of the slow developing that made me quit. I was able to create new ideas all the time using the same basic functions.
This is not a final farewell though, I may eventually get back into it, but that is not for certain, and I still check the blog everyday, playing the amazing pico-8 catridges. Thanks to everyone who bothered to read this short message about me.
Thanks,
Jauq






1 comment




