VOGONS


First post, by Gagster

User metadata
Rank Newbie
Rank
Newbie

There are certain older games and even emulators that's either not maintained much nowadays, or maybe still maintained but with rather "ancient" video-support. What I have in mind, is the good old Dos-emulator DosBox, OpenTyrian, and the freeware game Giana's Return.

What all of those games/emulators have in common, is that they use the old SDL 1 API. They can all scale the image to some degree, but they are not 4K/8K ready to put it that way. Giana's Return can scale the image to fill some of the screen while using a 1080p monitor, but not all of the screen-space. OpenTyrian on the other hand have its source code available, so I manually added a 5X scaling mode (from 4X), but I could not run any higher scale than 4X in fullscreen mode somehow (while the 5X mode works in windowed mode). That may because of limitations of the SDL 1 API, but it can very well be due to my lack of programming experience (most likely that). Regarding DosBox, I have for some time used a special build (SVN Daum by ykhwong) for the sole reason of it having a normal 5X scale mode included (usually DosBox only has normal 4X scale as max), so I can use all the screen-space of my 1080p monitors.

When I get a UHD/4K TV/monitor some time in the future however, even the scaling in the SVN Daum by ykhwong DosBox build won't be enough.

There is some confusing way to somehow use dgVoodoo2 with SDL I was told, as quoted here by Dege from the "dgVoodoo 2 for DirectX 11" thread:

SDL should work but its default renderer seems to be OpenGL even on Windows.
(see https://www.libsdl.org/release/SDL-1.2.15/doc … sdlenvvars.html, for more, at least for SDL 1.x)
When I set SDL_VIDEODRIVER=directx environment variable in a command box and launched Giana's executable from there, then it worked for me:

As I'm using Windows 10, I have tried various ways to do this (even googled quite a lot without understanding how I switch the SDL_VIDEODRIVER to directx in Windows). I'm not that familiar with Linux and such, and I had to use way too many hours to even successfully compile the source-code of OpenTyrian with MSYS2 in Windows (because of a missing sdl 1 installation in MSYS2) to even add that 5X scaling mode in OpenTyrian.

Well, enough of my rambling. Is adding more SDL 1 support something that's in the future scope of dgVoodoo2?

(I got some success in making dgVoodoo2 to work with DosBox, by changing the "output" value in dosbox.conf to ddraw)

CPU: i7-4790K
RAM: 16 GB
GPU: GeForce GTX 1080
OS: Windows 10 64 bit

Reply 1 of 11, by ZellSF

User metadata
Rank l33t
Rank
l33t

I'm amazed that you managed to figure out how to modify OpenTyrian's source code and build it, but can't figure out how to set environment variables. The simplest way to set a temporary environment variable is just to type it into a command prompt before running the game from the same command prompt:

set SDL_VIDEODRIVER=directx
opentyrian.exe

opentyrian 2017-10-22 19-30-20-99.jpg
Filename
opentyrian 2017-10-22 19-30-20-99.jpg
File size
593.55 KiB
Views
1900 views
File license
Fair use/fair dealing exception

Also in case you're not aware there's a SDL2 version of OpenTyrian. It has aspect ratio correction implemented, though I suppose dgVoodoo2 can always handle that anyway.

Dege: this brings up an interesting question actually. If I want to run Tyrian integer scaling with no filtering at its proper aspect ratio (4:3) then I would need to have different integer scaling factors for different axis. Is there any chance that's easy to implement? Since I have a 1440p monitor I would need to run Tyrian at 320*5x200*6 (1600x1200) centered if I wanted a pixel perfect picture. Or if I wanted to I could do 320*6x200*7 (1920x1400) which would still be less AR distortion than using equal scaling factors for both axis and fill out more of the screen. This is going to get more important for 320x200 & 640x400 games when we get higher resolution monitors.

Reply 2 of 11, by Gagster

User metadata
Rank Newbie
Rank
Newbie

Thanks; it was really that easy to set environment variables? I thought you were supposed to download some kind of Linux-command prompt for Windows (or even edit some of the SDL source-files and then recompile SDL.dll), like I had to do to compile opentyrian (that was a nightmare to compile). Now I just made a batch-file named start.bat, and put those two lines you named in that file to quick-launch SDL games with dgVoodoo2. Kind of embarrassing that I didn't figure out that on my own, I know.

I did not know of a SDL2 port of opentyrian; I thought that the development of opentyrian in general halted a long time ago. Might be worth checking out.

Well, since dgVoodoo2 handles both the 3dfx/glide API and earlier versions of ddraw/d3d, SDL 1 support as of now works with the "set SDL_VIDEODRIVER=directx" workaround. Is OpenGl support in dgVoodoo2 a feature that's planned in a future release? I have no idea whatsoever how much work that would be to implement, and one of the few benefits I see with OpenGl support as of now is better native SDL support maybe?

Edit: just managed to compile the SDL2 version of opentyrian with msys2, but somehow the audio is distorted/sounds like its broken after compiling. It's easier when a precompiled version if available, but I have to try again later I suppose.

CPU: i7-4790K
RAM: 16 GB
GPU: GeForce GTX 1080
OS: Windows 10 64 bit

Reply 3 of 11, by Dege

User metadata
Rank l33t
Rank
l33t
ZellSF wrote:

Dege: this brings up an interesting question actually. If I want to run Tyrian integer scaling with no filtering at its proper aspect ratio (4:3) then I would need to have different integer scaling factors for different axis. Is there any chance that's easy to implement? Since I have a 1440p monitor I would need to run Tyrian at 320*5x200*6 (1600x1200) centered if I wanted a pixel perfect picture. Or if I wanted to I could do 320*6x200*7 (1920x1400) which would still be less AR distortion than using equal scaling factors for both axis and fill out more of the screen. This is going to get more important for 320x200 & 640x400 games when we get higher resolution monitors.

Yes, it could be implemented easily.

Gagster wrote:

Is OpenGl support in dgVoodoo2 a feature that's planned in a future release? I have no idea whatsoever how much work that would be to implement, and one of the few benefits I see with OpenGl support as of now is better native SDL support maybe?

CoolGamer once asked the same and I replied:

It depends... what OGL version. […]
Show full quote

It depends... what OGL version.

I had a quick look at OpenGL 1.4 and its core funtions don't seem to be too hard to implement. But, as always, it'd take much more time than I may think now, because there are always unexpected things, debugging, reverse engineering because of the details, etc.
Even the shader assembly of 1.5 could be supported, I think.
(Starting with 2.0 GLSL as shader language appeared which requires an internal compiler, it's complicated...)

However there are a lot of non-core 'glu*' functions that are not rendering- or GPU-specific. For example, the glu tesselator, bezier curve utilities and such.
They'd be time consuming to implement and also needless, and I'm not sure I could 'write better' versions than the existing matured implementations (also, I don't want to copy paste them from an opensource implementation).
(DirectX separates the API set into two, lowlevel 'immediate' mode (what I implemented) and high level 'retained mode' or D3DX for newer API versions)

So the best solution would be to override OGL core functions in dgVoodoo and pass the others to the host OpenGL implementation. 😖

So, all in all, it's not a work of 5 minutes, but on the other hand, I wouldn't have to start OGL from a full scratch: OGL could be tied to the slightly modified DDI (backend) that DX implementations currently are.
glu* functions however should have to be passed to the host OGL implementation. OGL extensions ( 😵) may not be hard question for OGL 1.4/1.5 (I'm unsure).

Reply 4 of 11, by CoolGamer

User metadata
Rank Member
Rank
Member

ScummVM also has an OpenGL rendering mode through SDL 1. I think it would be beneficial to start OpenGL implementation in the easiest possible way (such as passing some functions to host OpenGL), later you can do full conversion from Opengl to pure Directx, step by step, as you add more features time permitting. I guess SDL 1 is a good starting point since many games use it. ScummVM alone has so many games in it that can benefit from dgVoodoo's advanced scaling and v-sync in OpenGL mode.

I was able to run ScummVM in SDL 1 directx mode by using ZellSF's "set SDL_VIDEODRIVER=directx" trick. Thanks a lot for that ZellSF. I did not even know that it was possible.

Dosbox SVN Daum Build by ykhwong is pre-configured and included in the Steam versions of many old games such as Harvester and Tex Murphy Games. Sadly Daum build uses Directx9 in Direct3d output mode 🙁. This is one more reason to be enthusiastic about the upcoming Directx9 dgVoodoo wrapper 😀. This way we will be able to use integer upscaling and v-sync in Dosbox Daum via dgVoodoo.

Reply 5 of 11, by spiroyster

User metadata
Rank Oldbie
Rank
Oldbie

Given that pretty much every gfx since 2000ish supports opengl, why not pipe all functions straight to the host, it would certainly give you less of a headache for retained stuff. Windows natively supports upto opengl 1.2 via gl.h out of the box, anything extra is exposed through gl extensions, clients requiring above 1.2 should call wglgetprocaddress on all extensions they require at runtime, and should head down appropriate code paths depending on the functions they retrieve (what's available on the machine). This includes vendor specific extensions which were more popular during the first decade of the millennium. For gl this is usually done through something like glew (gl extension wrangler). It wouldn't be hard to fire up a gl context under the hood and either draw straight to that or to an offscreen render buffer and then perhaps present this through your current backend (Ye old textured quad 0.o) This way you can use the bundled shader compiler provided by the vendor/icd. Also there is something called Mesa which is an open source implentation of gl (even supports vulkan 😀) which should give you a nice insight into the inner workings of gl if you want to go a semi software route. To my knowledge there is no major change to any of the functions over time so they don't behave differently, only addition of new states, enums and functions. I can't even recall prototypes/signatures changing. Yes there is a good chance glu was used for stuff like quadrics and power^2 image scaling in the earlier days until the latter was supported as standard. Vulkan (like dx12) is an entirely different ball game

SDL is much more though (keyboard, audio etc), However It's zlib lic so you can statically link it no problemo.

Reply 6 of 11, by Azarien

User metadata
Rank Oldbie
Rank
Oldbie

I wonder what would be the main purpose of OpenGL implementation.
To bump supported GL version a bit (e.g. 1.2 to 1.4?) — that theoretically could be done, depending on particular GL versions and supported extensions.
To bump supported GL version even more (1.x to 2.x or later?) — not really, software emulation of GLSL shaders would be sloow and we're talking of old and slow hardware to begin with.
To emulate GL 1.5 in Direct3D 9 for cards with poor or non-existing OpenGL drivers? Possible.
To emulate GL 2+ in Direct3D? Much harder.
To emulate GL 1.x fixed-function pipeline in core GL 4.x? Not needed for now, all vendors still provide drivers with compatibility context support.

Reply 7 of 11, by CoolGamer

User metadata
Rank Member
Rank
Member

I forgot to mention, Microsoft has an opensource Opengl ES to DirectX 11 wrapper named Angle. Link is below. Unfortunately it is only for OpenGL ES and no binaries are present. Binaries must be compiled from source by the user. Maybe Microsoft Angle might be useful for Dege as a starting point. It is free to use.

Dege might even translate the OpenGL calls into OpenGL ES compliant format and send them to a compiled Angle DLL to translate them to DX11 if it is easy for him to do so. In this proposal, dgVoodoo will handle OpenGL to OpenGL ES conversion and use Microsoft Angle DLL to translate OpenGL ES to DX11. This might also provide the option to pass OpenGL ES calls directly to the system drivers for OpenGL fans who want the game to stay in OpenGL.

The issue is that, since OpenGL ES is a subset of OpenGL for embedded systems, I don't know if all regular OpenGL calls can be translated into OpenGL ES or not. Maybe it is best if Dege does his own full OpenGL to DX11 implementation. I am sure that quality will be the best when Dege does it all on his own. 😀

https://github.com/Microsoft/angle

DotEmu used a compiled Angle DLL file in the Windows port of their Little Big Adventure 1 Enhanced edition game (steam version) to make the game DX11 compliant. I think the Android and iOS ports of the game use OpenGL ES. Apparently Angle is fast enough to add DX11 support to production quality games that are originally programmed for OpenGL ES. Even on my slow laptop with Nvidia GT 230M GPU, Little Big Adventure 1 Enhanced Edition played very fast.

dgVoodoo opengl wrapper will be useful with current enhancement features such as resolution upscaling, v-sync, texture filtering and anti-aliasing. It will be even more useful with the upcoming features such as texture replacement, ambient occlusion (HBAO) and Nvidia gameworks DLL integration. 😀. I agree that OpenGL wrapper is not the most urgent feature request, but it will be good if it gets implemented eventually.

Reply 8 of 11, by Azarien

User metadata
Rank Oldbie
Rank
Oldbie
CoolGamer wrote:

Dege might even translate the OpenGL calls into OpenGL ES compliant format and send them to a compiled Angle DLL to translate them to DX11 if it is easy for him to do so. In this proposal, dgVoodoo will handle OpenGL to OpenGL ES conversion and use Microsoft Angle DLL to translate OpenGL ES to DX11. This might also provide the option to pass OpenGL ES calls directly to the system drivers for OpenGL fans who want the game to stay in OpenGL.

I will add that ANGLE supports OpenGL ES 2.0 and 3.x (depending on user's hardware support), but it's missing ES 1.x. This means that it's shader-only. The fixed-function pipeline, matrix stack, immediate mode etc. are non-existent.
Some of those missing features are trivial to implement, some are rather tricky.
I don't think it is possible to accurately and fully emulate OpenGL 1.2 in OpenGL ES 2.0, but it should be possible with OpenGL ES 3.0.
And then there is GLU library, which would have to be written from scratch (or taken from Mesa or such).

Reply 9 of 11, by dr.zeissler

User metadata
Rank l33t
Rank
l33t

the SDL port of "opentyrian" does not work smooth on my P4-2,26 Ghz. The sound stutters sometimes and the video is not smooth,
there are visable lines on the top of the display, no smooth framerate over the entire display.

Is my machine to slow for it?

Retro-Gamer 😀 ...on different machines

Reply 10 of 11, by ZellSF

User metadata
Rank l33t
Rank
l33t
dr.zeissler wrote:

the SDL port of "opentyrian" does not work smooth on my P4-2,26 Ghz. The sound stutters sometimes and the video is not smooth,
there are visable lines on the top of the display, no smooth framerate over the entire display.

Is my machine to slow for it?

Isn't this of topic? Because I don't think you're running dgVoodoo2 on a Pentium 4 system?

At any rate, check CPU usage, if that's not maxed out it's probably your sound card driver. As for video not being smooth, keep in mind that unless your display runs at a refresh rate that's a multiple of 35 (normal game speed) or 50 (high game speed) it will never be completely smooth. LCDs displays (usually) don't do DOS games. Without knowing more about how those "visable" lines look like I can only guess they're tearing lines. Enable vsync in your graphic driver settings.

Reply 11 of 11, by spiroyster

User metadata
Rank Oldbie
Rank
Oldbie
Azarien wrote:
I will add that ANGLE supports OpenGL ES 2.0 and 3.x (depending on user's hardware support), but it's missing ES 1.x. This means […]
Show full quote
CoolGamer wrote:

Dege might even translate the OpenGL calls into OpenGL ES compliant format and send them to a compiled Angle DLL to translate them to DX11 if it is easy for him to do so. In this proposal, dgVoodoo will handle OpenGL to OpenGL ES conversion and use Microsoft Angle DLL to translate OpenGL ES to DX11. This might also provide the option to pass OpenGL ES calls directly to the system drivers for OpenGL fans who want the game to stay in OpenGL.

I will add that ANGLE supports OpenGL ES 2.0 and 3.x (depending on user's hardware support), but it's missing ES 1.x. This means that it's shader-only. The fixed-function pipeline, matrix stack, immediate mode etc. are non-existent.
Some of those missing features are trivial to implement, some are rather tricky.
I don't think it is possible to accurately and fully emulate OpenGL 1.2 in OpenGL ES 2.0, but it should be possible with OpenGL ES 3.0.
And then there is GLU library, which would have to be written from scratch (or taken from Mesa or such).

I reckon it would be quite a trivia exercise to replicate the fixed functionality pipeline in shaders, but agree, there is no point when most dx cards support full opengl anyhows. Seems a rather strange thing that angle lib. Must be purely for lazy ports of android games to UWP.