I can get Windows, Linux and Raspberry updates but what about PocketCHIP?
My mobile development platform can no longer run a lot of the newly published games :[
24 comments
Back 30 years ago, After Burner and Thunderblade ruled the arcades.
As a kid, I only had an Amiga and near zero coding skills to produce very (very) weak clones.
Now a seasoned programmer with the mighty power of PICO-8, I can beat a Sega X board!
Well, err...:
Credits
• Chris Butler (player + tank sprites lifted from the C64 1989 version)
• gamax92 for midi to pico-8 program
• dw817 (david w) for image decompression code (http://writerscafe.org/dw817)
• pico-8 community
What's Missing
• gameplay tweaking...
• levels 2,3,4,5
• gazillions of buildings on screen!
Tech Details
Map:
Drawn using sprite sheet (2), you can tweak the level using colors:
4: tank
6,7,13: building
8: enemy helicopter
9: Battleship boss
10: swtich to chase mode
11: switch to top-down mode
15: end_game (use carrefully!)
Title screen:
Title image is loaded from a stringified image, decompression done 'asynchronously' with yield.
Main screen:
Buildings are mostly drawn with many rectfill using a big checkerboard pattern to simulate windows/floors.
Everything is z-sorted (w actually ;) before being drawn. This 'zbuffer' is in charge of drawing every asset.
Game screen manager:
A light version of what I've extensively used during my XNA period. Allows nice decoupling between game loop and other loops (title, game over).
Coroutines:
Used only for rare events (like player dying) to easily control animation and state changes.
Lessons Learned
• PICO-8 is a fantastic platform. Forces you to keep things simple (say that to my dozen or so failed Unity attempts...)
• token count is everything
• Coroutines are unfortunately too slow to be used in the core game loop
• Throw OOP techniques out. The nice class:method() construct eats up too many tokens - had to rewrite half of the code to stays within the limits :[
• bnot-cheating the platform is way too easy (but resisted against!)
• Did I say token count is everything?
Working on my game, I often find myself wondering how much cpu such or such construct uses.
I do my benchmarks using stat(1).
Issue is, my measures are all over the place according to the number of samples :[
Ex: Let's bench band vs. % and shr vs / @ 100 calcs/update
Good, % is almost free, / is slightly better than shr
Let's try 200:
Hu? shr is now better than /
Push it to 300:
Back to "normal"
400:
WTF?
How come number of samples for a given run is turning results upside down?
Note: if I push number of iterator further, I tend to have stable results - but who's performing 5000% per update cycle?!?
On top of that, @zep, we should be provided with op cost of basic operations (similar to cpu specs).
Reference code:
function bench(name,n,fn)
local t0=stat(1)
for i=1,n do
fn(i)
end
return {name,(stat(1)-t0)}
end
function stat2pct(s)
return flr(1000*s)/10
end
function bench_draw(name1,stat1,name2,stat2,y)
print(name1.." vs. "..name2,1,y,7)
y+=6
local total=stat1+stat2
local pct1,pct2=stat1/total,stat2/total
local c1,c2=8,11
if(stat1<stat2) c1=11 c2=8
local x=flr(128*pct1)
rectfill(0,y,x+1,y+6,c1)
x+=1
print(stat2pct(stat1),x/2,y+1,0)
local x2=128*pct2
local msgx2=x+x2/2
if(x2<1) then
x=127 x2=127 msgx2=120
end
rectfill(x,y,x+x2,y+6,c2)
print(stat2pct(stat2),msgx2,y+1,0)
y+=8
return y
end
local res={}
local n=100
function _update60()
if(btnp(0)) n-=100
if(btnp(1)) n+=100
n=max(n,100)
res={}
add(res,bench("band",n,function()
j=band(546,127)
end))
add(res,bench("%",n,function()
j=546%128
end))
add(res,bench("shr",n,function()
j=90/8
end))
add(res,bench("/",n,function()
j=shr(90,3)
end))
end
function _draw()
cls(0)
rectfill(0,0,127,6,1)
print(n.." iterations - \139\145 to change",1,1,7)
local y=9
for i=1,#res,2 do
y=bench_draw(res[i][1],res[i][2],res[i+1][1],res[i+1][2],y)
end
end
|
