When I Change Maps the other map remains on screen and you can walk on it resulting in...weirdNES

How can I change maps without the previous map remaining on screen?

I am using this function to Change maps.

Code: (javascript) [Select]

function Teleport(x, y,map)
{
        ChangeMap(map)
        SetPersonLayer(player,1);
        SetPersonX(player,x*16+7);
        SetPersonY(player,y*16+7);

}

**Facepalm**

I forgot to use

FlipScreen();

sorry 

Code: (javascript) [Select]

function Teleport(x, y,map)
{
        ChangeMap(map)
        SetPersonLayer(player,1);
        SetPersonX(player,x*16+7);
        SetPersonY(player,y*16+7);
        FlipScreen();
}

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

It might introduce a random black flash depending on what you do with it in the future, so I recommend you don't FlipScreen when you don't need to.

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.

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.

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

Here are the details:

Code: (cpp) [Select]

See the end of this message for details on invoking 
just-in-time (JIT) debugging instead of this dialog box.

************** Exception Text **************
System.ComponentModel.Win32Exception: The system cannot find the file specified
   at System.Diagnostics.Process.StartWithShellExecuteEx(ProcessStartInfo startInfo)
   at System.Diagnostics.Process.Start()
   at System.Diagnostics.Process.Start(ProcessStartInfo startInfo)
   at System.Diagnostics.Process.Start(String fileName, String arguments)
   at Sphere_Editor.EditorForm.RunToolButton_Click(Object sender, EventArgs e)
   at System.Windows.Forms.ToolStripItem.RaiseEvent(Object key, EventArgs e)
   at System.Windows.Forms.ToolStripButton.OnClick(EventArgs e)
   at System.Windows.Forms.ToolStripItem.HandleClick(EventArgs e)
   at System.Windows.Forms.ToolStripItem.HandleMouseUp(MouseEventArgs e)
   at System.Windows.Forms.ToolStripItem.FireEventInteractive(EventArgs e, ToolStripItemEventType met)
   at System.Windows.Forms.ToolStripItem.FireEvent(EventArgs e, ToolStripItemEventType met)
   at System.Windows.Forms.ToolStrip.OnMouseUp(MouseEventArgs mea)
   at System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks)
   at System.Windows.Forms.Control.WndProc(Message& m)
   at System.Windows.Forms.ScrollableControl.WndProc(Message& m)
   at System.Windows.Forms.ToolStrip.WndProc(Message& m)
   at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
   at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
   at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)


************** Loaded Assemblies **************
mscorlib
    Assembly Version: 2.0.0.0
    Win32 Version: 2.0.50727.5472 (Win7SP1GDR.050727-5400)
    CodeBase: file:///C:/Windows/Microsoft.NET/Framework/v2.0.50727/mscorlib.dll
----------------------------------------
Sphere Editor
    Assembly Version: 0.9.5.0
    Win32 Version: 0.9.5.0
    CodeBase: file:///G:/Game%20Engines/Sphere/SphereStudio%20v0.9.5/Sphere%20Editor.exe
----------------------------------------
System.Windows.Forms
    Assembly Version: 2.0.0.0
    Win32 Version: 2.0.50727.5468 (Win7SP1GDR.050727-5400)
    CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System.Windows.Forms/2.0.0.0__b77a5c561934e089/System.Windows.Forms.dll
----------------------------------------
System
    Assembly Version: 2.0.0.0
    Win32 Version: 2.0.50727.5467 (Win7SP1GDR.050727-5400)
    CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System/2.0.0.0__b77a5c561934e089/System.dll
----------------------------------------
System.Drawing
    Assembly Version: 2.0.0.0
    Win32 Version: 2.0.50727.5467 (Win7SP1GDR.050727-5400)
    CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System.Drawing/2.0.0.0__b03f5f7f11d50a3a/System.Drawing.dll
----------------------------------------
WeifenLuo.WinFormsUI.Docking
    Assembly Version: 2.3.1.24483
    Win32 Version: 2.3.1.0
    CodeBase: file:///G:/Game%20Engines/Sphere/SphereStudio%20v0.9.5/WeifenLuo.WinFormsUI.Docking.DLL
----------------------------------------
System.Xml
    Assembly Version: 2.0.0.0
    Win32 Version: 2.0.50727.5473 (Win7SP1GDR.050727-5400)
    CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System.Xml/2.0.0.0__b77a5c561934e089/System.Xml.dll
----------------------------------------

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

For example:

<configuration>
    <system.windows.forms jitDebugging="true" />
</configuration>

When JIT debugging is enabled, any unhandled exception
will be sent to the JIT debugger registered on the computer
rather than be handled by this dialog box.

I've been eager to use the new sphere editor otherwise.

Well for one you are using a really old version of the editor. So naturally I'll refuse to help debug your situation, (It could be fixed, who knows?) Oh and the code isn't C++, it's C#

O.K I'll get the latest version and try it out 

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.