-
Notifications
You must be signed in to change notification settings - Fork 383
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Multi script drawing #3775
Multi script drawing #3775
Conversation
We do not use PolySharp, it seems to be a transitive dependency accidentally added to SharpGen (which is a dep of Vortice). Opened SharpGenTools/SharpGenTools#236. We may be able to downgrade Vortice as a workaround.
You can't do this. The test project is .NET Core and EmuHawk is .NET Framework. I'm also not seeing what part of your
If you can't see what's wrong with this, nothing I say can help you. |
Thanks for your feedback.
It did seem less than ideal to add that reference. (I can do it, it will build and run, but calling certain pieces of code does of course crash.) I'll look into moving the classes as you suggest. Thanks for pointing it out, as I hadn't seen it since the project isn't part of the solution. It seems strange to move code written for tests outside of test projects, though. Might it be better to move them to BizHawk.Tests? BizHawk.Tests.Testroms.GB could add a reference to BizHawk.Tests.
As for making tests that actually use Lua scripts, I do want to do this but am currently unsure how. (Still looking, though.) If you know a good way to do this I would appreciate your input. One of the problems is that, as the code is written right now, we cannot instantiate BizHawk.Client.EmuHawk.LuaLibraries since it requires a reference to a Windows Form. An actual Windows Form, not just stuff on MainForm, for the FormsLuaLibrary (and, of course, a project reference to BizHawk.Client.EmuHawk). I may end up creating a new test project that targets windows. I noticed there's a folder output/Lua/UnitTests. But these don't appear to have any automation. (and don't all even work) |
….Common (to support testing).
…ies to BizHawk.Client.Common (to support testing).
… with the old filename.)
…o LuaLibraries, as part of moving LuaLibrariesBase to BizHawk.Client.Common (to support testing). Remove params that can instead be obtained from mainForm (instead of creating private variables to hold them for reference in code that was moved outside of the constructor). Also remove them from Restart method for consistency in how ApiManager.RestartLua is called.
…ariesBase to BizHawk.Client.Common (to support testing).
…ore sense there. (They had no need of a reference to a LuaConsole.) This also supports testing by removing the need to use a LuaConsole in tests.
…thTwoScripts fails.
db12b97
to
1bb5f9e
Compare
…e bug where if two lua scripts draw stuff on the same frame only one script's drawings are visible. Replaces a bunch of obscure ThisIsTheLuaHack and locking/unlocking code with a simple pair of methods.
I've force-pushed with new commits, this time Lua scripts are run in tests. The first several commits are all refactoring so that the code needed for the test can be moved to BizHawk.Client.Common. There should not be any behavior changes except for commit 0c8ce93. Regarding the SimpleGDIPDisplayManager in BizHawk.Tests.Testroms.GB, that implementation is outdated and does not compile. So I decided not to use it. |
…names (expected, actual)
… in preparation for testing external APIs
…upport testing external tools
…ing around a load callback method. Add TestExternalToolCanUseApi (passes)
d43bfcf
to
712ba93
Compare
I realized that this broke drawing via external tools (which already wasn't working as semi-documented anyway, but another undocumented way). My new commits address this issue by allowing external tools to use the new BeginFrame and EndFrame methods without having to worry if Lua is also running. External tools + LuaConsole tool can now draw on the same frame. It looks like none of the external tools in /ExternalToolProjects used the GuiApi. However one of the ones linked in https://github.com/TASEmulators/BizHawk-ExternalTools/wiki/Catalog does, but it uses the obsolete (and now deleted) DrawNew/DrawFinish methods so hasn't worked for a couple years now. It might be a good idea to update documentation to include a working example of drawing (which may be as simple as forking Ecco_BizHawkTool and replacing the obsolete methods with the new ones and linking to that instead). |
Here's one of my in-development projects which uses |
https://github.com/CasualPokePlayer/PokemonGBTASTool |
Thanks for sharing those. So, I guess we want to keep the old WithSurface behavior to preserve compatibility with these tools and any others people may have made? I just looked at the Lua library and it does not expose the WithSurface method, meaning it's only available to external tools right now. So we should be able to preserve compatibility by putting calls to BeginFrame and EndFrame inside WithSurface, without breaking anything. We could even give it an optional parameter to control that functionality so external tools could still control the calls to BeginFrame and EndFrame (when LuaConsole isn't open at least). @CasualPokePlayer Correct me if I missed something, but the only use of IGuiApi I see in that Pokemon tool is using Gui.Text. That is not relevant here since it goes to the OSD instead of rendering like other methods do. |
IMO, if you're going to change it, it should be to add a † Which I haven't implemented for ApiHawk yet, but plan to. |
…tools unable to draw. This removes the old obsolete methods IGuiApi.DrawNew and DrawFinish (they didn't do anything; any scripts using them already didn't work).
712ba93
to
8bd025d
Compare
Okay, new force push reverts the changes to IGuiApi. There are now no changes to how external tools draw. To summarize, the behavior changes in this PR are:
There is also a fair bit of moving code around and refactoring in order to support the new tests, but this should not have any impact on behavior. Note that drawing from multiple external tools still does not work. All external tools share API instances and the GuiApi class doesn't know who's calling it, so we cannot support multiple external tools without either changing the API usage or giving each external tool its own GuiApi instance. I tested a Lua script making thousands of calls to drawPixel per frame and got the same FPS on both master and this branch so performance seems unaffected. |
Seeing as #2600 has been resolved, can this be closed? |
This pull request fixes #2600.
The first commit (add a reference to BizHawk.Client.EmuHawk) requires removing use of init setters in BizHawk.Client.EmuHawk. I've never encountered this sort of issue before, so I might be missing a better solution.