VOGONS

Common searches


DOSBox-X branch

Topic actions

Reply 660 of 2062, by Jarvik7

User metadata
Rank Newbie
Rank
Newbie
xcomcmdr wrote:

Maybe I'm off-topic, but kekko's 3dfx hardware emulation work/patch might interest you : 3dfx voodoo chip emulation
(not updated since ages, however...)

That thread hasn't been updated in 2.5 years, so it'll be no more up to date than anything else I think.

Reply 661 of 2062, by bloodbat

User metadata
Rank Oldbie
Rank
Oldbie

Thanks for all your work, I decided to integrate the GUS panning registers fix to my build and it works...with one small caveat: it seems DosBox emulates an older version of the GUS hardware (at least in the current SVN)...therefore stereo is reversed, I tried it in both Epic Pinball and Extreme Pinball, the first won't allow you to reverse stereo so...it can be fixed in code:

void WritePanPot(Bit8u val) {
PanPot = val;
PanLeft = pantable[(val & 0xf)];
PanRight = pantable[0x0f-(val & 0xf)];
UpdateVolumes();
}

Reply 662 of 2062, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie

I just realized I forgot to post the VGA register captures I mentioned earlier.

Here they are: http://hackipedia.org/Platform/x86/VGA/VGA%20 … er%20snapshots/

DOSBox-X project: more emulation better accuracy.
DOSLIB and DOSLIB2: Learn how to tinker and hack hardware and software from DOS.

Reply 663 of 2062, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie
bloodbat wrote:
Thanks for all your work, I decided to integrate the GUS panning registers fix to my build and it works...with one small caveat: […]
Show full quote

Thanks for all your work, I decided to integrate the GUS panning registers fix to my build and it works...with one small caveat: it seems DosBox emulates an older version of the GUS hardware (at least in the current SVN)...therefore stereo is reversed, I tried it in both Epic Pinball and Extreme Pinball, the first won't allow you to reverse stereo so...it can be fixed in code:

void WritePanPot(Bit8u val) {
PanPot = val;
PanLeft = pantable[(val & 0xf)];
PanRight = pantable[0x0f-(val & 0xf)];
UpdateVolumes();
}

Works for me. Applied.

DOSBox-X project: more emulation better accuracy.
DOSLIB and DOSLIB2: Learn how to tinker and hack hardware and software from DOS.

Reply 666 of 2062, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie
masaykh wrote:

i trying to build your versions from git using W64-mingw and cant pass GUI phase.
is there way to compile it with only opengl ?

Sorry, OpenGL is the optional part. You just need to make sure you're compiling SDL correctly.

I'm guessing that SDL isn't compiling because you don't have the DirectX SDK or headers installed.

DOSBox-X project: more emulation better accuracy.
DOSLIB and DOSLIB2: Learn how to tinker and hack hardware and software from DOS.

Reply 667 of 2062, by arromdee3

User metadata
Rank Newbie
Rank
Newbie

I hope someone can help me...

I used the latest dosbox-x version off of github. I am trying to run Tomb Raider 3DFX version. System is Mageia 4.0, video card is a crappy built-in Radeon HD 3000. Monitor is 1920x1080. I am running the ati driver (and in fact cannot even get fglrx to work).

I have two problems:
1) Attempting to run with output=opengl and voodoo=opengl (and fullscreen=false) produces a strange result where non-Voodoo screens are 640x480, but Voodoo screens come up wrong. I get outputs such as
DOSBox LOG: VOODOO: OpenGL: mode set, resolution 640:560
DOSBox LOG: VOODOO: OpenGL: mode set, resolution 640:640
DOSBox LOG: VOODOO: OpenGL: mode set, resolution 640:720
and the window does indeed become those weird sizes, as well as having corrupted output. It is possible this is a flaky driver, but I don't know how to figure out if it is. Trying to do it in full screen just gives me those same weird sizes in the middle of a large black screen.
2) I have no idea how to get a window that is not 640x480. The config file says that windowresolution will only work if the device support s hardware scaling and output=surface does not. However, if I try to use output=opengl, it still won't scale the window. In fact, nothing I can do will prevent the window from being 640x480. Fullscreren will scale the openGL windows but not the regular windows.

Attachments

  • Filename
    dosbox-DOSBox-X.conf
    File size
    60.6 KiB
    Downloads
    9 downloads
    File license
    Fair use/fair dealing exception
  • Filename
    dosbox.log
    File size
    5.41 KiB
    Downloads
    7 downloads
    File license
    Fair use/fair dealing exception

Reply 669 of 2062, by arromdee3

User metadata
Rank Newbie
Rank
Newbie

Aside from speed problems (of course I expect voodoo=software to be slow), voodoo=software does not give me the weird 640x560, 640x640, 640x720 screens. All the screens are 640x480.

Unfortunately, all the screens are now also 640x480 when I go full screen as well. Previously, fullscreen would scale the voodoo-based windows but not the regular windows. Now, fullscreen won't scale any of the windows.

Reply 670 of 2062, by truth_deleted

User metadata

It is very likely a problem between the SDL software library and your (opengl) video subsystem. If you are unable to diagnose the indicated video driver issue and use of SDL applications, then it would be simple to edit a line in the dosbox-x code to enforce the 640x480 mode while voodoo=opengl.

See these functions in voodoo_opengl.cpp: SDL_Surface* SDL_SetVideoMode_Wrap(int width,int height,int bpp,Bit32u flags) -and- void voodoo_ogl_set_window(voodoo_state *v).

Reply 671 of 2062, by leileilol

User metadata
Rank l33t++
Rank
l33t++

TW: the word 'just'

I still don't get why the Glide OpenGL emulation can't just be rendered into a texture buffer to copy over to the normal OpenGL screen buffer as a stretched quad.... you don't really need offscreen rendering for it either. Sure it won't use the scalers, but that's what GLSL shaders are for 😀

Would love to see a 640x480 OpenGL Glide rendering aspect scaled to fill my 1080p desktop.

apsosig.png

Reply 672 of 2062, by SA1988

User metadata
Rank Member
Rank
Member

is it possible to separate the disk swapping of imgmount (CDROMs) from the boot command (floppies)? It isn't so reliable to switch floppies and cdroms at the same time and some programs can have problems with such configuration.

Reply 673 of 2062, by arromdee3

User metadata
Rank Newbie
Rank
Newbie
truth5678 wrote:

It is very likely a problem between the SDL software library and your (opengl) video subsystem. If you are unable to diagnose the indicated video driver issue and use of SDL applications, then it would be simple to edit a line in the dosbox-x code to enforce the 640x480 mode while voodoo=opengl.

See these functions in voodoo_opengl.cpp: SDL_Surface* SDL_SetVideoMode_Wrap(int width,int height,int bpp,Bit32u flags) -and- void voodoo_ogl_set_window(voodoo_state *v).

No, it is not a problem between the SDL software library and my opengl video subsystem. It is a bug in dosbox-x. voodoo_opengl.cpp contains (unless it was edited since I last got the source code) this code:

//EF2000 FIX
glViewport( 0, 0, v->fbi.width, v->fbi.height );
last_width = v->fbi.width;
last_height = v->fbi.height+80;
v->fbi.height = v->fbi.height+80;

If I remove the offending line, I no longer find that the size has increased by 80 each time. Of course, I have no idea what EF2000 problem I would break by removing the line, but it's certainly not an error on my side.

voodoo_opengl_set_window also contains this suspicious code. It doesn't affect me, but I think the "height" should be "width":

if( v->fbi.height < 480 && GFX_IsFullscreen()) adjust_y=(480-v->fbi.height)/2;
if( v->fbi.height < 640 && GFX_IsFullscreen()) adjust_x=(640-v->fbi.width)/2;

And there is no function named SDL_SetVideoMode_Wrap.

Once I make the fix above, I no longer have the problem of weirdly sized and corrupted windows. However, I still do have the problem that any non-voodoo windows are 640x480 in fullscreen, and all windows are 640x480 in windowed mode, no matter what settings I change. Any ideas on that?

Reply 674 of 2062, by truth_deleted

User metadata

That issue and the other one are easily diagnosed by use of a past dosbox build by Ykhwong. It is simple to test with his build to confirm bugs: ykhwong.x-y.net. Also, are the non-voodoo games running in 8-bit color depth? Try to provide further details, including only the "pertinent" dosbox.conf settings, and attach a screen image of the issue (such as the console window which logs warnings and errors). The non-voodoo games are using a different section of SDL window code than the voodoo=opengl games.

Reply 675 of 2062, by arromdee3

User metadata
Rank Newbie
Rank
Newbie

Using a yhkwong build, I cannot get voodoo with glide to work at all. (Even if I copy the conf fiile to the correct name and set my LD_LIBRARY_PATH to include the supplied libraries.)

However, using that build, the problem I had with screens being stuck at 640x480 is gone. The screens properly resize in both windowed mode and fullscreen (until I get to a glide-based screen, which either doesn't work or locks up).

I don't know which dosbox.conf settings are "pertinent".

The only program I was running was Tomb Raider glide version. By non-voodoo screens I meant screens such as the title screen and videos which don't use the voodoo card. These screens are, in the github build, stuck at 640x480.

The screens are running in my normal X session, which is 24 bit depth. The machine is set in the dosbox.conf to svga_s3 with vmemsize=2 which according to the comments is 640x480 at 16M colors. Setting it to 8 has no effect.

I still believe that the code I pointed out above is a bug, considering that removing the line fixed the behavior. I would imagine that, considering that the screens were not stuck at 640x480 in the ykhwong build, that is a bug too, but I don't know how to fix it. What should I do if I want to download a stable version?

Reply 676 of 2062, by truth_deleted

User metadata

Since ykhwong's build doesn't have the issue, and dosbox-x does, then it is reasonable to make a difference file between these two builds. A difference file shows the different lines of code between the two builds, so identical lines are not shown in the output file. The tool is "diff", although there are text editors which do the same.

I would only compare voodoo_opengl.cpp between the two builds (between dosbox-x and the older working version of ykhwong's). This is a good starting point and there are just a few files which would cause the issue. However, I'm not sure whether the color depth is 256 for the "title screen and videos". If you can verify the color depth is higher, then I could suggest a patch as a workaround. There is a patch on this forum so that 16-bit color depth does not prevent stretching in non-voodoo opengl mode, although I have no reason to suspect this patch is relevant yet.

Have you tested a non-voodoo VGA game to confirm stretching works with output=opengl?

These particular builds are for developing code and they are only as stable as tested and debugged by users. It's ideal to debug the problem as much as possible, whether the issue is immediately fixed or that others can then more clearly understand the issue and offer solutions.

Reply 677 of 2062, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie
arromdee3 wrote:
No, it is not a problem between the SDL software library and my opengl video subsystem. It is a bug in dosbox-x. voodoo_opengl […]
Show full quote
truth5678 wrote:

It is very likely a problem between the SDL software library and your (opengl) video subsystem. If you are unable to diagnose the indicated video driver issue and use of SDL applications, then it would be simple to edit a line in the dosbox-x code to enforce the 640x480 mode while voodoo=opengl.

See these functions in voodoo_opengl.cpp: SDL_Surface* SDL_SetVideoMode_Wrap(int width,int height,int bpp,Bit32u flags) -and- void voodoo_ogl_set_window(voodoo_state *v).

No, it is not a problem between the SDL software library and my opengl video subsystem. It is a bug in dosbox-x. voodoo_opengl.cpp contains (unless it was edited since I last got the source code) this code:

//EF2000 FIX
glViewport( 0, 0, v->fbi.width, v->fbi.height );
last_width = v->fbi.width;
last_height = v->fbi.height+80;
v->fbi.height = v->fbi.height+80;

If I remove the offending line, I no longer find that the size has increased by 80 each time. Of course, I have no idea what EF2000 problem I would break by removing the line, but it's certainly not an error on my side.

voodoo_opengl_set_window also contains this suspicious code. It doesn't affect me, but I think the "height" should be "width":

if( v->fbi.height < 480 && GFX_IsFullscreen()) adjust_y=(480-v->fbi.height)/2;
if( v->fbi.height < 640 && GFX_IsFullscreen()) adjust_x=(640-v->fbi.width)/2;

That explains a lot... I was wondering what was causing weird window sizes and rendering errors in my tests:

Filename
thatexplainsalot.jpg
File size
179.47 KiB
Downloads
No downloads
File license
Fair use/fair dealing exception

DOSBox-X project: more emulation better accuracy.
DOSLIB and DOSLIB2: Learn how to tinker and hack hardware and software from DOS.

Reply 678 of 2062, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie
SA1988 wrote:

is it possible to separate the disk swapping of imgmount (CDROMs) from the boot command (floppies)? It isn't so reliable to switch floppies and cdroms at the same time and some programs can have problems with such configuration.

Sure. What keyboard shortcut do you think it should be assigned to?

DOSBox-X project: more emulation better accuracy.
DOSLIB and DOSLIB2: Learn how to tinker and hack hardware and software from DOS.

Reply 679 of 2062, by arromdee3

User metadata
Rank Newbie
Rank
Newbie
truth5678 wrote:

Since ykhwong's build doesn't have the issue, and dosbox-x does, then it is reasonable to make a difference file between these two builds. A difference file shows the different lines of code between the two builds, so identical lines are not shown in the output file. The tool is "diff", although there are text editors which do the same.

It may have occurred to you that since I'm running on Linux and understand such concepts as LD_LIBRARY_PATH, and was already capable of finding a different bug, I probably know what diff is, and explaining it like this is condescending. I was attempting to report a bug, and find out whether it's my setup or an actual bug, not debug an unfamiliar codebase, and I should not be expected to do so in order to report a bug. You could at least check it yourself and tell me whether it happens for you.

Have you tested a non-voodoo VGA game to confirm stretching works with output=opengl?

The problem happens on the command prompt screen before running a game. This screen is stuck at 640x480 in the dosbox-x build and is not affected by windowresolution. In the ykhwong build, this screen is affected properly.