Log In  

Cart #34557 | 2016-12-31 | Code ▽ | Embed ▽ | License: CC4-BY-NC-SA
1

Think I found a bug while poking around at trifill related stuff...

If you give the Y co-ords to RECTFILL upside down (so that Y1 is a greater number than Y2), it seems to cost 0 CPU.

Here I am drawing 42 large RECTFILLs to screen in this manner. If you press Z/O, it will draw them with the Y values swapped, showing about 150% CPU usage instead, as you'd expect.

P#34558 2016-12-30 21:42 ( Edited 2017-04-09 10:24)

"If you give the Y co-ords to RECTFILL upside down (so that Y1 is a greater number than Y2), it seems to cost 0 CPU."

Shhhh, don't tell him! :P

P#34560 2016-12-30 22:10 ( Edited 2016-12-31 03:10)

We had a good run.

I'm fearing that there's gonna be a spike in the CPU usage of this project I'm working on cos I've been relying on this without realising it. May as well get it over and done with rather than being surprised about it later...

P#34565 2016-12-30 22:42 ( Edited 2016-12-31 03:42)

same thing left/right. I guess there's a (x1-x0)*(y1-y0) to count pixels or something.

here's a snippet to know where you stand until this is fixed:

---[[
orf=rectfill
function rectfill(x0,y0,x1,y1,col)
 if (x0>x1) x0,x1=x1,x0
 if (y0>y1) y0,y1=y1,y0
 orf(x0,y0,x1,y1,col)
end
--]]

there's a little overhead (0.06 on solar's cart above). well, that means a little gain once it's fixed ;)

P#34593 2016-12-31 09:29 ( Edited 2017-04-09 10:31)

Oh, nice one, thanks!

P#34602 2016-12-31 11:11 ( Edited 2016-12-31 16:11)

Good catch. Unfortunately it turns out most of the rasterizer routines in that thunderdome thread are affected by this to some degree.

Also be careful with that workaround - using:

color(n)
rectfill(x0,y0,x1,y1)

will draw a black rectangle, no matter which colour you set previously. Removing the parameter fixes this, but you may need to add separate functions to support both use cases.

P#34619 2016-12-31 16:41 ( Edited 2016-12-31 21:57)

According to my test, the bug is even more bad. In fact, rectfill of 1 px width or 1 px height doesnt cost anything either. You start paying a cost only for each additionnal lines beyond the first, if you put the coordinate in ascending order. So that means line-by-line rasterizer should not change cost when swapping coordinates, but if Zep add some cost for the first line, it will hurt every rasterizer code.

P#34630 2017-01-01 02:45 ( Edited 2017-01-01 07:45)

@Catatafish: I thought the missing parameter would pass through as nil, but vanilla rectfill(x0,y0,x1,y1,nil) draws in black...
here's a better version then:

---[[
orf=rectfill
function rectfill(x0,y0,x1,y1,col)
if (x0>x1) x0,x1=x1,x0
if (y0>y1) y0,y1=y1,y0
if (col) then
    orf(x0,y0,x1,y1,col)
else
    orf(x0,y0,x1,y1)
end
end
--]]

doesn't help for the 1px issue though. maybe use line() instead? will rectfill() end up on par with it?

maybe zep could keep rectfill somewhat faster, on account of some fantasy gpu?

P#34653 2017-01-01 07:12 ( Edited 2017-04-09 10:17)

Bumping this just in case zep missed it.

P#39037 2017-04-03 10:10 ( Edited 2017-04-03 14:10)

@ultrabrite: You can also use lua's "..." operator to accept "zero or more" parameters. If no fifth value is passed to rectfill(), then no fifth value will be passed to orf().

orf=rectfill
function rectfill(x0,y0,x1,y1,...)
if (x0>x1) x0,x1=x1,x0
if (y0>y1) y0,y1=y1,y0
orf(x0,y0,x1,y1,...)
end
P#39176 2017-04-08 00:47 ( Edited 2017-04-08 04:47)

@LRP: ah yes, that's neat!

P#39443 2017-04-09 06:24 ( Edited 2017-04-09 10:24)

[Please log in to post a comment]

Follow Lexaloffle:          
Generated 2024-03-28 20:49:54 | 0.020s | Q:32