So I was working on making an improved version of "The Story of Zeldo" and realized a few weeks ago that outlining my sprites was taking up more CPU cycles than I wanted it to. I was using the outlining function where the palette is cleared to a color, then 8 sprites are drawn around the actual sprite to produce an outline effect as shown here. I decided to change all the sprites that needed outlines to 10x10 instead of 8x8.
|
[64x64] |
You can see the 10x10 sprites at the bottom right of the graphic. Getting rid of the outlining function like this improved my CPU, but wasted sprite space. I later needed more sprite space, but didn't want to take a CPU hit. Then I thought, what if I use rectangles to draw the outline of sprites instead of drawing actual sprites for the outline?
So that's what I did and I thought I would share. There are two parts to this process. The first is generating the rectangles for all your sprites and caching them at the beginning of the game.
-- 175 tokens
g_out_cache = {}
function init_out_cache(s_beg, s_end)
for sind=s_beg,s_end do
local bounds, is_bkgd = {}, function(x, y)
return mid(0,x,7) == x and sget(x+sind*8%128, y+flr(sind/16)*8) != 0
end
local calc_bound = function(x)
local top, bot
for i=0,7 do
top, bot = top or is_bkgd(x,i) and i-1, bot or is_bkgd(x,7-i) and 8-i
end
return {top=top or 10, bot=bot or 0}
end
g_out_cache[sind] = {}
for i=0xffff,8 do
-- prev, cur, next
local p, c, n = calc_bound(i-1), calc_bound(i), calc_bound(i+1)
local top, bot = min(min(p.top, c.top), n.top), max(max(p.bot, c.bot), n.bot)
if bot >= top then
add(g_out_cache[sind], {x1=i,y1=top,x2=i,y2=bot})
end
end
end
end |
init_out_cache should be called on startup in the _init function, passing in the start and end of the sprites you want outlined. Then the other part to outlining sprites is to actually outline them!
-- 84 tokens
function spr_out(sind, x, y, sw, sh, xf, yf, col)
local ox, x_mult, oy, y_mult = x, 1, y, 1
if xf then ox, x_mult = 7+x, 0xffff end
if yf then oy, y_mult = 7+y, 0xffff end
foreach(g_out_cache[sind], function(r)
rectfill(
ox+x_mult*r.x1,
oy+y_mult*r.y1,
ox+x_mult*r.x2,
oy+y_mult*r.y2,
col)
end)
spr(sind, x, y, sw, sh, xf, yf)
end |
This function just takes the rectangle data created from the init function and draws them as rectangles. A little bit extra logic is needed for xf and yf to work. Using these snippets, CPU efficiency of outlines is better than the old method, but worse than having no outline at all.
Although I thought this was cool, there are four at least four drawbacks to using this method:
- The token count is much higher than the old method (259 tokens instead of 59 tokens).
- The init function is not very efficient, because I went for token count on that instead of efficiency.
- Currently sw and sh are not implemented with this method. So it only works on 8x8 sprites.
- If a sprite is hollow, then the entire hollow region will be filled with the outline color as seen below.
|
[28x23] |
The green arrow is the old method, the red arrow is the new function.
Here is a demo of this sprite outline function in action!
As you can see, drawing 56 outlined sprites with this function saves over 15% of CPU usage compared with the old method!
As far as improvements go, here are a few areas this code could be improved on:
- There are only up to 10 rectangles drawn for each 8x8 sprite, but some sprites could have less rectangles if extra code is added to check for duplicate rectangles.
- Making variable sprite height and width, instead of just 8x8 (aka. sw and sh).
I am going to be using this in my Zeldo game in the future, but I will probably pre-process all the outlines I need and just store the rectangle data to save on token count. Comment if you have improvements for this, if you found this useful, or if you just have something to say. I might do another post like this in the future if I find people read this one :D.
0 comments
Hello!
I am a new clockwork GameShell purchaser and I am very new to virtual systems and hardware. While waiting for my device to ship, I have been researching things that I can play or do on it. PICO8 Has caught my eye, and along with it; Voxatron. I know PICO8 runs well from the forum over at ClockWorkPI, but I was curious if a 3d based virtual system would work just as well; keeping in mind that the GPU on the GameShell is not fully supported at the moment.
Does the GameShell and Voxatron play nicely together?
Will the control schemes, hardware, or software be compatible or enjoyable to play on the GameShell?
Will the full GPU support be necessary to run Voxatron?
Thankful for any info on the matter!
Saw this screensaver again after a while and wanted to give recreating it a shot. It's pretty simple stuff, but it's helped me out learning some of the quirks with Lua.
Sauce: https://gist.github.com/Fortyseven/a4e2d5d3105ed86e0916d162a1a4d466
Yo, here is a version of the next game I'm working on! It's a dungeon exploration game, kinda like a roguelike, but without any procedural generation lol (at least for now). I am still learning so I didn't want to cram too much stuff into it.
Let me know what you think!
Controls: Use the arrows to move. Move in the direction of an enemy to attack.
this is a deltarune paper doll fangame made by me and my brother, CrossroadsWanderer ( @XroadsWanderer)! we started out making a paper doll game unrelated to deltarune, but when we played deltarune together, we became enamored with ralsei, and decided to make it a ralsei dressup game instead. we made this for ourselves, but i hope others will find it enjoyable!
controls
z/okay: wear
x/cancel: take off
left and right: scroll through items
some options are found on the enter/pause menu.
credits
- the designs of ralsei and his default outfit are from deltarune
- the designs of the two hidden items are from deltarune and undertale
- the music composition, "friendship" (which can be found on bandcamp), is from deltarune
everything else was done by us. this includes:
- game design
- pixel art (including our renditions of the aforementioned preexisting designs)
- coding
- music arrangement
I'm trying to write a tool that has text editing, and I find that the devkit keyboard doesn't return a lot of the special keys that it easily could.
You're returning a string, so there's no reason why it has to be just one character. So pressing the Home key could simply return the string "home". No need for special characters, escape sequences, etc., since these verbose names would all be distinct from any single regular typed character.
I'm mainly thinking of the standard navigation cluster: up, down, left, right, ins, del, home, end, pgup, pgdn.
It'd also be nice if there were a second stat() value that had a bitmask of the modifier keys that are currently pressed, if the host has them. Like, left/right shift, left/right alt/cmd, maybe left/right win/opt, altgr, maybe capslock. Not crucial, but definitely helpful. It'd be nice to be able to support things like ^Z for undo in my tool.
I say all this because one of the things I love about PICO-8 is working entirely within PICO-8, so it's nice to write tools that work inside of the platform, but the devkit functionality is a little limited in this department.
You're just chillin' in your lawn chair, sipping a cold lemonade outside your sweet new trailer home when suddenly, HOLY CRAP! A wall of fire blasts out of nowhere! Can you escape this fiery blitz with your life? Run, flap, and flip your way to safety in this short and sweet platformer. You'll dodge spikes and walls and maybe even discover a couple secrets along your way. Good luck and don't end up as a BBQ!
This is my first time utilizing a collision system with floating point values. Let me know if you enjoyed this adventure! I sure loved making it!
Z - Start Game
X - Make the ball go a little faster
Beginning of a version.
I don't know if this is a bug or a debug feature? But when pressing the number 6 while in the designer, it zooms in super huge on the mouse. This is really distracting when coding because it'll flash up huge on the screen if you happen to hit a 6 while you type! 😆 Maybe an option to disable that feature while editing code?
I'm learning to make hitbox collisions (instead of flags collisions).
Vertical collisions seem to work just fine but horizontals don't.
How can this be done?
Maybe hitbox collisions are just to complicated and shouldn't be used?
.
.
.
.
.
.
function _init()
pad_x=45
pad_y=45
pad_width=30
pad_height=30
pad_color=7
pad_speed=3
ball_x=80
ball_y=10
ball_radius=4
ball_color=8
ball_speed_x=2
ball_speed_y=2
end
function _update60()
btnprss=false
cls(1)
--ball movement
ball_x+=ball_speed_x
ball_y+=ball_speed_y
--ball-screen collision
if ball_x<0 or ball_x>128 then
ball_speed_x=-ball_speed_x
end
if ball_y<0 or ball_y>128 then
ball_speed_y=-ball_speed_y
end
--pad movement
if btn(0) then
btnprss=true
pad_speed=-5
end
if btn(1) then
btnprss=true
pad_speed=5
end
pad_x+=pad_speed
if btnprss==false then
pad_speed=pad_speed/2
end
if pad_x<1 or pad_x>126-pad_width then
pad_x=mid(1,pad_x,126-pad_width)
end
pad_color=7
if ball_box(pad_x,pad_y,pad_width,pad_height) then
pad_color=8
ball_speed_y=-ball_speed_y
end
end
function _draw()
rectfill(pad_x,pad_y,pad_x+pad_width,pad_y+pad_height,pad_color)
circfill(ball_x,ball_y,ball_radius,ball_color)
end
function ball_box(box_x,box_y,box_w,box_h)
--conditions where there are no collisions
if ball_y-ball_radius>box_y+box_h then
return false
end
if ball_y+ball_radius<box_y then
return false
end
if ball_x-ball_radius>box_x+box_w then
return false
end
if ball_x+ball_radius<box_x then
return false
end
return true
end
|
This is a work in progress for a midterm. The basics are all there, but the goal, in the end, is to have a single player "snake" like mode, add in some power-ups, work on better hit detection collision when sprites are added, and general cleanup to look more like a SNES game than a basic Atari game.
