VOGONS


DOSBox ECE (for Windows & Linux)

Topic actions

Reply 681 of 1006, by Yesterplay80

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

My full-featured DOSBox SVN builds (without debugger) for Windows: Vanilla DOSBox and DOSBox ECE (Enhanced Community Edition)

Reply 682 of 1006, by Qbix

User metadata
Rank DOSBox Author
Rank
DOSBox Author

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.

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

Reply 683 of 1006, by cambeiu

User metadata
Rank Newbie
Rank
Newbie

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?

Reply 684 of 1006, by realnc

User metadata
Rank Member
Rank
Member
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:

mididevice = mt32
romdir = <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.

Reply 686 of 1006, by Python1980

User metadata
Rank Newbie
Rank
Newbie

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?

Reply 687 of 1006, by Yesterplay80

User metadata
Rank Member
Rank
Member

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.

My full-featured DOSBox SVN builds (without debugger) for Windows: Vanilla DOSBox and DOSBox ECE (Enhanced Community Edition)

Reply 688 of 1006, by Python1980

User metadata
Rank Newbie
Rank
Newbie

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!

Reply 689 of 1006, by Yesterplay80

User metadata
Rank Member
Rank
Member

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.

My full-featured DOSBox SVN builds (without debugger) for Windows: Vanilla DOSBox and DOSBox ECE (Enhanced Community Edition)

Reply 690 of 1006, by Srandista

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

My overkill "retro" PC - ASRock 4CoreDual-VSTA, Pentium E6500K, 512MB/4GB RAM, Radeon 9500@9700 (Softmod), ESS Solo-1 + Dreamblaster X2, 80GB IDE HDD, Win 98/XP

Reply 691 of 1006, by appiah4

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

A500:Rev6|+512K|ACA500+|C1084S
i386:Am386SX25|4M|GD5402|ES688
i486:U5S33|8M|GD5428|YMF719
i586:P133|32M|T64V+/MX2|V1|CT3980/32M
i686:K6-2/500|128M|Banshee|CT4500/32M
S370:P3-1200|384M|GF4-4200|MX300
S754:A3700+|2G|X800XTPE|SB0350

Reply 692 of 1006, by Ant_222

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

Reply 694 of 1006, by Ant_222

User metadata
Rank Oldbie
Rank
Oldbie
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?

Attachments

  • Filename
    pp24a-4253.diff
    File size
    86.92 KiB
    Downloads
    12 downloads
    File license
    Fair use/fair dealing exception

Reply 695 of 1006, by Ant_222

User metadata
Rank Oldbie
Rank
Oldbie
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:

fullresolution = desktop
output = openglpp
scaler = none

It will automatically adapt to the current game resolution.

Reply 696 of 1006, by realnc

User metadata
Rank Member
Rank
Member
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:

fullresolution = desktop
output = openglpp
scaler = 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.

Reply 697 of 1006, by Ant_222

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

Reply 698 of 1006, by realnc

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

Reply 699 of 1006, by KainXVIII

User metadata
Rank Member
Rank
Member
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?