I was wondering if you can make ZC suspend all Explorer.exe processes while ZC has focus but resume the processes when not in focus? Or is such a thing just not possible with your code base D:
It's what one of the coders for Worms Armageddon did to fix the vast majority of colour corruption situations under Vista/7.
It should be possible, but then you wouldn't be able to switch out if the game hangs. Don't want that.
I made a modified alleg42.dll that I hope will fix the color problem, but I haven't heard if it works yet. Here, try it.
franpa wrote:The interface problem hasn't happened for a long time now which is odd, the new DLL doesn't resolve change or alter the colour problem in any way shape or form.
You've gotta tell me, y'know. 😛
All right, second try: http://www.mediafire.com/?umwwdmqzefa
No, that does not solve it.
Shoot. Well, sooner or later, one of these ought to do it...
http://www.mediafire.com/?t0ghymxdnyj
I'll tell you if it has an affect or not, anyways it has no effect.
I'm a color palette and windows 7 was my idea. 😃
Gah, what the hell? I'm not too sure what else to do with it... I'll fiddle with it tomorrow, I guess.
If anyone else wants to look at it, this and this are relevant. The file that needs fixed should be win/wwnd.c.
allegro/tests/win/dibhello.c is an example program that handles WM_QUERYNEWPALETTE and WM_PALETTECHANGED, but it uses WinMain().
This would be much easier if there was a developer that actually has windows 7.
..This post was brought to you by; "Stating the obvious brand Streak Shredder. The only windows cleaner made from real human tears." :P
edit: Just curious; are you able to aquire and reset the correct palete from within the allegro wwin.c source? ..I'm assuming you are I guess.. I suppose it wouldn't be any easier from within zelda.cpp ..Sorry nevermind. I don't think I have any helpful ideas, and I don't think I'd be able to get it working any better then.
Well, it's not like I have a clue what I'm doing here, clearly. I'm thinking maybe this should do it:
case WM_PALETTECHANGED:
case WM_QUERYNEWPALETTE:
return FUCK_OFF;
I don't exactly have high hopes for it, but here's another one: http://www.mediafire.com/?djdagjzinej
I giggled a little at that snippet. Can you perhaps log the results of the code snippet? Anyways I've noticed something for Zquest, the entire screen is either tinted white with the default DLL or entirely tinted pink by your modified DLL. The tint goes away after the initial dialog box but dialog box title bars are still rainbow coloured. Zelda-w.exe hasn't changed.
Image 1 = original DLL with faded white tint over the whole screen. Phone camera kinda sucks and our proper camera is worse but probably because it is flat ._.
Image 2 = Modified DLL with pink tint.
Zquest is in fullscreen mode as it is only fullscreen modes for Zelda-w and Zquest that are affected. I doubt many use Zquest in Fullscreen though.
franpa wrote:I giggled a little at that snippet. Can you perhaps log the results of the code snippet?
Eh, no good. It just responds with WM_NO_U, and handling that creates an infinite loop.
I think I've been going about this completely the wrong way... I don't think it'll work quite right, but what does this one do? http://www.mediafire.com/?ainkz4mzkmy (It might just hang the game, so be ready for that.)
The problem with the new quest dialog may be unrelated. There seems to be an uninitialized bitmap being used there.
That fixes the new quest dialog screen tint but title bars still have a rainbow colour. It has no effect on ZC.
This one looks promising: http://www.mediafire.com/?2tofynee0t3
If it screws up again, not counting ZQ's new quest dialog, post allegro.log afterward.
Even if it does work, it's overkill and should be whittled down, but that's not a big deal.
FUCK YES! That solves the colour problems in full screen modes!
I'll do a bit more in depth testing (aka: extended play session) but it looks very promising.
edit: maybe get Freedom's attention :P
Cool. 😊
Just curious what the deciding code was.
Turns out a lot of the information out there about this problem only applies to GDI applications. Apparently, this is all it needs:
case WM_QUERYNEWPALETTE:
case WM_PALETTECHANGED:
if ((HWND)wparam != wnd && gfx_directx_primary_surface) {
IDirectDrawSurface2_SetPalette(gfx_directx_primary_surface->id, ddpalette);
InvalidateRect(wnd, NULL, 1);
}
return 1;
One more file to try, with all the seemingly unnecessary stuff removed. If you can confirm that this one works, I think we're done here.
http://www.mediafire.com/?3fz2aymigon
Yep, that works still 😊 no more additional logging to allegro.log either (which is intended, I know).
All right, I went ahead and committed it. Hopefully, that's the end of that. Thanks for being patient with me here.
It probably would have been worked out quicker if we had used MSN >.> though I have no clue how long it takes to compile Allegro.dll