CPU - the scaler is a mathematical algorithm applied to a bitmap image before it gets to the video card. MMX is certainly used in some of the implementations. I've never seen native scaler support (2D anyways) in a graphics card (or driver) but it certainly would be a good thing!

Having said that, the D3D output mode in DOSBox supports custom pixel shaders which can scale the output using the video card. This doesn't seem quite 'right' (to use D3D for an old 2D game) but if it works... 😀

Hmm, that's unfortunate. Knowing the amount of power those operations require, and how little the video card is taxed while running games in DOSBox, I think it would be awesome if those instructions could be pushed up into the GPU.

Try D3D patch from Gulikoza's page. Latest version claims to support scaling with shaders (normal, bilinear and advmame2x)

You can already get a good hardware-accelerated antialiasing effect by using overlay (and maybe openGL) mode, but for the fancier filtering modes someone would have to write pixel shader implementations like Srecko mentioned.

Reckless wrote:

I've never seen native scaler support (2D anyways) in a graphics card (or driver) but it certainly would be a good thing!

Of course there is native scaler support on most videocards, try using DirectDraw with an output window larger than the 'canvas'. I attached a small example. Of course, this is a kind of nasty blury scaling totally unusable, but still.

JAL

Yes, using overlay or ddraw you will get bilinear filtering at best. But I doubt Snover had that in mind...

Reckless wrote:

This doesn't seem quite 'right' (to use D3D for an old 2D game) but if it works...

Why is it that using D3D is 'strange', yet OpenGl (another 3D API) is in dosbox for some time now? 😁 Did you know that DirectX8 and 9 no longer contain ddraw interfaces (of course, since whole DX is backwards compatible you can use dx7 interfaces), any 2D graphics have to be done through Direct3D.
Anyway, to use GPU u need somekind of API....in this case D3D or OGL. I don't know how much the OGL interface in dosbox would need to be changed to support shaders, I don't like OGL that much since it doesn't work well on my ATi 😀
As already mentioned, I did find some shader examples I could integrate in my code and it would be great if somebody could code something like hq2x. It seems to be the most demanding. Unfortunately, the advmame2x shader seems to be running somewhat slower on my gpu than the current software implementation...

gulikoza wrote:

Why is it that using D3D is 'strange', yet OpenGl (another 3D API) is in dosbox for some time now? 😁 Did you know that DirectX8 and 9 no longer contain ddraw interfaces (of course, since whole DX is backwards compatible you can use dx7 interfaces), any 2D graphics have to be done through Direct3D.

Well, I also find it strange that OpenGL is supported although I never bothered to mention it. Yeah, I did know that ddraw is now 'obsolete' but that's just 'cause the world went 3D mad, nothing to do with the fact that there's still a use for 2D primitives.

Anyways, I've got nothing at all against your release although I've never used it.... I only have a DX8 card 🙁

Well with 3D there's always room to do some more stuff. Like I read somewhere, adding the emulation of curvature of the CRT screen 😁 Yeah...playing games on my 19" flat screen I really miss the 14" baloon I had before...you don't need dx9 for that 🤣

rofl, that's progress eh 🤣

Gulikoza, would it be impossible to realize scaling through pixel shading on DirectX 8 cards?

Btw, I have to agree that it's sad that nobody currently seems to work on the hq filter implementation for Dosbox. It's the best filter I've seen so far and I miss hq3x which was implemented in ScummVM.

Not to my knowledge...afaik ps1.4 is too limited in the instruction count to make these complicated shaders possible. Perhaps it would be possible to make some simpler algorithm but I don't know how to do it.

Uhm, well, actually there is.

It's sitting on my Harddisk.

I will post it soon, it does Hq2x (well, actually, Hq<any>x) entirely on the GPU, using a Radeon 9500/GeForce 5600 class card or better. It handles any scaling factor, including aspect ratio correction and non-integral numbers, though it will probably start to look bad at more than 16x scaling, and it is a bit questionable around 1x-1.2x scaling.

The look: gorgeous. Better than my current hq2x patch. The speed: impressive (I'm doing 320x200 -> 1280x800 with it), but on the above mentioned cards not fit for frameskip=0.

I haven't yet posted it, because I am pondering an SDL port. The current code uses OpenGL via SDL 1.3 (i.e., the current CVS) and is platform-independent. The scaler could be added to SDL itself, thus gaining hq scaling for all SDL apps (like scummvm or descent-sdl).

Watch the hq2x patch page on sourceforge, I'll probably post an experimental version soon.

😳 Jeeeeeezzzzzzzzzzzzzzz 😳

Just what has to be done !!! Can't wait 😁 !

No preview screenshots to send to me ? Want to dribble of love 😊 !!!

I will post it soon, it does Hq2x (well, actually, Hq<any>x) entirely on the GPU, using a Radeon 9500/GeForce 5600 class card or better

You must be using a shader program to do this. That sounds really slick to me. I have been playing with the shader support in Pete's OpenGL2 plugin for ePSXe. It does some pretty amazing things. And gives some ideas twords what else could be done with shaders.

`Moe` wrote:

Uhm, well, actually there is.

It's sitting on my Harddisk.

Sounds cool 😀

You may want to look at the sourceforge patches page. Just be warned, you need latest SDL cvs (upcoming 1.3).

What SDL is needed exactly? I pulled SDL12 from cvs and it has version 1.2.9 defined in config. There is no SDL13 module in sdl cvs 😕

Just use -r branch_1_3_x when checking out...oh wait...that was me asking 🤣

I've been trying to compile hq2x ogl patch under mingw for the past hour or so. There seems to be some problems:

1. sdl_opengl.h that the patch creates is also the name of SDL opengl include file. Sure that one is named SDL_opengl.h but windows is not case sensitive 😁

2. 2 functions cannot be found (glActiveTexture and glTexImage3D). Then I found this in the gl.h:

/* Under Windows, we do not define OpenGL 1.2 & 1.3 functionality, since
it is treated as extensions (defined in glext.h) */

and at the bottom

/* Include external definitions of OpenGL extensions */
/* Removed, see this bug report for reference:
* http://sourceforge.net/tracker/index.php?func … 435&atid=102435
*
* #include <GL/glext.h>
*/

These functions are also not present in libopengl32.a so I guess mingw does not have them.

I have been trying to compile the patch under MingW too. These two functions are part of OpenGL 1.2 and 1.3. The tricky part is that Windows has a very old OpenGL 1.1 implementation in opengl32.dll and all 1.2 and posterior functions are implemented by the driver as extensions, so you must load the functions dinamically by adding to the code :

1/* supported only on fairly recent video cards (somewhere around ATI Radeon 9500 or a similar NVidia card) 
2*/
3PFNGLPROGRAMSTRINGARBPROC glProgramStringARB = NULL;
4PFNGLBINDPROGRAMARBPROC glBindProgramARB = NULL;
5PFNGLGENPROGRAMSARBPROC glGenProgramsARB = NULL;
6PFNGLDELETEPROGRAMSARBPROC glDeleteProgramsARB = NULL;
7PFNGLGETPROGRAMIVARBPROC glGetProgramivARB = NULL;
8PFNGLPROGRAMLOCALPARAMETER4DARBPROC glProgramLocalParameter4dARB = NULL;
9PFNGLPROGRAMENVPARAMETER4DARBPROC glProgramEnvParameter4dARB = NULL;
10+PFNGLTEXIMAGE3DPROC glTexImage3D = NULL;
11+PFNGLACTIVETEXTUREPROC glActiveTexture = NULL;

and:

1glProgramLocalParameter4dARB = (PFNGLPROGRAMLOCALPARAMETER4DARBPROC)SDL_GL_GetProcAddress("
2glProgramLocalParameter4dARB");
3+glActiveTexture = (PFNGLACTIVETEXTUREPROC)SDL_GL_GetProcAddress("glActiveTexture");
4+glTexImage3D = (PFNGLTEXIMAGE3DPROC)SDL_GL_GetProcAddress("glTexImage3D");
5                if (gl_ext && *gl_ext) {

With these modifications, and renaming sdl_opengl.h to avoid case clashes, you can compile DOSBox, but it crashes in opengl and openglhq mode by an apparent threading problem, in a probe() function in libwinmm. Removing glActiveTexture and glTexImage3D doesn't help.