Return Styles: Pseud0ch, Terminal, Valhalla, NES, Geocities, Blue Moon. Entire thread

Drawing bitmaps in Windows assembly

Name: Anonymous 2016-07-01 7:31

so I've been a bit bored and decided to reverse engineer an old game so that it will run on modern computers. the big problem here was the resolution: the game runs in 320x240. I managed to redraw the game 'window' to 640x480 without too much hassle but I'm having a hard time with redrawing levels.

basically, if the level is smaller than 640x480, it will be drawn in the middle of the screen. if a previous level was bigger, parts of it will remain drawn on the screen which looks pretty dumb. also, triggers are visible in cutscene because it seems they've been programmed as actual in-game objects and simply hidden from your view.

my idea of fixing that is to upscale the window only and create a bitmap with some fancy borders around the 320x240 area with actual game, kinda like all those vertical shmups do it on non-vertical screens. drawing once would be enough as the game would stick to its original size and wouldn't touch my borders. this way, the game would look the way it was originally meant to but there would be no screen real estate wasted.

how would I go around doing that provided I can get handle to the window easily? MS documentation sucks and it clearly wasn't written with assembler in mind. I can fuck around with C but where's fun in that?

Name: Anonymous 2016-07-06 19:00

ok /prog/, I did a bit of research and I decided that I'll do DLL injection because accessing windows APIs by directly modifying assembly code is less fun than I thought. before I prepare an environment that is able to link to windows APIs, I'll post what I hope to achieve so maybe you'll find some flaws I'm too stupid to see:

1. as the program starts, there's a simple hook to my custom-made asm function that loads my DLL, performs hijacked action and returns.
2. when the game window is drawn, I hardcode a correct resolution but I don't do the memory patching so that the levels are still drawn at original resolution.
3. when the windows is prepared (i.e. it has correct resolution and is switched to fullscreen but nothing is drawn on-screen yet), I hook into my second asm function. it calls the function in my DLL, calls the hijacked function and returns.
4. function in my DLL is basically a wrapper around BitBlt or SetDIBitsToDevice. it takes window handle as a parameter and calls the actual drawing function using shit I've hardcoded.
5. now I should have a nice border around the levels that should remain there because nobody will draw over it.

I'm not sure about point 4 though. I'm afraid I'll ruin the stack somewhere along the way. this would be way easier if arguments on x86 were passed through registers.

Newer Posts
Don't change these.
Name: Email:
Entire Thread Thread List