Log In  
Log In  
BBS > Lexaloffle Community Superblog
This is a combined feed of all Lexaloffle user blogs. For Lexaloffle-related news, see @zep's blog.

All | Following | PICO-8 | Voxatron | General

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!

Cart [#efficient_outline-1#] | 2019-01-22 | License: CC4-BY-NC-SA | Embed

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.

P#61115 2019-01-22 22:38

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!

P#61091 2019-01-22 14:59

Cart [#zinmtamu-0#] | 2019-01-22 | License: CC4-BY-NC-SA | Embed
2

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

P#61085 2019-01-22 07:36

Cart [#fasudabewi-0#] | 2019-01-22 | License: CC4-BY-NC-SA | Embed

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.

P#61083 2019-01-22 04:54 ( Edited 2019-01-23 01:35)

Cart [#paperdalseifluffyfashion-0#] | 2019-01-22 | License: CC4-BY-NC-SA | Embed
2

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
P#61080 2019-01-22 01:31 ( Edited 2019-01-22 01:35)

Cart [#podimikesi-0#] | 2019-01-21 | License: CC4-BY-NC-SA | Embed

P#61076 2019-01-21 22:16

@zep

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.

P#61062 2019-01-21 11:38 ( Edited 2019-01-21 15:02)

Cart [#dasohitoda-2#] | 2019-01-21 | License: CC4-BY-NC-SA | Embed
1

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!

P#61061 2019-01-21 06:58 ( Edited 2019-01-21 07:03)

Cart [#staticbrick-2#] | 2019-01-21 | License: CC4-BY-NC-SA | Embed

Z - Start Game
X - Make the ball go a little faster

P#61060 2019-01-21 04:03

Cart [#kaylasbreakout-1#] | 2019-01-21 | License: CC4-BY-NC-SA | Embed

P#61059 2019-01-21 03:55 ( Edited 2019-01-21 04:03)

Cart [#brickbreak-0#] | 2019-01-21 | License: CC4-BY-NC-SA | Embed
1

P#61058 2019-01-21 03:54

Cart [#yorofojiso-0#] | 2019-01-20 | License: CC4-BY-NC-SA | Embed

Beginning of a version.

P#61053 2019-01-20 23:31 ( Edited 2019-01-20 23:33)

Cart [#betayumewa-0#] | 2019-01-20 | License: CC4-BY-NC-SA | Embed

P#61049 2019-01-20 21:58
P#61047 2019-01-20 20:28 ( Edited 2019-01-20 20:51)

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?

P#61046 2019-01-20 20:02

Cart [#breakoutgame-0#] | 2019-01-20 | No License | Embed

P#61038 2019-01-20 18:01

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?
.
.
.

Cart [#hermo-0#] | 2019-01-20 | License: CC4-BY-NC-SA | Embed

.
.
.

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
P#61033 2019-01-20 17:33

Cart [#fahidajegu-0#] | 2019-01-20 | No License | Embed

P#61032 2019-01-20 17:00

Cart [#mumodoyuye-1#] | 2019-01-20 | License: CC4-BY-NC-SA | Embed

P#61024 2019-01-20 07:23 ( Edited 2019-01-20 07:23)

Cart [#zosohatoko-0#] | 2019-01-20 | No License | Embed

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.

P#61022 2019-01-20 06:50 ( Edited 2019-01-20 06:54)
View Older Posts
X
About | Contact | Updates | Terms of Use
Follow Lexaloffle:        
Generated 2019-01-23 03:29 | 0.180s | 4194k | Q:205