Reply 1340 of 2397, by TheGreatCodeholio
- Rank
- Oldbie
Thanks. I found two commits so far that are related to the change in alt-tab behavior from 1.2.13 to 1.2.15:
https://hg.libsdl.org/SDL/rev/090d764c56e4
https://hg.libsdl.org/SDL/rev/676a54593bc4
The latter seems like a possibility:
1.1 --- a/src/video/wincommon/SDL_sysevents.c Thu Dec 29 04:24:15 2011 -0500
1.2 +++ b/src/video/wincommon/SDL_sysevents.c Thu Dec 29 04:29:53 2011 -0500
1.3 @@ -309,6 +309,8 @@
1.4 if ( WINDIB_FULLSCREEN() ) {
1.5 appstate |= SDL_APPMOUSEFOCUS;
1.6 SDL_RestoreDesktopMode();
1.7 + /* A fullscreen app gets hidden but will not get a minimize event */
1.8 + appstate |= (SDL_APPACTIVE | SDL_APPMOUSEFOCUS);
1.9 #if defined(_WIN32_WCE)
1.10 LoadAygshell();
1.11 if( SHFullScreen )
I see the fix - thanks!
I just figured out the lighting issue. OpenGL's default context state is GL_SMOOTH. The display code in DOSBox/DOSBox-X sets glShadeModel to GL_FLAT. Adding code to 3Dfx OpenGL initialization to set it back to GL_SMOOTH fixes the random lighting errors.
That's good news. Those issues are difficult to diagnose.
Testing the latest win32 binary in W10. This version does not change from window to fullscreen where fullresolution=original. Also, the 3dfx/gl lighting of "Trip's" green tunnel has that issue again. I think the opengl gremlins are out again.
Making this change seems to fix the non-3dfx fullscreen scaling in W10:
@@ -751,7 +751,7 @@ SDL_Surface *DIB_SetVideoMode(_THIS, SDL
}
#endif
-#ifdef _WIN32_WCE_DONT_USE_THIS
+#ifndef _WIN32_WCE
settings.dmBitsPerPel = video->format->BitsPerPixel;
settings.dmPelsWidth = width;
settings.dmPelsHeight = height;
I can't allow that. I made changes to prevent DOSBox-X changing monitor video modes entirely. Fullscreen should scale up or center to the screen. output=surface is written not to scale, so it should center in the screen.
A better change is if output=surface were modified to pick an integer scale to scale up by (that fits to the screen) so that at least it's not a postage stamp in the middle of your screen.
Noted that the opengl state has different behavior depending on whether the async window code is present or not. Is there a reliable way to reset the opengl state and start a new one in W10?
I'm sure that the next Windows version will fix any opengl issues.
Is this the latest code, or the latest binary?
The GL_SMOOTH fix was applied after the latest binary.
The OpenGL standard doesn't appear to offer a "completely reset the OpenGL context" function, sadly.
That behavior was tested outside the latest dosbox-x code. I removed the async code and the opengl state appeared different. I think these large libraries should require a test program for every new feature in code.
I meant W11 on the hope of opengl fixes to W10. I had no doubt about dosbox-x. 😀
It is now producing a good result for the 3dfx/gl window in W10.
To isolate the other 3dfx/gl rendering issues, it may help to have a keystroke attached to a timestamp on the log output and logging at each of the functions along the 3dfx pipeline. With some issue, such as a missing animation, the user could produce the timestamp (not necessarily real time) to mark before the animation issue occurs, and then again after the issue. The logging could be examined in 3dfx/gl mode for functions that are rarely used, annotated in the code as incomplete, or just for likely candidates. I recall that there is an incomplete implementation of z-order along the pixel pipeline in gl mode, for example.
I just made a script in the demoscene testing repository to generate a HTML list of demos tested and test results. Test results now include DOSBox-X vs DOSBox-SVN. Enjoy.
https://htmlpreview.github.io/?https://github … mpat-chart.html
Repository: https://github.com/joncampbell123/demotest
wrote:I know not a lot of games use the Sound Blaster "goldplay" hack, but, is there any interest in DOSBox SVN to implement support for it?
I cannot speak for the DosBox developers, but if you look at the recent history of commits to the DosBox repository, you see that it has almost died out, with only one commit every week, or even less. It appears DosBox is considered largely "feature-complete" by its devs now. I wouldn't bet on any major features from the many forks being mainlined in the near future.
I'll note that lack of support for goldplay is intentional, which will affect the demoscene test results.
I just started another one for MS-DOS games. https://htmlpreview.github.io/?https://github … mpat-chart.html
wrote:wrote:I know not a lot of games use the Sound Blaster "goldplay" hack, but, is there any interest in DOSBox SVN to implement support for it?
I cannot speak for the DosBox developers, but if you look at the recent history of commits to the DosBox repository, you see that it has almost died out, with only one commit every week, or even less. It appears DosBox is considered largely "feature-complete" by its devs now. I wouldn't bet on any major features from the many forks being mainlined in the near future.
Best not to comment if you don't have any idea of what you're talking about. Most of those features aren't needed by games or don't work across multiple operating systems or are only needed by a few games and the patch is hacky but because one or two games need it people bitch. If you have a patch for DOSBox that is for gaming then upchannel it to the devs. If it's a fix for compatibility and it doesn't break anything then you'll see it in SVN. If it's a new feature and it's for gaming purposes then you'll eventually see it in a new ver.
So far "goldplay" Sound Blaster playback seems to be the domain of the early 1990s demoscene. I don't know of any DOS games that use Sound Blaster like that, yet, so I'll leave it alone for now. But if you find any DOS games who's Sound Blaster music sounds unnecessarily "muffled" and low fidelity compared to what it should sound like, let me know, it might be doing just that.
I do have one patch I might submit though, it has to do with the PC speaker and the limited precision in SVN that it renders in response to rapid changes to both frequency and gating. One good example being Duke Nukem's PC speaker effects. DOSBox-X so far in my tests sounds much closer to real hardware than SVN. I recall this being mentioned in a recent Ancient DOS Games episode as well.
Another area to check DOSBox SVN against is the "Disney Sound Source" emulation. Plain LPT DAC output (without consideration for DSS) doesn't seem to produce any sound in DOSBox SVN. At least when compiled on 64-bit Linux.