Yesterplay80 wrote:

Unfortunately, that's normal because software scaling consumes massive amounts of CPU power.

Why can't OpenGL do this on the GPU?

realnc wrote:

Yesterplay80 wrote:

Unfortunately, that's normal because software scaling consumes massive amounts of CPU power.

Why can't OpenGL do this on the GPU?

As I understand things, the image is processed internally before being put out through the desired method. I might be wrong, though, maybe one of the devs can explain it better.

I have changed that in my local code actually (a while ago), but the resulting image can be different. (between letting opengl doing all the scaling vs scale software first and opengl later), so I am doing a lot of tests before committing it.

I am very new to this, so please forgive me if the question is stupid.
For MT-32 support do I need to install MUNT just like I would with the regular DOSBOX or is the MT-32 support already build into the ECE version? And if it is, how do I enable/configure it?

cambeiu wrote:

I am very new to this, so please forgive me if the question is stupid.
For MT-32 support do I need to install MUNT just like I would with the regular DOSBOX or is the MT-32 support already build into the ECE version? And if it is, how do I enable/configure it?

It's built-in. To use it, you set these in your dosbox-ECE.conf file:

1mididevice = mt32
2romdir = <directory path that contains your MT-32 ROMs>

When you run dosbox-ECE for the first time, a default dosbox-ECE.conf file is created which contains documentation comments for the various settings.

Perfect. Thanks a lot!

Hi all,

Ive been playing around with 3DFX in Dosbox ECE. Ive got it working but I have a question about how to change a certain setting. When I use voodoo=software the window size is able to respect my dosbox windowresolution setting, however not all games are smooth when using this setting. When I use voodoo=opengl although those same games run smooth, the window is set to 640x480. The Dosbox status window is also telling me "VOODOO: OpenGL: mode set, resolution 640:480". My assumption is that glide2x.ovl is set for this resolution but I have not been able to change it. Any tips?

Only the more accurate software emulation of the Voodoo allows scaling, the OpenGL emulation is faster but restricted to the original resolution of the Voodoo 1 chip.

Thanks for the heads up. Is that likely to change at any point (opengl emulation for either the Voodoo 1 6mb (I believe that card could do (limited) 800x600), or Voodoo 2 for example?) or stay like that for the foreseeable? And please don't take that as a lack of appreciation for current achievements!

The patch enabling Voodoo emulation was created by kekko (VIDEO - 3dfx voodoo emulation (SDL1)), but he hasn't updated it in the last five years, so I wouldn't expect any updates in the foreseeable future.
You already can define more memory for the Voodoo, however. if you set voodoomem=max it will use 12 MB of video memory instead of the 4 MB it normally does. I don't know if there'a any game that benefits from this setting, though. A resolution of 800x600 could only be achieved by using TWO Voodoo 2 cards in SLI mode back in the days, a feature which isn't emulated in this patch, afaik.

Yesterplay80 wrote:

A resolution of 800x600 could only be achieved by using TWO Voodoo 2 cards in SLI mode back in the days, a feature which isn't emulated in this patch, afaik.

No, two V2 in SLI could push the resolution to 1024x768. With one V2 in system, 800x600 is max resolution.

Srandista wrote:

Yesterplay80 wrote:

A resolution of 800x600 could only be achieved by using TWO Voodoo 2 cards in SLI mode back in the days, a feature which isn't emulated in this patch, afaik.

No, two V2 in SLI could push the resolution to 1024x768. With one V2 in system, 800x600 is max resolution.

I think he meant to say Voodoo 1.

aardvark82 wrote:

It's a constant behaviour with any 640x480 resolution game i've tested, but only when scaling to 960x720.

Can you please name an easily obtainable and runnable 640x480 game so that I can debug and fix the error? Angel devoid is 1.9 Gb monster.

Something wrong with dosbox ece download page? 😕

aardvark82 wrote:

640x480 --> 960x720 surfacenp scaling is glitchy since ECE r4180.3
Bottom of the window doesn't update properly. Works fine on r4180.2 and older.

Yesterplay80, can you please check whether the bug persists the with the attached version of my patch?

realnc wrote:

realnc wrote:

Can I use "output = opengl" and "scaler = normal6x forced" and simply forget about it?

Answering my own question: nah, it's slow as hell during fade effects. The game slows down to a crawl when using 6x with a 640x480 game.

Try pixel-perfect scaling with OpenGL:

1fullresolution = desktop
2output         = openglpp
3scaler         = none

It will automatically adapt to the current game resolution.

Ant_222 wrote:

Try pixel-perfect scaling with OpenGL: […]
Show full quote

realnc wrote:

realnc wrote:

Can I use "output = opengl" and "scaler = normal6x forced" and simply forget about it?

Answering my own question: nah, it's slow as hell during fade effects. The game slows down to a crawl when using 6x with a 640x480 game.

Try pixel-perfect scaling with OpenGL:

Copy code to clipboard

1fullresolution = desktop
2output         = openglpp
3scaler         = none

It will automatically adapt to the current game resolution.

I know. The point was to not do that, because it leaves black bars with some games, and/or incorrect aspect ratios with others. On the other hand, 6x integer upscaling with subsequent bilinear opengl downscaling looks virtually perfect (at least on my higher-than-regular-DPI screen) *and* is fullscreen *and* has the correct aspect ratio.

realnc wrote:

The point was to not do that, because it leaves black bars with some games, and/or incorrect aspect ratios with others.

You can't have a correct aspect ratio without the black bars unless your display is 4:3.

realnc wrote:

On the other hand, 6x integer upscaling with subsequent bilinear opengl downscaling looks virtually perfect (at least on my higher-than-regular-DPI screen) *and* is fullscreen *and* has the correct aspect ratio.

What about openglnb—nearest-neighbor interpolation should look well on hi-res displays, and it is hardware-accelerated.

Ant_222 wrote:

You can't have a correct aspect ratio without the black bars unless your display is 4:3.

No, I mean some resolutions are not shown as 4:3 when using pixel perfect. 640x400 for example is not shown as 4:3. And by black bars I mean the top/bottom black bars, not the left/right ones.

realnc wrote:

What about openglnb—nearest-neighbor interpolation should look well on hi-res displays, and it is hardware-accelerated.

It looks very distorted. Maybe on a retina-level display it might look better, I don't know. But on my 1440p display, it's just too distorted.

In any event, the best way to upscale "pixel-art" games really is to upscale them with integer scaling to a higher then native res, and then downscale that with filtered downscaling to the native res. The result is rather superb.

realnc wrote:

On the other hand, 6x integer upscaling with subsequent bilinear opengl downscaling looks virtually perfect (at least on my higher-than-regular-DPI screen) *and* is fullscreen *and* has the correct aspect ratio.

How do you do this?