That just *seems* to fix it, but it doesn't. Once you draw anything at all over the blank area, it'll stick on there. It's because your map is smaller than the screen, so Sphere doesn't know what to draw there, so it just draws whatever was already there. Make sure your maps are always at least as large as the screen dimensions.

This kind of stuff also happens when you have transparent tiles at the bottom-most layer. Whatever used to be there will be displayed instead of blackness. Though you can create a neat (unintended) blur effect if you have half transparent tiles on the bottom layer like that.

Yeah I stumbled on that blur effect by mistake but technically its a glitch/bug because its not intended with code but it still looks sweet (^_^).O.K from now on I'll set my maps to 15x 13y. My screen resolution width is 15*16 and height 13*16.

Do do I remove FlipScreen(); from the code or is it harmless to leave it there just in-case...

My Sphere Engine doesn't do that on maps though, it's a good boy and remembers to clear the screen prior to each flip. Why the map engine doesn't do this is beyond me.. perhaps it was an optimization thing: since you are always going to draw tiles over the space of the screen it doesn't have to clean the back buffer: the tiles do it, thus reducing a draw call. However since I use hardware, clearing the back buffer is very fast. Hmm, in SFML, I don't think I have the privilege to not clear the buffer... I wonder if passing a transparent color does the same thing. I'm sure it would.

How about this: my engine will clear the backbuffer to avoid further confusion in this area.

If you use code to help you code you can use less code to code. Also, I have approximate knowledge of many things.

How about this: my engine will clear the backbuffer to avoid further confusion in this area.

But then you'll break games that use the earlier mentioned blur trick! I thought you were aiming for 100% backwards compatibility...

Just kidding. Ideally if a map is smaller than the screen, then what the map engine should be doing is centering the map in the screen and surround it with black. Like how the 2D Pokemon games work when you enter a (tiny) house.

miniSphere 5.1.3 - Cell compiler - SSj debugger - thread | on GitHubFor the sake of our continued health I very much hope that Fat Cerberus does not become skilled enough at whatever arcane art it would require to cause computers to spawn enourmous man eating pigs ~Rhuan

For some reason Radnens Editor wont run my games at all, the directory is in Drive D in my computer. I don't think I have access settings that would limit running a game on drive D becuase I run games there all the time on Emulators, other editors, e.t.c

************** JIT Debugging **************To enable just-in-time (JIT) debugging, the .config file for thisapplication or computer (machine.config) must have thejitDebugging value set in the system.windows.forms section.The application must also be compiled with debuggingenabled.

My Sphere Engine doesn't do that on maps though, it's a good boy and remembers to clear the screen prior to each flip. Why the map engine doesn't do this is beyond me.. perhaps it was an optimization thing: since you are always going to draw tiles over the space of the screen it doesn't have to clean the back buffer: the tiles do it, thus reducing a draw call. However since I use hardware, clearing the back buffer is very fast. Hmm, in SFML, I don't think I have the privilege to not clear the buffer... I wonder if passing a transparent color does the same thing. I'm sure it would.

How about this: my engine will clear the backbuffer to avoid further confusion in this area.

I almost guarantee it was an optimization. When I was still doing software rendering, I found that (when you have double buffering) not clearing the buffers made flipscreen calls take less than 1 ms, as opposed to about 10 ms.