Build internal level editor

[Lgt2x]

Pull Request Type

• [ ] GitHub Workflow changes
• [ ] Documentation or Wiki changes
• [x] Build and Dependency changes
• [ ] Runtime changes
  • [ ] Render changes
  • [ ] Audio changes
  • [ ] Input changes
  • [ ] Network changes
  • [ ] Other changes

Description

Minimal modifications to get the internal D3 editor to build (Windows only), based on @jmarshall23 's work.

[GravisZro]

It looks like you need to add #include "pserror.h" in editor\d3edit.h

[GravisZro]

Also, if you could review my various small PRs, that would be great.

[GravisZro]

A bunch of missing files that you will need are located over in: https://github.com/DescentDevelopers/D3Edit

[GravisZro]

I'm not sure why people are bent on having an in-game editor but when going this route it would be best to use https://github.com/ocornut/imgui/ to make the actual tool windows. Frankly, I think it would be far better and easier to simply port the existing editor to Qt which works on all platforms.

[Lgt2x]

It looks like you need to add #include "pserror.h" in editor\d3edit.h

Yeah I have some small fixes locally that I have yet to push to fix the remaining builds. This should be still marked as "draft".

Also, if you could review my various small PRs, that would be great.

Sure, that's in my task queue, I'm struggling to get much free time (with an online connection) this week, sorry about that. I'll make sure that you don't get a ton of merge conflicts this time.

A bunch of missing files that you will need are located over in: https://github.com/DescentDevelopers/D3Edit

Thanks, for now it is just a matter of getting the editor to build to unlock modifications of the Dallas-related files (#346, #347), I'll see afterwards for getting it to run properly

I'm not sure why people are bent on having an in-game editor but when going this route it would be best to use https://github.com/ocornut/imgui/ to make the actual tool windows. Frankly, I think it would be far better and easier to simply port the existing editor to Qt which works on all platforms.

I agree that Qt is the way to go to get cross-platform support of D3Edit, I have familiarity with the framework so it should not be too hard if we ever want to do that. Meanwhile I think we should still try reviving the internal editor and provide an option to compile it, at least for historical purposes. It's not a problem if we ever need to drop it.

Thanks for your feedback!

[GravisZro]

After a bit of checking, the non-"new editor" appears to have functions missing that were undoubtedly discarded when moving to make the "new editor".

[bryanperris]

I think the in-game editor would be useful for allowing you mess with D3 like its a sandbox. Yes, I am too on board for the modern dear imgui to be used for the in-game editor UI.

For example, a highly sophisticated one: https://www.cryengine.com/features/view/sandbox

[winterheart]

There DXX-Rebirth Editor exists (very impressive applications based on imgui framework), which can generate D2 compatible levels that can be loaded by D3Editor (our legacy editor, I believe) for additional polishing. Perhaps we can contribute to DXX-R with D3 map support or fork DXX-R editor and adapt it for our needs.

Still, we need working legacy editor to figure out what is miss or what we need to implement.

[bryanperris]

There DXX-Rebirth Editor exists (very impressive applications based on imgui framework), which can generate D2 compatible levels that can be loaded by D3Editor (our legacy editor, I believe) for additional polishing. Perhaps we can contribute to DXX-R with D3 map support or fork DXX-R editor and adapt it for our needs.

Still, we need working legacy editor to figure out what is miss or what we need to implement.

D3 maps are radically different from D1/D2 maps.

[GravisZro]

@Lgt2x the ; at the end of #define In_editor_mode 0; isn't doing the build any favors. :)

[Lgt2x]

The code is a mess but CI builds are all green, will revisit to clean up

[JeodC]

As expected, x64 throws an error for dinput.

The x86 build runs, but the mouse cursor becomes invisible and it becomes almost impossible to exit the application. There is a mouse mode selection in init.cpp which seems to be the problem--the debug build's editor works fine.

Previously, in release builds, mouse exclusive mode was the default since -windowed was disabled for release. With the advent of the editor, this block needs tweaking again. Simply removing the preprocessor definitions should suffice, but that will reintroduce the issue that caused them to be placed: hardware cursor visibility in fullscreen mode in release builds.

[Lgt2x]

Thanks for testing! This PR only aims to fix the build, I did not even expect the editor to start without crashing. Don't hesitate to file an issue about the cursor problem, it looks like an easy enough fix. The editor was supposed to never be built in release mode when you look at the code, I'm not surprised it has runtime problems

[JeodC]

It would just reopen #363.

[GravisZro]

@Lgt2x I'm working on a parser for the "Resource-Definition File" format which is the editor.rc file that defines the GUI layout. Would you be interested in hooking up generated "Dear ImGui" code if I make it? This would make the editor usable on all platforms. The only other robust/well supported alternative I can think of is Qt and that has a lot of dependencies.

[bryanperris]

@Lgt2x I'm working on a parser for the "Resource-Definition File" format which is the editor.rc file that defines the GUI layout. Would you be interested in hooking up generated "Dear ImGui" code if I make it? This would make the editor usable on all platforms. The only other robust/well supported alternative I can think of is Qt and that has a lot of dependencies.

It is not worth the time to be trying to parse .rc files (https://learn.microsoft.com/en-us/windows/win32/menurc/about-resource-files?redirectedfrom=MSDN) and trying generate imgui from it, that is a whole long-term project itself.

I recommend writing a simple imgui C++ app, and begin to mimic the d3 editor UI by hand, mostly its just buttons and list views, besides the 3D viewer of the map, look at the inferno project (https://github.com/nbayazes/Inferno).

RC scripts are compiled into something else, and they can involve preprocessing directives. You aren't going to understand the exact layout without emulating the entire GDI+ system. Who even knows what hacky things has been put into the RC compiler from Microsoft over a decade. I have no doubt it took the wine team to reach a stable GDI emulated system after like 17 years. I know that the RC files are generated by Visual Studio's drag and drop based GUI designer.

[Lgt2x]

@Lgt2x I'm working on a parser for the "Resource-Definition File" format which is the editor.rc file that defines the GUI layout. Would you be interested in hooking up generated "Dear ImGui" code if I make it? This would make the editor usable on all platforms. The only other robust/well supported alternative I can think of is Qt and that has a lot of dependencies.

It is not worth the time to be trying to parse .rc files (https://learn.microsoft.com/en-us/windows/win32/menurc/about-resource-files?redirectedfrom=MSDN) and trying generate imgui from it, that is a whole long-term project itself.

I recommend writing a simple imgui C++ app, and begin to mimic the d3 editor UI by hand, mostly its just buttons and list views, besides the 3D viewer of the map, look at the inferno project (https://github.com/nbayazes/Inferno).

RC scripts are compiled into something else, and they can involve preprocessing directives. You aren't going to understand the exact layout without emulating the entire GDI+ system. Who even knows what hacky things has been put into the RC compiler from Microsoft over a decade. I have no doubt it took the wine team to reach a stable GDI emulated system after like 17 years. I know that the RC files are generated by Visual Studio's drag and drop based GUI designer.

It also looks like a big effort to me as well that may or may not be worth it in the end. You can make a proof of concept if you want to gauge the task and get community feedback first, to see if we want to pursue this further

[GravisZro]

It is not worth the time to be trying to parse .rc files (https://learn.microsoft.com/en-us/windows/win32/menurc/about-resource-files?redirectedfrom=MSDN) and trying generate imgui from it, that is a whole long-term project itself.

Not really because I've done XSL parsing before and .rc files are simplistic by comparison.

It also looks like a big effort to me as well that may or may not be worth it in the end. You can make a proof of concept if you want to gauge the task and get community feedback first, to see if we want to pursue this further

Well since it's generated, it's really an all or nothing proposition but I suppose I'll post something. The hard part in this is learning the imgui API since it's so poorly documented. Qt would be a super easy port, so I might do that first.