Commit graph

8 commits

Author SHA1 Message Date
MS
907c85616b
Supporting items for SetupCopyRect() (#177)
* Minor improvements all related to SetupCopyRect

* Rename inline getters. malloc/free -> new/delete

* MxTypes in TransitionManager. Remove stub marker (oops)
2023-10-07 18:48:36 +02:00
Joshua Peisach
c7458211f3
Some MxBitmap vtable functions (#89)
* 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>
2023-08-28 03:04:39 -07:00
MattKC
e16249b672
Define MxLong/MxULong (#71)
* define MxLong/MxULong

The "long" type has different sizes on different platforms, and this may cause issues.

* use DWORD to match RegQueryValueExA arg
2023-07-02 01:05:49 -07:00
Christian Semmler
8aad15d18b
lego1: match MxBitmap::Read and vtable (#67)
* lego1: match MxBitmap::Read and vtable

* fix param name
2023-07-01 21:49:42 -07:00
Joshua Peisach
428b5ae8db
Initial implementation of MxBitmap (#34)
Co-authored-by: Anonymous Maarten <madebr@users.noreply.github.com>
2023-06-30 16:24:00 -07:00
itsmattkc
4c9e138cbf implement all DLL exports (as TODOs)
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.
2023-06-30 11:34:39 -07:00
itsmattkc
279d626279 import all functions from lego1 exports
This declares a bunch of classes and functions for us, as well as fixes some declarations that were slightly incorrect (e.g. missing "virtual", etc)
2023-06-11 18:03:54 -07:00
itsmattkc
d4e2fb8d8a reorganized repo, implemented mxcore 2023-05-05 02:54:17 -07:00
Renamed from lib/mxbitmap.h (Browse further)