Drawing bitmaps in Windows assembly

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?

Add online multiplayer support in assembly.

I think you need to get the Window's "Device Context" DC, using GetDC(hWnd); You can draw directly to the DC with SetPixel, but this will be SLOW AS FUCK, but might be ok for a shitty old game. The proper way to do it would be with to assemble the frame in memory, then use BitBlt();

>>2
I think we should do it the /prog/ way and write a Scheme program that writes a multiplayer assembly module and adds it to the game.

>>3
how slow would it be? if you could see the lines filling up, it might be fun and given that it happens only during startup it wouldn't be that annoying.

wouldn't it be easier to load a bitmap into memory (or maybe hardcode an asset with reshacker), call some magic functions to create a paintstruct or whatever is its name and paint it?

SetDIBitsToDevice

>post yfw mozilla released servo before cudder's windows 95 netscape clone

>>6
that feel when Cudder posted in my thread and now it's going to be about vaporware browsers instead of REing old vidya

>>1
As you're probably talking about PC gaming, 320x240 was scandoubled on a CRT monitor. Just double it up.

At least the pixels are properly square, unlike 320x200 on 4:3.

>>8
I'm not sure, the game is not that old. it's for windows and from the beginning of this century, just made with a quirky engine. patching the parts of memory that hold its resolution resulted in a scenario I mentioned in the OP: the game keeps larger portions of the level on-screen and if the level is too small, it just looks silly. your solution does sound tempting but I'm afraid doing it might not be straightforward - the best way of doing it I can think of (correct me if I'm wrong, I'm new to reversing vidya) would be to find a pixel-drawing routine and make it draw four pixels at time which might be hard to do without breaking offsets.

bonus points: every single fucking thing is in the exe, except of a single dll with multimedia-related functionality (I guess it's used for playing midis). and it must be embedded in some obscure way as resource hackers doesn't detect it.

Check em

>>10
Fuck off.

Check em

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.

>>13
Doesn't windows first check the executable's directory for the DLL before checking system32 and %PATH%? You could just pass calls through without patching the EXE.

>>14
so like a fake gdi32 or user32 which passes all the functions to the normal one but adds my code to one of them? this might potentially work but the game's code is a bit weird - for example, I couldn't just draw the image when window is being created because it isn't created with correct dimensions, it starts off as a small rectangle and then is resized. plus, wouldn't I need to make the offests exactly the same as in the actual DLL?

BTW if that works, I still need to patch the executable, just a bit less than in the approach I'm thinking of. I still have to make the resolution right.

check em

>>13

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.

Windows API is __stdcall, (defined as WINAPI), so the calls shouldn't be too bad as you will just push args to the stack, and not need to clean it up afterwards

>>17
I'm more wooried about the C lib I'll be injecting

is there a tool for editing .exe files that doesn't corrupt them? whether I try to statically add my code as a new section or add an import from a .dll, the modified executable fails to run. inb4 write your own exe parser - I'm too lazy for that.

oh well, looks like I'm going to go the fake .dll route after all

Check em

>>18
Just say NO to drugs.

Say yes to dubs

check Em

You do realize Windows 10 has a built in Screen Magnifier, right?

>>24
yes, but that's an ugly hack. I'd rather have a working standalone executable

>>24
Why do you mention Windows 10 specifically when that feature has existed since Windows 98? Are you a Microsoft shill?

Check em