* reccmp: avoid repeated execution of winepath
Executing winepath many times is slow,
so try we like to avoid it as much as possible.
When the path start with a known prefix, replace it with
a cached prefix and do some string manipulation.
This change reduces execution time of reccmp.py from 90s to 2s.
Which is nice.
m
* reccmp: continue looking when source cannot be found
Most often, the reasons is mismatched sources.
* reccmp: add basic logging + optional debug
* Read the addresses in the exe headers as little endian
* 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>
