Alright, the title explains what this is really. So I mapped a random """heightmap""" to the sprite sheet (using poke), later in _draw() I SSPRed the whole sheet, giving 128 rows from the sprite sheet on the screen. Then I offset the Y using the function √1-x^2 modified to look more visually appealing, and hacking off the sides so weird noise wasn't visible. Offsetting the source of the SSPR on the X-axis allowed me to scroll what was visible to the user.
You might say, "Hey, that noise looks like sh!t", and yeah you're right. This is not quality noise. but I coded the noise in like 2 hours, so cut some slack, please. My current project doesn't need noise thats anymore complex than this. I don't need a fancy system of noise. Also, please ignore how bad my code is, I can be a bit of a spaghetti coder.
(Btw: Z/X to rotate the cynlindar, i submitted this to share less as a resource so i didnt include user interface text)
This cart demos some work I've been doing on 3d rendering - including both flat shading and per-vertex shading.
up/down/left/right - orient
z - change colour palette
x - change render mode
The per-vertex shading is experimental code using sspr for render scanlines from the spritesheet. There are some issues with this - lighting discontinuities possibly fixed-point related.
I wouldn't be surprised if there are some bugs, and I need to update the transform code and add in viewport culling.
- increased rendering performance (radix sort + pipeline changes)
- fixed per-vertex shading
I have done a game code for a red ball that I can move in a line. I have figured out the code for that. However, I am stuck on making it change a color when it hits the end of the pico 8 screen. I have searched it online and have had no luck. Can anyone explain what I need to do to get the ball to change color? Thank you
Here is my code so far without changing the color.
xpos = 64
ypos = 64
col = 8
size = 5
if (btn(0) and xpos > 0) xpos -= 1
if (btn(1) and xpos < 127) xpos += 1
if xpos < 33 then col = 5
circfill(xpos, ypos, size, col)
Surprisingly with all the updates PICO-8 has received, it has one gross error in it that took me hours to debug and later find out and break it into the exact components giving the error alone. It was definitely a case of "it's not my fault." Could cause problems later in other carts and programs.
This will not run:
if (key=="(") print"open"
This will also not run:
if (key==")") print"close"
This will run:
if (key=="[") print"open"
Wow. And no-one's discovered this till now ??
Update: Added GRAY, bars, text, Hopalong Cassidy
As you know, a new palette method was discovered. Now while you can't use all 32-colors in one screen (which is what I had hoped), you CAN tweak individual palettes of the 16 to use the new set.
This means for those of you who want to make games that use only one HUE, then you might find this program useful.
It shows 6-squares going from darkest but not black to each color of purple, red, orange, yellow, green, and blue, using the (O) key to change between, and the coding involved to produce it.
I have since added a picture of Hopalong Cassidy. This was not easy. First I converted a square picture of him to 128x128 B&W. Then manually created a palette based on the 7-colors that comprise of (Gray). Then reissue the image using that palette.
Then manually modify the palette only to default PICO-8 standard. Import. Re-hue, done. He looks best in the GRAY hue because that is the picture he was originally, B&W.
Would be keen to have optional 16-shades of B&W. :D Maybe next PICO-8 release.
Note, the color bars and squares are still there, change value HOPALONG=0 in the program and re-run.
So this is my first time working with PICO-8 and really my first time making a game from scratch in general.
The entire movement system is my own creation, I didn't look to see how other people did movement so it may not be perfect but I'm rather proud of it. A lot of it just came naturally as little things I added as I discovered the different capabilities I had. Some things, such as the glitchy title intro and the hp bar jolting in the direction you're hit, were actually just pure mistakes or stupid coding on my part that gave me an idea for a cool effect. It may not be much of a game yet as there are no objectives, but it means a lot to me as the joy that coding it brought me has solidified my desire to be an indie game dev and make a career of that.
To quote the maker of the game Forager:
"I hope you love this game as much as I do"
There's an Alakajam! event scheduled for the 20-22th September week-end!
The event is an online gamedev competition where people make a game from scratch over 48 hours. Start/end times are suited to European timezones (7pm UTC), also both the theme and the winners are decided by the community! As I write the theme submission phase is about to start, and you will be able to suggest ideas for one week. The full jam works this way:
More than the thrill of the competition, a cool thing is that all games are getting valuable feedback their games thanks to our voting/comment system.
If you're interested feel free to check in, we also have a Discord & an IRC chan. See you there!
Hey everyone, with the new colors being discovered recently, I decided to package them all up into an aseprite palette file/extension. Hope they are useful to someone!
pico8.zip modifies the default pico8 extension that comes with aseprite. Replace the contents of the directory with the contents of the zip. You can find the directory by opening aseprite, opening the list of palletes, selecting pico8, and clicking "open folder".
pico-8-secret.aseprite is just the standalone version which you can load by selecting the "load palette" option.
Hello there, after a positng a sketch variation I did on Twitter earlier today, I was asked how one would do such a similar result.
So instead of a badly written Twitter thread, let me post you a badly written BBS post with a badly written (but well commented) breakdown on how I did it.
The spiral is a cylinder sliced in a few circles I offset on X and Y based on a formula. This formula varies with time and on which circle it'll yield the offset to (here, the index).
So, I progressively iterated from nothing to the spiral. Here's how I broke it down:
First I generate circles made by vertices I'd store aside. Drawing circles this way will allow me to the other steps. Each circle is drawn by drawing a segment between two consecutive vertices in the circle and by linking the same vertex between two consecutives circles. Here, it looks like a colored spider web.
Then, I made the circles' center move based on the time. But it still doesn't look like a spiral. We can do better.
So I make each circle's offset move indenpendtanly. I draw the circle in a for i=1,n
loop, so I can use i to have a different result per circle. Here I just add an offset to the sin formula to make each center different from the others.
By doing the same on the y axis, I'd have a diagonal if I would use the exact same formula. The complement formula to draw a circle based on T with sine is cosine, so for the y offset I used the same formula but with sin turned into cos. Now each center moves into a circle.
I can perfectly tweak both formulas differently. For instance here, I removed the x offset and made the y offset in a way so circles will cross some of their neigbors. It'll be useful to give a better sense of depth in the next step
And, as a last step, I replaced the line drawing by drawing quads with the trifill routine generously made by ElectricGryphon so we have a solid tunnel instead of a wireframe one!
And that's the core basics on how I made the Nuclear Throne inspired vortex sketch a while ago! I'll be leaving the commented code on the bottom of this post, feel free to have a look on how I did it, but here's a fair warning: I clearly didn't optimize the code, there is still a lot that could be done to avoid useless calculations, but it should be clear enough to allow quickly anyone to hack it, it works and in 30 FPS. Have a nice day and happy 32 colors day!
Been toying around slightly with Pico-8 as a break from bigger projects, and I'm wondering if there will ever be an increase to the possible resolution of pico-8?
I dig the limits being used to force creativity, though I do feel 128x128p only gets you so far and no amount of memory-banking between carts can get around that for game-scale, it was the same thing I took issue with on both Gamebuino consoles.
To note I'm not saying like "hey we should have mega-complex 240p with 3x more sprites and 90 more colours so we're basically just on a snes", but I do think even just an upscale to 160x144 would help so much. I'd looked at alternatives but clearly the community and scale of potential support and resources is here in pico-8. As much as I'd like something like the C64 res of 320x200, I think even just the Gameboy 160x144 on some kind of Pico-8+ with the necessary memory increase, maybe a tiny bit more for graphical allocation, would be great.
While playing around with poke/peek, I discovered theres a new palette to choose from.
Poking the address 0x5f11 and setting it to a value of 0xf1 [the 1 being the color in the palette, in this case dark blue] you'll notice something strange. The blue seems to be even darker! this goes from 0xf0 to 0xff and corresponds to the color palette available naturally. It seems to darken/add a warm filter to the colors, allowing us to provide sprites with more specific details. You can see this in action via Neil Popham's post on twitter. To return the color to normal, replace the f before the color ID with 0. for example, 0x01 would be normal dark blue where as 0xf1 is the darker dark blue.
Address range is 0x5f10 to 0x5f1f from what I can tell, and there is no other hidden colors yet discovered but knowing zep... there probably is. :)
Have fun with this discovery.
respriter is a tool that you run in PICO-8 that let you edit other p8 cartridges
With this tool you can move sprites around and have the map updated to point to the new location of your sprites, so it isn't ruined. Sprite flags are moved along with the sprite pixels.
It is useful for when you want to move sprites around in the sprite bank so related sprites are next to each other, for example.
So you can turn an unplanned and unorganized bank into a more organized one
And your map will still look like this:
Respriter will also move the sprite flags when you move the sprites.
You can write protect parts of the sprite bank if that memory is used for the map, or you can work unprotected if you really want to
It is also possible to define where your map data is stored. If it is the full 128x64, shared 128x32 or some custom rectangle anywhere in the 128x64 space
If you work often in the same cartridge you can save the cartridge, map rect and all the other settings in a workbench and load them later. When you load a workbench you load the cartridge for that workspace and also all the settings
You need to download the cartridge and run locally for it to work since it needs to load the cartridges you have stored locally
- download the respriter.p8.png cartridge
- place it in the same folder as the cartridge you want to edit
- in PICO-8, go to that folder using cd in the command line interface
- load respriter.p8.png
0.3 beta (pw_respriter-5.p8.png)
- added workbenches
- added saving of state in custom map rect mode so the camera isn't reset every time it is opened
- fixed mouse cursor bug when exiting custom map rect
- fixed tutorial where right-click was used but it should read left-click
- fixed tutorial text that still referred to the app as "tilemover"
0.2.1 beta (pw_respriter-4.p8.png)
- added visualisation for where map and sprite memory overlap
- made the map memory protected from edits
0.1.2 beta (pw_respriter-2.p8.png)
- the tool now accept pw_respriter-x as filename of the tool since that is what it is called when downloaded from the Lexaloffle BBS. This should fix the issue where a downloaded cart would report an error when opening the "load cart" screen.
0.1 beta (pw_respriter-0.p8.png)
- initial release
I recently discovered the 16 extra colors, and since it's not very fun to go back and forth between sprites/code/game just to test colors, I made this cart so you can actually draw sprites with the extra colors directly!
Swap beteen tabs PAL1/PAL2 to select which colors will compose the 16 colors of your sprites:
Select the index on the right and the color on the left. "OK" means your palette already has that color. "▤" Means that index is using a color from the pal1 when you're viewing pal2 and vice-versa.
- Your pallete is saved between sessions (poke 0x5e00~f).
Standard pico-8 features
- Zoom in/out with mouse wheel
- Save by pressing SHIFT+S or via pause menu
- Pick colors with left button on the sprite
- 2 extra sprite tabs, because why not! (will draw on the map region: 0x2000-0x2fff)
Hello everyone, today I stumbled on a undocumented feature I didn't know existed: 16 extra colors.!
I searched on the wiki and the forums and I didn't see it mentioned anywhere (except this thread, but it was a differnt thing and that feature was removed by zep at that time).
If you change the screen palette via poke (0x5f10 to 0x5f1f) to a value above 0x80, the color will change as shown below:
Here's world 2 of Jack of Spades with all colors swapped, except black and yellow:
Original colors for comparison:
You can't have more than 16 colors in a single frame though, since poking (0x5f00 to 0x5f0f) will just make the color transparent, as documented in the wiki. Still it's good for fades, and can be used for someting like stage-specific palettes like in the NES and other old consoles.
So I'm fiddling around with a quirky fantasy romper, following the wacky adventures of Stabitha and her sidekick Quiver. What do you kids think?
(that's not Stabby and Quiver, its just a random grab of orcs from my game WIP!)