iF-22 odd color keying issues
Window hooker to run fullscreen programs in window and much more...
Status: Beta
Brought to you by:
ghotik
Menu
▾
▴
Hi! I'd like to get some pointers (maybe some combos of options to try) for solving some weird transparency issues and missing text & graphics in the menus for I-Magic's "iF-22" from 1997. At this point I've done about 15 hours of research and trying combinations of fixes through dxwnd 2.04.26. I did find a thread talking about iF/A-18E, which is the sequal to iF-22, but I wasn't able to use the tips from that thread to solve iF-22's issues. The most interesting results I've gotten are by turning on the Flip/Blt Wait, which I think prevents some normally-hidden menu items from being drawn over unintentionally by other rectangles; but then the content of the screen never gets cleared - the next "page" of the menu just gets flipped over the last page to create a jumbled mess. But with all the testing and tweaking I've done, I can't get the menus to a playable state.
I have noticed, however, that the active UI in all cases is fully functional - meaning invisible buttons are right where they should be.
Any combos of options you'd recommend? Maybe I have missed some. I do have a dxwnd.log with DirectDraw trace info logged if that would help.
I'm totally new to forum etiquette so hopefully it's OK that I posted a couple of links to images showing what I'm talking about.
https://ibb.co/gSUai5
https://ibb.co/hqrAGQ
Last edit: gho 2017-05-03
Hi. No problems with the pictures, I just tried to edit your post to make it show the pictures directly, but the trick didn't work, maybe because it wants a http URL and your images are hosted on a https server. Never mind, I'm duplicating them here.
I'm surely going to grab a copy of iF-22 and make some testing, but as far as I could understand and looking at the screenshots, i'd say that here we have another nasty problem of interaction between DirectX rendering and GDI/USER32. The old games mixed the two techniques quite often, but the integration of the two follows rules quite different between a fullscreen and windowed environment, always giving me serious troubles.
In any case, if the guess is correct, the place to look for is surely the DxWnd "Libs" tab, in particular the GHI handling panel that let you pick one of the four integration policies developed so far (No GDI handling, Scaled GDI calls, Emulated Device Contet and Share ddraw and GDI DC).
Once selected the optimal policy, the flags below can help tuning specific problems.
But to be honest, remembering all the troubles that this integration gave and is still giving me, I woudn't expect to find a magic recipy: all these logics are quite imperfect and will likely require some coding intervention, a thing that I will be very happy to do also with your help for finding further problems. So, let's stay in touch.
Last edit: gho 2017-05-03
My God! Here is a proof of the game weirdness: it doesn't blit on a single window, but it uses two, presumably one for ddraw rendering and the second for forms data entry. As I said, in fullscreen mode only the window currently used is shown, while in windowed mode the two window can coexist and will overlap each other according to Z ordering rules. In the screenshot I managed to move each window in a different position so that both are visible. In the other screenshot the result of my forst mission. I think that this game will provide fun for a while ...
P.s. to syncronize our researches, may I ask you what configuration you were using to get your screenshots? Just right-click on the DxWnd game entry, select "export ...", create an exported dxw file and post it here. In the meanwhile I fixed the scaling error for the rounded boxes (see my screenshots), if youre interested I'm posting the fixed dll here.
Last edit: gho 2017-05-03
Another surprise: while I was trying to find the reason for the bad colors in window mode I simply discovered that .... the same happens also in fullscreen mode! Look at the screenshots.
But that doesn't mean I won't try to fix the problem.
Screenshots in windowed mode:
And screenshots in fullscreen mode. The main difference is that in windowed mode some picture may disappear togheter with some text. By the way, I'm trying to verify one hypothesis, that the text is not lost but simply drawn black on black, then invisible.
Last edit: gho 2017-05-03
First of all, thanks so much for delving into this. I have about a 2 hour free window after the kid goes to bed, so you'll probably only hear from me once a day.
I did play around with the GDI settings (Libs tab) for a few hours and got some interesting results, especially interesting for diagnostics if I had a clue about DDraw and GDI programming. There do seem to be some pallette or colorkey issues related to the text disappearing and the big white boxes impinging on the rounded rectangles in the menu UI, so your theory about black on black text would make sense. I posted the export file here.
I also see now how in windowed mode you can separate or line up different components of the UI depending on how you size the window; the DDraw elements seem to sit on a certain x,y coordinate from one corner, the image size and location scales with the window (though not sure why they're disappearing and coming back randomly) and the controls might be using x,y coordinates based off a different corner of the window (maybe that's a DDraw vs. GDI thing).
Nice first flight :) And thanks for the DLL, although I can't reproduce the rounded rectangle scaling issue you seemed to have in windowed mode.
Let me know what I can do from here to help.
Also - can you tell I'm trying to use the correct terms here? Hopefully I don't sound like a moron.
>> I have about a 2 hour free window after the kid goes to bed, so you'll probably only hear from me once a day
No problem, that holds also for me (children have grown up enough to mind themselves without the goodnight song, but still free time hasn't grown that much ...) though by using the smartphone I sometimes give the fake impression of being always available.
Neverthless, in the little dedicated time I made a few small steps forward.
First of all, yes, we have to deal with a palette problem, probably a unhappy choice of the 16 system colors of the old 16bit platforms (Win3.1!). By setting the "Libs / Syncronize GDI to ddraw palette" you can scramble the palette definition in a bad way, but altering the colors enough to show that the graphic is all there (look at screenshot "syncpalette.png"), simply invisible because of the wrong color. Of course the effect of the flag on the gameplay is not good (see "syncpalette2.png") so let's forget about it, but that just demonstrates that we don't have to make GUI elements visible, but simply color them with good colors!
Second news is a bad news: apart from the known problems, it seems that at the ending of a flying mission the game stops itself. It showed the screenshot in "block.png" that was somehow active (the program was updating the cursor shape while hoovering the differeng sections) but unresponsive to commands. Well, too bad!
Third news a good news: I'm improving my pilot skills, I learnt how to land without harm (see safelanding.png). Too bad I have to pick another plane afterwards... ;)
>>Also - can you tell I'm trying to use the correct terms here? Hopefully I don't sound like a moron.
Man (or mylady, maybe...), you said correct terms? But I'm the king of randomic technical jargon, if you need some seemingly good technical definition you're asking the right guy. :)
Last edit: gho 2017-05-04
Small update today: always seeking for a clue to find the game good old native behaviour, I installed it inside a WinXP virtual PC, only to discover that the black-on-black invisible text and other problems are also there! I wonder where this game was working in a satisfactory way (I fear I know the answer: it worked ok on Win95/98/ME, then it broke...).
Anyway, no panic: it is only the beginning of the hunt!
The hang at the end of the mission is pretty odd. I actually "completed" two missions (really just quit the mission mid-air, and the designers were pretty gracious and assumed that the pilot flew back to base and landed when that happens) and didn't run into a hang as you described. This is on Windows 10 though; you never know what might affect that.
About the virtual PC idea - I actually installed the game on a Win98 SE Virtualbox and the menus were 100% good, but the game was slow in general due to the lack of any graphics acceleration capability in Virtualbox (though I think they do offer it for XP and up). Plus the 640x480 resolution limit that the game forces in absence of 3D acceleration is pretty bad.
Try ctrl-Q to quit mid-mission like I described; you can avoid ejecting and ditching the plane that way :)
I spoke too soon about not having the program hang after a mission. Just flew one now, got shot down, and the screen just sort of froze up just like yours. I could have sworn I ended a mission at one point without it freezing like that. I can't remember what setup I used to get there, though, so I can't recreate it now.
The graphical issues seem fixable with enough work but I'm not sure about the crashes.
I'm posting the results of latest searches in the iF22 logic, not to good news, but in the hope that someone could understand better than me and provide some help.
The oddity of the game seems to lay in the massive usage of "STATIC" controls, that seems to be a legacy from the past,supported but not too happily from MS mommy. But let's proceed with order.
First oddity is the usage of two main windows, both as big as the full screen, that would require a refresh of the whole window whenever the z-order is switched
Then the "iF-22 UI Class" is filled with static controls for text, images and so forth. Here the second window creates the "Database" button on the main panel.
The game defines custom colors for the text font, background, borders and so on. Looking at the game logs, you find many references of this kind:
But to make things more complicated, the game does not use a single way to draw text, it also uses the more conventional DrawText call:
That would explain why the text & background color problems are not visible everywhere but only on certain elements.
In conclusion, my guess is this one: while the conventional elements are properly managed, the static controls are drawn correctly at the first instance, but then when switching to and fro with the two main windows the color settings are lost and the window manager applies unhappy default colors, making part of the elements invisible by lack of contrast.
Now, the problem is that all this mess is not triggered by DxWnd windowing operations but is visible also in native fullscreen more when running the game from WinXP and later releases. It seems that Win95/98 is the only proper platform for the game and the compatibility issue is caused by MS itself.
Also applying Win95 compatibility shim and running the game fullscreen doesn't fix the problem, it seems that a genuine Win95 machine (or VM) is required.
Is anyone aware of this compatibility issue?
Last edit: gho 2017-05-06
Another little step forward: looking the error messages in the log I noticed some failed Blt operations: this is a known problem that can be eliminated by setting the "DirectX / Emulation" selector to "GDI".
This way the pictire quality is much less, but the pictires (the pilot portraits, the planes....) are always visible. This fact will give me a good track to find and fix this problem.
A small request. You wrote:
Could you grab a snapshot of some menu panels in Win98? I'd like to have a reference to tell which colors are good and which are bad.
Absolutely, I am out of town until Sunday (GMT-5 time zone) but I will post a screenshot from Win98 emulation when I get back. I hope this hot mess of a game is not wasting all your weekend time. The crashing after mission makes me worry that it will remain unplayable outside of emulation.
This is running at 640x480 32-bit in VM Virtualbox with a Win98 SE install using Scitech Display Doctor graphics driver. Even this setup does not emulate the game perfectly; two of the screenshots have missing images. Where the cursor arrow is in the "aircraft payload" screenshot (title is at the top), there is supposed to be a green and black image of an F-22 from the front angle (helping show where the weapons are mounted on the plane). In the "main options" screenshot, the picture of the pilot is missing. I noticed the game seems to draw these images onscreen first, then when some of the other features are drawn on the screen, the images become hidden until a control causes them to be updated, at which point they display correctly. This is how I got the other 3 screenshots to actually show the images - I used controls on the screen that switched (updated) the image to another one and got it to display.
Other than this weird behavior, everything else about the game appears to function normally in the emulator, although it's a little slow.
Last edit: beeley 2017-05-07
Also - check out the wonderful texture or pallette problem here. This might be related to running 256 colors in flight mode. Any 3D object such as a launched missile (not terrain for some reason) seems to have very strange colors.
Edit: I confirmed the weird color issue in the screenshot is happening even when running in 16-bit color mode in the game during flight. I recommend you ignore this issue for now. It's probably something that can be fixed within game settings.
To throw more fuel on this dumpster fire, when running native on Windows 10, the game strangely will not allow you to select an AGM-88 HARM missile to fire even if you have it equipped during flight. I tried this in the Win98 emulator and it worked fine, so it's just some oddity with running on a non-Win95/98 platform. I'm guessing that's not something that Dxwnd could even touch.
Last edit: beeley 2017-05-07
Uhm.... for sure the game has more than one single problem. But I start to believe that some different problems could have a common origin, that is the excessive CPU speed. Increased speed and a poor game architecture (with missing thread syncronizations) could generate many problems, that could go all away slowing the CPU down. DXWnd has some tricks to do that (single threading, CPU slow down) though they are not too sophisticated. But there are ways to check the theory and see if this path can lead to a positive result.
Apart form that, I see that at least the colors are identical (when applied timely and correctly): black background, green and light green UI elements.
Ok, let's hope to get some good result. There were lucky cases where I tamed the problem in a few hours, others (like Warlords 3, in the recent post) that had to wait from the very beginning of the DxWnd project. Let's cross our fingers...
I decided I'm going to find an old PC, install Windows 98 and try to run this game natively from there. Is there any testing I can do with that setup that would help?
Other than some more screenshots, on Win98 I don't think much more than this.
With WinXP or later, DxWnd should work without problems, so you could capture some logs, but on Win95/98/ME I doubt DxWnd could even start and I know for sure it can't work.
I'll try to produce some good idea, at the moment I have very little in my mind.
Also, I apologize for putting this game a little aside: I was caught in the middle of two big improvements (SDL hooking first and a new GUI behaviour right after) that are keeping me working like crazy all time on other problems, but eventually I'll come back to yours.
Last edit: gho 2017-05-17
Hey, no problem, if there is fruit hanging much lower in the tree it makes sense to go after it first. I'm glad to see this utility become more fleshed out and I'm grateful that you even gave this an initial look. I will keep checking back in periodically for news.
Quick update. I found an old Dell Dimension desktop running WinXP Pro 32-bit SP2 with a Pentium 4. My intent is to get Win98 running on it but I decided to try to run iF-22 on it before I wipe WinXP off. Here's the result.
There are zero DirectDraw / GDI window alignment issues in the non-flight menu screens. The white rectangles are still showing up behind all the buttons, and the images (pilot pictures, campaign map, etc.) don't show up until they're refreshed by a control on the screen, but everything else seems to work perfectly. All controls are at least visible and usable, and there is no crash at the end of a flown mission unlike in Win10. And the game does allow you to select the AGM-88 missile during flight (a weird problem I mentioned previously in Win10). I would call this playable on WinXP 32-bit.
Now I'm debating whether it's worth the pain of installing Win98 on a 2005 PC. I might as well go for a dual boot so I can keep XP around as an option.
Let me know if there's any testing I can help with on these old Windows versions.
Yes, there's a chance that this behaviour is caused by the old PC and old video card missing some specific capabilities, so it could be interesting to grab some logs from the game. The log settings in this case should include also the hexdump of some structure, see the panel in attach. Also, for this purpose the game session can be as short as you like, the capabilities are queried at the beginning.
I take you described a behaviour without DxWnd: I also wonder how good it will stay after running the game in DxWnd.
P.s. using laters DxWnd release you will find the logs tab only after setting the "Options->Expert mode" menu command,
The log is attached here.
I also noticed that the patch released late in 1997 by i-Magic causes at least two problems in Windows XP; the game's .exe will fail to start up if my Logitech Wingman is installed, and the AGM-88 HARM missile cannot be selected during flight. I ran into these in Windows 10 as well despite any dxwnd tricks I tried. I also got a few random CTDs while running the patched game but not the pre-patch version in XP. Strange problems.
At this point I think it would be fine to call this game a very high-hanging fruit and not bother spending much more time on it. I'm going to start sinking my time into getting Windows 98 running on the 2005 Dell PC and just try to run the game natively from there.
Thanks for the help! I'll check back in periodically here to see if there's been more interest or activity.
***Update - I mentioned that air to ground weapons can't be selected after the patch. I simply needed to read the patch notes. There's a different key to select air to ground vs. air to air weapons.
Last edit: beeley 2017-06-08
One very interesting thing is the lack of the DDCAPS_GDI capability. Here is what MSDN says:
Now, since most of our problems come from the shared device context between ddraw and GDI, the lack of this capability may force an independent and more accurate behaviour.
Unfortunately, it seems that letting the application believe that the capability is missing does nothing good: probably it would be necessary to convince the video drivers of this situation, which is probably a more complicated thing.