Strange graphical artifacts when drawing canvas to itself?

[DustyAtticGames]

This is probably something stupid that I'm doing wrong.

Essentially what I'm trying to do is make a canvas for background tiles. I want to draw the visible tiles to the canvas, then when the user moves, I want to shift the cached canvas (drawing it to itself but shifted) and draw any newly visible tiles.

It seems to work fine, the problem is that when I move my character around, I start to see these artifacts (see the screenshot). Anyone have a suggestion for what I might be doing wrong?

screenshot.jpg (41.98 KiB) Viewed 3333 times

Thanks,
Bryan

[Nixola]

Don't ever draw a canvas on itself. The most likely result is graphic glitches.
I noticed some other things. For example, the line 11 can just be

Code: Select all

return (keyBindings[key])

Because this way, you're not hardcoding anything: if you later want to change key bindings you can just change them in the table above, without having to change this line too,

[DustyAtticGames]

Hey, thanks for the suggestions. Can you recommend another way to achieve what I'm trying to do? Basically I want a cached canvas of drawn tiles. When the user moves I want to draw more tiles onto the cache. Finally I want to draw the cache to the screen to limit draws per frame.

[Nixola]

I have a couple solutions:
1) just use two canvases and swap them after you're done (which I'd call a quick hack and possibly a memory hog)
2) switch to [wiki]Spritebatch[/wiki]es. It won't limit the actual draws per frame, but it will do them all in C, resulting in vastly improved speed.

[DustyAtticGames]

Great, thanks for the ideas! I'll do a POC with both and see if it solves the problem.

[I~=Spam]

It won't limit the actual draws per frame, but it will do them all in C, resulting in vastly improved speed.

Unless LOVE handles them differently (and if this is the case then it is not actually a spritebatch and there won't be any performance boost), SpriteBatches do reduce draw calls but this is not because it is done in C. All LOVE graphics calls are done in C and directly call OpenGL. Each draw call has a lot of overhead. So graphics hardware creators added hardware support for batching. This allows for objects using the same shaders, materials, textures, etc. to be drawn all at once in a single draw call for each set of similar sub-draws.

So again, this speedup is because the graphics hardware is picking of the slack not because of C. No program (that runs on a standard processor ie. not a GPU), can compete with the performance added by hardware accelerated graphics. Graphics cards are designed very differently than a typical processor. Often graphics cards have hundreds of cores/threads (sometimes thousands I think) specifically designed for 3D math.

[Nixola]

Maybe I was referring to the "old" or "fallback" spritebatch, which shouldn't even exist anymore; if you did every draw call in Lua (as in lg.draw(tile, x, y)) it would add a LOT more overhead, because each call would cross the Lua/C barrier (which is costly). If there's actual hardware support (which is always the case, with the minimum requirements LÖVE now has) it's even fasterer, as you say. Thanks for the correction by the way! As a wise man just said, you learn something new every day

[I~=Spam]

Lol I wonder did just say that....