Force change resolution

[Lambchops]

there's lots of parts to this question...

I dont think you will find a "640" and "480" setting for screen resolution.

Those numbers will be around as constant values for various calculations to display the graphics, as the entire game is hard-coded for 640x480 screen res.

As for the actual graphics card display, back then 640x480x256 was mode 257 (0x101)
not much point in searching for that value, as you will get anything that has two 0x01 bytes in a row, but if you want to chase down the GL code that sets the graphics mode and change that value you could try
mode 259= 800x600x256 or mode 261= 1024x768x256 colors.

however you will only end up with either the screen still being displayed in a 640x480 rectangle in the corner, or totally mashed into the first 640*480=307200 (0x4B000)pixels of the screen, depending on the method they use to access the graphics hardware.

All the internals are designed for 640x480, for instance if you read the dword at 0x4D4A94 you'll find a pointer to a 0x4B000 byte buffer that holds the current game screen.... you can do a DIY ss by reading these bytes and the 256x3 byte palette from 0x4AE844 then making a PCX or BMP file out of them.

maybe you could just use a generic image resize and display it at higher res, but you havn't really gained anything doing that - you still really have only 640x480 pixels.

To really change the res, you would have to enlarge the buffer (and any others), and change lots of other stuff.

as and example, if you wanted to display a pixel at certian co-ords you would use:
buffer_address + X+ (Y*screen_width)

so for say the location {333,122} you might do ptrScrBuff + 333 + (122*640)

..but in 800x600 you would need ptrScrBuff+333+(122*800), except I think you'll find LOTS of places where the 640 is hard coded... idk never tried to find them. so if you change the display mode and enlarge the buffer to 800x600= 0x75300 bytes, then lots of things... probably the GRP decode routine for starters... would still calculate 333+(122*640), so instead of {333,122} you end up at  {13,98}... then the next row of pixels could end up on the other side of the screen etc.

Not a small job, but I'd love to see it done 

[Lambchops]

i didnt find shiti was changing to 320x240.. dos version (maywork)..i tried 800x600 also..
need lambchops<-----------
just make sure i was doing it right 640 dec to hex 280----->then inputed as 082 correctall !?

hehe. Yes 640 = 0x280

in hex byte display (a la hex editor) the byte order is reversed so as a dword it would be 80:02:00:00

[Delete mine too]

Damn!

Okay so their is a referenced string for display adapter you can find with cheat engine, etc. Change that also!

Also another tip! Try to hex ddraw.dll!

[Lambchops]

Damn!

Okay so their is a referenced string for display adapter you can find with cheat engine, etc. Change that also!

Also another tip! Try to hex ddraw.dll!

Actually, now I look at it, bne is just using standard windows gdi stuff. The DOS version would use interrupt 16 and mode 257. But wc2.exe and storm.dll only import graphics stuff from GDI32.dll and USER32.dll, so its all just device contexts...

ddraw.dll (directX) isn't imported by anything, in the traditional way. It's being dynamically loaded by one of the sneaky little embedded code modules blizz use. It seems they only use:

CreateBackSurface
SetPalette
CreatePrimarySurface
SetDisplayMode
DirectDrawCreate

Which is just a very basic set of initialization routines. Also there's a help message in there for the event where it can't use directX, telling you to set your desktop to 640x480x256.

There's a few calls to GetDesktopWindow followed by GetDC, this gets the device context of the windows desktop (being the top level window), so it looks like its, in effect just resizing the desktop to 640x480 then writing directly to it. Possibly. At lot of it relates to dialog boxes and stuff, hard to tell without spending more time. Anyway, anyone who understands standard windows GDI programming should be able to have a go at it...

( all the other stuff still applies, just the 257 code may or may not be what directX uses )

------edit:

Code: [Select]

HRESULT SetDisplayMode(
                         dwWidth,
                         dwHeight,
                         dwBPP,
                         dwRefreshRate,
                         dwFlags       );

... so bne is a wonder of modern technology 

[Lambchops]

There's a few calls to GetDesktopWindow followed by GetDC, this gets the device context of the windows desktop (being the top level window), so it looks like its, in effect just resizing the desktop to 640x480 then writing directly to it. Possibly. At lot of it relates to dialog boxes and stuff, hard to tell without spending more time.

Was having a look at other threads and found this desktop SS from USA~Archer. I get a similar issue when I am alt-tabbed and I disconnect from the network, but seeing it side-by-side with the window is helpful.



After seeing this I would guess the reasons would be:

 - WC2 was originally written for DOS. When they made BNE they needed to port the display code for windows, so somebody came up with the bit of DirectX code to change the display to 640x480x256 and provide a handle to it, so the original dos code could use that.

 - The basic channel screen frame etc. uses this handle, but the code that writes the text and dialog boxes etc. to the screen was done seperately, and that is what is being done with the calls I mentioned above.

This is what is happening in this SS. The borders etc. are being written to the DC of the window, but the text is being written directly to the desktop so its appearing in the top-left 640x480 section of the desktop, regardless of the position of the window.

Anyway, the point is I would guess that replacing all (or perhaps most of) the calls to GetDesktopWindow with calls to GetActiveWindow could fix this problem. If not, then converting the co-ords with either ClientToScreen or MapWindowPoints should work, but this would be a little bit trickier to patch as it isn't a straight 1:1 replacement.

[iL]

ddraw.dll (directX) isn't imported by anything, in the traditional way. It's being dynamically loaded by one of the sneaky little embedded code modules blizz use. It seems they only use:

CreateBackSurface
SetPalette
CreatePrimarySurface
SetDisplayMode
DirectDrawCreate

That would be probably interesting to look into ddraw.dll source codes from aqrit, this thread: http://forum.war2.ru/index.php/topic,1790.0.html
He uses handlers for many ddraw functions. At least these fucntions should rewritten i think.

[shesycompany]

lol omg ty easy to my past self fuck that e-300 was the machine play tribes fuking muz what happend to that kid..ahh i cant help but like easy that 100% compatable motherfucker