I was playing Zelda: Link's Awakening and was surprised to find that there were platform game levels in some of the dungeons.

So I started playing around with pixels to see what this would look like on the Pico-8 -

However, Nintendo isn't known to be friendly to such fan projects :(

BTW, here is the original Gameboy version for comparison -

I made a mistake in a method and wrapped an entire logical expression in a flr() statement instead of just the number. Instead of an error message the pico-8 would just hang when I tried to run it.

if (flr(self.bottomPaneX == 17)) del(objects,self) spawnWindow()

Above causes pico-8 to hang when you try and run the cart below doesn't

if (flr(self.bottomPaneX) == 17) del(objects,self) spawnWindow()

In a smaller scale test I found that it didn't hang running the following

cls()
test = {}
test.var = 0x42
if(flr(test.var==0x42)) print("reached")

Here is the code which can reproduce the error.

objects = {}
window = {}

function round(fract)
	if fract-flr(fract)>=0.5 then return flr(fract)+1 end
	return flr(fract)
end

function _init( ... )
	spawnWindow()
end

function spawnWindow()
	local obj = {}
	--dimensions for drawing. there are lots so that they can be slightly altered for spooky animations
	obj.topPaneX,obj.topPaneY,obj.topPaneW,obj.topPaneH = 51,27,25,11
	obj.bottomPaneX,obj.bottomPaneY,obj.bottomPaneW,obj.bottomPaneH = 51,30,25,10
	obj.frameX,obj.frameY,obj.frameW,obj.frameH = 51,27,25,21
	obj.colour = 12

	--the object state controls which animation the object is in
	obj.state = 2
	--update method for the object
	obj.update = function(self)
		if(self.state==1) then 
			if(self.bottomPaneY < 37) self.bottomPaneY += 0x0.8
		elseif self.state == 2 then
			self.topPaneX -= 0x1
			self.frameX += 0x1
			self.bottomPaneX -= 0x0.4
			self.bottomPaneW += 0x0.8
			self.bottomPaneY -= 0x0.4
			self.bottomPaneH += 0x0.4
           --This is the fated line top breaks bottom doesn't
			if (flr(self.bottomPaneX == 17)) del(objects,self) spawnWindow()
            if (flr(self.bottomPaneX) == 17) del(objects,self) spawnWindow()
		end
	end

	--draw method for the object
	obj.draw = function(self)
		--remember to save tokens we only need to delcare colour when we are drawing with a different colour to the last thing drawn
		--draw the frame
		rect(self.frameX,self.frameY,self.frameX + self.frameW,self.frameY + self.frameH,self.colour)
		--draw the top pane
		rect(self.topPaneX,self.topPaneY,self.topPaneX + self.topPaneW,self.topPaneY + self.topPaneH)
		line(self.topPaneX + round(self.topPaneW /2),self.topPaneY,self.topPaneX + round(self.topPaneW /2),self.topPaneY + self.topPaneH)
		--draw the bottom pane
		rect(self.bottomPaneX,self.bottomPaneY,self.bottomPaneX + self.bottomPaneW,self.bottomPaneY + self.bottomPaneH)
		line(self.bottomPaneX + round(self.bottomPaneW /2),self.bottomPaneY,self.bottomPaneX + round(self.bottomPaneW /2),self.bottomPaneY + self.bottomPaneH)

	end

	window = obj

	--adds the object to relevant tables
	add(objects,obj)	
end

function _update( ... )
	-- body
	for o in all(objects) do
		o:update()
	end

end

function _draw( ... )
	-- body
	for o in all(objects) do
		o:draw()
	end
end

Gaplus: Galaga Edition 1.0.0

Cart File | Forum Post |

	More cartridges by Arcaden

More Cartridges [View All]

 

Gaplus: Galaga Edition 1.0.0

by Arcaden

Cart #46484 | 2017-11-19 | Code ▽ | Embed ▽ | License: CC4-BY-NC-SA

7

I made this modification of GA TASU (https://www.lexaloffle.com/bbs/?pid=46485#p46485) with my Pocket Chip. It changes many of the sprites to resemble Galaga instead of Gaplus. I made this because I've always loved the graphics of Galaga for their recognizable, colorful designs, and the gameplay of Gaplus for it's complexity, so why not combine them?

I cannot seem to get the F7 screenshot key to work correctly, so it has a garbled label. Sorry about that, trust me, I tried every variation of pressing F7 (with alt and FN and such). I don't know how to fix it :( I tried modifying the .p8.png image to include a manually edited label that looks like it could be a screenshot of the game (accurate sprites & such) but none of my programs seem to be able to save it with the original resolution or color density (that was 30 minutes of sprite editing down the drain). I still wanted to post it so I could play it outside of my Pocket Chip and to have something to show for my two hours of editing, hense the WIP section while I try to figure out how to get the thing to take a screenshot. If you have any ideas please let me know!

Tarot Triad

by Jusiv

Cart #46482 | 2017-11-19 | Code ▽ | Embed ▽ | No License

14

I made this for a 48-hour game jam hosted by Worcester Polytechnic Institute's Game Development Club. The theme was either tarot cards in general, or to take three specific tarot cards and design the game off of them. I opted for the latter, and ended up making a boss rush shmup.

Due to time limitations I wasn't able to add sounds or music, and backgrounds are basically nonexistent, but aside from that the game is pretty much completely done.

Can you defy your fate?

CONTROLS:

• Left + Right: Move
• Z/C: Shoot
• X: Dash

Hey, everybody. In the Toy Train tutorial in PicoZine 1, the first function created looks like this:

function move_segment(s,dir)
spd=dir*2
if(s[2]==8) --TOP SIDE
then
if(s[ 1]==112) --top RIGHT
then
s[2]+=spd
else
s[ 1]+=spd
end
...

And on like that. There must be something I don't get about function arguments/parameters, because the whole function hinges on the relationships between spd, dir, and s - but spd and dir are never defined...! Just what is going on here? It really flies in the face of everything I've learned about code to this point. Where the hell is it getting any type of value? Dir isn't even used again in this entire cart. I'm so confused.

I've looked at several function tutorials, but haven't seen this explained... At least not in a way I'm able to understand. Clearly I'm not the brightest or most informed, but jeez louise this confounded me. Because I don't know what exactly this behavior is called, I don't know what I can search for to learn more about this behavior.

If anyone wants to look at the cart/entire body of code, here's the link.

[ Continue Reading.. ]

Block around the Clock by Genesis Project

by papademos

Cart #46464 | 2017-11-19 | Code ▽ | Embed ▽ | License: CC4-BY-NC-SA

13

Code - Papademos
Music - Stinsen
Graphics - Illmidus

The Neo Jumper .8

by alanxoc3

Cart #46456 | 2017-11-19 | Code ▽ | Embed ▽ | License: CC4-BY-NC-SA

2

• saving the level you got to and score
• having a scoring system
• pretty backgrounds, and particle effects. I'm definitely going to use fillp(). That sounds legit.
• animation for game over
• lives need pics
• the tileset changes themes. (there will be a cloud theme, hell/fire theme, and earth theme, and maybe a space theme, who knows)
• temporary power-ups (jump booster, run booster, extra life, countdown/don't have the screen chase you for a bit)
• tutorial level and being able to pick your level based on the highest one you've gotten to at the title screen.

[ Continue Reading.. ]

Snowball Sunday 0.1b 0.1b

by c64glen

Cart #46635 | 2017-11-23 | Code ▽ | Embed ▽ | License: CC4-BY-NC-SA

2

Snowball Sunday is a remake of the c64 classic game Snowball Sunday by Ash & Dave released in 1988 on the Commodore 64.

This remake version has up to two human players and two computer players.

Instructions

Throw snowballs at each other and have fun. That's it

Controls

Player One/Two - Left/Right to move. Down Cursor to Duck and Collect snow. Z, C, or N to throw snowball.
Player One/Two - Left/Right to move. Down Cursor to Duck and Collect snow. left Shift or Tab to throw snowball.

Credits

Original Programming, Graphics and Idea by Ash & Dave

Changes

Sounds - Done 0.1b
Scores - Done 0.1b

Any more comments/suggestions before I submit this as finished?

I want to control my pico game via html element event handlers. Given that, what memory address (pico8_gpio offset) must I poke at if I want to simulate a btn(0) event? Also, what's the offset for simulating additional player actions, say, btn(0,1)? Thanks.

Picotool is a library and toolset for manipulating Pico-8 cart data, useful for build workflows, as well as cart generation and transformation experiments. Many Pico-8 devs use it for its code minification feature (p8tool luamin), which can be handy when your game's code is near the uncompressed character limit.

A more recent feature is "p8tool build", a tool to assemble carts from multiple files. This tool takes a cart and replaces a type of its data from another file. For example, you can copy the spritesheet from another cart like so, such as to collaborate with an artist working in a separate cart file:

% p8tool build mygame.p8.png --gfx sprites.p8.png

You can pull in Lua code from a .lua file with the --lua argument:

% p8tool build mygame.p8.png --lua mygame.lua

When you use --lua, you get an especially powerful feature: build-time support for Lua's require() statement. The main .lua file can call require() to include code from additional .lua files, such as reusable libraries. It supports several features of the official Lua require() statement, such as only including a module once, and module return values.

You can get Picotool from its Github repo, as well as file bug reports, here:

https://github.com/dansanderson/picotool

[ Continue Reading.. ]

I noticed Pico-8 was missing one thing that isn't too major, but would be nice to have: a way to copy SFX between carts. Yes you can export the music as .wav files, but there is no way to import. I am quietly hoping that zep adds a way to import the .wav files or some format so that we can copy sfx between carts, but until we have that, here is a simple script that will accomplish just that. It just copies all the sfx from one cart and pastes it into another, not allowing for specific tracks yet (Though I may add that later to a separate script). All you have to is type

python sfxCopy.py <inputFile> <outputFile>

and it will quickly copy the sfx from the input file to the output file. Link to the script on Github Gist is here. It is licensed under the CC 3.0 license, so do with it whatever you want. Happy coding!

Is it possible to add an option on the config to disable the screensaver while pico-8 is running , whether it is in windowed or full-screen mode?
When I am testing games out on my Windows setup, the screensaver comes on and ruins my game session.

Character Utility Functions 1.0

by micahcowan

Cart #46393 | 2017-11-17 | Code ▽ | Embed ▽ | License: CC4-BY-NC-SA

1

Char Utility Fns is a non-playable cartridge with some utility functions for categorizing and manipulating character strings, including conversion to and from string characters, and numeric code points. It also has tolower(), totitle(), and toupper() functions to take advantage of the lower-case (well... small caps) letters that are available in the PICO-8 font, but which may not be typed in cartridge source code.

This project was primarily for my own education, and also theoretically for use as a library of useful char-manipulation functions... but since it takes up almost 400 tokens on its own, it'd be a fairly costly library, especially if you don't have need for all the facilities provided. Still, it could be edited down to include just the parts you want to use in a game. I think being able to print title-case messages is particularly neat; I might think about creating a version that only provides the tolower(), totitle() functions, since that was the main thing I was interested in while creating this.

As a curiosity, the source code also demonstrates some advanced function techniques; notably, the use of a top-level, anonymous function to contain/hide some local values - and local functions - that are used to construct some of the actual functions that are exported globally. (The same technique is quite common in many popular JavaScript code libraries.)

I don't see anything wrong with the actual pattern system, but it feels weird that specifying the pattern, the color, and the transparency is all split across multiple commands.

What if we could put it all in one place? What if I wanted a hideous red/green checkerboard, and could say so right in the rect() that drew it?

Well, there's room in the color parameter to do it:

rect(0,0,127,127,0xb8.a5a5)

Where b is color 11, green, 8 is color 9, red, and a5a5 is pattern 1010/0101/1010/0101. All in one combined, dithered, eye-bleeding "color."

Also, we can handle transparency. Let's say we want a less-hideous red/transparent checkerboard:

rect(0,0,127,127,0x108.a5a5)

Where the leading 1 means the second color (which was green) is transparent. Basically, if the second color is 16 (0x10) it's transparent.

This actually mirrors the poke-able pal/palt() registers, where the color is 00-0f if opaque and 10-1f if transparent. Calling pal() sets the bottom four bits, and calling palt() sets or clears the fifth bit.

There's a caveat, though. A lot of us do demo trickery where we treat the color value as automatically getting floored. So we might need a flag that says whether or not to treat colors oldschool or this way. Either a poke() trick or maybe a dithcol(true|false) call.

What do you guys think? I just feel like this would unify stuff so much better.

[box=ddffbb]Edit: Worth noting is that if you just pass, say, "8" for red, you get the usual behavior, because that's actually 0x008.0000, which is an opaque red/black color pair with a solid dither pattern (all 0's) that choose only the red color.

In short, the default behavior would match the normal usage. This wouldn't require any changes for people who use the API the way it's always been.

[ Continue Reading.. ]

Hi, I'm currently working on a text heavy narrative game and as of now my main text table(Formatted as a string I then parse into a table at runtime) takes up 41% of the compressed size limit. Is there any way I can slim this down without losing text?
Is it viable to store the strings in a seperate cart and then memcpy them into my main cart? Would that stop it running in html/bbs/.exe?
Alternatively I can split the text into distinct sections and then store them as a string of carts which daisy chain into one another but that won't work in html to my knowledge and would rather fill the bbs up unnecessarily with carts that are just meant to be run by another cart.

I have been using tiles as a placeholder, as I have not yet learned how to work with collisions. At the moment, I am trying to figure out how to replace sprite 34 with sprite 35 when the player interacts with it. Any help is appreciated.

HBShell

by MEMalguy

Cart #46344 | 2017-11-16 | Code ▽ | Embed ▽ | License: CC4-BY-NC-SA

The pico-8 manual mentions the following argument to the "pico8" program:

  -p param_str             pass a parameter string to the specified cartridge

but I can't find any mention of how to access that parameter. I was thinking it might be passed as an optional argument to _init(), but that doesn't appear to be the case; and PICO-8 doesn't expose lua's standard arg array.

How can I access that string?

I'm running on Mac OS btw, invoking the binary directly with:

~/Applications/PICO-8.app/Contents/MacOS/pico8 -p foo -run path-to-cart.p8

This seems to make the keyboard keys unresponsive (except a few, like return), not sure why...

Help!

by gigs

Cart #46336 | 2017-11-15 | Code ▽ | Embed ▽ | License: CC4-BY-NC-SA

I have the town with buildings that have collision coded into them with the doors coded to take the player to another room which is admittedly hacked together.
What happens is the player is then transported(sorta) to a new location - yet when I move him around in the 'new' zone there seems to be residual collision code which prevents total freedom of movement for the player.

Any better ways to go about this? I want the player to enter the brown zone and be able to freely move around at will.

Thanks!