Diving through functions in the Ghidra server, seeing what the unknown functions are doing

# reminder
- i am new to reverse engineering/decomp/ghidra
- these are guesses

# variable offset notes
- +0x8 = this->m_info (BITMAPINFO*)
- +0xc = this->m_bmiHeader (BITMAPINFOHEADER*)
- +0x10 = this->m_paletteData (RGBQUAD*)
- +0x14 = this->m_data (LPVOID*)
- +0x18 = this->m_unk18 (MxBool)
- +0x1c = this->m_palette (MxPalette*)

# to update: w/ confidence. all of these are in the MxBitmap vtable
## Functions that get information from an existing MxBitmap, it sounds like
This section is probably a mess, so please bear with me
### `int FUN_100bcc40` -> `int MxBitmap::IDontKnow`
- Primarily does stuff with the bmiHeader size and width
- throughout this function, it accesses the bmiHeader a lot and then sets MxBitmap variables to things in the header
- the original (this*) offsets it was using match with the parameter offsets above
- adjusts bmiHeader.biSize to its width(?)
- at the end, sets the original MxBitmap::bmiHeader to the MxBitmap::m_info->bmiHeader
- sets the original MxBitmap::paletteData to the MxBitmap::m_info->bmiColors

- further guesses after investigating the next function makes me think it's looking at an existing bitmap and taking info from there
- ghidra agrees when i retype, based on what its accessing, the param is something with a BitmapInfoHeader.. so then wtf is the next one?
- this function seems to get info from the BMIHeader's planes, the next one doesn't (idk how i came to this conclusion)
- setting the param type to MxBitmap shows it looks at the param's m_data so idk what this is..
### `int FUN_100bcba0` -> `int MxBitmap::SetInfoFromBitmapInfoHeader`
- also accesses info from the bmiHeader and does something
- but wtf is param_1? it could be the .biSize but that would be a DWORD, this looks like a ptr to an array
- the offsets suggest it could be a MxBitmap* but there's a few undefined things (like something at 0x4)
- sheer guess as BITMAPINFOHEADER shows it could be! with 0x4 being the biWidth and 0x8 being biHeight
- documentation also confirms this
- then does the same as earlier, sets original data to info from the original BITMAPINFOHEADER

- very similar function as above - these two need some work together, but accomplish similar things

# loading information from parameters
## `int FUN_100bcaa0` -> `int MxBitmap::FUN_100bcaa0` (I can't think of a name.. LoadFromFoo)
- a mess with a ton of params, but a lot of the params/this calls suggest the offset referring to bmiHeader
- `this` is definitely MxBitmap*
- i wonder if this is some sort of Reset function, or just like, SetResolution

- it looks like it does a possible memcpy?
- primary notes of what it does to the bmiHeader:
- `biSize` is set to 0x28
- `biWidth` is set to param_1
- `biHeight` is set to param_2
- `biPlanes` is set to 1
- `biCompression` is set to 0
- `biSizeImage` is set to.. `uVar4 = (param_1 + 3U & 0xfffffffc) * param_2;`, which a malloc call suggests is a sizeof something
- then:
- it calls `FUN_100bd450` on m_paletteData with param_3 as an argument
- if returns 0 (success??), calls `this->vtable + 0x3c` (LAB_100bd2d0, likely in the MxPalette class) casted with param_4

## `int FUN_100bce70` -> `int MxBitmap::FUN_100bce70` (name idea TBD)
- yes, it is MxBitmap related, does set info
- a lot of parameter gibberish, maybe another function to load the bitmap from an existing thing
- param_1 looks like its another MxBitmap based on its offsets
- there's a call to FUN_100b6e10
### what i know about FUN_100b6e10
- params: param_1->bmiHeader->biWidth, param_1->bmiHeader->biHeight, this->biWidth, this->biHeight, then params 2 thru param 7
- params 2 thru 7 seem to be related to some addition/subtraction operation from the other biVars

# stuff relating to MxPalette
## `void FUN_100bd280` -> `void MxBitmap::SetPalette`
- Possibly another function related to creating a palette! Maybe replacing a Bitmap with an existing Palette
- Checks this->m_unk18, then calls `FUN_100bd450` (appears to be part of MxPalette), then checks again?
- ensures palette isn't null, then destructs it
- TL;DR: clones a new palette from param_1, then sets this->m_palette to it
- it looks like this just sets the palette to an existing palette, but clones it first (probably to ensure things that change wont screw up the original palette)
- I am confident that this is about accurate:

# wth is FUN_100bd450?
- something palette related