1
Mods & Development / remake of Warcraft 1
« on: September 04, 2019, 09:57:07 PM »
saw this today: https://github.com/acoto87/war1
Welcome to the forums! We're glad to have you here! :) You can register your account here, then feel free to introduce yourself in the Server.Warcraft2.online board & let us know who you are on the server.
Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
2
Server.War2.ru / Re: New features
« on: January 06, 2019, 10:51:20 PM »
BabyShark threadjacks another topic into a tire fire. News at 11.
Also:
lol
Also:
Quote from: Sepi
Quote from: WhatWouldjessu001Dojust a non-toxic thread here guysQuote from: tupacYou're being petty and narrow-minded, maciek.Quote from: maciekYou have now been added also.Quote from: tupacso ask those people on your own forum?Quote from: tk[as]That's your opinion. Plenty of people play on my server. You made your choice months ago. You are in the shit list already and won't be removed.Quote from: tupacMost of the assholes here is blocked from my software.nobody joining ur server tupac...that's just the way it is. things will never be the same.
??
Some of us are actually interested in the long term success of this game. [...]
No one has done anything to you. What is your agenda? What's your plan/mission/purpose? [...]
You don't own W2. [...]
You want to kill W2. [...]
lol
3
Server.War2.ru / Re: Warcraft 2 speedrun $$ bounties
« on: October 16, 2018, 04:49:16 PM »
so everything claimed except the dark portal full campaigns?
4
Server.War2.ru / Re: War2 graphics for Win Vista/7/8/8.1/10/2012 fixed
« on: August 16, 2016, 02:59:55 AM »
> Could you tell me how to fix the Korean text using invasive hooking?
http://www.teamliquid.net/forum/viewpost.php?post_id=25568672
IIRC, 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?
http://www.teamliquid.net/forum/viewpost.php?post_id=25568672
IIRC, 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?
5
Server.War2.ru / Re: War2 graphics for Win Vista/7/8/8.1/10/2012 fixed
« on: August 14, 2016, 12:10:23 AM »
@xboi
I keep trying to improve this project by hooking WM_DRAWITEM and WM_PAINT messages...
which eventually causes me to rage quit.
fixing the Korean text is trivial, if using invasive hooking...
if you're going to build a launcher then this would be good practice for you :p
The only non-invasive way to fix the KR font, that I can think of, would be to override the Ariel font with a custom one. However, I've never tried that out.
other known issues:
1. D3DCREATE_FPUPRESERVE flag is missing
2. In 0.4 the 32bpp surface is not locked, only the 8bpp texture is locked...
so color converting anything by hand is a giant WTF!
How it doesn't crash is currently a mystery...
Do you think the new official 1.1.17 Starcraft patch is waiting on the HD upgrade?
I keep trying to improve this project by hooking WM_DRAWITEM and WM_PAINT messages...
which eventually causes me to rage quit.
fixing the Korean text is trivial, if using invasive hooking...
if you're going to build a launcher then this would be good practice for you :p
The only non-invasive way to fix the KR font, that I can think of, would be to override the Ariel font with a custom one. However, I've never tried that out.
other known issues:
1. D3DCREATE_FPUPRESERVE flag is missing
2. In 0.4 the 32bpp surface is not locked, only the 8bpp texture is locked...
so color converting anything by hand is a giant WTF!
How it doesn't crash is currently a mystery...
Do you think the new official 1.1.17 Starcraft patch is waiting on the HD upgrade?
6
Server.War2.ru / Re: War2 graphics for Win Vista/7/8/8.1/10/2012 fixed
« on: April 12, 2016, 04:11:22 PM »
In 0.4 the 32bpp surface is not locked, only the 8bpp texture is locked...
so color converting anything by hand is a giant WTF!
How it doesn't crash or produce visual garbage is currently a mystery...
Stayed tuned for a fix for this :p
so color converting anything by hand is a giant WTF!
How it doesn't crash or produce visual garbage is currently a mystery...
Stayed tuned for a fix for this :p
7
Server.War2.ru / Re: War2 graphics for Win Vista/7/8/8.1/10/2012 fixed
« on: April 12, 2016, 02:07:45 PM »Quote
Then you used SSE2 just to make that converts 8->32bpp faster. And then you used d3d shaders to make it work faster, but on systems not supporting SSE2, right?
No, SSE2 is used to do a transparent BitBlt. If SSE2 is not supported it falls back to some GDI operations.
though, on the bnet menu screens...
color conversion is done with regular 386 instructions, instead of using the d3d shader.
because originally I wasn't planning on using d3d at all.
---
Everything else you posted seems correct.
8
Server.War2.ru / Re: War2 graphics for Win Vista/7/8/8.1/10/2012 fixed
« on: April 12, 2016, 01:50:58 AM »
that crash is expected behavior for the "minimal" version on XP.
the "minimal" version is for win8+ only...
the "full" version will never encounter this issue...
as it will never return DDERR_SURFACELOST
If we cared... to get the minimal version to not crash on XP we just need to forward the dds->Restore function.
15012F62 == dds->Lock call
15012F78 == dds->Restore call
the "minimal" version is for win8+ only...
the "full" version will never encounter this issue...
as it will never return DDERR_SURFACELOST
If we cared...
to get the minimal version to not crash on XP we just need to forward the dds->Restore function.15012F62 == dds->Lock call
15012F78 == dds->Restore call
9
Server.War2.ru / Re: DKPuzzle Solution Video
« on: April 08, 2016, 02:05:30 PM »
Great video Player!
I also liked your 1v7comps gow video.
Do you really need to drag enemy units into positions in all those places?
It seems like you're leaving peons/peasants standing around that could be brought forward.
I also liked your 1v7comps gow video.
Do you really need to drag enemy units into positions in all those places?
It seems like you're leaving peons/peasants standing around that could be brought forward.
Quote
Rip DKdoesn't seem deceased from my quick google search...?
10
Server.War2.ru / Re: War2 graphics for Win Vista/7/8/8.1/10/2012 fixed
« on: April 06, 2016, 11:56:56 AM »Quote
Both versions have the same bug.. alt+tab chat crashthe minimal version is doing basically nothing...
I can add some checks to the user32/GDI function calls, but I thought they were fairly safe even when they fail.
Quote
full is slower than minimalThat whole part of the full version should be ported to a d3d shader instead of trying to use SIMD
Quote
merge both projects: full and minimalThe full version changes color-depth the minimal version is a study of how DWM broke the game.
There is an overlap between the two if the user doesn't support SSE2, but if that section is ported to a d3d shader then the overlap would be cut from the code.
They should not be merged.
Quote
comments or questionsI'll answer questions...
---
I have to do something to fix the Korean text in Starcraft (broken by changing color depth), doing that might inspire me to put some more time into this project.
11
Mods & Development / Re: War2 100% of 1 core CPU load - CPU Savior, version 2
« on: April 06, 2016, 11:19:58 AM »
untested but same idea ( no fix-ups needed in the injected code )
Code: [Select]
15011370 6A 01 PUSH 1
15011372 FF15 68014900 CALL DWORD PTR DS:[490168] // Sleep in exe IAT
15011378 EB E3 JMP SHORT 1501135D
1501137A 90 NOP
1501137B 90 NOP
data[] = { 0x6A, 0x01, 0xFF, 0x15, 0x68, 0x01, 0x49, 0x00, 0xEB, 0xE3, 0x90, 0x90 };
12
Mods & Development / Re: Re: War2 100% of 1 core CPU load - CPU Savior, version 2
« on: April 06, 2016, 03:53:49 AM »Quote
GetPropA and Sleep is constant in all the systems, past and future. Can it be hardcoded as 3C?
yeah that is NOT going to work
I shouldn't post things without trying them I suppose...
I was thinking it was mov ebx, xxxxx
when it was actually mov ebx, [xxxxx]
/facepalm
13
Mods & Development / Re: Re: War2 100% of 1 core CPU load - CPU Savior, version 2
« on: April 06, 2016, 02:07:09 AM »Quote
Ordinal208 == storm208yeah, IDA just makes up a name for it because it is un-named...
in the "Exports" tab... double-clicking "Storm_208" jumps to "Ordinal208"
This can be checked by looking at it in a debugger,
checking the IAT structure by hand, or using some other tool.
Quote
why EBP-3C is address of Sleep?That is a typo, EBX is the pointer to GetPropA (not EBP)
which would make the first two bytes of data "89 D8" ( not "89 E8" )
ebx == GetPropA == 0x15033270
Sleep == 0x15033234
0x15033270 - 0x15033234 = 0x3C
14
Mods & Development / Re: Re: War2 100% of 1 core CPU load - CPU Savior, version 2
« on: April 04, 2016, 11:38:23 PM »
the dll can be rebased but the exe can not, so the trick is to pull the dll address from the exe IAT.
any reason to avoid patching in-place?
this untested example code makes my eyes bleed less
any reason to avoid patching in-place?
this untested example code makes my eyes bleed less
Code: [Select]
void CpuSaver_Hook_Storm208( HANDLE hProcess ){
DWORD dwPrevProtect;
DWORD storm208_va;
DWORD offset = 0x15011370 - 0x150112E0;
BYTE data[] = { 0x89, 0xE8, 0x83, 0xE8, 0x3C, 0x6A, 0x01, 0xFF, 0xD0, 0xEB, 0xE2, 0x90 };
ReadProcessMemory( hProcess, (void*)0x004902C8, storm208_va, 4, 0 );
VirtualProtectEx( hProcess, storm208_va + offset, sizeof(data), PAGE_EXECUTE_READWRITE, &dwPrevProtect );
WriteProcessMemory( hProcess, storm208_va + offset, data, sizeof(data), 0 );
VirtualProtectEx( hProcess, storm208_va + offset, sizeof(data), dwPrevProtect, &dwPrevProtect );
}
Spoiler
Code: [Select]
/*
old:
1501135D 68 247D0315 PUSH OFFSET 15037D24 ; "SDlg_EndDialog"
15011362 56 PUSH ESI ; hWnd
15011363 FFD3 CALL EBX ; USER32.GetPropA
15011365 85C0 TEST EAX,EAX
15011367 75 13 JNZ SHORT 1501137C
15011369 8BCE MOV ECX,ESI
1501136B E8 40FAFFFF CALL 15010DB0
15011370 68 247D0315 PUSH OFFSET 15037D24 ; "SDlg_EndDialog"
15011375 56 PUSH ESI ; hWnd
15011376 FFD3 CALL EBX ; USER32.GetPropA
15011378 85C0 TEST EAX,EAX
1501137A 74 ED JZ SHORT 15011369
new:
...
15011370 89E8 MOV EAX,EBP // ptr to GetPropA
15011372 83E8 3C SUB EAX,3C // adjust to point at Sleep
15011375 6A 01 PUSH 1
15011377 FFD0 CALL EAX
15011379 EB E2 JMP SHORT 1501135D // loop to GetPropA
1501137B 90 NOP
*/15
Server.War2.ru / Re: War2 graphics for Win Vista/7/8/8.1/10/2012 fixed
« on: February 17, 2016, 04:57:58 PM »Quote
10001284 0019ED54 0001:00000284 C:\War2anti\ddraw.dllthe return address doesn't line up for the current version...?
if the local ddraw.dll loaded at address 0x10000000 then the return address should be 0x10001288 not 0x10001284 ?