Datadata

Pico8 use 2 functions to update stuff at a regular basis. One _update() function called every 1/30s (or 1/60s since the 0.1.8 version) and one _draw() function that do the same thing.

That allow, for a project use that use the second as a time unit, to not slow down that unit.

From manual: _draw() is normally called at 30fps, but if it can not complete in time, PICO-8 will attempt to run at 15ps and call _update() twice per visible frame to compensate.

e.g., If I decide to make a sprite move from A to B in exactly 1 second but have a render process slower than 1/30s. I can put the move process in the _update function and the rendering in the _draw() function. The animation will not be smooth but the sprite will move from A to B in exactly 1 second.
This is true if the _update() function do not take more than 1/30s to execute.
This simple separation is only used for that purpose.

For my shmup project (bullet hell/danmaku) project, it's different.

[ Continue Reading.. ]

Cart #45582 | 2017-10-29 | Embed ▽ | No License

For day 28 the theme was campfire. This campfire is a little excited. You have to sit a ways back. It's not ready for marshmallows.

This is my first post here, so greetings everyone! 😀

But i was curious how to code in collisions
like bumping into walls and enemies.
And creating boundaries for my levels.

Thanks everyone 😊

I wanna collab with other people. Who wants to collab?

Porting a classic C64 game over to Pico-8. This has been a fun project so far.

Though I barely even have a game, the very basic core elements are there.

Still have to program in all the mini-games, and work on that god-awful layout I have on screen right now.

Cart #39588 | 2017-04-13 | Embed ▽ | License: CC4-BY-NC-SA

2

Is that broken for anybody else?

Oh no, idk what happened to this - I can't find my local copy and my copy here is b0rked too :\

Hello everybody! I normally use Gamemaker Studio but my graphics card crapped out on me and I only have a Linux laptop as a backup which Gamemaker Studio doesn't run on. Fortunately, Pico-8 does run on Linux! I've owned Pico-8 for a while but never really used it so I figured this was a better time than any and I'm pretty glad I did now. This program has really made me appreciate the Lua programming language. It's super simple to use and learn. Over the past few days I put together a simple starter project that lets you not worry about the boring stuff and just jump straight into making your game. The only thing I didn't write myself is the insert function which is edited from Adam Scott's "Missing Built-ins" extension.

Features:
-Sprite animations
-Sprite origins
-Automatic depth sorting
-Mouse support

Plans:
-Integrate map editor
-Collision system
-more to come? we'll see.

GITHUB LINK
Online Demo

[ Continue Reading.. ]

Overview

So the other day I delved deep into trig to pull out the bare minimum of what makes things move in circles.
The problem I've had in the past is that I often looked at games or demos that incorporated a lot more things, so I often would make incorrect assumptions about how to implement these types of things. My hope with this tutorial is to just show you the absolute bare minimum of what you need to get a sprite moving in a counter-clockwise circle, and explain everything line by line as best I can.

Here is what we are making:

To make something move in a circle, we have to use trigonometry. This tutorial is going to explain the trig functions we'll be using so that you can hopefully use them on your own without copy and pasting.

Prerequisites

To get the most out of this tutorial, you just need pico8 installed.

The gist

A sprite moving in a counterclockwise circle

radius = 30
originx = 64
originy = 64
angle = 0

while(true) do
 angle += 5
 if (angle > 360) angle = 0
 cls()
 x=originx + radius * cos(angle/360)
 y=originy + radius * sin(angle/360)
 spr(0, x, y)
 flip()
end

Rendering with pico8

[b]NOTE: Skip this section if you want to get right to the trig! Just go to "Show me the trig!"

[ Continue Reading.. ]

Being a fan of 8bit and 16bit graphical adventure games from back in the day, I've set off on the mission to create one on the Pico. With the understanding on the size limitations of the Pico-8, I'm building a game engine that is utilizing as many reusable components as possible. I'm documenting my efforts on my blog at: http://whiteoutlabs.com/game-development/pico-8-sprite-animation-basics/

Alright. I'm finally getting somewhere with my level code, physics, and... well, I'm still WORKING on my composition stuff, too. But now I'm also starting to work on enemy AI. And here's another spot I'm kind of fresh to.

See, past projects I've worked on include fighting games - which are essentially just really big FSMs, and the AI uses some conditions like player distance or input to determine appropriate responses (some MegaMan bosses do this, too)... and music games, which is really just about lining up targets with precise timing and that's really all there is to it. Making shots doesn't seem any different than making fireballs in SF, either. But making enemy AI for platformer and top-down-adventure games is kind of a different thing; and I could use some guidance - heck, maybe even outright collaboration with.

There's four titles of enemies I'm trying to reasonably replicate here:

200X - a MegaMan knockoff.

Concert of the Damned - something between Zelda II and SotN, maybe a little Shovel Knighty too.

Gentroid - Yet Another Metroid Fangame (there's a good grip of these, it seems - and Cow has the physics/feel to that DOWN! Perhaps I should just step aside...)

...and an as-of-yet-to-be-determined title that's in line with Zelda 1 and/or Gauntlet; maybe a bit Isaacy, but certainly not Isaac. Save for maybe boss influence, we'll see where that goes.

How do some of you do your enemy AI? I know really simple stuff could be handled by my "MakeTarget()" code, but not stuff that depends on terrain contact. "MakeTarget()" is mainly about making basic movement patterns - lateral, vertical, sine-waved values, diagonals, circles or semicircles, that kind of thing.

function maketarget(obj,scr,x,y,xrange or 0,yrange or 0,speed or 0,loop or 0)
--x/y position relative to map
 obj.p.x=((scr\5)*16+x)
 obj.p.y=((scr/5)*16+y)
--set sine motions to control
 local movex=2*sqrt(xrange)*speed
 local movey=2*sqrt(yrange)*speed
--reverse direction! 
 if (movex=xrange or movex=-xrange or xrange<0) movex*=-1
 if (movey=yrange or movey=-yrange or yrange<0) movey*=-1
--diagonals or curves
 if loop=1 then
  movex=xrange
 elseif loop=-1 then
  movex-=xrange
end

So... I guess what I'm aiming for is a back-calculating method for controlling player movement, via globals. So, let's say I'm wanting a typical jump-to-same-level duration to be 90 frames; and for it to go up 3.5 "tiles" of 8 pixels apiece; with a 0.8x accel/decel rate (gravrate). I define the jumpheight as 28 (pixels) and the jumptime as 45 (ground-to-apex; so half of 90), and then use that to calculate jumpvelocity.

My usual go-to is jumpvel=2sqrt(gravity tiles * gravrate), and then letting the typical gravity accel/decel take over from there. "gravity" is seperate from gravrate, in case I want to disable it (by making it 0) reverse it (by making it -1), or reducing it (making it a decimal, usually between 0.5 and 1).

Also, working on a similar accel/decel for horizontal walk/runspeed... so let's say I'm aiming at 0.3 px/frame to be the max speed (18 pixels a second, or a little over 2 tiles, so you can jump four across, level-to-level)... I still want a 20-frame accel and 10-frame decel delta to that, to give some fluidity to the player's motion, it's not all "everything or nothing." So the actual velocity is like "0.3 - (0.015 * runframes, if less than 20)" and then at release, setting that value to 20 and reducing it 2 at a time so that the calculation still affects the movement speed.
...
I think I'm losing my mind though, so am I still doing this right? >.>

I'm increasingly forgetting stuff, and when I'm working and calculating, it's interfering with my work - and THEN when I'm off, I'm no longer calculating, and everything's kind of getting messy. Dammit!!

A heads up for Voxatron users -- the first version of the Lua api will be out next week in 0.3.5!

Pictured above is the result of drawing voxels directly into a room's map. The 0.3.5 api also provides access to actor attributes and state, spawning, camera control, and direct access to the display. The entire PICO-8 api is in there with some 3D counterparts (line3d, box, sphere), and it's possible to import a pico-8 cart into the resource tree, place it in a room, and run the cart on a single slice of the display. The .p8 cart shows up in the resource navigator, and is placeable in the room like this:

The code can also be edited to make slight adjustments for the 3d display:

In other news, I've updated the website with mobile-friendly cart listings and touch controls for the carts. It's still a work in progress -- the sound in particular is very choppy or missing altogether. But apart from that it is quite useable. If you have a modern phone or touch device please try it out!

I'm so excited about the new Pocket C.H.I.P. where I will be creating games on. That's why I just created my account.

PRE-ORDER CONFIRMED!

Thanks for your pre-order! It’s confirmed in our system and estimated to ship this November . Look for another email from us to confirm your shipping address closer to your estimated ship date.

Date 11/12/2016

And that's it. I wish all of you an awesome weekend.

Hello there.
This is my first post. I will try to write about PICO-8 from a view of amateur who try to solve problems and write about them. Write about his first steps in programming, music creating etc.

CHAPTER ONE: PICO-8 and DROPBOX

It was not so hard to see, where to start. PICO-ZINE makes great introduction especially with the SQUASHY game. But lets start with something other.

How to start pico in another directory:
If you got Dropbox and you are using PICO-8 on more than one computer, than is a really good way to store your project on Dropbox. I`ve got really trouble to change the config where the directories are for PICO. So lets see how to do it:

This steps will be for those, who are running PICO-8 for the first time.
If you got config.txt, just skip to step 6.

Run PICO-8 Type FOLDER and press ENTER You will see, where the main directory of PICO8 is. Don't be fooled, if you don't see any config.txt Exit PICO-8 (now PICO-8 writes a config.txt) If you haven't see config.txt, now you should see it. Just edit it and change the thing you would like (paths...) RUN PICO-8 and see if something changes.

[ Continue Reading.. ]

Character generator 3D test

i have to count frames a lot because i'm using them to base the timing for the rhythm game and the clock. rather than having some global variable i increment every update (which would then require some kind of modulo operation to check, say, if we are on an even numbered frame) i decided to use the closure technique to make a counter that resets after a certain number of frames.

function frame_looper(frames)
 local f = 0
 return function()
         f += 1
         if (f>frames) f=1
         return f
        end
end

here i have a function FRAME_LOOPER that takes a number of frames. it creates a local variable f and then returns an anonymous function that when called returns that local variable f. we can now make a variable that uses a frame_looper as a counter.

beat_counter = frame_looper(10)

now in my _update function i can just call beat_counter() and i'll get back a number from 1-10 depending on how many times the function has been called. rather than having to declare some random variable and set and increment it every update, that local variable f that was enclosed in the anonymous function gets generated every update.

i'm still new to all of this, but i was able to use the technique for two other parts of my code that also work on a counter like this.

function drum_beater(accents)
 local i,s = 0,0
 return function ()
    i += 1
    if (i > #accents) i=1

    if accents[i] then
      s=0
    else s=1 end   
    sfx(s)
 end
end

accent1 = {true,false,false,false}
drum = drum_beater(accent1)

--[[ moonbeat:
used in _draw to flicker the
moon sprite]]--
function moonbeat(b)
 local moon = {x=80,y=40,
               r=8,col=10}
 return function()
         if b == beat_frame then
          moon.r = 10
         end
         return circfill(
           moon.x,moon.y,
           moon.r,moon.col)
        end            
end

moon = moonbeat(0)

[ Continue Reading.. ]

I couldn't help myself, naming the title that; just thought it was too much of a cliche to miss.

Anyways, my name is Rollerstar and I am an Australian Indie Dev!

In the coming weeks I will be doing my final exams for secondary school! (Yea I'm pretty young...)

So on the balance of study and play, I will hopefully be working on a few exciting projects :P

I only discovered PICO-8 about a week ago, I was on itch.io looking for web games when I came across several titles which all had the same start screen. Originally I thought this must be included in all the games because of all the game jam they were participating in and after a quick google search, I couldn't find anything.

However eventually I stumbled upon this 'fantasy console' and I've been intrigued ever since, I think the whole thing is frikkin awesome and I cannot wait to delve into this new and exciting world!

So I guess if you're interested in seeing what I come up with, keep your tabs open and maybe, eventually.... I'll have something to show!

Glad to be a part of this community and see you all soon :P

Rollerstar[i]

[ Continue Reading.. ]

Now that I'm remembering code I wrote on other computer platforms (ow my head !) I am reminded of one unique feature that the Commodore Amiga 1000 had, and that was HARDWARE SPRITES.

Yessirree, I did not remember until now, just how powerful these little things were.

You had 16 of them, they used color sets 17-19, 21-23, 25-27, and 29-31. They could be any size vertical but only 16-pixels across. Not very exciting in itself, but let me explain.

In the Commodore Amiga, you could use one of these hardware sprites and it would appear on top of graphics. No, that's not correct. They would appear on TOP of graphics. That is, you did not plot them, you INVOKED these sprites, and when you did, when you changed their position, for instance, the background of what was beneath them was always remembered and untouched.

In the Commodore Amiga, you could give a hardware sprite an acceleration, that is, you could give one say AX+=.1 and AY=0 and it would creep to the right across the screen, but ALSO continue to creep even after you stopped running your code.

Curious little things. With the many ignored suggestions, I'd like to add this one, that PICO have the ability of being able to work with 16 "hardware" sprites. However, instead of being limited to 8 or 16-pixels across, you can choose the number of tiles it works with.

It also would not have a limited palette but be able to use the full 15-color set (with zero to show background through).

The advantage of this would be clear. You could invoke these sprites and not have to worry about "cleanup" behind when they moved off of an area. By giving them an acceleration, they would continue to move and not need code to continuously "push" it.

Additionally, you could not READ these sprites. That is, if you had a solid black screen and you invoked a sprite, say 8x8 that was white to appear in the top-left-hand corner, reading directly the pixels there would STILL be black, as these "hardware" sprites have their own invisible layer and would not be read by PGET().

MHWSPR(n,x,y,h,v) Make HW Sprite ID #n from tile set position x,y size across h and v down
RHWSPR(n) remove HW Sprite ID # n
HWSPR(n,x,y,a,b) move sprite #n to pixel x,y or, if zeroes, a & b are acceleration with real numbers.
s=(HWSPRCOL(n)) return 0 if no collisions or ID # if collided into other HW sprite

Collision checking is done by overlapping pixels, not area.