eL_PuSHeR wrote:

1. Yes I already tried your CVS build. It works just fine using renderer=direct3d

2. Yes, I have latest Catalyst 5.6 - OpenGL renderer doesn't work yet (DOSBox 0.63)

Strangely enough I did the same and have the same drivers , and guess what :
no errors here 😁
I think I had a porked 0.63 build , and i have to admit that the direct3d output is on paar with overlay output with my settings (and i finally have the looks from then , hate scalers 🤣 )
openglnb and direct3d are so far nearly equally good, (other than the fact i cant load custom smartshaders in direct3d!!!), having said that , how hard is it to implement a module to accept a shader written for ati smartshader tool ? Essentially the smartshader fx are operating on the backbuffer. Because that opengl ones did the very same thing, and resluts very VERY nice (HDRrish for playing games is way cool) !
Seems I have to learn some direcd3d shader stuff in the meantime 😉
(jsut peeked into the .fx filez) 😁

Smart shaders should work just fine in D3D mode (you're talking about Smart Shader setting in the control panel, right?) but some of them are OpenGL only so you have to select the right one.

In fact I wasnt refering to the control panel ones , ati released an (unsupported) tool that works for opengl only , and only on the rendered frame (it manipulates the 2d data when buffer swaps), in opengl mode you actually manipulate the pictures so much you want while staying of the boundaries of the cards limits, the generic shaders supplied with ati drivers are generally crap or other sensless effects.
But if one could make their one shaders with the direct3d (which seems to work , you using the .fx files to set up the shaders) it would even work on non ati cards.
I have at. some examples of the custom shaders that work with every opengl app. (for ATI cards only of course!)

Still it doesn't work for me using OpenGL, even with drivers defaults. I get a SDL_APP window that closes fast. I am quite satisfied with overlay though. I should try a different SDL.DLL version, but who cares about OpenGL.

eL_, what SDL.DLL are you using?

More weirdness....

Gulikoza's build works perfectly using output=opengl

My DOSBox 0.63 used SDL.DLL version 1.2.8.0

Tried replacing it with the one from Gulizoka's build but STILL DOESN'T WORK. 😕

NV1 emulation could be what I'm looking for. Hardware limitation possibly...
===========================
debug showed something like this:
..................~=.IB
M COMPATIBLE....
8.!04/18/96...BR
D001C-2 1/2/4MB
(Hyper Page Mod
e enabled) DRAM
with 64-bit DAC
==========================
windrv showed something like this:
Nvidia NV1 PCI VGA Compatible Device
Nvidia Corporation
4.02.1120
Copyright Nvidia Corp. 1994-1995

NVDISP.DRV
NV.VXD
vmm32.vxd (vdd.vxd)
============================
ASUS 166MMX
64MB SDRAM
AWE32
W95b
DOSBox 0.63 wouldn't start.

Guest: S'cuse me, you're trying to run DOSBox on a 166MHz processor?

Reopening this old thread.
I've decided to take a look as I have ATI and I still remember a thing or two about OpenGL. It did not take long to find the culprit (sdlmain.cpp):

1#if C_OPENGL
2	case SCREEN_OPENGL:
3		glBindTexture(GL_TEXTURE_2D, sdl.opengl.texture);
4		glTexSubImage2D(GL_TEXTURE_2D, 0, 0, 0, 
5				sdl.draw.width, sdl.draw.height, GL_BGRA_EXT,
6				GL_UNSIGNED_INT_8_8_8_8_REV, sdl.opengl.framebuf);
7		glCallList(sdl.opengl.displaylist);
8		SDL_GL_SwapBuffers();
9		break;
10#endif

GL_BGRA_EXT is not supported by ATI hardware. One of the principles (and often annoyances) of OpenGL is that it silently drops to software mode if it encounters a feature unsupported by hardware. Just do a little test -- replace GL_BGRA_EXT with GL_RGBA (known supported) and DOSBox suddenly becomes 100x faster on ATI. Well, you'll have blues and reds swapped.
There is another place where GL_BGRA_EXT is used but that one does not get called every frame.
I can see that RGBA was used at some point (or an attempt to use it was made), line 690 in the same file. It may be way to go. I don't have NVIDIA card right now to test if that mode is supported in hardware but I think it is.

That's really good news. Reds and blues can probably be swapped in GFX_GetRGB. I'm gonna test this as soon as I get home 😁

Yes, I already tried that, seems to be working just fine. There is even commented out code there just to that effect. Do you have NVIDIA card to test?

I can probably get a friend to test it....
There's just one thing bothering me. I'm pretty sure I've already looked into this texture issue, but I thought it was ok since I was sure GL_BGRA_EXT is supported by ati. I even found this:

1/*
2** GL_EXT_bgra
3**
4**  Support:
5**   Rage   128   based : Supported
6**   Radeon 7000+ based : Supported
7**   Radeon 8500+ based : Supported
8**   Radeon 9500+ based : Supported
9*

Are they saying it's supported and do a software conversion anyway ??

You know, something is very odd going on. After I tried it in RGBA mode I can run in BGRA. I don't understand this, I did not install anything new in the last few days, did not change any settings. It's almost like there is some state that was left hanging and it cleared up.

EDIT: I even rebooted my system -- I don't see the old behavior anymore. Before, running 0.63 with opengl almost locked my system, now it runs just fine without any frameskip. Weird, really weird.
The only thing I've istalled in the past few days is Visual Studio 2005 Express (freely downloadable from MS). Hmmm...

I can see no difference...Dosbox takes 100% cpu with GL_RGBA as well. And I have Visual Studio installed too 😀

Neither can I... anymore 🙁 Both are taking close to 100% of CPU but I can run two copies of DOSBox at the same time and then each takes only 50%, both working fine. Before I could not even run one copy without frameskip and I have no idea what changed in the last four days. There was probably some data stuck in driver or something.

Well, finally I'm no longer the only one who has opengl working just fine...

One thing I have noticed which may be of some use: I once had problems with GL_RGBA_888 (or whatever it was, don't remember exactly), it was slow, while using plain GL_RGBA was fast. In both cases I fed the same data into it and got correct results. I think ATI drivers have a few quirks in that area.

vasyl, btw, OpenGL falls back to software mode silently, but you can query OpenGL if you are using a "recommended" data format. It's just quite unknown 😉

100% CPU isn't what I'd call "just fine"... I know it's probably just a busy wait or something though (as vasyl indicates with two copies running fine at 50% usage each).

As for the performance variance due to texture format, it sounds like it may be worth trying to either:
- use a format that works well across most cards
- try to auto-select the appropriate format based on available data (OpenGL queries, etc.), and/or
- let the user specify in dosbox.conf?

Although if I'm reading this thread correctly, you guys aren't getting reliable results from using certain texture formats?

Apparently I am not getting reliable results on the same machine... ATI OpenGL definitely has its share of quirks.

XP has an OGL->D3D wrapper included that enables itself in some situations. (Doesn't work all the time).
Mabye this is having an effect?

Try disabling all Ddraw/D3D acceleration in Dxdiag and then trying OGL.

Feel free to call me crazy but here's what I found on my system. If I have VirtualPC running (not a virtual machine, just a launcher in status bar) DOSBox OpenGL switches to software mode 😳 Really hard to kill it, the system is almost completely locked. I have to slowly move extremely jerky mouse, click, and wait 20 seconds or so. Tried a few times -- VPC launcher is running -> DOSBox is in software OpenGL; VPC launcher is not running -> DOSBox is in hardware (still not idling, at 100%, but at least usable).
Direct3d seems to be completely unaffected, which does not surprise me -- D3D does not have a habit of silently dropping to software, it would just fail. I've tried a few OpenGL demos and none seemed affected by the issue but I could not find any windowed demo using textures as large as DOSBox does.
Something tells me that VPC launcher is not the only application that can trigger the issue. Now, what exactly does it trigger???