* Match MxBitmap::vtable+40 (CopyColorData)
It's basically a call to StretchDIBits, which copies color data for a rectangle
* Name a ternary raster op
* Name variable m_unk18 (m_bmiColorsProvided)
Since this variable is passed to StretchDIBits, we can see what its supposed to mean.
We dont have DX5 docs, but we have docs of the current day, and this as its 'iUsage':
"Specifies whether the bmiColors member of the BITMAPINFO structure was provided and, if so, whether bmiColors contains explicit red, green, blue (RGB) values or indexes."
The second part (about what the bmiColors contains) seems redundant, since we know this is a boolean.
Source: https://learn.microsoft.com/en-us/windows/win32/api/wingdi/nf-wingdi-stretchdibits
* MxBitmap::CreatePalette is now up to 60%
* Add progress on MxBitmap::LoadFile, add the global bitmap signature, add Clone call in CreatePalette
* getting closer
* Implement MxBitmap::vtable18
* Got vtable18 into a better state
It's progress doesn't affect the status of CopyColorData, which is
back at 100%, as it makes sense the loop is a memcpy
* if you want to do more of vtable18 have fun
* Cleanup MxBitmap::LoadFile
* Begin work on FUN_100bd450 (ImportColorsToPalette)
This took a lot of time, finally I got a good understanding of it.
Primarily what's left now is the loop
https://hackmd.io/@KsNMFSBHTO2gxDyRIPRQ1g/H1LCVQXon
* Don’t include class name in method declaration
* yolo vtable38 (I can't test the build atm)
I moved up ImportColorsToPalette so other functions, including this one can use it
* Cleanup while i keep getting bored of matching these functions that wont match
* likely malloc is an operator new
* A few things for MxBitmap
* new struct MxBITMAPINFO
* vtable18 and ImportPalette 100%
* ImportColorsToPalette improvement
* Match vtable1c and vtable3c
* use MxResult return types
* CreatePalette - Use MxResult to track success
* Define types for the bit depth
That boolean is not really a boolean, its just a variable to store
the bit depth as some DWORD. 0 = 256 color, 1 = High Color (16-bit).
* Match MxBitmap::CreatePalette
* Match LoadFile
YEGYEEHEEHEHEHEHEHE3 YES THIS IS FINALLY DONE OMFG
* Reorder variable placement in CreatePalette
* Start vtable14
* Match MxBitmap vtable14, down to reg swap.
Maybe some import function?
* Name MxBitmap vtable functions
---------
Co-authored-by: disinvite <disinvite@users.noreply.github.com>
Co-authored-by: Christian Semmler <mail@csemmler.com>
* LegoNavController: Match CalculateNewTargetSpeed
Ghidra showed this correctly too, but the asm showed the problem simply, an incorrect comparison
* Match a MxPresenter vtable function
* Match known functions in LegoPhonemePresenter
* Revert "LegoNavController: Match CalculateNewTargetSpeed"
This reverts commit 718489923b4dd5a3f12d53510d299033924c5dea.
* MxPresenter: rename tickle flag fields
* LegoPhonemePresenter: add size assert
---------
Co-authored-by: MattKC <34096995+itsmattkc@users.noreply.github.com>
* Implement MxAtomId and reference counter (stl set)
* Partial success in hiding 4786 warning spam.
* Build out most of MxOmni::Destroy since it also touches the set
* Add some size asserts
In newer versions of MSVC, this could have been achieved with /wd4237, however 4.2 doesn't have this option, it only seems to have the pragma. Ah well.
* MxStringVariable -> MxVariable
* cursor test
* GetVariable to 100
* meh
* node insert inline
* move to header file
* use reference to match available code
* variable table init in mxomni, some reshuffling
* Start MxBackgroundAudioManager
* Match MxBackgroundAudioManager constructor. This took WAY too much time.
* add size assert
* improve readability of MxBackgroundAudioManager::Enable
While the previous iteration wasn't incorrect, it definitely reads like pseudocode (i.e. it's very unlikely any actual developers would have written that). This is much more readable/likely to have been written and still results in the same asm.
---------
Co-authored-by: itsmattkc <34096995+itsmattkc@users.noreply.github.com>
* All of the MxVectors share an inheritance chain. MxVector4 inherits
from MxVector3 which inherits from MxVector2.
* They all operate on a shared `float*` data member which points to the
underlying storage.
* There are also MxVector3/4Data classes, which inherit from Vector3/4,
but add concrete storage for the Vector data rather than just an
abstract data pointer.
* The same is true for MxMatrix, with there being an abstract and a
concrete variant of it.
* Also improve reccmp.py register matching algorithm. It previously
could not recognize an effective match when a swap had to take place
between two registers used on the same line. It turns out this happens
a lot in floating point math code so I adjusted the implementation to
break the disassembly lines on spaces rather than just linebreaks
allowing the existing effective match code to handle that case too.
* Checkpoint to show MxTickleManager::SetClientTickleInterval match.
* Match MxTickleManager::~MxTickleManager, obliterate MxTickleManager::SetClientTickleInterval.
* Make conditional more realistic, move MxTime to mxtypes.h, add TODO for MxTickleManager::Tickle.
* Start IslePathActor
* Update types/add needed type in LegoPathActor for Pizza
Yes, this is a recommit because last time I pushed my cmake dir
* Fix types in islepathactor
* Adjust variables
* add size asserts
---------
Co-authored-by: itsmattkc <34096995+itsmattkc@users.noreply.github.com>
* MxDirectDraw functions and structures
* fix indents, and globals
* fix build, add mxdirectdraw build configuration
* add new files to cmake
* MxDirectDraw: Add code from my PR #19 on main repo
Merging in the missing functions from my pull request for MxDirectDraw on the main repo. Credit to @foxtacles for the GetPrimaryBitDepth function. All match 100% on reccmp except ErrorToString, but the problem there is with the jump table at the end.
Co-authored-by: Christian Semmler <mail@csemmler.com>
* improve match
* improve accuracy
* improve accuracy
* move _countof, impove up to 96.90%
* Update LEGO1/mxdirectdraw.h
Co-authored-by: MattKC <34096995+itsmattkc@users.noreply.github.com>
* Update LEGO1/mxdirectdraw.cpp
Co-authored-by: MattKC <34096995+itsmattkc@users.noreply.github.com>
* Update LEGO1/mxdirectdraw.cpp
Co-authored-by: MattKC <34096995+itsmattkc@users.noreply.github.com>
* Update LEGO1/mxdirectdraw.cpp
Co-authored-by: MattKC <34096995+itsmattkc@users.noreply.github.com>
* Update LEGO1/mxdirectdraw.cpp
* Update LEGO1/mxdirectdraw.cpp
---------
Co-authored-by: itsmattkc <34096995+itsmattkc@users.noreply.github.com>
Co-authored-by: disinvite <disinvite@users.noreply.github.com>
Co-authored-by: Christian Semmler <mail@csemmler.com>
* start pizza
* Add some pizza vtable functions (they are stubs at the moment)
Unknown parameter types, likely either Pizzeria or PizzaMissionState.
* Pizza: Add/update functions as according to MxCore inheritance
IsleActor::Notify needs to be stubbed
---------
Co-authored-by: Kai Kaufman <ktkaufman@wpi.edu>
* match pizza destructor
* Update pizza members
* add size asserts
---------
Co-authored-by: Kai Kaufman <ktkaufman@wpi.edu>
Co-authored-by: itsmattkc <34096995+itsmattkc@users.noreply.github.com>
* Implementation of MXIOINFO. Not a 100% match, but we are very close. I don't wanna wrangle with this one any more, so I figured I would open it up for review in case anyone else has ideas.
**Known problems:**
- The Open function uses a `movzx` instruction on the value of parameter `fdwOpen` before pushing to OpenFile from the kernel. You can force this to appear by casting to `unsigned short`, but this disturbs the instructions for the rest of the file. To get the "best" overall match I decided to leave this out.
- Flush, Advance, and Descend differ only in the order of operands on a `cmp` instruction.
- This entire file is honestly pretty ugly. The main reason is all the nested ifs; we are constrained by returning a result value from each function, but only at the very end instead of bailing out with a `return`. By far the worst offender is the do/while loop in the Descend function.
**Design considerations:**
- We are casting the file handle from MMIOINFO to `HFILE` everywhere it is used, so I decided to just change the type. While doing that, I figured I might as well just pull out the members from the struct so we don't have `m_info` all over the place.
- Without using a struct member, we have the issue of the obvious `memset` used to zero out the values in the constructor. I changed this to work on the object itself, which would not be valid in most cases, but seems fine here since we have no virtual methods.
There is a lot of repeated code here, namely the call to `_llseek` to reset `m_lDiskOffset` based on the current file position. You could move this to an inline function, but maybe that's not appropriate.
There are probably strides to be made on code clarity and comments (if needed or wanted) here. I'm open to any suggestions.
* remove casts on read, add size assert
* Use more Mx* types and param style convention
* Fixing up MXIOINFO to prepare for merge.
* Following feedback from @stravant and @itsmattkc, reverted back to using `MMIOINFO` struct as the class member instead of adding its values directly. (We actually gained a little on accuracy with this change.)
* The memset to zero out the values in the constructor now acts on `m_info` instead of `this`. Strictly speaking we don't need the size assert any more but I decided to keep it in case we change the members later for some reason.
* Casting the `hmmio` member to `HFILE` (int) or `HMMIO` (WORD) typedefs where needed.
* Squelch a signed/unsigned type comparison warning
* Match MxDSChunk ctor/dtor
* Push work on MxDSAction/MediaAction/Sound
* MxDSMediaAction constructor is matching up to a mov location
* Match MxDSSound constructor by adding the missing member
just four bytes in between them in ghidra.. isn't that enough for ghidra to justify a member variable?
* Match MxDSMediaAction constructor
Today's lesson: ecx suggests '1'
* MxNotificationManager initial work.
* Add .swp files to .gitignore.
* Checkpoint before anything too crazy with param
* Cleanup and add MxParam.
* Checkpoint for everything except MxNotificationManager::Register.
* Add int return type to MxCore::GetId instead of relying on implicit function nonsense.
* Add stlcompat.h so this can still be built on modern compilers, fix affected type size asserts.
* Switch to Mx types
* Add BUILD_COMPAT option to CMake so the project can still be built with modern compilers.
* Change vtable14 and vtable18 to Register and Unregister in MxTickleManager.
* Remove last unsigned int reference to id type.
* Remove MxList, use one inherited class per type. Improves accuracy again.
* Address compiler compatibility code review.
* Match MxNotificationManager::Register.
* Re-enable MxNotificationManager DECOMP_SIZE_ASSERT.
* add smartheap
* cmake: bump even further
* this seemed to be necessary but now it isn't? ok
* cmake: force include smrtheap.hpp
Co-authored-by: Anonymous Maarten <madebr@users.noreply.github.com>
* cmake: force include smrtheap.hpp 2
Co-authored-by: Anonymous Maarten <madebr@users.noreply.github.com>
* remove compiler defs - unnecessary if force-including anyway
* cmake: use interface for cleaner code
---------
Co-authored-by: Anonymous Maarten <madebr@users.noreply.github.com>
* Rather than using <OFFSET> as a replacement for all offsets in a
function, label the offsets as <OFFSET1>, <OFFSET2>, etc. Doing this
will avoid false-positive 100% matches resulting from the same
function being called in two times where a different on should have
been called or vice versa. And the same for globals. I already
encountered one case of this in the wild.
* When a 100% match initially fails, try to make the functions match by
swapping register allocations. This makes it possible to get a 100%
match where the generated machine code differs only in register
allocation.
* Only apply the above when it is possible to reach a 100% match in that
way. Otherwise show the developer the unadultrated diff to avoid
complicating decompilation.
* In the result listing, show the functions which are "effective
matches" in this way as "100%*" instead of "100%".
* MxPalette - add missing member variables, Detach function
* mb
* MxPalette: give bob the builder his constructor
* push progress, gn
* avoid hexadecimal
Co-authored-by: Anonymous Maarten <madebr@users.noreply.github.com>
* fix MxPalette::GetDefaultPalette
Co-authored-by: Anonymous Maarten <madebr@users.noreply.github.com>
* aaaaaaaaaaaaaa
* Revert "fix MxPalette::GetDefaultPalette"
This reverts commit 63f2215737d3bcd286f67dcf1a04fdf8a234d41b.
* Implement MxPalette::Clone (doesn't match)
* fix MxPalette structure and match ctor/dtor
* Matching progress for MxPalette::GetDefaultPalette
* Implement ApplySystemEntriesToPalette except the memcpy calls
* implement SetSkyColor (doesn't match)
* Use MxTypes instead of generics
* prefer decimal values than hex for m_entries
* Update mxpalette.cpp
* Push MxPalette progress - read comments in code.
* improved MxPalette::operator==, will be 100% when MSVC feels like making it so
* improved MxPalette::SetSkyColor, will be 100% when MSVC feels like making it so
* improved MxPalette::Clone, will be 100% when MSVC feels like making it so
* Fixes
- reordered the functions in order of where they are in the hex because recmp.py sometimes kept saying it couldn't find the symbol (??)
- clone returns a pointer, not a ref
- worked a bit on setpalette/applysysentriestopalette
* Match GetDefaultPalette a bit more
* fix: MxPalette::GetDefaultPalette is now 100% matching
* fix: MxPalette::ApplySystemEntriesToPalette is now 100% matching
* tidy: rename `DC` var in GetDefaultPalette to `hdc`
* fix: MxPalette::SetPalette is now functionally matching
Not assembly matching yet because of MSVC weirdness.
At some point it will probably start matching, because
the structure seems to be accurate.
* fix: MxPalette rgbquad ctor functionally matches
Not quite ASM matching yet because of weird
register allocation mismatches.
* fix: I forgot to commit mxpalette.h...
* tidy: use Mx* primitives instead of builtins
* refactor: remove MxPalette::FromBitmapPalette
* fix: call ApplySystemEntriesToPalette from MxPalette(const RGBQUAD *)
* rename MxPalette::SetPalette to MxPalette::SetEntries
* fix: I once again forgot to commit mxpalette.h...
* feat: add/match MxPalette::Reset [0x100BF490]
* fix: add MVideoManager() to mxomni header
* refactor: change unk50 in MxVideoManager to LPDIRECTDRAW
* feat: add/match MxPalette::CreateNativePalette [0x100BF000]
* fix: MxPalette::SetSkyColor is 100% matching
* Annotate MxPalette members' offsets
* Annotate the global default aplette
* use hex size
* remove unnecessary variable offset listing
* Update LEGO1/mxpalette.cpp
---------
Co-authored-by: Anonymous Maarten <madebr@users.noreply.github.com>
Co-authored-by: Christian Semmler <mail@csemmler.com>
Co-authored-by: ktkaufman03 <ktkaufman@wpi.edu>
Co-authored-by: MattKC <34096995+itsmattkc@users.noreply.github.com>
* Add MxSemphore + MxThread and the two implementations I could find
of MxThread (consumers extend it and override the Run method).
* Implement a function in MxDiskStreamProvider which uses thread and
semaphore to confirm correct layout / size of those classes.
* All 100% match except two functions with a pair of registers swapped.
* MxFile and implementations 100% match
* Add MxFile and it's implementations, MxSystemFile and MxMemoryFile.
The names are chosen by me, we don't know their original naming.
* These expose a Read/Write/Seek/Tell interface for reading and writing
data, either from a file on disk or memory buffer.
* 100% match all functions.
* Change name to LegoStream
* Use p_ convention
* Assert size
