VOGONS

Common searches


DOSBox-X branch

Topic actions

Reply 1340 of 2397, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie

That can be done. I only followed existing SDL 1.x behavior of minimizing the window into the change.

DOSBox-X project: more emulation better accuracy.
DOSLIB and DOSLIB2: Learn how to tinker and hack hardware and software from DOS.

Reply 1341 of 2397, by hail-to-the-ryzen

User metadata
Rank Member
Rank
Member

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 )

Reply 1343 of 2397, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie

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.

DOSBox-X project: more emulation better accuracy.
DOSLIB and DOSLIB2: Learn how to tinker and hack hardware and software from DOS.

Reply 1344 of 2397, by hail-to-the-ryzen

User metadata
Rank Member
Rank
Member

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.

Reply 1345 of 2397, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie

Haven't compiled the latest OpenGL fix yet. The GL_SMOOTH fix will appear in the next binary.

DOSBox-X project: more emulation better accuracy.
DOSLIB and DOSLIB2: Learn how to tinker and hack hardware and software from DOS.

Reply 1346 of 2397, by hail-to-the-ryzen

User metadata
Rank Member
Rank
Member

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;

Reply 1347 of 2397, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie

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.

DOSBox-X project: more emulation better accuracy.
DOSLIB and DOSLIB2: Learn how to tinker and hack hardware and software from DOS.

Reply 1348 of 2397, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie

The option should remain open, of course, if you would rather have the postage stamp in the middle of your screen.

DOSBox-X project: more emulation better accuracy.
DOSLIB and DOSLIB2: Learn how to tinker and hack hardware and software from DOS.

Reply 1349 of 2397, by hail-to-the-ryzen

User metadata
Rank Member
Rank
Member

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.

Reply 1350 of 2397, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie

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.

DOSBox-X project: more emulation better accuracy.
DOSLIB and DOSLIB2: Learn how to tinker and hack hardware and software from DOS.

Reply 1351 of 2397, by hail-to-the-ryzen

User metadata
Rank Member
Rank
Member

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. 😀

Reply 1352 of 2397, by hail-to-the-ryzen

User metadata
Rank Member
Rank
Member

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.

Reply 1353 of 2397, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie

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

DOSBox-X project: more emulation better accuracy.
DOSLIB and DOSLIB2: Learn how to tinker and hack hardware and software from DOS.

Reply 1354 of 2397, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie

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?

DOSBox-X project: more emulation better accuracy.
DOSLIB and DOSLIB2: Learn how to tinker and hack hardware and software from DOS.

Reply 1355 of 2397, by Darkstar

User metadata
Rank Newbie
Rank
Newbie
TheGreatCodeholio 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.

Reply 1356 of 2397, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie

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

DOSBox-X project: more emulation better accuracy.
DOSLIB and DOSLIB2: Learn how to tinker and hack hardware and software from DOS.

Reply 1357 of 2397, by DosFreak

User metadata
Rank l33t++
Rank
l33t++
Darkstar wrote:
TheGreatCodeholio 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.

How To Ask Questions The Smart Way
Make your games work offline

Reply 1358 of 2397, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie

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.

DOSBox-X project: more emulation better accuracy.
DOSLIB and DOSLIB2: Learn how to tinker and hack hardware and software from DOS.

Reply 1359 of 2397, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie

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.

DOSBox-X project: more emulation better accuracy.
DOSLIB and DOSLIB2: Learn how to tinker and hack hardware and software from DOS.