4k's: display adapter choice!
category: general [glöplog]
I'd also love most D3D fullscreen stuff wouldn't move all my opened windows to the other monitor... but don't know if this is fixable via code :-)
Visual Studio 2010 tends to like gettings its maximized window on the bottom of the tool panes i have on the secondary monitor (which fill it up completely thus finding the code window again tends to be a pain in the ass).
Then again, that's why 1080p youtube just works :-)
Visual Studio 2010 tends to like gettings its maximized window on the bottom of the tool panes i have on the secondary monitor (which fill it up completely thus finding the code window again tends to be a pain in the ass).
Then again, that's why 1080p youtube just works :-)
@gloom: "plethora"?!
Jcl: In Windows (XP at least, not sure about 7) switching resolution always means changing the size of the desktop, and due to the way Windows handles multiple monitors (as a single desktop) this causes stuff to fly all over the place.
I know there are utilities that remember window and icon positions to put everything back where it was after running a fullscreen application. But the best way to avoid it in code is always to use the desktop resolution for any fullscreen application. To render in a lower resolution, render to a texture and stretch it to fill the screen (which doesn't stress the GPU all that much (or makes no difference at all in some cases, like with monitors that only support one resolution)).
Not really an option for 4ks, though.
I know there are utilities that remember window and icon positions to put everything back where it was after running a fullscreen application. But the best way to avoid it in code is always to use the desktop resolution for any fullscreen application. To render in a lower resolution, render to a texture and stretch it to fill the screen (which doesn't stress the GPU all that much (or makes no difference at all in some cases, like with monitors that only support one resolution)).
Not really an option for 4ks, though.
Quote:
actually now that i think of it... i have an idea: using kkapture-esque techniques, one could, in theory, detour some of the d3d calls and change some of the parameters transparently - and it would work, on paper, with any intro (or 64k, or demo, etc.)
I have been toying with the idea of making a "DemoRunner" like that. There are lots of things you could do with it: run intros packed with old packers, fix ordinal imports, fix the Device Lost bug in Win7 Aero, patch shaders (and other things) to run on ATI, you name it...
If demos could be treated like objects in Window's Power Shell...
You shouldn't treat demos as objects. That's humiliating... ;)
You should treat objects like women!
In other news, Gloom is scaring me.
In other news, Gloom is scaring me.
blueberry: how do you fix broken ordinal imports? am i wrong or you need to know which function belong to that ordinal in the original dll, how do you do that? guessing? manual digging into the code?
rename the exe from fook_1280_720.exe to fook_1440_900.exe of course.
argv[0]! :D
GetCommandLinetoArgvW(GetCommandLine(),NULL)[0]! :D
rmeht: Qualified guesswork. You would need:
- A list of functions typically imported by intros: CreateWindow, ShowCursor, GetAsyncKeyState etc.
- The function ordinals for all versions of the relevant DLLs. This might be tricky to obtain, but there might be some way...
Given these, you could search through the DLL versions and pick the one where the imported functions would most closely match the expected set. I think it would work.
- A list of functions typically imported by intros: CreateWindow, ShowCursor, GetAsyncKeyState etc.
- The function ordinals for all versions of the relevant DLLs. This might be tricky to obtain, but there might be some way...
Given these, you could search through the DLL versions and pick the one where the imported functions would most closely match the expected set. I think it would work.
blueberry: ordinals of all versions is indeed tricky. you have to track down every version of, say, kernel32, from the old win95 to latest win7 going through every patch, service pack, and so on. sound very tricky to me...
my idea was to step in the code and do some analysis: how many parameters an imported call requires (tracking the stack pointer), guess the size of that structure pointer-passed to this call (many functions begin with their sizeof for example, but you can track it down from the stack accesses), maybe even the calling order (createwindow before showcursor?). not that this is easier, but no doubt is going to bring some codepron fun :)
my idea was to step in the code and do some analysis: how many parameters an imported call requires (tracking the stack pointer), guess the size of that structure pointer-passed to this call (many functions begin with their sizeof for example, but you can track it down from the stack accesses), maybe even the calling order (createwindow before showcursor?). not that this is easier, but no doubt is going to bring some codepron fun :)