VOGONS

Common searches


DosBox-0.74-ES (SDL2)

Topic actions

Reply 20 of 41, by Diduz

User metadata
Rank Newbie
Rank
Newbie

aqualung99, your DosBox is potentially great: I think the Lottes shader is my favorite CRT shader ever. 😀
Unfortunately, I noticed the precompiled version is extremely slow and choppy when "frameskip=0" is set. I don't use the "frameskip=1" setting when I play, because some of the smoothest games suffer from this. Alas, I cannot help you to understand why this happens, because I'm not a programmer and I cannot compile the code.
Anyway, I endorse the effort and I hope you'll be able to merge your fork with Nuked OPL3 and Glide support! 😉

Reply 21 of 41, by aqualung99

User metadata
Rank Newbie
Rank
Newbie

That doesn't sound so good.
The Lottes2 shader is *very* demanding -- with branches, etc. It could be that your video card is having difficulty keeping pace. You can test that theory by using a smaller window: if fewer pixels has a dramatic impact on performance, then the video card is likely your culprit.

You could also try the bicubic option (that I mention earlier, with "perform_2pass=true".) See if that option is a lot faster or not.

For the record, part of the intention of this project was to _increase_ performance. By removing all scaling/rendering work from the CPU, it is freed-up to compute more x86 cycles. And output resolution has no CPU-side impact. On my PC I can run Quake in 640x400 (with cycles=250000 and frameskip=0) using the Lottes2 shader and still get around 60fps.

Reply 22 of 41, by Diduz

User metadata
Rank Newbie
Rank
Newbie
aqualung99 wrote:

The Lottes2 shader is *very* demanding -- with branches, etc. It could be that your video card is having difficulty keeping pace. You can test that theory by using a smaller window: if fewer pixels has a dramatic impact on performance, then the video card is likely your culprit.

I get the same problem at every resolution, fullscreen or windowed. Also, I've got a Geforce GTX 1050 Ti 4Gb DDR5 VRAM, which can even handle Retroarch with CRT Royale shader (12-passes!) smoothly. The problem must be somewhere else. Beats me.

aqualung99 wrote:

You could also try the bicubic option (that I mention earlier, with "perform_2pass=true".) See if that option is a lot faster or not.

I see no difference, except that the image looks wrong. 😊

Reply 24 of 41, by Diduz

User metadata
Rank Newbie
Rank
Newbie
aqualung99 wrote:

Would it be possible for you to send me your .conf file? I'd like to see if I can get the same behavior to happen.

Sure. Could be something related to audio?

Attachments

  • Filename
    dosbox.conf
    File size
    11.72 KiB
    Downloads
    100 downloads
    File license
    Fair use/fair dealing exception

Reply 25 of 41, by aqualung99

User metadata
Rank Newbie
Rank
Newbie

I think it's related to the code in DosBox that attempts to automatically adjust CPU cycles. It no longer functions correctly.
When I use your .conf file, all sorts of bad things happen to my computer and I have to reboot! 😀

Please find the line in your .conf that reads:

"cycles=auto"

and change it to read:

"cycles=80000"

That should fix the problem. Unfortunately with modern DosBox you need to manually adjust your "cycles" (i.e. how fast to make your virtual Dos machine) yourself. 80,000 should act like a reasonably fast 386. You will need a much lower number for older games.

Let me know if that fixes the problem for you!

Reply 26 of 41, by Qbix

User metadata
Rank DOSBox Author
Rank
DOSBox Author

I worked for a long time on that code recently and it behaves pretty good as far as I know
Is that with the recent code or with the 0.74 auto cycles code ?

If it is with the current code, then we might need to run some more tests, as I still have the knowledge on how that piece of code works in my mind 😀
For one, it should never cause a reboot...

Water flows down the stream
How to ask questions the smart way!

Reply 27 of 41, by aqualung99

User metadata
Rank Newbie
Rank
Newbie

This is with the old 0.74 code. I always had trouble with "auto" in that version; and in fact if that code is using any kind of per-frame rendering times to help it figure out how fast to go, then my changes might have made the behavior it even worse. It didn't really cause a reboot though -- it just started taking so many cycles that the window was no longer responding to my close command and I took drastic measures 😀

Were your changes to fix "auto" limited to the code in the CPU folder? I don't think I've touched any of that code.

Reply 28 of 41, by Qbix

User metadata
Rank DOSBox Author
Rank
DOSBox Author

Nope.
Some tiny changes to src/hardware/mixer.cpp
but the bulk of the work was done to src/dosbox.cpp (as that is where the work happens of the auto cycling) (revisions 4028-4043 (and then the commits towards trunk))
http://source.dosbox.com/dosboxsvn.html

Water flows down the stream
How to ask questions the smart way!

Reply 29 of 41, by Diduz

User metadata
Rank Newbie
Rank
Newbie
aqualung99 wrote:

Let me know if that fixes the problem for you!

Unfortunately, it didn't. 😢
There's something strange too: isn't 80000 overkill to emulate a 386? In regular DosBox, I have to set 3000/4000 in order to get AdLib sound in The Secret of Monkey Island or Indiana Jones and the Last Crusade, otherwise I get an "integer divide by 0" error. I got the same error on my old real Pentium, I remember I had to slow down the CPU to get AdLib sound on these games. If I set 80000 with your version of DosBox, I get the same error message, so I don't think DosBox ES is really emulating a 386 at 80000 cycles.

Reply 30 of 41, by aqualung99

User metadata
Rank Newbie
Rank
Newbie

Bummer. Are you willing to help try to narrow down what might be going wrong? The next thing I would want you to do would be to do a sanity test against the old DosBox official 0.74 release. Do you happen to have that old version around? If not, I can make you one.
If that version works perfectly fine then we know the problem is definitely in my code; and since Windows has basically none of the audio changes, that would put the problem squarely in the GLES code. Then I would probably make a custom build for you to run that would record some timings and stuff -- clearly the code is getting bogged-down somewhere!

Oh as for the cycles count, you know, you gotta do what you gotta do 😀 None of the games I play regularly use OPL2, and I like my DOS to be a little bit on the smokin'-fast side 😀 Probably from only having a 386-16 for so long.....
Anyway, for compatibility sake let me amend my previous statement and recommend instead 4000 cycles 😀

Reply 31 of 41, by Diduz

User metadata
Rank Newbie
Rank
Newbie
aqualung99 wrote:

I would want you to do would be to do a sanity test against the old DosBox official 0.74 release.

Done, original 0.74 Dosbox works perfectly fine with openglnb rendering and frameskip=0. Btw, the new Dosbox Communiy Enhanced edition works fine too (surfacenpp rendering).
I don't know it this can help, but your Dosbox ES works fine if I set "frameskip=1".
I feel bad about this, because honestly you could play the vast majority of DOS games with "frameskip=1" without even noticing the choppiness: they were choppy anyway. 😊 The problem is with more modern games such as Jazz JackRabbit, which used Mode-X to get extra-smooth graphics: you really miss the effect if you force DosBox to skip every other frame. Just this. 😀

Reply 32 of 41, by Ant_222

User metadata
Rank Oldbie
Rank
Oldbie
aqualung99 wrote:

As for your "pixel perfect" patch, there is no need. I have already recently implemented that in my code. I've posted a new Window binary containing this change. To use it, you will need to edit your "DosBox-0.74-ES.conf" file.
I have added a new option to the [sdl] section of the config called "make_square_pixels". This only works properly in Windowed mode, unfortunately. It does not work in fullscreen.

From my viewpoint, this is a serious limitation.

In Windowed mode, if you set "make_square_pixels=true" then the window will always be a 4x3 aspect ratio. If you set "make_square_pixels=false" then the pixel layout from the DOS program is used as-is.

These settings seem reversed. In order to make a 4:3 image from a 320 x 200 game its pixels should be treated as 5:6 rectangles. Maybe you can rename the flag to something like stretch_to_43?

You can then use perfect multiples of your target resolution to get pixel-perfect doubling, tripling, etc.

If your build will not try to interpolate the result, it will be indeed equivalent to running the pixel-perfect patch in windowed mode.

For example, if your target program runs at 320x200, and you set your window resolution to 640x400 and set make_square_pixels=false, then you will get perfect doubled pixels with no correction.

This is another problem. My patch will automatically calculate the optimal integer scaling factors, taking into account the pixel aspect ratio and double-width and double-height flags. This must be done on the CPU and the result passed to the shader.

If you would pass horizontal and vertical scales to the pixel shaders as parameters, you would have pixel-perfect scaling in fullscreen too.

Reply 33 of 41, by aqualung99

User metadata
Rank Newbie
Rank
Newbie

Been gone for a while -- just wanted to post an update about the performance problem with frameskip=0 in my build.
I've posted a new build (https://github.com/aqualung99/dosbox-0.74-ES/ … dows_010718.zip) that, when combined with the latest nVidia drivers, appears to clear up the problem. It does on my machine anyway -- I'd be curious if anybody else tries it out and what the result was.

@Ant_222 I admit I'm a little bit puzzled how to handle having fullscreen without scaling pixels. So, for (say) 320x240 fullscreen would you propose having 20-pixel tall blank areas at the top and bottom of the screen?
Such a change wouldn't be too tough if it weren't for the 2-pass support; that makes it a little bit trickier. Let me give it some thought.

Reply 34 of 41, by Diduz

User metadata
Rank Newbie
Rank
Newbie
aqualung99 wrote:

Been gone for a while -- just wanted to post an update about the performance problem with frameskip=0 in my build.
I've posted a new build (https://github.com/aqualung99/dosbox-0.74-ES/ … dows_010718.zip) that, when combined with the latest nVidia drivers, appears to clear up the problem. It does on my machine anyway -- I'd be curious if anybody else tries it out and what the result was.

Everything is smooth now! Way to go! There are no aspect correction and scalers in this compile, though...

Reply 35 of 41, by Ant_222

User metadata
Rank Oldbie
Rank
Oldbie
aqualung99 wrote:

@Ant_222 I admit I'm a little bit puzzled how to handle having fullscreen without scaling pixels. So, for (say) 320x240 fullscreen would you propose having 20-pixel tall blank areas at the top and bottom of the screen?

The exact number depends on the target resolution. For 1680x1050 the answer will be:

320x240 -> [4x4] -> 1280x960

which leaves vertical margins of 45 pixels and horizonal ones of 200 pixels.

Such a change wouldn't be too tough if it weren't for the 2-pass support; that makes it a little bit trickier. Let me give it some thought.

Thank you, but bear in mind that for complete support of pixel-perfect mode you will have to pass certain additional information to the shader, such as the double-height and double-width flags and the source pixel-aspect ratio (PAR).

Reply 36 of 41, by aqualung99

User metadata
Rank Newbie
Rank
Newbie

@Diduz that was an accidental oversight. I am flying blind with this problem somewhat; the build was working quite well yesterday (so I quickly posted it!) but today after messing about with some settings and some code, I am back to the same old problematic behavior. Even more bizarrely, the same build that I posted is no longer working correctly for me on my machine!
I don't think any of this is related to that sizing code (though I could be wrong.) I'm continuing to look for some sort of cause or at least remote commonality but it is very difficult. For me, when the problem happens I cannot exit the program normally and have to reboot the whole machine. So each failure takes time. (I am on a 1080 now, but wrote the code originally on a 980.)

@Ant_222 I think I understand; that will probably require that I rewrite how how I'm dealing with the scaling altogether. I do see the benefit though -- especially since I think that will make the format more closely match other similar ones (like in MAME, etc.) I'm definitely willing to put that on the todo list.

Of course that will have to wait until I can figure out this frameskip0 problem. I'm tempted to try out a few other video cards to see if there is any difference as well. I also have an old 780 to test with; since each failure requires a reboot I might as well swap a video card while I'm at it! 😀

Reply 38 of 41, by aqualung99

User metadata
Rank Newbie
Rank
Newbie

New build posted (https://github.com/aqualung99/dosbox-0.74-ES/ … dows_010818.zip)
with fullscreen aspect ratio correction. That scaling code all needs some work.

I think the next immediate concern is to expose vsync on/off as a property in the .conf file.

Reply 39 of 41, by Diduz

User metadata
Rank Newbie
Rank
Newbie
aqualung99 wrote:

New build posted (https://github.com/aqualung99/dosbox-0.74-ES/ … dows_010818.zip)
with fullscreen aspect ratio correction. That scaling code all needs some work.

I think the next immediate concern is to expose vsync on/off as a property in the .conf file.

I've just noticed that the plain Lottes shader produces a garbled image. Lottes2 works fine.