MWEdit

[Spastic Hamburger]

Not really. Ideally, that kind of thing needs a native environment or you could get weird results.

I’m not really seeing much in the commit log. Even the changes necessary to the Windows API and for C++20 compliance look relatively benign so I’m not sure why it works in 0.6.3 but not in 0.7.0. Right now, the best I can say is that the ongoing overhaul should fix it as that will pretty much rewrite most of the internals and replace the GUI.

Haven’t thought about it too much, been busy with other tasks. We could simply replace the list with a standard open file dialogue box that other programs use. If we want to keep it, we’ll definitely want to fix it to actually search in the path specified by the settings window (why it was written otherwise is beyond me). That could be fixed by simply passing the path variable to it, will check on that. There’s also a third, more complex option: implement project workspaces where each workspace saves a list of plugins to filter out based on configuration. Many new land projects have a set grouping they work with, for instance.

[DeVaultSetter]

In most cases (for me at least) 0xc0000005 emitted by the VS debugger gives a pretty good indication of the source in the code of the invalid memory write. YMMV. 🙂
Yeah it’s a funny one, pathing back then was limited by issues such as 8.3 filenames and the like, so I think Dave was motivated by dealing with the “root” path for Morrowind, and not worrying about anything else. Fortunately, things have moved on since then. 🙂
Sounds an interesting range of options. 🙂

[Spastic Hamburger]

Looks like we can turn on experimental Unicode support by just setting up the _UNICODE and UNICODE macros in CMake and replacing the DevIL libraries with the Unicode versions. The code already has checks for those to use the wide-character version of TCHAR (it may be done in the Windows API already but I haven’t gotten there yet) if the macros are present. Will add it to test list at some point.

At the basic level, we could have config files that simply list the files associated with a project and then have a separate list-view for each. Wouldn’t be hard to implement for someone more familiar with GUI programming. After the windows are set up, you’d simply populate them with a loop, going until you reach EOF.

Working on more cleanup tasks now. Adding missing includes and splitting up headers into headers and source files. We’ll need to look at replacing NULL with nullptr and nullptr_t once we learn the differences.
A bit slow-going due to the nature of hunting down all of the include nesting. Worth it, though. When it’s done, we’ll be able to see at a glance where all of the symbols are coming from, making things easier to work with.

Putting the loading troubles on the back-burner for now as I can’t see anything in my changes that would have caused the problems (I even did a deep dive into the project files (both the old VS project files and the vcxproj files) and didn’t see anything that I missed), unless it has to do with the DevIL changes. Which is quite possible as we may be using an incompatible version and I never did hear back from NimrodPSI or rfuzzo about their changes after we got the initial permissions to edit their code.

• This reply was modified 5 days, 14 hours ago by Spastic Hamburger.
• This reply was modified 5 days, 14 hours ago by Spastic Hamburger.

[Spastic Hamburger]

Almost got the includes sorted out for the Containers library in common. We’ll definitely want to review the directory structure at some point. We can do that now or later, doesn’t really matter when. If we do it later, though, that’ll mean I’ll need to adjust some include paths again. Will already need to do that anyways since I had to add the directories to them when I was setting up the build script

Regarding the containers library, I’d like to remove it in favor of the containers in the standard but we’ll need to see how they compare first.

Additionally, I’m adding some notes about other tasks that need doing, such as namespacing stuff that replaces things in the standard library and swapping out the byte typedef for std::byte

And here’s the full diff of stuff that changed between 0.6.3 and 0.7.0 if you want to take a look and see if anything stands out.

[DeVaultSetter]

Sounds good. The compare list for the changes is really neat – tried reversing the order for newest first – it’s up to date. 😛
Ok, asked about options – no – really helpful over there btw. 🙂
The two-dot compare is massive with overflow on display limits no doubt.

[Spastic Hamburger]

Most of those are readability changes: a lot of unneeded comments were removed as they were just clutter, for instance. There are some functional changes but the trick is to determine what in the diff broke things. Maybe you’ll see something that I missed 🙂

How does the two-dot version differ? To me, things look the same. 😛

Think I’m done with the Common container library but I want to give it another look before I commit it in case I missed something. I’m also tempted to enable dev builds just to help with testing, CI limits be damned

Once that’s done, I may open a new issue for the directory layout so that we can start figuring out what to do with it 🙂

• This reply was modified 13 hours, 13 minutes ago by Spastic Hamburger.
• This reply was modified 13 hours, 9 minutes ago by Spastic Hamburger.

[Author]

Posts