There's a new version of War2Observe that fixes the crash issue,
download from the downloads page today!
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.
there is currently no fix to scale windows 10 full screenThe issue is not due to the OS, but instead your graphics card settings.
ive looked
Here's another problem reported from newbie: a notebook (he didn't call a model), resolution 1366х786 , win 8.1.He needs to configure the scaling options for his graphics card. There's instructions on Google for this.
He got fresh war2 at 1/4 of screen, also your ddraw.dll didn't resolve the problem.
But another project called ddhack10 helped him.
At the same time ddhack10 is unplayable as known, but maybe there's something to get from that project and to add to war2_ddraw_test to ToSceen?
Also, to everyone: please, notify us if you have the same problem with war2_ddraw_test2. Need to have a system to test.
1. Does "in-game" Broodwar have any open SDlgDialog windows?I have no idea, and don't know how to check. My best guess is probably yes when you click on the menu button.
2. For Each SDlgDialog window GdiTransparentBlt color converts the same 640x480 from 8bpp to 32bpp each time... Would it be faster to color convert once then GdiTransparentBlt out to all the windows?Not a graphics programmer, but to check if anything is faster, you would profile the code.
3. Would it be faster to GdiTransparentBlt only the changed portions of the screen instead of the entire screen to every window... Unfortunately the game locks the entire screen so we don't immediately know where changes occur. However, since we know every unchanged scan line will be all 0xFE bytes... it should be possible to do a quick hash of a scan line to know if anything on that line has changed... which would allow us to quickly determine a bounding rect around changes which we could then intersect with the window rects thus allowing us to move much fewer bytes around.Updating only parts of the screen is what modern video encoding libraries and game developers do nowadays so it should be faster. Maybe it's even faster to just check the first few bytes of a line for 0xFE bytes instead of hashing the whole line, what would go wrong if this assumption is incorrect?
4. The only thing we can do for "ddraw only mode" is switch to uploading to video memory with a real API, not GDI. But that means when switching from "mixed mode gdi/ddraw" to "ddraw only" we need to clear any gdi stuff... can we just paint the main window with a NULL_BRUSH or do we have to destroy and re-create the main window?Are you suggesting to interpret the DirectDraw calls and use something like OpenGL or DirectX to draw to the screen instead?
Not sure if that could help, but maybe to use an idea from cpu savior? http://forum.war2.ru/index.php/topic,409.0.html
The idea was to add sleep 1ms in each gdi drawing loop or w/e.
If it redraws mixed ddraw+GDI millions times per second, it causes CPU utilization. If you add timeout into the graphics loop, if will free the CPU.
Another idea is to enforce your code 1 time of 1000, not every time. Then interface will be fixed not in realtime but with a little delay.
noSeems to also work for StarCraft!
Great, you playing on USeast?
Sent from my Motorola DynaTAC 8000X using Tapatalk
how does w-mode work? is it something Lance could replicate for War2?I don't really know the specifics since the source code isn't available. I do know that some Windows and DirectDraw functions are hooked at least.
