2023-06-30 14:34:39 -04:00
|
|
|
#include "mxbitmap.h"
|
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 06:04:39 -04:00
|
|
|
#include "decomp.h"
|
|
|
|
|
2023-10-09 18:20:38 -04:00
|
|
|
DECOMP_SIZE_ASSERT(MxBitmap, 0x20);
|
|
|
|
DECOMP_SIZE_ASSERT(MxBITMAPINFO, 0x428);
|
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 06:04:39 -04:00
|
|
|
|
2023-10-09 18:20:38 -04:00
|
|
|
// Bitmap header magic string "BM" (42 4d)
|
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 06:04:39 -04:00
|
|
|
// Sources: https://learn.microsoft.com/en-us/windows/win32/api/wingdi/ns-wingdi-bitmapfileheader, DirectX Complete (1998)
|
|
|
|
// GLOBAL: LEGO1 0x10102184
|
2023-10-09 18:20:38 -04:00
|
|
|
MxU16 g_bitmapSignature = TWOCC('B', 'M');
|
2023-06-30 14:34:39 -04:00
|
|
|
|
|
|
|
// OFFSET: LEGO1 0x100bc980
|
|
|
|
MxBitmap::MxBitmap()
|
|
|
|
{
|
2023-06-30 19:24:00 -04:00
|
|
|
this->m_info = NULL;
|
|
|
|
this->m_bmiHeader = NULL;
|
|
|
|
this->m_paletteData = NULL;
|
|
|
|
this->m_data = NULL;
|
2023-10-09 18:20:38 -04:00
|
|
|
this->m_isHighColor = FALSE;
|
2023-06-30 19:24:00 -04:00
|
|
|
this->m_palette = NULL;
|
2023-06-30 14:34:39 -04:00
|
|
|
}
|
|
|
|
|
|
|
|
// OFFSET: LEGO1 0x100bca10
|
|
|
|
MxBitmap::~MxBitmap()
|
|
|
|
{
|
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 06:04:39 -04:00
|
|
|
if (this->m_info)
|
2023-06-30 19:24:00 -04:00
|
|
|
delete m_info;
|
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 06:04:39 -04:00
|
|
|
if (this->m_data)
|
2023-06-30 19:24:00 -04:00
|
|
|
delete m_data;
|
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 06:04:39 -04:00
|
|
|
if (this->m_palette)
|
2023-06-30 19:24:00 -04:00
|
|
|
delete m_palette;
|
2023-07-02 00:49:42 -04:00
|
|
|
}
|
|
|
|
|
2023-10-09 18:20:38 -04:00
|
|
|
// Bit mask trick to round up to the nearest multiple of four.
|
|
|
|
// Pixel data may be stored with padding.
|
|
|
|
// https://learn.microsoft.com/en-us/windows/win32/medfound/image-stride
|
|
|
|
inline MxLong AlignToFourByte(MxLong p_value)
|
|
|
|
{
|
|
|
|
return (p_value + 3) & -4;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Same as the one from legoutil.h, but flipped the other way
|
|
|
|
// TODO: While it's not outside the realm of possibility that they
|
|
|
|
// reimplemented Abs for only this file, that seems odd, right?
|
|
|
|
inline MxLong _Abs(MxLong p_value)
|
|
|
|
{
|
|
|
|
return p_value > 0 ? p_value : -p_value;
|
|
|
|
}
|
|
|
|
|
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 06:04:39 -04:00
|
|
|
// OFFSET: LEGO1 0x100bcc40
|
|
|
|
MxResult MxBitmap::ImportBitmap(MxBitmap *p_bitmap)
|
2023-07-02 00:49:42 -04:00
|
|
|
{
|
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 06:04:39 -04:00
|
|
|
MxResult result = FAILURE;
|
|
|
|
|
|
|
|
this->m_info = new MxBITMAPINFO;
|
|
|
|
if(this->m_info) {
|
2023-10-09 18:20:38 -04:00
|
|
|
MxLong height = _Abs(p_bitmap->m_bmiHeader->biHeight);
|
|
|
|
this->m_data = new MxU8[AlignToFourByte(p_bitmap->m_bmiHeader->biWidth) * height];
|
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 06:04:39 -04:00
|
|
|
if(this->m_data) {
|
2023-10-09 18:20:38 -04:00
|
|
|
memcpy(this->m_info, p_bitmap->m_info, sizeof(*this->m_info));
|
|
|
|
height = _Abs(p_bitmap->m_bmiHeader->biHeight);
|
|
|
|
memcpy(this->m_data, p_bitmap->m_data, AlignToFourByte(p_bitmap->m_bmiHeader->biWidth) * height);
|
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 06:04:39 -04:00
|
|
|
|
|
|
|
result = SUCCESS;
|
|
|
|
this->m_bmiHeader = &this->m_info->bmiHeader;
|
|
|
|
this->m_paletteData = this->m_info->bmiColors;
|
|
|
|
}
|
|
|
|
}
|
2023-10-09 18:20:38 -04:00
|
|
|
|
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 06:04:39 -04:00
|
|
|
if (result != SUCCESS) {
|
|
|
|
if (this->m_info) {
|
|
|
|
delete this->m_info;
|
|
|
|
this->m_info = NULL;
|
|
|
|
}
|
2023-10-09 18:20:38 -04:00
|
|
|
|
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 06:04:39 -04:00
|
|
|
if (this->m_data) {
|
|
|
|
delete this->m_data;
|
|
|
|
this->m_data = NULL;
|
|
|
|
}
|
|
|
|
}
|
2023-10-09 18:20:38 -04:00
|
|
|
|
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 06:04:39 -04:00
|
|
|
return result;
|
|
|
|
}
|
|
|
|
|
|
|
|
// OFFSET: LEGO1 0x100bcba0
|
|
|
|
MxResult MxBitmap::ImportBitmapInfo(MxBITMAPINFO *p_info)
|
|
|
|
{
|
|
|
|
MxResult result = FAILURE;
|
|
|
|
MxLong width = p_info->bmiHeader.biWidth;
|
|
|
|
MxLong height = p_info->bmiHeader.biHeight;
|
2023-10-09 18:20:38 -04:00
|
|
|
MxLong size = AlignToFourByte(width) * height;
|
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 06:04:39 -04:00
|
|
|
|
|
|
|
this->m_info = new MxBITMAPINFO;
|
|
|
|
if (this->m_info) {
|
2023-10-09 18:20:38 -04:00
|
|
|
this->m_data = new MxU8[size];
|
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 06:04:39 -04:00
|
|
|
if(this->m_data) {
|
2023-10-09 18:20:38 -04:00
|
|
|
memcpy(this->m_info, p_info, sizeof(*this->m_info));
|
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 06:04:39 -04:00
|
|
|
this->m_bmiHeader = &this->m_info->bmiHeader;
|
|
|
|
this->m_paletteData = this->m_info->bmiColors;
|
|
|
|
result = SUCCESS;
|
|
|
|
}
|
|
|
|
}
|
2023-10-09 18:20:38 -04:00
|
|
|
|
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 06:04:39 -04:00
|
|
|
if (result != SUCCESS) {
|
|
|
|
if (this->m_info) {
|
|
|
|
delete this->m_info;
|
|
|
|
this->m_info = NULL;
|
|
|
|
}
|
2023-10-09 18:20:38 -04:00
|
|
|
|
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 06:04:39 -04:00
|
|
|
if (this->m_data) {
|
|
|
|
delete this->m_data;
|
|
|
|
this->m_data = NULL;
|
|
|
|
}
|
|
|
|
}
|
2023-10-09 18:20:38 -04:00
|
|
|
|
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 06:04:39 -04:00
|
|
|
return result;
|
2023-07-02 00:49:42 -04:00
|
|
|
}
|
|
|
|
|
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 06:04:39 -04:00
|
|
|
|
|
|
|
// OFFSET: LEGO1 0x100bd450
|
|
|
|
MxResult MxBitmap::ImportColorsToPalette(RGBQUAD* p_rgbquad, MxPalette* p_palette)
|
2023-07-02 00:49:42 -04:00
|
|
|
{
|
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 06:04:39 -04:00
|
|
|
MxResult ret = FAILURE;
|
|
|
|
PALETTEENTRY entries[256];
|
|
|
|
|
|
|
|
if (p_palette) {
|
|
|
|
if (p_palette->GetEntries(entries))
|
|
|
|
return ret;
|
|
|
|
} else {
|
|
|
|
MxPalette local_pal;
|
|
|
|
if (local_pal.GetEntries(entries))
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2023-10-09 18:20:38 -04:00
|
|
|
for (MxS32 i = 0; i < 256; i++) {
|
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 06:04:39 -04:00
|
|
|
p_rgbquad[i].rgbRed = entries[i].peRed;
|
|
|
|
p_rgbquad[i].rgbGreen = entries[i].peGreen;
|
|
|
|
p_rgbquad[i].rgbBlue = entries[i].peBlue;
|
|
|
|
p_rgbquad[i].rgbReserved = 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
ret = SUCCESS;
|
|
|
|
return ret;
|
2023-07-02 00:49:42 -04:00
|
|
|
}
|
|
|
|
|
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 06:04:39 -04:00
|
|
|
// OFFSET: LEGO1 0x100bcaa0
|
2023-10-09 18:20:38 -04:00
|
|
|
MxResult MxBitmap::SetSize(MxS32 p_width, MxS32 p_height, MxPalette *p_palette, MxBool p_isHighColor)
|
2023-07-02 00:49:42 -04:00
|
|
|
{
|
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 06:04:39 -04:00
|
|
|
MxResult ret = FAILURE;
|
2023-10-09 18:20:38 -04:00
|
|
|
MxLong size = AlignToFourByte(p_width) * p_height;
|
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 06:04:39 -04:00
|
|
|
|
|
|
|
m_info = new MxBITMAPINFO;
|
|
|
|
if (m_info) {
|
2023-10-09 18:20:38 -04:00
|
|
|
m_data = new MxU8[size];
|
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 06:04:39 -04:00
|
|
|
if (m_data) {
|
|
|
|
m_bmiHeader = &m_info->bmiHeader;
|
|
|
|
m_paletteData = m_info->bmiColors;
|
|
|
|
memset(&m_info->bmiHeader, 0, sizeof(m_info->bmiHeader));
|
|
|
|
|
|
|
|
m_bmiHeader->biSize = sizeof(*m_bmiHeader); // should be 40 bytes
|
|
|
|
m_bmiHeader->biWidth = p_width;
|
|
|
|
m_bmiHeader->biHeight = p_height;
|
|
|
|
m_bmiHeader->biPlanes = 1;
|
|
|
|
m_bmiHeader->biBitCount = 8;
|
|
|
|
m_bmiHeader->biCompression = 0;
|
|
|
|
m_bmiHeader->biSizeImage = size;
|
|
|
|
|
|
|
|
if (!ImportColorsToPalette(m_paletteData, p_palette)) {
|
2023-10-09 18:20:38 -04:00
|
|
|
if (!SetBitDepth(p_isHighColor)) {
|
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 06:04:39 -04:00
|
|
|
ret = SUCCESS;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (ret) {
|
|
|
|
if (m_info) {
|
|
|
|
delete m_info;
|
|
|
|
m_info = NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (m_data) {
|
|
|
|
delete[] m_data;
|
|
|
|
m_data = NULL;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return ret;
|
2023-07-02 00:49:42 -04:00
|
|
|
}
|
|
|
|
|
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 06:04:39 -04:00
|
|
|
// OFFSET: LEGO1 0x100bcd60
|
2023-07-02 00:49:42 -04:00
|
|
|
MxResult MxBitmap::LoadFile(HANDLE p_handle)
|
|
|
|
{
|
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 06:04:39 -04:00
|
|
|
MxResult result = FAILURE;
|
|
|
|
DWORD bytesRead;
|
|
|
|
BITMAPFILEHEADER hdr;
|
|
|
|
|
2023-10-09 18:20:38 -04:00
|
|
|
BOOL ret = ReadFile(p_handle, &hdr, sizeof(hdr), &bytesRead, NULL);
|
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 06:04:39 -04:00
|
|
|
if (ret && (hdr.bfType == g_bitmapSignature)) {
|
|
|
|
this->m_info = new MxBITMAPINFO;
|
2023-10-09 18:20:38 -04:00
|
|
|
if (this->m_info) {
|
|
|
|
ret = ReadFile(p_handle, this->m_info, sizeof(*this->m_info), &bytesRead, NULL);
|
|
|
|
if (ret && (this->m_info->bmiHeader.biBitCount == 8)) {
|
|
|
|
MxLong size = hdr.bfSize - (sizeof(MxBITMAPINFO) + sizeof(BITMAPFILEHEADER));
|
|
|
|
this->m_data = new MxU8[size];
|
|
|
|
if (this->m_data) {
|
|
|
|
ret = ReadFile(p_handle, this->m_data, size, &bytesRead, NULL);
|
|
|
|
if (ret) {
|
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 06:04:39 -04:00
|
|
|
this->m_bmiHeader = &this->m_info->bmiHeader;
|
|
|
|
this->m_paletteData = this->m_info->bmiColors;
|
2023-10-09 18:20:38 -04:00
|
|
|
if (this->m_info->bmiHeader.biSizeImage == 0) {
|
|
|
|
MxLong height = _Abs(this->m_info->bmiHeader.biHeight);
|
|
|
|
this->m_info->bmiHeader.biSizeImage = AlignToFourByte(this->m_info->bmiHeader.biWidth) * height;
|
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 06:04:39 -04:00
|
|
|
}
|
|
|
|
result = SUCCESS;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2023-10-09 18:20:38 -04:00
|
|
|
|
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 06:04:39 -04:00
|
|
|
if (result != SUCCESS) {
|
|
|
|
if (this->m_info) {
|
|
|
|
delete this->m_info;
|
|
|
|
this->m_info = NULL;
|
|
|
|
}
|
2023-10-09 18:20:38 -04:00
|
|
|
|
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 06:04:39 -04:00
|
|
|
if (this->m_data) {
|
|
|
|
delete this->m_data;
|
|
|
|
this->m_data = NULL;
|
|
|
|
}
|
|
|
|
}
|
2023-10-09 18:20:38 -04:00
|
|
|
|
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 06:04:39 -04:00
|
|
|
return result;
|
2023-07-02 00:49:42 -04:00
|
|
|
}
|
|
|
|
|
|
|
|
// OFFSET: LEGO1 0x100bcd10
|
2023-07-02 04:05:49 -04:00
|
|
|
MxLong MxBitmap::Read(const char *p_filename)
|
2023-07-02 00:49:42 -04:00
|
|
|
{
|
|
|
|
MxResult result = FAILURE;
|
|
|
|
HANDLE handle = CreateFileA(
|
|
|
|
p_filename,
|
|
|
|
GENERIC_READ,
|
|
|
|
FILE_SHARE_READ,
|
|
|
|
NULL,
|
|
|
|
OPEN_EXISTING,
|
|
|
|
FILE_ATTRIBUTE_NORMAL,
|
|
|
|
NULL
|
|
|
|
);
|
|
|
|
|
|
|
|
if (handle != INVALID_HANDLE_VALUE && !LoadFile(handle))
|
|
|
|
result = SUCCESS;
|
|
|
|
|
|
|
|
if (handle)
|
|
|
|
CloseHandle(handle);
|
|
|
|
|
|
|
|
return result;
|
|
|
|
}
|
|
|
|
|
|
|
|
// OFFSET: LEGO1 0x1004e0d0
|
|
|
|
int MxBitmap::vtable28(int)
|
|
|
|
{
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
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 06:04:39 -04:00
|
|
|
// OFFSET: LEGO1 0x100bce70 STUB
|
2023-07-02 00:49:42 -04:00
|
|
|
void MxBitmap::vtable2c(int, int, int, int, int, int, int)
|
|
|
|
{
|
|
|
|
}
|
|
|
|
|
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 06:04:39 -04:00
|
|
|
// OFFSET: LEGO1 0x100bd020 STUB
|
2023-07-02 00:49:42 -04:00
|
|
|
void MxBitmap::vtable30(int, int, int, int, int, int, int)
|
|
|
|
{
|
2023-06-30 14:34:39 -04:00
|
|
|
}
|
|
|
|
|
|
|
|
// OFFSET: LEGO1 0x100bd1c0
|
|
|
|
MxPalette *MxBitmap::CreatePalette()
|
|
|
|
{
|
2023-06-30 19:24:00 -04:00
|
|
|
MxBool success = FALSE;
|
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 06:04:39 -04:00
|
|
|
MxPalette *palette = NULL;
|
2023-06-30 19:24:00 -04:00
|
|
|
|
2023-10-09 18:20:38 -04:00
|
|
|
switch (this->m_isHighColor) {
|
|
|
|
case FALSE:
|
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 06:04:39 -04:00
|
|
|
palette = new MxPalette(this->m_paletteData);
|
|
|
|
if (palette)
|
|
|
|
success = TRUE;
|
|
|
|
break;
|
|
|
|
|
2023-10-09 18:20:38 -04:00
|
|
|
case TRUE:
|
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 06:04:39 -04:00
|
|
|
palette = this->m_palette->Clone();
|
|
|
|
if (palette)
|
|
|
|
success = TRUE;
|
|
|
|
break;
|
2023-06-30 19:24:00 -04:00
|
|
|
}
|
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 06:04:39 -04:00
|
|
|
|
|
|
|
if (!success && palette) {
|
|
|
|
delete palette;
|
|
|
|
palette = NULL;
|
2023-06-30 19:24:00 -04:00
|
|
|
}
|
|
|
|
|
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 06:04:39 -04:00
|
|
|
return palette;
|
2023-06-30 14:34:39 -04:00
|
|
|
}
|
|
|
|
|
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 06:04:39 -04:00
|
|
|
// OFFSET: LEGO1 0x100bd280
|
|
|
|
void MxBitmap::ImportPalette(MxPalette* p_palette)
|
2023-06-30 14:34:39 -04:00
|
|
|
{
|
2023-10-09 18:20:38 -04:00
|
|
|
// Odd to use a switch on a boolean, but it matches.
|
|
|
|
switch (this->m_isHighColor) {
|
|
|
|
case FALSE:
|
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 06:04:39 -04:00
|
|
|
ImportColorsToPalette(this->m_paletteData, p_palette);
|
|
|
|
break;
|
|
|
|
|
2023-10-09 18:20:38 -04:00
|
|
|
case TRUE:
|
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 06:04:39 -04:00
|
|
|
if (this->m_palette) {
|
|
|
|
delete this->m_palette;
|
|
|
|
}
|
|
|
|
this->m_palette = p_palette->Clone();
|
|
|
|
break;
|
|
|
|
}
|
2023-07-02 00:49:42 -04:00
|
|
|
}
|
2023-06-30 19:24:00 -04:00
|
|
|
|
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 06:04:39 -04:00
|
|
|
// OFFSET: LEGO1 0x100bd2d0
|
2023-10-09 18:20:38 -04:00
|
|
|
MxResult MxBitmap::SetBitDepth(MxBool p_isHighColor)
|
2023-07-02 00:49:42 -04:00
|
|
|
{
|
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 06:04:39 -04:00
|
|
|
MxResult ret = FAILURE;
|
|
|
|
MxPalette *pal = NULL;
|
|
|
|
|
2023-10-09 18:20:38 -04:00
|
|
|
if (m_isHighColor == p_isHighColor) {
|
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 06:04:39 -04:00
|
|
|
// no change: do nothing.
|
|
|
|
ret = SUCCESS;
|
|
|
|
} else {
|
2023-10-09 18:20:38 -04:00
|
|
|
switch (p_isHighColor) {
|
|
|
|
case FALSE:
|
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 06:04:39 -04:00
|
|
|
ImportColorsToPalette(m_paletteData, m_palette);
|
|
|
|
if (m_palette)
|
|
|
|
delete m_palette;
|
|
|
|
|
|
|
|
m_palette = NULL;
|
|
|
|
break;
|
|
|
|
|
2023-10-09 18:20:38 -04:00
|
|
|
case TRUE:
|
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 06:04:39 -04:00
|
|
|
pal = NULL;
|
|
|
|
pal = new MxPalette(m_paletteData);
|
|
|
|
if (pal) {
|
|
|
|
m_palette = pal;
|
|
|
|
|
|
|
|
// TODO: what is this? zeroing out top half of palette?
|
|
|
|
MxU16 *buf = (MxU16*)m_paletteData;
|
|
|
|
for (MxU16 i = 0; i < 256; i++) {
|
|
|
|
buf[i] = i;
|
|
|
|
}
|
|
|
|
|
2023-10-09 18:20:38 -04:00
|
|
|
m_isHighColor = p_isHighColor;
|
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 06:04:39 -04:00
|
|
|
ret = SUCCESS;
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// If we were unsuccessful overall but did manage to alloc
|
|
|
|
// the MxPalette, free it.
|
|
|
|
if (ret && pal)
|
|
|
|
delete pal;
|
|
|
|
|
|
|
|
return ret;
|
2023-06-30 14:34:39 -04:00
|
|
|
}
|
2023-06-30 19:24:00 -04:00
|
|
|
|
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 06:04:39 -04:00
|
|
|
// OFFSET: LEGO1 0x100bd3e0
|
2023-10-09 18:20:38 -04:00
|
|
|
MxResult MxBitmap::StretchBits(HDC p_hdc, MxS32 p_xSrc, MxS32 p_ySrc, MxS32 p_xDest, MxS32 p_yDest, MxS32 p_destWidth, MxS32 p_destHeight)
|
2023-07-02 00:49:42 -04:00
|
|
|
{
|
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 06:04:39 -04:00
|
|
|
// Compression fix?
|
2023-10-21 18:40:31 -04:00
|
|
|
if ((this->m_bmiHeader->biCompression != BI_RGB_TOPDOWN) && (0 < this->m_bmiHeader->biHeight)) {
|
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 06:04:39 -04:00
|
|
|
p_ySrc = (this->m_bmiHeader->biHeight - p_destHeight) - p_ySrc;
|
|
|
|
}
|
|
|
|
|
2023-10-09 18:20:38 -04:00
|
|
|
return StretchDIBits(p_hdc, p_xDest, p_yDest, p_destWidth, p_destHeight, p_xSrc, p_ySrc, p_destWidth, p_destHeight, this->m_data, (BITMAPINFO*)this->m_info, this->m_isHighColor, SRCCOPY);
|
|
|
|
}
|