Resolution switching

[GoogleCodeExporter]

nullDC 1.0.4r50 is not able to switch resolution. version 1.0.3 was able to 
switch to 640 x 480. Native resolution, resolution switching, is requested as I 
use it on a real arcade cabinet with a CRT monitor/Arcade Frontend.

In the PowerVR setting "native 640 x 480" can be selected but the program does 
not switch the resolution to 640 x 480.

Original issue reported on code.google.com by shaba...@gmx.net on 9 Oct 2010 at 10:17

[GoogleCodeExporter]

When pressing Alt+Return I suddendly see the picture again (but in the 
resolution I use for Maximus Arcade 640x288). When pressing Alt+Return again, 
it's full screen but still 640x288 whether I set native 640x480 in the nullDC 
prefs or not. If I set Maximus Arcade to 640x480 it still does not show any 
picture (screen stays black, sound could be heared). Only pressing Alt+Return 
twice helps. I also tried Alt+Tab to see if it is not in the foreground but 
this is also not the cause.

Original comment by shaba...@gmx.net on 10 Oct 2010 at 8:51

[GoogleCodeExporter]

nullDC never changes resolution, it uses whatever your screen is setup up at. 
You should change to the desired resolution before using nullDC.

The "Native" setting only affects the internal drawing resolution and not the 
screen one :)

Is there some particular reason you want nullDC to set the resolution ?

Original comment by drkIIRaziel on 16 Oct 2010 at 12:18

[GoogleCodeExporter]

Yes! The reason why I want that nullDC sets the required resolution is that I 
use nullDC on a real Arcade cab with Maximus Arcade as frontend. It does not 
full work without problems because nullDC does not fully use its own screen but 
with the resolution set by the Desktop. This and because of another yet unknown 
behaviour of the frontend results that sometimes nullDC does not start as the 
foreground application, sometimes even the console of nullDC is in front of 
everything. As I do not know any other emulator that can not use its own screen 
with setting its own resolution, nullDC is the only emulator I've this kind of 
troubles. Why was this behavior changed since version 1.0.3? 1.0.3 worked 
absolutely perfect - but I need 1.0.4r50 because of the Purupuru plugin...

Original comment by shaba...@gmx.net on 16 Oct 2010 at 2:50

[GoogleCodeExporter]

I found a workaround but I still have the problem that sometimes the console of 
nullDC is in front of all. I know that I can press ALT+Tab to get to the main 
window - but on my real arcade cab these keys are not available. So it would be 
cool - if the discussed resolution settings will take longer to be (re)included 
into nullDC - if there would be a possibility to show the console window of 
nullDC only when choosen in the menu or set in prefs...

Original comment by shaba...@gmx.net on 17 Oct 2010 at 4:37

[GoogleCodeExporter]

The console can be hidden via an option, iirc it was -config nullDC:NoConsole=1

Original comment by drkIIRaziel on 18 Oct 2010 at 9:23

[GoogleCodeExporter]

OK, thank you for he hint. I found it in the ini-file. The console is not shown 
anymore.

Unfortunately in half of the cases I still do not see a picture after starting 
a game using Maximus Arcade as frontend. The screen stays black or half of the 
screen stays black. Sometimes it works without problems, sometimes screen stays 
black. There must be a small bug in the display routines of nullDC as I do not 
have any similar troubles with any other emulator on my machine.

Original comment by shaba...@gmx.net on 19 Oct 2010 at 4:17

[GoogleCodeExporter]

If nullDC works fine when not using the front-end then the front-end is to 
blame for your problem. It's not a fault of nullDC.

Original comment by Mr.PsyMan on 19 Oct 2010 at 5:40

[GoogleCodeExporter]

It's an interesting solution to a problem I have with nullDC only...

Original comment by shaba...@gmx.net on 19 Oct 2010 at 9:00

[GoogleCodeExporter]

I found the problem: nullDC does not make it's window the active foreground 
window automatically. So if another applications is started right before nullDC 
(like in my case a resolution switching program, both in a batch file) the last 
started program remains the active window and nullDC does not show anything. As 
soon as you press ALT + tab to make nullDC the active program and then 
ALT+Return twice to make it full screen that's the only solution at the moment 
to get it working right. I removed the resolution switching program and used 
the Windows option "start in 640 x 480" in the compatibility properties to get 
the resolution I need.

So the request remains: bring back the resolution switching menu of nullDC 
1.0.3 to set the required resolution within nullDC. This would also solve the 
problem with the non-active window...

As I found several users having the same problem in some forums I think this 
would not be a low priority...

Original comment by shaba...@gmx.net on 20 Nov 2010 at 4:39

[GoogleCodeExporter]

Exclusive mode is cumbersome.

http://forums.pcsx2.net/Thread-blog-A-new-kind-of-fullscreen

The frontend mode should just adapt and get the nullDC window to top. Since 
this seem to be a problem of the frontend's doing.

Original comment by KrossX3 on 20 Nov 2010 at 10:18

[GoogleCodeExporter]

It's not only a problem of a frontend but of a batch file too. It's not the 
fault of nullDC. No, no. It's everthing else. I know.

Original comment by shaba...@gmx.net on 20 Nov 2010 at 10:50

[GoogleCodeExporter]

Well, the program works alright as supplied. Which doesn't include, neither a 
custom frontend nor a batch file. If the frontend is meant to work with 1.0.3 
then you shouldn't be using 1.0.4 with it.

If a third party software has problems with it, and need something that can 
only be applied to nullDC itself. Well, the code is open and free to tamper 
with. Otherwise, workaround the issues from the third party software itself.

All in all, priority-low is quite befitting for this issue.

Original comment by KrossX3 on 20 Nov 2010 at 11:37

[GoogleCodeExporter]

I would stay with 1.0.3 - but I can not define the ALT key. This works with the 
PuruPuru plugin only. I know that the developers do not want to improve that 
behavior so I will not further post concerning this matter. It's only sad that 
you do not even consider to add the resolution switching method of 1.0.3 at 
least additionally.

By the way - I noticed that the mdf/mds cd images can not be used with 1.0.4r86 
anymore...

Original comment by shaba...@gmx.net on 21 Nov 2010 at 8:43

[GoogleCodeExporter]

I tried everything in the mean time - with this kind of code the emulator can 
not be started correctly in full screen mode by any other means then starting 
it manually by double clicking its icon in explorer. No batch file, no front 
end. This is real sh... as I never exeriences such stubborn behavior of any 
other emulator.

I'm writing this lines only because I accidentally read an article from the 
PCSX2 programmers (they are also using this kind of full screen mode 
ADITIONALLY to the regular full screen mode for performance reasons) where they 
admit that it is not the best solution as it is not working correctly for CRT 
users and there are some other problems because of this new mode. But they use 
it aditionally only - they are using a second full screen mode for all other 
people out there having problems with this kind of new mode.

As Arcade Cabinet owners (and I think there are a lot of these people out 
there; I personally know many of them asking me what to do with nullDC) would 
like to use this emulator because of it's excellent compatibility they are 
certainly very angry because of this new troublemaker-mode...

Original comment by shaba...@gmx.net on 14 Dec 2010 at 5:12

[GoogleCodeExporter]

nullDC uses the current resolution of the monitor when switching to fullscreen.

If your desktop resolution is 1280x1024, that's the resolution nullDC will use 
for fullscreen mode, if you use 640x480 as desktop resolution, it will use 
640x480 and so on.

This is not the same method used by PCSX2 or whatever else.

Now, when it comes to the "resolution" option on the drkPVR option menu... What 
it does is set the internal resolution (the resolution games render at). It's a 
form of enhancement or a workaround depending on how you use it.

The technically accurate one is the 640x480 option and it should stay like that 
for compatibility reasons unless you are a "graphics whore" (as some people 
would say) or your cpu/gpu is too slow to handle 640x480 or more.

This option is not related in any way to fullscreen switching and the likes. 
It's just that drk||raz tends to give misleading names to some options.

Once again, your "problem" is not a fault of the emulator. It has to do with 
the way batch files/frontends and the likes work.

Instead of commenting again and again you could just commit a patch and "fix" 
the thing by yourself instead of asking others to do it for you.

Original comment by Mr.PsyMan on 14 Dec 2010 at 8:07

[GoogleCodeExporter]

Hmm, actually I was wrong, according to that thread above PCSX2 uses the same 
method as nullDC now. Maybe it was drk who made the PCSX2 change too? Or maybe 
he got the idea from there. In any case, it is a safer method.

Original comment by Mr.PsyMan on 14 Dec 2010 at 9:07

[GoogleCodeExporter]

I tell you what - if I would be able to do such fixes by my own I would be 
delighted to contribute to this project. I always thought that issues and 
problems can be posted there and they will be dealt with - at least this is the 
case with other emulators. But it seems to me that there is simply no urge to 
do anything like that.

I like the PCSX2 programmers more as they claim: "We're still leaving the door 
open for adding optional support for exclusive mode fullscreen, since there 
could still be some use to it for special scenarios like CRT displays and TV 
projection".

I'll not post anymore - instead I'll use Demul. There is no desire to chafe at 
this silly thing anymore. Say what you want - it has something to do with 
nullDC as there are no troubles with other emulators, even the former version 
1.0.3 does not show that strange behavior. Keep it to your elitist club...

Original comment by shaba...@gmx.net on 15 Dec 2010 at 8:20

[GoogleCodeExporter]

Dude , calm down :|

The first thing that i would try is to set the window flags to TOPMOST
then focus to the window's instance ...instantly :p

Try this..

Open : nullDC/Plugins/nullDC_GUI/emuWinUI.cpp

Look for : SetWindowPos( ..

Replace with :
SetWindowPos( g_hWnd, HWND_TOPMOST, 0, 0, r.right - r.left, r.bottom - 
r.top,SWP_NOACTIVATE | SWP_NOMOVE ) ;

Append this : SetFocus(g_hWnd);
After this  : ShowWindow(..

Compile nullDC_GUI.dll and try it ...or if you can't compile code , then just 
say 

Original comment by Dimitris...@gmail.com on 15 Dec 2010 at 9:48

[GoogleCodeExporter]

Actually , here grab the dll just in case : 
http://www.mediafire.com/?ee9setwjh7n9cov

Original comment by Dimitris...@gmail.com on 15 Dec 2010 at 9:51

[GoogleCodeExporter]

Thank you so much!

After my experences here at this thread I never thought I would find such a 
kind person here... :)

I'll try that soon and I'll let you know if it works! Nevertheless I do not 
understand why this small fixes are not included into the regular release?

Original comment by shaba...@gmx.net on 15 Dec 2010 at 11:35

[GoogleCodeExporter]

Cause there is no release. SVN snapshots do not count as a release.

Original comment by Mr.PsyMan on 15 Dec 2010 at 11:36

[GoogleCodeExporter]

It seems that this small modification did it! Please include this fix in the 
final release! Thank you! :)

Original comment by shaba...@gmx.net on 15 Dec 2010 at 5:26

[GoogleCodeExporter]

I have actually added a whole new entry into the gui/config file at the time i 
provided the dll..just looking into some other stuff now and got to work on my 
own stuff aswell :p

Original comment by Dimitris...@gmail.com on 15 Dec 2010 at 6:15

[GoogleCodeExporter]

I'll have a look at it! Thank you for the reminder! :)

Original comment by shaba...@gmx.net on 15 Dec 2010 at 6:32

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Please add 1280x960 (native x2) like before.
This is much better than 1280x1024 or 1280x800.

Original comment by iori3...@hanafos.com on 16 Dec 2010 at 12:07

[GoogleCodeExporter]

This new modification should be integrated in the next official release as it 
works perfectly! :)

Original comment by shaba...@gmx.net on 17 Dec 2010 at 2:48

[GoogleCodeExporter]

I bet that its going to take a while before the "official" release(its not my 
"job" anyway).. so just just svn-checkout and compile the whole solution :|

Original comment by Dimitris...@gmail.com on 17 Dec 2010 at 2:58

[GoogleCodeExporter]

Nevertheless: it seems to be a very small change but with a very big effect - 
without damaging anything for regular users. Great enhancement! :)

I really hope this will be included in the next regular release...

Original comment by shaba...@gmx.net on 17 Dec 2010 at 9:33

[GoogleCodeExporter]

Just a quick question: Has this modification been already integrated into the 
latest SVN snapshot? It doesn't seem to break anything in the regular behavior 
but fixes the problem with full screen mode...

Original comment by shaba...@gmx.net on 20 Feb 2011 at 9:08

[GoogleCodeExporter]

hey guys im having the same issue with maximus but i grabbed that .dll you 
provided and it didnt change anything. it still shows up either minimized on 
hidden thru maximus.

Original comment by ayabre...@hotmail.com on 18 Jul 2011 at 10:57

[GoogleCodeExporter]

hey guys im having the same issue with maximus but i grabbed that .dll you 
provided and it didnt change anything. it still shows up either minimized on 
hidden thru maximus.

Original comment by ayabre...@hotmail.com on 18 Jul 2011 at 11:16

[GoogleCodeExporter]

I have a feeling that nobody is interested in solving this issue, except the 
fellow guy Dimitris. I really do not understand why this solution has not been 
entered the official releases if the solution is that simple?

Original comment by shaba...@gmx.net on 18 Jul 2011 at 11:18

[GoogleCodeExporter]

I'm having a similar problem with Maximus Arcade. It runs "fullscreen" in the 
sense that it takes up the desktop space, but the Windows Taskbar is clearly 
visible (unless you disable it in MA) and NullDC runs at a smaller resolution 
than the desktop mode. Going into the menu and switching back and forth between 
fullscreen fixes the problem, but you can see why this is not a desirable 
solution.

Original comment by chinagre...@gmail.com on 17 Feb 2014 at 3:30

[GoogleCodeExporter]

I was able to solve my problem by using an autohotkey script which can be found 
by a Google search for anyone stumbling upon this. Still, I assume this is 
related to the nonexclusive mode, and if it's possible I'd suggest a 
user-defined option.

Original comment by chinagre...@gmail.com on 17 Feb 2014 at 7:55

[GoogleCodeExporter]

Can you just post the script here? Simply copy/paste it here.

Original comment by shaba...@gmx.net on 17 Feb 2014 at 8:44

[GoogleCodeExporter]

For the truly, truly lazy:

Sleep, 2000
send, !{Enter}
Sleep, 1500
send, !{Enter}
exit

Original comment by chinagre...@gmail.com on 18 Feb 2014 at 6:57

[GoogleCodeExporter]

I used the .exe creator and set it to open with the emulator in my frontend and 
it works great.

Original comment by chinagre...@gmail.com on 18 Feb 2014 at 6:58

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Hi, all.

Reading this post as a result of an extensive google search for a solution to 
this *issue in nullDC*. I've got that very same scenario: MA v2.10, all emus 
running fine, but this one... well, anyway, "it's the front-end's fault" as the 
legend says...

I extend my thanks to user @Dimitri for taking the time to search through the 
UI code and replacing the display option in the call to SetWindowPos() function 
as well as adding the necessary call to SetFocus() afterwards. I *eagerly* look 
forward to trying his modified .dll when I get home today. I also intend to 
enter the "-config nullDC:NoConsole=1" option in MA config window, as I see no 
use for the console window to show as a default (it would be somewhat useful if 
I was involved in the development of this emulator) - it's just another window 
taking space in the desktop area and memory (and adding to the confusion).

I also had previously found the website where this dude had posted about using 
an AutoHotKey script to work around this *issue in nullDC* - It's gonna be my 
last resort plan if the above fails - anyhow, I thought of it as a nice 
workaround for another small "issue" I have: running my PSX emulator within MA 
and having MA automatically set the "Analog" function (since ePSXe doesn't 
provide a way to map that key on the gamepad).

Here's the original post referred previously: 
http://joomla.maximusarcade.com/phpbb/viewtopic.php?f=49&t=2523
And here's the AutoHotKey page: http://www.autohotkey.com/
(for the very, very, very, veeeeery lazy people out there, eheheh - GIYF)

I'll come back here later with my results.

Original comment by wmoecke on 9 Apr 2014 at 4:23

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Hi all.

Well, yesterday I said I would come back so here I am again.
The .dll didn't do any good. I was very disappointed, but then I started 
thinking, hey this might not even be the correct solution for this *issue in 
nullDC* after all.

It was coded with a premise in mind, that the root cause of the *issue in 
nullDC* would be as simple as setting the window to the foreground.

It turned out that using a AutoHotKey script that simulates the Alt+Enter key 
combination pressed twice did the job well. Well... not so well, let me explain 
in more detail.

I've ended up with no less than 3 different compiles of nullDC: v1.0.4 r389 
(June 20 2010), r136 and r141.
The r389 was the last one I've added to my "collection" - just last evening tbh.

It turned out that the .ahk script *workaround* (it's not a solution - a 
solution would be to work the code to eliminate this *issue in nullDC*) worked 
*partially* on the 2 latter compiles (sometimes it would work, sometimes not, 
especially if the emu is called more than once in a row - like entering the emu 
from MA menu, exiting, then entering again, then exiting again, so on... I did 
this as sort of a "burn-in test").

I've downloaded r389 (from here: 
http://www.emuparadise.me/emulators/files/user/NullDC%201.0.4-389.zip) as a 
result of searching for r50 (I saw lots of comments spread throughout talking 
about the *workaround* having worked flawlessly in this release), but to my 
frustration, older versions seem to be completely wiped out of the web.

It turns out this particular compile seems not only to work well with the 
*workaround* (not a solution) without any hiccups, but it also offers better 
overall compatibility with games (last evening I've seen this release work 
fairly well with CDIs that the other compiles had just spat back at me).

Now to the "solution" part - despite Dimitris' best efforts (kudos again) it 
seems to me now that the real cause for this *issue in nullDC* has more to do 
with resolution switching (I am taking a guess here, since pressing Alt+Enter 
does pretty much force a resolution switch in the main window) than to just 
setting the window to the foreground (there's even an option in the menu to 
make the window stay "Always on top" - and I had that turned on at all times, 
to no avail).

So, I am curious to see if I could have a look at that source and see if I 
could figure something out on my own. From the previous posts in this thread, 
it is obvious to me that the dev team is not interested in tackling this 
particular *issue in nullDC*.

I have my C++ skills a bit rusty, but I'll take my chances some time. If I get 
to it, I will come back with my findings.

Original comment by wmoecke on 10 Apr 2014 at 2:28