I'll look into it sometime, SourceForge is currently throwing a 500 error.
DirectDraw provides no hardware support for anti-aliasing AFAIK
I see no reason to add it since I'm not stretching anything with this dll
Hi aqrit, I just registered to ask for your help.
In short, Red Alert 2[ & Yuri's Revenge] on Windows 8 Consumer Preview (and for some folks with Windows 7 and I don't know what Windows update or low power mode laptop video card drivers) fails to initiate the main menu buttons animation (otherwise the game runs fine, maybe with small really short hickups every 3-4 seconds).
I found a weird fix: draw an overlayer on top of the game using Logitech Setpoint (OSX/iOS like icon for indicating current volume or Caps Lock state).
Other overlayer drawing software (to which I have access to source code, such as "volume2") do not unblock the main menu buttons.
Other than that, I tried your wrapper DLL and it didn't have any side effects (all options on auto), nor did it fix the menu buttons behaviour.
Thanks for your help in advance 😀
All I could find of my copy of RA2 was the manual 🙁
AFAIK the "First Decade" pack is still available at the local store though.
I have to assume it has problems similar to RA1.
I can't tackle this game in a generic fashion until I decide how to handle primary surface locks. I see others fake the front buffer then blit to the real surface ~60 times a second. However, I would like to have the front buffer mapped into the process address space somehow.
Have you tried running the game under wined3d?
----
interesting link: early directx sdks here
I actually looked for Wine under Windows and found nothing, thanks for telling me about it:)
The wine3d installer required Safe-mode.
In safe mode I had to take ownership of System32 and SysWOW64 and give Full permissions.
In normal mode, the game now crashes with error code 0xc000007b.
Since the problem I described only exists in the main menu, I will keep on looking for what SetPoint actually does when drawing that overlayer.
If you happen to know where to look, please point me in the right direction.
Thanks.
Fixed an issue with the wrapper code that was causing a blank screen on
OpenGeneral and probably hundreds of other games.
---
YURI runs fine here so it will be hard for me to debug.
It sounds like an issue with specific drivers...
so the best solution from my point-of-view will be to add front buffer locking in HEL
YURI also works here under just the wined3d ddraw lib
open wined3d.exe inside of 7zip
and extract libwine.dll, wined3d.dll, and ddraw.dll from $SYSDIR into your game folder
Placed the wined3d ddraw.dll (and libwine.dll, wined3d.dll).
No issues on a working Windows 7 64bit (edit: crashed once after 30 minutes of network play, and the buttons now freeze if alt-tabbing, yet they recover on first click and then keep on working).
Rebooted in Windows 8 (64bit).
Menu buttons animation is fixed.
While playing, the mouse cursor is flickering fast, and the game stutters badly, and is slow (compared to how fast it worked with these libraries on 7).
After exiting to the main menu, menu buttons frozen problem was back, and worse, nothing (needed task manager) could overlap the game.
I have installed the video card drivers from AMD.
Me thinks Microsoft has removed something, or is somehow keeping the video card in low power mode?
Thank you for the new version, open general runs now good for me.
Awesome. DOSFreak's llink fixed Stronghold HD in Win8 for me. Woot.
Been trying to use this with Dark Omen to resolve my win8 issues:
Dark Omen Windows 8
however just gives me a crash. If its any help dark omen is a Dx5 game. Thanks
Hi,
I tried your DirectDraw Wrapper with Blade Runner to limit the FPS. In general, the game works fine on Windows Vista, Windows 7 and Windows 8 (I developed a patch and a new installer), but, caused by a too high framerate, some sequences cannot be passed.
"NoVideoMemory" and "FakeVsync" succesfully limit the frames, but the screen is flickering in green color shades. Any idea?
Regards
I'm popping in just to let people know I'm not dead :p
---
I fixed one of the bugs in NoVideoMemory a few days ago, make sure you have the lastest version. Whenever I see alot of green I want to assume its a 555 vs 565 color bug. I ordered a copy of Blade Runner, I'll take a look when it shows up.
Collector added "some kind" of graphic fix to his installer.
http://archive.adventuregamers.com/forums/sho … ead.php?t=30597
----
I'll get my Dark Omen CD back sometime around XMAS.
Once I get Win8 install I'll take a look at that too.
I'm not entirely sure what Dark Omen is doing.
Rumor has it that it supports Glide, I know it static links to Direct3D.
---
here some stuff on getting some Command & Conquer games running with win8 http://cnc-comm.com/community/index.php?topic … g11551#msg11551
---
lately I've been looking at generically converting paletteized games to 16-bit color. http://www.bitpatch.com/downloads/palette_test.cpp GDI32.BitBlt converting to 16 bit-color is pretty snappy (0.5ms). BitBlt converting to 32-bit color takes twice as long as it does if converted by hand. But we can't really convert by hand because we shouldn't be locking the primary surface. It seems the real speed difference between 32 and 16 bit colors is simply how many pages of memory a 640x480x32 texture spans.
Final Liberation is one of those games that would benefit from running entirely in 16-bit color... (can't be fixed by colorfix=1) But I've decided to hard-code a patch to do that for this game [ edit: http://bitpatch.com/downloads/fl_highcolor_patch.zip ] . By stopping the game from changing display modes we also fix the crashing on WinXP.
/ramble
I ordered a copy of Blade Runner, I'll take a look when it shows up.
That's great, thank you.
555 vs 565 color bug
Well, I recorded a short video. Take a look: http://www.youtube.com/watch?v=DYE2zZmF7m0
Hi,
Thanks for putting this .dll together. I have just tryed your latest version with RayForce (aka Layer Section aka Galactic Attack) under WinXP and it was able to make the framerate more playable. Still mucking around with the settings so I'm not sure I have it running perfect, but it is this (wrapper?) has done the best job so far that I have found.
A couple of requests or questions as to whether these features might be possible in the future;
1) Being able to force display output to windowed mode instead of a game defaulting to fullscreen?
2) If 1) is possible then to be able to specify window size.
3) possibility to have a "output" framerate counter.
(I have checked Fraps FPS counter works with your .dll as an alternative in the interim)
PS: Tried D3DWindower to do 1) & 2) above but noticed that it introduced a 'flickering' or 'blinking' to the displayed output.
Thanks.
Actually after trying a few different settings out with Raiden 1 it seems best to keep things simple.
In the aqrit.cfg using FakeVsync = 1 by itself seems to be the only way I could play the game without it crashing after a random amount of time. Using one or more of the other options seems to cause random crashing but I couldn't find which setting/s exactly were the culprit so I decided to just make all the other options = 0 which resulted in the game working fine.
Out of the three different options pertaining to 'framerate' FakeVsync = 1 was the only one that gave me the best results... well, sorta.
You see it's not quite 60 FPS it ends up averaging around 65 FPS (oscilating between 58FPS and 68FPS) but that is a better result than anything else I have tried so, hmm.
I'll spend a little bit more time and if I find anything else worth mentioning I'll report back.
Edit:
~~~~
Ok, I just turned VSync off in my video driver and now the framerate oscilates between 65FPS & 69FPS so the average is around 68FPS. It makes things a bit smoother since the framerate is not making large movements. But it is still a shame it is not fixing it to 60FPS? I'll have to make my reaction times 10 percent faster to compensate. 😅
hi,
I have/know-how-to add windowed mode to ddraw games, but I have no plans to add that feature to this wrapper. I link to DxWnd in my readme... did you try that?
FakeVsync targets 71 fps because I have it sleeping for 14ms between frames.
It can easily be made to target 62 fps by simply changing the sleep interval to 16 ms. This was also an issue with Total Soccer 2000, which I "fixed" yesterday by simply reporting a Monitor Frequency of 71Hz if FakeVsync=1. So grab the latest version... and see if it is also fixed for your game.
Yes, it is possible to add a frame rate counter.
Anytime I've needed it I just drop it into the debug build and log it to a file.
I'll add an on-screen display at some point.
----
@Mr.Blade
Blade Runner should now work with the NoVideoMemory option.
GetCaps and GetSurfaceDesc now lie and add the DDSCAPS_PRIMARYSURFACE flag when reporting the characteristics of the Fake Primary Surface.
I didn't take the time to reverse things any further.
---
Also fixed a regression with ForceBltNoTearing today.
Hi Aqrit,
Wow, cool a new version to try. Just trying it out now...
1) Trying this and the previous version does nothing with Raiden II. The game appears to lock the framerate internally or something similar because it will always run at a rock stable 59/60FPS. I enabled/disabled video card VSync, tried all the settings in your config file, but nothing has an effect on the game. No complaints, just an observation.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Edit:
Actually, I should explain that I only tried using your .dll with this game because when you first start level one the scrolling forest has a kind of wave effect to it as if it is not scrolling 100% perfect. It is not 'tearing' though. Also, the scrolling of the trees creates a kind of blinking light effect around them which is distracting. The two 'problems' are not that bad though and I suppose some people might not even notice them. Maybe nothing can be done about it anyway, as it might just be the result of the games internal framerate limiting?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2) Trying this new version with RayForce, ok I can confirm that the framerate is now at a rock stable 71/72FPS. The game feels too fast though. I assume it is suppose to run at 60FPS. I am thinking most of the older games were made to run at 60FPS (or 30FPS if you go way back)?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Results:
Video Card VSync ON and NO .dll = 200+FPS
Video Card VSync OFF and NO .dll = 200+FPS
Video Card VSync ON and .dll FakeVSync OFF = 600+FPS
Video Card VSync ON and .dll FakeVSync ON = 71FPS
Video Card VSync OFF and .dll FakeVSync OFF = 600+FPS
Video Card VSync OFF and .dll FakeVSync ON = 71FPS
So it doesn't matter if I have Video Card VSync enabled or disabled, yay!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I would love to try a version with target 62FPS please. Wonder if the extra 2FPS could be turned into some kind of buffer like triple buffering for example? Maybe that could net us 60FPS?
Please don't think I am trying to upset you but why were you targeting 71FPS?
Anyway, thanks for improving the FakeVsync & ForceBltNoTearing.
PS: I can't compile myself which is why I ask for a 60 or 62 FPS version.
hi,
I have/know-how-to add windowed mode to ddraw games, but I have no plans to add that feature to this wrapper. I link to DxWnd in my readme... did you try that?
I looked at DXWind but couldn't work out how to force into a windowed mode. None of the options screamed to me 'click here to run in a window'.
I'll have another look.
wrote:hi,
I have/know-how-to add windowed mode to ddraw games, but I have no plans to add that feature to this wrapper. I link to DxWnd in my readme... did you try that?I looked at DXWind but couldn't work out how to force into a windowed mode. None of the options screamed to me 'click here to run in a window'.
I'll have another look.
You may change Directx version Hook to" Directx1~6" and Emulation to "Primary Surface" in Dxwnd Option, it should work for most games. If not simply send a question to http://sourceforge.net/p/dxwnd/discussion/. Hope that help!
