ZellSF wrote:Starship Trooper does present a problem with resolution forcing that Populous 3 also has: the game switches between 4:3 menus an […] Show full quote
Starship Trooper does present a problem with resolution forcing that Populous 3 also has: the game switches between 4:3 menus and FMVs and 16:9 gameplay.
If I force resolution to 1920x1440, menus and FMVs will look ok, but unless the game is set to 4:3, gameplay graphics will stretch and have heavily distorted aspect ratio.
If I force resolution to 2560x1440, gameplay works great in fantastic widescreen, but menus and FMVs will stretch heavily distorting aspect ratio.
Not sure I see an easy solution, but have you though about that problem?
Yes. Recently I tried some stuffs on a 4K monitor and encountered a little annoyance: what resolution should I force to 1) max it out and 2) keep the 4:3 aspect ratio. I had to calculate and enter it manually. Not to mention varying in-game aspect ratios...
My first approach is introducing a new type for resolution forcing. We now have 'unforced' and a bunch of other automatically offered ones. I'd like to add a new "max" one or sg like that (didn't yet find a cool name) that would automatically choose a maximum resolution for the given scaling mode/app resolution pair. So, its effect would be the same as of 'Unforced' for scaling modes 'unspecified', 'centered' and 'stretched' (res coming from the app is used) but it'd calculate the max available resolution based on the native one for the others ('Stretch, keep AR', 'Stretch, 4:3 AR').
Remember the DSR and VSR variable in the equation.....I don't think it would be a painless task :p
Hi. I am big fan of Resident Evil classic series, and now I and couple others people working on Resident Evil 3: Restoration Project http://www.moddb.com/mods/resident-evil-3-res … oration-project PC version of this game still have very big unrealized potential. The most of her graphical resources (like backgrounds, movies) performed in full color with 24 bit depth, in spite of this it works only in 16 bit color mode. Image extracted from game resources Ingame screenshoot
This game has built in 32 bit resolution option for all game resolutions, and it really switching display in this mode, but judging by the graphic appearance, it actually works only in 16 bit color anyway. Maybe it's possible to find out how to turn on real 32 bit color mode with dgVoodo or anyhow? Dege, I've heard, you have very good knowledge about DirectX functioning, so can you please help us to find out how to turn on 32 bit color mode for this game?
Hi, first let me tell you how grateful I am for the work you've put into creating such an awesome tool as DgVoodoo 2. Thanks to you I got to enjoy my great old games again.
I've got a question or a query of sort regarding Alone in the Dark The New Nightmare which - contrary to other games- doesn't seem to recognize dgVoodoo 2 at all (and yes, I'm aware of the issues this game presents under 8.1 and Win10 but these can be fixed by using the game's spanish.exe over the original one - tested successfully with the GOG and the Steam version). Has someone tried to get dgVoodoo 2 up and running with Alone in the Dark TNM - even under older OS ? Am I doing something wrong ?
Thanks again for all your efforts, Dege, you're awesome !
is current 2.52 including the GDI for Resident Evil and King Quest 8 videos? I still get black screen but I would like to be sure this is not a problem of my PC.
Many thanks.
KQ8 is Intel Indeo AFAIR, which is currently incompatible with dgVoodoo (black screen is normal in fullscreen, unfortunately, but it should work in windowed mode).
Resident Evil plays its video for me, though not via dgVoodoo. As if it used an external process for video playback. But I'm on Win7, will test it on Win10 soon.
lowenz wrote:
Remember the DSR and VSR variable in the equation.....I don't think it would be a painless task :p
It won't go over the native (well, the desktop...) resolution. 😀
kalash49 wrote:Hi. I am big fan of Resident Evil classic series, and now I and couple others people working on Resident Evil 3: Restoration Pro […] Show full quote
Hi. I am big fan of Resident Evil classic series, and now I and couple others people working on Resident Evil 3: Restoration Project http://www.moddb.com/mods/resident-evil-3-res … oration-project PC version of this game still have very big unrealized potential. The most of her graphical resources (like backgrounds, movies) performed in full color with 24 bit depth, in spite of this it works only in 16 bit color mode. Image extracted from game resources Ingame screenshoot
This game has built in 32 bit resolution option for all game resolutions, and it really switching display in this mode, but judging by the graphic appearance, it actually works only in 16 bit color anyway. Maybe it's possible to find out how to turn on real 32 bit color mode with dgVoodo or anyhow? Dege, I've heard, you have very good knowledge about DirectX functioning, so can you please help us to find out how to turn on 32 bit color mode for this game?
Great Project!!
If the game switches to 32 bit mode and the textures (background) suffers from quality loss in spite of that, then I guess there are some surface copy operations in the background before it get rendered to the screen.
For example, I can imagine the following:
- The game create a temporary 32 bit software surface and copies the 32 bit texture data into it, from its resources
- Then it creates a permanent 16 bit surface in video memory (16 bit to spare with video memory) and copies the content of the temporary 32 bit surface into it; this is where the quality loss takes place
- When rendering the frames ingame, then it copies the 16 bit surface into the 32 bit backbuffer
Unfortunately it's very hard, if not impossible, to figure out what's going on exactly without hooking the old DX interfaces and trace what happens there. 🙁
Earlier I was pondering if dgVoodoo were useful not only for playing old softwares but for general debugging and understanding their working, like in the case of this project.
What if I made a 'dev' version of the DX dlls along with a debug layer?
The source of the debug layer dlls would be public, and the debug version of the DX objects would embed the real (dgVoodoo) ones with some additional pointers into its internals. So, a developer could debug the same way as I can.
Andromedius wrote:
Thanks again for all your efforts, Dege, you're awesome !
Thanks! 😎
I didn't try Alone in the Dark TNM though.
Dege wrote:Unfortunately it's very hard, if not impossible, to figure out what's going on exactly without hooking the old DX interfaces and […] Show full quote
Unfortunately it's very hard, if not impossible, to figure out what's going on exactly without hooking the old DX interfaces and trace what happens there. 🙁
Earlier I was pondering if dgVoodoo were useful not only for playing old softwares but for general debugging and understanding their working, like in the case of this project.
What if I made a 'dev' version of the DX dlls along with a debug layer?
The source of the debug layer dlls would be public, and the debug version of the DX objects would embed the real (dgVoodoo) ones with some additional pointers into its internals. So, a developer could debug the same way as I can.
Thanks for your answer. It will be great if it can help, but I doubt that we could perform such analysis by using your tool cause we not a programmers, but we try to find someone who can. Thank you.
kalash49 wrote:Hi. I am big fan of Resident Evil classic series, and now I and couple others people working on Resident Evil 3: Restoration Pro […] Show full quote
Hi. I am big fan of Resident Evil classic series, and now I and couple others people working on Resident Evil 3: Restoration Project http://www.moddb.com/mods/resident-evil-3-res … oration-project PC version of this game still have very big unrealized potential. The most of her graphical resources (like backgrounds, movies) performed in full color with 24 bit depth, in spite of this it works only in 16 bit color mode. Image extracted from game resources Ingame screenshoot
This game has built in 32 bit resolution option for all game resolutions, and it really switching display in this mode, but judging by the graphic appearance, it actually works only in 16 bit color anyway. Maybe it's possible to find out how to turn on real 32 bit color mode with dgVoodo or anyhow? Dege, I've heard, you have very good knowledge about DirectX functioning, so can you please help us to find out how to turn on 32 bit color mode for this game?
Great Project!!
If the game switches to 32 bit mode and the textures (background) suffers from quality loss in spite of that, then I guess there are some surface copy operations in the background before it get rendered to the screen.
For example, I can imagine the following:
- The game create a temporary 32 bit software surface and copies the 32 bit texture data into it, from its resources
- Then it creates a permanent 16 bit surface in video memory (16 bit to spare with video memory) and copies the content of the temporary 32 bit surface into it; this is where the quality loss takes place
- When rendering the frames ingame, then it copies the 16 bit surface into the 32 bit backbuffer
Unfortunately it's very hard, if not impossible, to figure out what's going on exactly without hooking the old DX interfaces and trace what happens there. 🙁
Earlier I was pondering if dgVoodoo were useful not only for playing old softwares but for general debugging and understanding their working, like in the case of this project.
What if I made a 'dev' version of the DX dlls along with a debug layer?
The source of the debug layer dlls would be public, and the debug version of the DX objects would embed the real (dgVoodoo) ones with some additional pointers into its internals. So, a developer could debug the same way as I can.
The game resources are palleted textures with 32 bit color tables, but hose are converted to 16 bit (A1R5G5B5) surfaces: conversion is done in software: the game changes the pixel format as it reads the texture data and copies it to locked textures.
My software could be used to swap the textures with 32 bit ones, but to complicate things further, the game uses big 1024x1024 or 512x512 textures which are divided in smaller 256x256 patches that correspond to the real images found in disk. This also adds the trouble to the game engine of transforming the texture coordinates in each object depending on where its texture was loaded (it varies). No idea why the game was coded like that. Fortunately, my software is fully scriptable and i'm close to finishing a script that allows it to swap textures in RE3
kalash49 wrote:Hi. I am big fan of Resident Evil classic series, and now I and couple others people working on Resident Evil 3: Restoration Pro […] Show full quote
Hi. I am big fan of Resident Evil classic series, and now I and couple others people working on Resident Evil 3: Restoration Project http://www.moddb.com/mods/resident-evil-3-res … oration-project PC version of this game still have very big unrealized potential. The most of her graphical resources (like backgrounds, movies) performed in full color with 24 bit depth, in spite of this it works only in 16 bit color mode. Image extracted from game resources Ingame screenshoot
This game has built in 32 bit resolution option for all game resolutions, and it really switching display in this mode, but judging by the graphic appearance, it actually works only in 16 bit color anyway. Maybe it's possible to find out how to turn on real 32 bit color mode with dgVoodo or anyhow? Dege, I've heard, you have very good knowledge about DirectX functioning, so can you please help us to find out how to turn on 32 bit color mode for this game?
Great Project!!
If the game switches to 32 bit mode and the textures (background) suffers from quality loss in spite of that, then I guess there are some surface copy operations in the background before it get rendered to the screen.
For example, I can imagine the following:
- The game create a temporary 32 bit software surface and copies the 32 bit texture data into it, from its resources
- Then it creates a permanent 16 bit surface in video memory (16 bit to spare with video memory) and copies the content of the temporary 32 bit surface into it; this is where the quality loss takes place
- When rendering the frames ingame, then it copies the 16 bit surface into the 32 bit backbuffer
Unfortunately it's very hard, if not impossible, to figure out what's going on exactly without hooking the old DX interfaces and trace what happens there. 🙁
Earlier I was pondering if dgVoodoo were useful not only for playing old softwares but for general debugging and understanding their working, like in the case of this project.
What if I made a 'dev' version of the DX dlls along with a debug layer?
The source of the debug layer dlls would be public, and the debug version of the DX objects would embed the real (dgVoodoo) ones with some additional pointers into its internals. So, a developer could debug the same way as I can.
The game resources are palleted textures with 32 bit color tables, but hose are converted to 16 bit (A1R5G5B5) surfaces: conversion is done in software: the game changes the pixel format as it reads the texture data and copies it to locked textures.
My software could be used to swap the textures with 32 bit ones, but to complicate things further, the game uses big 1024x1024 or 512x512 textures which are divided in smaller 256x256 patches that correspond to the real images found in disk. This also adds the trouble to the game engine of transforming the texture coordinates in each object depending on where its texture was loaded (it varies). No idea why the game was coded like that. Fortunately, my software is fully scriptable and i'm close to finishing a script that allows it to swap textures in RE3
Couldn't the executable be patched in a way that texture surfaces are allocated with a 32 bit pixel format (if the game enumerates tex formats) and format-converting code is cut out so that the game simply copies the texture data?
Texture coordinates shouldn't be a problem, only the format would change.
Couldn't the executable be patched in a way that texture surfaces are allocated with a 32 bit pixel format (if the game enumerates tex formats) and format-converting code is cut out so that the game simply copies the texture data?
Texture coordinates shouldn't be a problem, only the format would change.
Texture coordinates are not a problem because i'm organizing the replacements following the same layout as the original textures. The only problem is that i have to force the game to render everything twice, one with the original textures, another with the replacement, If there is no replacement for a particular texture, the corresponding area in the replacement will be black and will be discarded with color keying. Rendering everything twice doesn't really impacts performance in any decent computer, even without dgVoodoo. Modding the executable is a option, but not my expertise. Seven months ago, i would be a weekend away from finishing the RE3 patch, but now with my daugther it might take a little bit longer
Year after year we were tryin' to emulate this baby in ways beyond imagination with so many failures it is uncountable., we were on a verge to dissasemble the damned thing.
There is something "special" in their specific Dx7 implementation which never worked 'good' on any emulator, VM machines. you name it , it just didn't work.
Last operating platform was Win7(/64) and that wasn't without "PAIN'. From vsync to the 16bpp textures gradiency, z buffer,... all kind of problems.
Especially it was designed for Nvidia more then Ati (God knows why, maybe broken drivers...) an since I have Ati5770 ... more frustration, please, yeah.. 🤣
With Win8.1(/64) things went down completely ... NoGo, nadda, zilch...
...Until , one beautiful, (day of the tentacles intro muse here), morning ... Some google-fu draft me to DgVoodoo site again , after years of non-Glide,...
I have previous experience with Jane's Longbow 2 and Janes F-15 in glide ... and results were ok, whether NGlide was a bit better with F-15, but nvm all that now..
Back to the point.
I've fired Janes Fa18 in DX7 emu with DgVoodoo ... and .. WHam , out of blue ... it works... damn, says me to myslef .. looks promising..
Have little troubles with menus not in aspect (mouse offset) , but I've came into the pit .. and ..Jesus, I Live ... again ...😁
THANK YOU, DEGE, no really , You are on the best way to DX7 .. ( I just couldn't believe with my very own eyes)
You've gave us back something that was almost so faint... HOPE
Please do continue with your finest project in the world. ... our Greatest Gratitudes from virtual flyers from SimHQ.
If you manage, anytime to deal with this game , we'll send You the BIGGEST Slavonian HOT SAUSSAGE (Kulen) in the world.
Cheers and Thanks
1Beneath a Steel Sky: 2 Lamb: What's that ROBOT doing here? 3 Foster: He's my PERSONAL ASSISTANT. Say Hello Joey 4 Joey: Hello, Joey. 5 Lamb: HUH! Pity it's got no BRAIN.
Lifeforce Tenka: FMVs don't work (but they don't work natively either, so...), resolution forcing doesn't work (seems to be software rendered). Game itself works perfectly though.
Tank Racer: Works perfectly, including resolution forcing, which is nice since this game only offers a limited choice of available resolutions and doesn't scale its UI up to any of them.
Year after year we were tryin' to emulate this baby in ways beyond imagination with so many failures it is uncountable., we were on a verge to dissasemble the damned thing.
There is something "special" in their specific Dx7 implementation which never worked 'good' on any emulator, VM machines. you name it , it just didn't work.
Last operating platform was Win7(/64) and that wasn't without "PAIN'. From vsync to the 16bpp textures gradiency, z buffer,... all kind of problems.
Especially it was designed for Nvidia more then Ati (God knows why, maybe broken drivers...) an since I have Ati5770 ... more frustration, please, yeah.. 🤣
With Win8.1(/64) things went down completely ... NoGo, nadda, zilch...
...Until , one beautiful, (day of the tentacles intro muse here), morning ... Some google-fu draft me to DgVoodoo site again , after years of non-Glide,...
I have previous experience with Jane's Longbow 2 and Janes F-15 in glide ... and results were ok, whether NGlide was a bit better with F-15, but nvm all that now..
Back to the point.
I've fired Janes Fa18 in DX7 emu with DgVoodoo ... and .. WHam , out of blue ... it works... damn, says me to myslef .. looks promising..
Have little troubles with menus not in aspect (mouse offset) , but I've came into the pit .. and ..Jesus, I Live ... again ...😁
THANK YOU, DEGE, no really , You are on the best way to DX7 .. ( I just couldn't believe with my very own eyes)
You've gave us back something that was almost so faint... HOPE
Please do continue with your finest project in the world. ... our Greatest Gratitudes from virtual flyers from SimHQ.
If you manage, anytime to deal with this game , we'll send You the BIGGEST Slavonian HOT SAUSSAGE (Kulen) in the world.
Cheers and Thanks
Well, shortly: Great to hear that, thanks!! 😎😎
Are you experiencing mouse/menu problems in forced windowed mode or in fullscreen too?
Some(?) apps in windowed mode are sensitive for the window position, so if it's not in the top-left corner of the screen then mouse offset problems occur, unfortunately.
Anyway, I'll try that game some day. Now I'm busy with building the test result base for the games/demos I've ever tried, and for new ones that the community reports (+implementing some things that are missing from 2.52). In this way anybody can see the expected results, and so they don't exist only in my head. 😀
Lode Runner 2 does not work properly, it fails to clear the screen between frames, so you see previous frames on parts of the screen that haven't changed. Works perfectly natively.
Dege wrote:Well, shortly: Great to hear that, thanks!! :cool: :cool:
Are you experiencing mouse/menu problems in forced windowed mode or […] Show full quote
Well, shortly: Great to hear that, thanks!! 😎😎
Are you experiencing mouse/menu problems in forced windowed mode or in fullscreen too?
Some(?) apps in windowed mode are sensitive for the window position, so if it's not in the top-left corner of the screen then mouse offset problems occur, unfortunately.
Anyway, I'll try that game some day. Now I'm busy with building the test result base for the games/demos I've ever tried, and for new ones that the community reports (+implementing some things that are missing from 2.52). In this way anybody can see the expected results, and so they don't exist only in my head. 😀
Thanks to you too, You've managed something nobody else did in at least 10yrs... not that everyone tried, but nobody has gone this far in ddraw/d3d emu approximation.
You're running DEMOs in emu, .. and few ppl understand how to code a demo , how to run direct asm graphics through emu is , huh, even worse 😉
1st I must warn that I've 2 monitor configuration, different res,.. one atop other,.. 16:10 is above, 5:4 below.
This is one of many? apps (game) which has different res for intro(video)/menu/3dworld
It actually refuses to run intro/menu's in fullscreen, whatever you change., it tries at startup (black screen) but fails and revert to default (800x600?) window at that 50x50 position. (in 3d it runs perfectly fullscreen, bit of text on mfd's - (small screens with radar etc..) are dissapearing in certain angles of view left/right/up, nothin gamebreaking, when you look straight front , all ok)
Anyways, like what you've guessed is exactly(?) part of the problem, window pos. of menu screen, because it is spawned at approx 50x50px , instead 0,0 , so there's that Y offset in mouse.(when I move window , by alt+space then move with cursors, at cca 0x0 location, Y offset gets smaller, about 1cm - so its a start 😉 )
Strangely enough offset appears only in Y axis, X seems OK., about 50px., and game window dialog buttons Yes/No(one of the pictures) are not affected, huh?)
So when selecting standard menu options you have to click about 2cm above to get one you want selected.
And there's screen redraw NOT happening when advancing through menu's - luckily there's only 3-4 screens to the game.,
aircraft arming/pilot selection screen is bit problematic, drag and drop function , so you dont know what you've changed until you re-drawed screen,
but simple by minimize - restore window. (or click on the right window border, redraws window too... (?):) )
So, OK, about getting the sim , well I must say it is still NOT abandonware (ah EA, from 98') but after applying (only) 1.01F patch it removes cd-check routines .. so 😎
I'll upload some shots.. and edit post.. so try to present all this by pics.. (only mouse cursor is not visible, but on one screen it can be seen date from file from window under the game window.. like transparent miracle 😀 , so you can guess where is mouse cursor really)
Resident Evil 3 is hardwired for 16 bit texture formats. Surfaces can have formats with and without alpha component.
I've did some modification so that the game always chooses a 32bit ARGB format for surfaces with alpha and rewrote some 16bit format-converting code as well. (It would be nice to have both but I couldn't find enough room for that.)
However surfaces without alpha cannot be converted to 32bpp because some of them are drawn using additive blending which causes serious artifacts: e.g. flames, fume or shadows have grey background because converting to 32 bit doesn't chop off (greater accuracy) the needed pixels to 0 (black) which is essentially needed. So they are still 16 bit.
Type of the textures used for FMV playback is also modified to alphaed, so the FMV's are 32 bit too.
I'm unsure about the backgrounds because there are some of them where I cannot see any difference between the 16bit and 32bit ones.
I did only quick tests with FMV playing and starting a new game, so it could turn out that this patch is unusable.
Sorry to attach it here but currently I cannot reach my site because there was a maintenance on the hosting side and sg went wrong, I'm going to have fun with the provider next week.
Edit: sadly it seems the game converts textures to 16bit before pushing them to DX, so using 32 bit surfaces itself is not enough. 🙁
Akuji The Demon: works perfectly. Force resolution to a multiple of 640x480 for sharper scaling. Needs D3DRM.DLL.
Rival Realms: works perfectly, but using dgVoodoo2's aspect ratio correction results in black screen. Also this is one of those games with a flickering cursor if vsync is enabled. Setup needs Windows 95 compatibility mode.
The Tone Rebellion: Mouse only responds some of the time, can't get keyboard shortcuts to work. Unplayable. Some sort of focus issue? When I force it windowed it has focus all the time though and still won't respond though... Tried changing the "Disable Alt-Enter to toggle screen state" option, no change.
It's not that important, as it works perfectly natively. Manual install instructions: Just copy THING1 to a folder, it will look for a key named HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\The Logic Factory\The Tone Rebellion\111 and a REG_SZ value named "cdrom" to figure out where to look for the THING2 folder (which has music).
Diggles: doesn't render fullscreen (game runs and plays sound, but no image). Performance terrible in windowed mode. Works fine natively. You need to import a reg file since autodetection of graphic settings is broken and so is the program for manually configuring them...: http://pcgamingwiki.com/wiki/Diggles:_The_Myth_of_Fenris
Clue - Murder at Boddy Mansion: works perfectly, no dgVoodoo2 issues. This is one of those annoying games that care which DirectShow filters you have installed, so if you can't run it, that's why.
Resident Evil 3 is hardwired for 16 bit texture formats. Surfaces can have formats with and without alpha component.
I've did some modification so that the game always chooses a 32bit ARGB format for surfaces with alpha and rewrote some 16bit format-converting code as well. (It would be nice to have both but I couldn't find enough room for that.)
