Build internal level editor

[Lgt2x]

Pull Request Type

• GitHub Workflow changes
• Documentation or Wiki changes
• 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]

The proper type is const char* const but this could totally be made into a std::array of std::string_views. Use of the extern keyword here is invalid as extern indicates the symbol is declared elsewhere.

[Lgt2x]

I modified the qualifier. For the sake of pushing minimal changes for the editor in this PR I did not convert to std::array, but it's a good future improvement

[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

[Lgt2x]

This is now ready for review for anyone interested. To sum up the changes made to get the editor to compile:

• un-const some functions that edit strings
• fix struct definitions
• added a 64bit compatibility layer for incompatible MFC defines
• disabled code paths that are missing some functions defined in missing files (may be enabled later if we can match with D3Edit)
• StdAfx.h fixes inspired by jmarshall's
• backport of some fixes made in the rest of D3 code
• make the editor use some Debug code paths, because in many places it supposes that it has been compiled in Debug mode. Maybe Release mode was never intended for the editor

[Lgt2x]

I modified the qualifier. For the sake of pushing minimal changes for the editor in this PR I did not convert to std::array, but it's a good future improvement

[Lgt2x]

It's not a very ideal or optimized solution because many source files need to be build twice. In many cases, the EDITOR define changes compilation units. I have not found a better solution so far that does not involve heavy changes to the D3 module system, I'd say we can keep it this way until the editor is in a less "experimental" state

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

[Arcnor]

I've done a first pass, but there is a ton of code removed, and I'm not sure if it's needed or not.

[Arcnor]

Like a few other files, this whole file is full of removed code, is the editor still working with all of this removed?

[Lgt2x]

this first PR is about building it, runtime correctness will come later. These deactivated parts don't seem necessary, Justin's fork disabled them as well

[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]

@Arcnor thanks for the review, I fixed or commented back on your comments, feel free to merge if it looks good enough

[Lgt2x]

this first PR is about building it, runtime correctness will come later. These deactivated parts don't seem necessary, Justin's fork disabled them as well

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