VOGONS


First post, by romek41

User metadata
Rank Newbie
Rank
Newbie

Hello there!

When running DOSBox in fullscreen mode, I can often notice black borders on the screen - i. e. when using resolution 640x400 in emulated PC and 640x480 in my real computer, DOSBox displays 40 black lines over and 40 black lines under the picture, instead of stretching the picture to full screen. I have decided to correct this, using OpenGL for display. The result of my work (modified sdlmain.cpp from DOSBox 0.60 - if you want to compile DOSBox with it, then you must also link executable with OpenGL, '-lGL' on Linux) is in the attachment. But there are some problems with this code:

1. It does not work with threaded video display (segfaults - I do not know why).

2. It displays a white, one pixel wide border around the display when switched to fullscreen.

Does anyone know how to fix them? I am newbie on OpenGL, so I would be very grateful for help...

Also note, that:

1. In actual stage it shows fullscreen display at 1024x768 resolution (I'm going to change this behaviour in the near future).

2. It will be really slow if you run it under plain Mesa, or Micro$oft software OpenGL. To achieve reasonable performance you will need 3D accelerator with hardware OpenGL support.

3. It won't work at all, if your OpenGL cannot use large textures.

That's it for now. I hope I will find enough time to complete this code...

Attachments

  • Filename
    sdlmain.cpp.bz2
    File size
    6.61 KiB
    Downloads
    216 downloads
    File license
    Fair use/fair dealing exception

Reply 2 of 12, by Harekiet

User metadata
Rank DOSBox Author
Rank
DOSBox Author

Oh well already working on opengl support, and with that a little change in vga update code, since i'll remove the multithreaded display updates, sorry for multicpu users 😜
Texture upload speeds in opengl are quite horrible though, using an nvidia extension helps it alot, but for non-nvidia people they'd better use the overlay support i think.

Reply 8 of 12, by oneirotekt

User metadata
Rank Member
Rank
Member

Oh well already working on opengl support, and with that a little change in vga update code, since i'll remove the multithreaded display updates, sorry for multicpu users

Curious, has anyone run current versions of DOSBox much on a multi CPU system? How much does performance improve? Can you get twice the cycles out of it compared to a comparable single CPU system, or is it somewhat less than 2x?

Reply 9 of 12, by Qbix

User metadata
Rank DOSBox Author
Rank
DOSBox Author

far less:)
Graphics is one thread. CPU emulation is the other.
See a bit like running with frameskip=10 😀

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

Reply 10 of 12, by quasarstrider

User metadata
Rank Newbie
Rank
Newbie

Texture upload speeds in opengl are quite horrible though, using an nvidia extension helps it alot, but for non-nvidia people they'd better use the overlay support i think.

How about using ARB_pbuffer and ARB_render_texture, at least on the cards which support the extensions?

Reply 11 of 12, by Harekiet

User metadata
Rank DOSBox Author
Rank
DOSBox Author

ARB_pbuffer and ARB_render_texture don't help with texture upload speeds which is the main opengl bottleneck, the nvidia extensions allows you to do agp dma transfers, but as far as i know they are discussing and ARB_* version of it too, so we'll have to see if that ever gets added. They already added the nvidia vertex_buffer so who knows 😀

Reply 12 of 12, by Srecko

User metadata
Rank Member
Rank
Member

OpenGL is really slow on my radeon, but overlay is quite fast and works without problems (only picture is a little blurry), including scaling.
I guess agp 8x interface improves performance here (unlike 3d games which rely on graphic card's internal memory speed which is a lot better than AGP's).
There probably shoudn't be much difference between overlay and opengl in speed.