Resolved
Help!
I recently made this little function to show the map at any size.
However, I am not satisfied with it. It does not represent decimal sizes properly,
(those weird breaks in between) it does not show any width/height except 16/16.
Also, looking back over my code, I am pretty sure it could be done better.
Any help or suggestions welcome.
Add scrolling to this, loan_wulf and you're all set !
To have the grid appear perfectly every time, force the grid to appear for that size. Curious - I am working on something exactly like this right now. Not a mapper though, but the grid ability.
To zoom with decimals I'd suggest using tline rather than sspr.
I did a cart previously to zoom the map but I wrote it with zooming in and out during gameplay in mind.
https://www.lexaloffle.com/bbs/?tid=40671
You should be easily able to adapt, if you wanted to.
@dw817 I understand the post to say that the grid is an undesired side effect.
Tline gets rid of the breaks @SquidLight, however, it runs at 25% CPU.
I need something that can do to 10-16%. Do you have a way of
increasing the efficiency of your mapper?
Pico8 is about trade-offs.
Using 25% to render, say, 80% of the game board is actually a very good deal.
What is that 10-16% target? what else do you have that would eat 80+% of the cpu??!
You said it, the issue is decimal sizes. Say at size 8, your sspr() draws 8x8 pixels. At size 8.5, sspr() still draws 8x8 pixels, but somehow you draw the next one at pixel 9. Actually there's no point in decimal sizes the way you render the map, it would be the same at 8 and 8.5. Or, you'll have to approximate your block size individually to compensate for the decimal. For instance at 8.5, render odd blocks at size 8, even ones at 9. At 8.25 you would go 8,8,8,9. Now if you want 8.17, keep a decimal error that you'll propagate between blocks and compensate when drawing with nearest integer size (tline() would do that for you)
Water @freds72.
When nearly the entire screen is covered with water, CPU is at ~80-85%.
I could redo the water, I was just hoping for a solution that kept the waves.
Thanks for the suggestion @ultrabrite. I will try it out.
80%???
how many full screen layers are you drawing?
would be good to see code…
The code @freds72.
'''
function wave(gx,gy)
for a=gx,gx+15 do
for b=gy,gy+11 do
if gf(a8,b8,32) or gf(a8,b8,16) or gf(a8,b8,64) then
for x=a8,a8+7 do
local yp=sin(x/8+time()0.9)/1.5+cos(x/6)+(b8)
local yp2=cos(x/8+time()0.9)/1.5+cos(x/6)+(b8)
if pget(x-gamex,yp+6-gamey)==12 or pget(x-gamex,yp+6-gamey)==1 then
pset(x-gamex,yp+6-gamey,sget(pget(x-gamex,yp+6-gamey)/7,0))
end
if pget(x-gamex,yp2+2-gamey)==12 or pget(x-gamex,yp2+2-gamey)==1 then
pset(x-gamex,yp2+2-gamey,sget(pget(x-gamex,yp2+2-gamey)/7,0))
end
end
end
end
end
end
'''
@loan_wulf. If I am understanding this correctly.
You making use of SIN() and COS() to animate the water ?
How about just having 8- or so pre-rendered tiles animate instead like RMVX does it ? Will cost a whole lot less CPU.
TO LOAD THIS CART in immediate mode, type:
load #water4x_animate
Here is a water animation using only 4-tiles. You note that unlike previous mapper games they do not have the water animate precisely the same for every tile - this gives you a bit of visual diversity to the map.
Uses 13-14% of the CPU.
There are actually many different ways you can animate these tiles so there is no distinct pattern to them when seen clustered together.
that explains!
pico simulated cpu cannot do that many per-pixel operation (math or drawing)
dw solution is good - another approach is to update a single sprite (or a group) with the wave (via sset) and then use a standard map call to draw them on top of the world
@Loan Wulf You may be able to optimise some of your code for speed. I think however writing to the spritesheet is probably easier.
Is there any chance that you show what your water animation looks like to get an idea.
Your code nests three levels deep so the inner code runs 16128 times if the if
statement passes.
pget isn't the fastest function in the world but you use identical statements in it.
edit
Sorry I didn't see the RESOLVED.
Hi @freds72.
The problem with changing only a single tile and plotting random pixels for it is THIS:
The tile repeats its image and is especially visible where the water collects the most.
Still it uses only 13% so it is a possibility to consider.
Did I say random sset?
:)
Hmm ! That's actually pretty neat, @freds72. And there are enough cycles before it repeats that it's worth doing the method you suggested, via SGET, not to have multiple tiles for water.
I'm pretty sure this could be done without SIN() though, although I'm starting to question my aversion to SIN() and COS().
Is it possible that all values for these functions are precompiled and there is no horrible speed difference as other programming languages have shown in the past in using these functions ?
@dw817 I don't want to talk down to you. But you do know the CPU cost of functions is virtualized right?
Basically Zep choose a cost for the sin and cos functions, their cost in hardware has little to do with this. Pico-8 deliberately doesn't run at native speeds. It can do a set number of for want of better word "CPU tokens" per frame.
https://pico-8.fandom.com/wiki/CPU
Sin and cos use the "standard amount" which from that page is basically the same as a function call.
Well now, @SquidLight, understand the background I come from. Where SIN() and COS() have always had a heavy cost to the CPU in coding.
If SIN() and COS() are as fast as I'm starting to see ... there may be some interesting code I can make with these.
I'm surprised some purists didn't complain that they needed to function slower. :)
[Please log in to post a comment]