Log In  

Cart #smallmapperthingybob-2 | 2022-11-16 | Code ▽ | Embed ▽ | License: CC4-BY-NC-SA
5

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.

P#120657 2022-11-14 03:53 ( Edited 2022-11-16 23:43)

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.

P#120667 2022-11-14 05:27

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.

P#120684 2022-11-14 10:16 ( Edited 2022-11-14 10:26)

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?

P#120783 2022-11-16 01:44

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

P#120789 2022-11-16 06:42

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)

P#120795 2022-11-16 12:21

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.

P#120813 2022-11-16 23:06

80%???
how many full screen layers are you drawing?

would be good to see code…

P#120836 2022-11-17 07:36 ( Edited 2022-11-17 07:37)

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
'''

P#120980 2022-11-19 03:33

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

Cart #water4x_animate-0 | 2022-11-19 | Code ▽ | Embed ▽ | No License

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.

P#120982 2022-11-19 04:14 ( Edited 2022-11-19 19:24)

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

P#120983 2022-11-19 06:58 ( Edited 2022-11-19 06:58)

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

P#120999 2022-11-19 17:55 ( Edited 2022-11-19 17:56)

Hi @freds72.

The problem with changing only a single tile and plotting random pixels for it is THIS:

Cart #pixel_water_animate-0 | 2022-11-19 | Code ▽ | Embed ▽ | License: CC4-BY-NC-SA

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.

P#121003 2022-11-19 19:22

Did I say random sset?
:)

Cart #bugurutewo-0 | 2022-11-19 | Code ▽ | Embed ▽ | No License

P#121014 2022-11-19 21:10

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 ?

P#121036 2022-11-20 02:15

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

P#121058 2022-11-20 09:37

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. :)

P#121062 2022-11-20 13:46

[Please log in to post a comment]

Follow Lexaloffle:          
Generated 2024-03-28 13:16:00 | 0.110s | Q:49