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.
"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
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...
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 ;)
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.
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.
@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?
@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 |
[Please log in to post a comment]
