It would stop execution and dump you into command mode. This would work like setting up breakpoint when you know that something doesn't go right after a specific instruction is executed but you are not sure what.
Example uses:
Stop() after changing the variable: Allows you to print it out in command mode to see if value change according to expectations (e.g. when dealing with imprecision of decimals or when you suspect integer overflow)
Stop() at the end of _Draw(): Allows you to display cart frame by frame e.g. when you debug graphics effects like particles that doesn't seem right.
And so on.
Of course after stopping cart you can then resume() it ;).
And before you ask, yes I know you can stop execution with ESC, but sometimes you need to stop it at the very precise moment which is hard to do manually and so something like stop() would be useful.

This is a reimplementation of a little graphic demo I first saw in the early 90ies on an Amiga500.
I have been writing that kind of demo on pretty much every platform I ever coded with since then.
Was good to see that something like that is possible on pico8 as well. Funnily enough, I pretty much ran into the same bugs, colour mixing issues and performance bottle necks as any other time I wrote a bouncy ball.
Enjoy!
Hi,
I got Pico8 today, I've just started toying around with it briefly and I'm having fun exploring other people's games and reading the forum. Incredible software!
One thing that I've noticed is that there are already various projects stuck because they hit the token limit (eg Underworld Siege or Kingslayer). Now, as a very young console not yet out of the alpha phase, I believe that no one has spent months on a single game and that a lot of things are still to be discovered and boundaries are to be pushed. Yet people hitting the (arbitrary) token limit is not very promising. For example, one of the two games quoted above is a LudumDare game. If someone can reach this limit in a one-week game competition, how can a project grow to a polished, full-featured game? I'm scared that this would prevent some kind of games (RPGs or adventures, for example) to be developed for Pic8, effectively making it less flexible that it could be.

I don't have something to post as a cart yet, but i'll post this capture of what i'm doing right now.
The animation has some color replacements to test the looks of the four turtles. This is the first iteration of how will look one of the three levels i plan to put in the game.
Updated:
Current status: Tech demo. Rewritten all sprite, frame, anim mechanics because i've hit all the limits at the same time :P
No bebop and rocksteady spawning this time, but it's useful to look at the changes i did to the code.
It has a HUD now.
A quick little puzzle game. The goal is to fill up the entire grid with your snake.
Directions:
First, place the snake egg using the arrow keys. Then press 'z' to hatch it. Once hatched, use the arrow keys to move around. The level will reset if you get stuck, or you can press 'x' to reset instantly.

With current one, playing 2 player games is downright impossible unless you have also a gamepad. Well, if you don't want to play a game of Hand Twister at the same time as well, that is.
So I'm proposing following mappings for the 2nd player:
Left: Numpad4
Up: Numpad8
Down: Numpad5
Right: Numpad6
Btn1: Numpad7
Btn2: Numpad9
Then our friend can sit at the side and while we're using arrows+z/x, he'd use just one hand to control the game.
This is exactly how I've set up second player in Nestopia, aside of mapping stert/select to Num+/NumEnter and it works remarkably well.

I've noticed that after few hours of using Pico, it starts to get more and more memory, but only when you start opening many different carts in a single, long (few hours, the shortest time I've seen it happening was in a session about 3h long) session. Obviously closing and reopening pico fixes it, but it should be looked into even if it's small (the biggest it got in memory was about 450MB when leaking).
//edit: Also the first sign the leak is happening is that sound starts to get choppy. That was what alerted me of the issue for the first time and I was investigating it for the past 3 days to get to what exactly causes it.

Would save a ton in tokens since brackets are treated as separate tokens.
//edit: Or if you're calling version of function that takes no arguments, ex:
palt(12,true) -- <- brackets necessary --draw something palt -- <- brackets unnecessary since this version of palt has no parameters |
Of course after such bracketless call/definition, a new line would be required, but most sane programmers do so anyway.






3 comments




