> Could you tell me how to fix the Korean text using invasive hooking?
http://www.teamliquid.net/forum/viewpost.php?post_id=25568672IIRC, the game creates an offscreen gdi surface the same color depth as the display
it draws the korean text to that surface using gdi
then it just does a straight memcpy of those bits to the (8bpp) ddraw surface.
it all happens around the GetBitmapBits() call
so pick one of the following:
A) hook some gdi calls so the gdi surface is 8bpp
B) color convert the data as it is moved between the 32bpp gdi surface and the 8bpp ddraw surface
C) output the text straight to the 32bpp d3d surface
D) replace the whole function with custom "draw string" code
> Regarding #2, how easy would it be to lock the 32bpp surface?
we DON'T want to lock the 32bpp surface.
instead we want to remove all calls to color_convert() and multiblt()
...
If you really want to lock the 32bpp surface... IIRC, the previous versions did it so check the git commit history.
> profiled the code
seems to be missing :p
but this project is not at the optimization stage...
it still has other fundamental issues :-/
Assuming the palette code gets optimized...
then the only thing going on in-game really is the mapping between video memory and system memory for the 8bpp texture? I don't know much about it and the docs seems vague on what is actually going on behind the scenes...
You can try using different texture creation flags, or different color format for the 32bpp surface or something, idk.
One could switch between exclusive mode in-game then pop back to normal mode on the menu...
which kinda leads to what I was saying about hooking WM_DRAWITEM/PAINT because (afaik) thats the only way to stay in exclusive mode 100% of the time.
/random
I was wondering awhile ago, if one flipped the GDI primary to the ddraw back buffer... could it be accessed simultaneous by ddraw and gdi? I suspect that behavior has also been broken, though.
> windowed mode
if the drawing was fixed in the 1.17 (alpha?) couldn't one just use dxwnd again?