Incorrect AutoTile IDs

[MarianoGnu]

When importing a game from RPG Maker 2000 deep water corners looks incorrectly.
When importing a game from RPG Maker 2003 some deep water corners tiles are not detected by Editor and not rendered at all.

Both cases must be checked in theirs counter-versions.

[Ghabry]

also the map rendering code is extremely slow when you load bigger maps like Yume Nikki & Fangames.

I'm considering to just replace the whole renderer with EasyRPG Player Tilemap code. This one is at least confirmed to be bugfree (except for FastBlit which is no problem here *g*).

[mateofio]

In general I'm in favor of making Player a dependency of editor, and reusing some of the code directly where it makes sense to do so.

Then we'll have one codebase we can test and reuse. Also doing this will force us to refactor player interfaces to be more reusable, testable, and standalone, like the recent algo refactor.

Maps and battle animations are the first things that come to mind

[Ghabry]

First: There are lots of use cases where using Player would be useful, think e.g. of a proper Interpreter Debugger integrated in the editor, for this you need an entire game engine to execute it.

For anything considering accessing Player from Editor the Player needs at first a way to be easily created and destroyed and actually it should be possible to have more than one Player active at once.
For Video/Audio/Input the Editor could provide an "EditorUi" object (like SDLUi etc).

What I think of: Instead of "Player::Init" you instantiate a "PlayerInstance" object. Multiple PlayerInstances are possible, all with there own state (Save data, databases can be shared)). For tear down you delete the object.

Though the design for this "Player object" is on you @fmatthew5876 I'm not really motivated to approach this ^^

[mateofio]

There's a few use cases I see really

• Reusing player logic for complicated things like tile mapping - Refactor out globals, just call functions or create / destroy isolated class instances directly in editor.

For this, what we can and should do is isolate the interfaces we want to reuse from global state using dependency injection. This also helps with making Player itself unit testable. More refactors like the Algo library for this.

• Actually running player game engine embedded in Qt and somehow allowing live editing and debugging - Requires engine globals

To be able to start and stop player within editor itself, yes I agree we need a very clean creation and destruction sequence that doesn't leak any global state between runs. We need this anyway for load game and player unit tests.

That being said, I wonder if IPC is also the way to go here. Then you could run a separate player binary and attach the interpreter debugger and other tools to it. We also again don't need to worry about player global state at all. Each player run starts and exits a new process for 100% guaranteed cleanliness.

The IPC approach would require us to add stuff to player to pipe the necessary data back and forth, as well as a protocol for the game strate (enhanced LSD?). That can be a lot of work but it would enforce a clean separation. If we did this though, it also opens the door to additional capabilities for regtesting and other introspection tools.

The biggest amount of work with doing IPC / networking is the serialization code, but we already have liblcf giving us a fast binary protocol.

If we don't go the IPC route, I would want to still see a very clean separation. Let's not pollute Player with random // needed for editor hacks.

Not going to IPC route would allow a much tighter and easier integration with edtior, and allow live editing while playing, which could be a big productivity booster for developers.

• Running multiple editors / players for different games at the same time - use IPC

To run multiple editor instances for different games at the same time with their own embedded players, I would only do it by spawning multiple processes. Then we don't need to worry about player globals, ui globals, renderer state, audio state, etc.. etc... If needed a parent UI process can manage all the child ui instances. Trying to manage all the global state ourselves, especially for all the backend third party libraries I'm 99% sure will end up in frustration and failure, not to mention massive complexity. This also completely shields us to state cleanup bugs from multiple editor/player instances.

For Video/Audio/Input the Editor could provide an "EditorUi" object (like SDLUi etc).

If we embed a running player directly into editor widget, we'll need this.

Options are:

1. QtWidget Ui to replace SDL - if player is in process
2. IPC Ui, which just pipes the framebuffer onto IPC channel, and editor picks this up and renders it into it's widget, with potential debug overlays - if player is out of process
3. Do nothing - if player is out of process, we can just run it in windowed mode using native SDL and have the editor debugging tools separate widgets.

Though the design for this "Player object" is on you @fmatthew5876 I'm not really motivated to approach this ^^

Regardless of editor, this is in my near term future plans. I want to make sure new game / load game bugs are impossible.

We're very close to being able to stand up and tear down player game instances. Once the character PR goes in I'll be unlocked to refactor the player global state to achieve this.