* Introduce "configure.py" and "build.py"
* Running "python configure.py && python build.py" will successfully
build a clean clone of the project with no additional effort needed.
* The repo now includes a copy of ninja for each platform, and the
configure script will download MSVC420 for you as part of configuring
the project. You can specify --modern-compiler when configuring to
configure with a different toolchain if desired.
* This also establishes a specific place (/original) for you to put
your original game files. The build process will let you know that
you need to put them there if you have not yet when you ask to
compare to the original game.
* The repo also now includes a .vscode folder by default, which
contains a tasks.json file including the build / configure tasks.
* This includes "build and compare function by cursor" task which allows
a very effective workflow where you just hit Ctrl+Shift+B and get an
updated diff of the function you were just editing.
* break build up into steps
* download artifacts
* clone uploadtool
* need env on windows
* just use ubuntu for inkscape
* report went missing
* add inkscape to path
* use ubuntu for compare
* Revert "use ubuntu for compare"
This reverts commit a4ce103d09.
* reinstall after cache
* try different apt cache
* use im
* use rsvg
* change size to avoid downscaling
* remove png
* do not install librsvg anymore
Now we can use our own compiled LEGO1.LIB rather than one generated from the original. Also implements a script that tests them to help ensure future commits don't break them.
* initial cmake implementation
* ci: i guess older cmake doesn't support this
* cmake: add max version to suppress warning
Co-authored-by: Anonymous Maarten <madebr@users.noreply.github.com>
---------
Co-authored-by: Anonymous Maarten <madebr@users.noreply.github.com>
* Stubbed a bunch of classes and annotated them for later use. Heavily wip and more of pseudocode right now.
* Converted pseudocode into real code!
* Created a bunch more classes and added more information to exisiting ones
Did not error check, this was pushed just for reference
* More classes and implementation details. Still not checked for any errors
* Fixed code and decided on a way to handle virtual table stubs
* Some additional fixes
* More smaller fixes
* Added classes to project and made it compile
* Fixed function adresses that caused the python script to fail
* More classes and virtual function resolves. Builds and compares fine.
* Again more classes and virtual function resolves. Builds and compares fine.
* No clue, I guess forced update for line endings
* Finished up some work, compiles fine. All functions are STUB annotated to not pollute reccmp.py output.
* line ending change
* rename GetClassName/IsClass
Mirroring recent changes from master
* further conform to current master
* update project
* cleanup
* project only updates when you close msdev
---------
Co-authored-by: Cydra <cydra95@gmail.com>
Co-authored-by: itsmattkc <34096995+itsmattkc@users.noreply.github.com>
Followed the hint from @madebr in #31 that the next function in MxString was operator+. The one after that is operator+= and both are at 100%.
Squashed commits:
* Removed unnecessary consts
* Replaced malloc/free with new/delete, which solved swapped regs in operator=
* Use delete[] when freeing char* m_data
Was intended as a simple code improvement, however it also seems to make WinMain, MxString::operator=, MxDSFile::Open 100% (all of which just needed registers to be switched around)
* match WinProc
* minor accuracy improvement
* WndProc at 50%
* fix WM_DISPLAYCHANGE branching
* fix type
* fix x/y comparison
* WndProc 82%
* 84%
* 97%
* rearrange functions to get close to the original
* remove newline
* inline no longer necessary
* merge
* 100% Match of MxDSFile
* ...almost, MxDSFile::Open is still not quite matching but all of the
other methods are 100% matching.
* Turns out that most of the virtual methods and some of the members are
actually on the MxDSSource base class, which I've pulled out as part
of this.
* In order to implement the methods I added the MXIOINFO class, which
seems to be a thin wrapper around the MMIOINFO windows structure. We
can tell this because MMIOINFO::~MMIOINFO was included in the DLL
exports, and calls down to a function which deconstructs something
looking exactly like MMIOINFO.
* Add mxdssource.cpp
* mattkc feedback
* some accuracy improvements
* Use FOURCC macro
* Tirival solve in mxioinfo.cpp
* Update mxdsfile.cpp
0xFFFFFFFF -> -1
---------
Co-authored-by: Christian Semmler <mail@csemmler.com>
