VOGONS

Common searches


Graphics performance boost

Topic actions

  • This topic is locked. You cannot reply or edit posts.

Reply 200 of 227, by Kronuz

User metadata
Rank Member
Rank
Member
Leolo wrote:

When I use opengl or openglnb I can get to full screen easily by pressing ALT+ENTER, and the image fills the entire screen of my monitor.

But when I use openglhq, pressing ALT+ENTER gives me a small image centered in the screen and surrounded by very big black borders.

Is this the expected behaviour?

I'm glad the thing I did fixed the OpenGL issue (it did, right?)
About the OpenGLHQ, I couldn't tell, since in my computer I can't run opengl, even less openglhq; however, I believe that shouldn't make a difference (I think they both should probably work the same; however, who really knows?) ...but hey, you can always use the optimized software HQ2x scaler in my patch achieving astonishing speeds and results 😉

Kronuz
"Time is of the essence"

Reply 201 of 227, by `Moe`

User metadata
Rank Oldbie
Rank
Oldbie
Leolo wrote:

But when I use openglhq, pressing ALT+ENTER gives me a small image centered in the screen and surrounded by very big black borders.

Is this the expected behaviour?

You have not enabled openglhq correctly. DOSBox is doing it's part correctly, but SDL_VIDEODRIVER is probably missing.

Reply 202 of 227, by Kronuz

User metadata
Rank Member
Rank
Member

Okay, I suppose the patch is now working "perfectly" as I haven't heard anything about it from anyone since last week, so I'm ready to label RTM version the RC7, unless someone has found anything that still needs to be fixed 😀

Kronuz
"Time is of the essence"

Reply 203 of 227, by Thraka

User metadata
Rank Member
Rank
Member

I haven't found any issues, I use only your patch now 😀

Thought though.. Does the comparing each line of screen data to see if it has changed, add a bit of extra cpu usage on the host side?

Just thinking that if it does, older machines might suffer if they are already devoting a lot of CPU to the game itself. Perhaps a full toggle is need to use old\new way?

Please make sure the first post (didn't check but I dont remember it being updated) is updated with the latest build so new comers wont have to sift through all the messages trying to find the latest exe of your patch 😀

Reply 204 of 227, by Kronuz

User metadata
Rank Member
Rank
Member
Thraka wrote:

Thought though.. Does the comparing each line of screen data to see if it has changed, add a bit of extra cpu usage on the host side?

Just thinking that if it does, older machines might suffer if they are already devoting a lot of CPU to the game itself. Perhaps a full toggle is need to use old\new way?

Well, I wouldn't say the comparison adds extra CPU usage (though technically it does, and in the very unlikely absolute worse case scenario it could be theoretically noticed), but instead, logically, it mostly moves the CPU usage from one place to other relieving the scalers from its heavy workload, helping to make them do the work that's really only needed. I sincerely don't believe that old computers will suffer at all, but on the contrary those are most likely the ones that would probably notice a bigger improvement. I believe the optimized scalers only have one drawback, and that is the usage of about 2MB of extra memory, which is really not that much anyway.
By the way, on the old/new issue, you can always compile the "original" scalers in DOSBox by defining UNOPTIMIZED_SCALERS during compilation.

Thraka wrote:

Please make sure the first post (didn't check but I dont remember it being updated) is updated with the latest build so new comers wont have to sift through all the messages trying to find the latest exe of your patch 😀

I've never put the exe in the first post... only the diff patches. (this is in part due the limitation of the posts to have no more than 5 attachments)
Perhaps I should only put the latest patch and the latest binary there...

Kronuz
"Time is of the essence"

Reply 205 of 227, by Kronuz

User metadata
Rank Member
Rank
Member

I'm going to be out for the holidays, so I probably won't be able to respond any posts till January. But if you find any bugs, etc. in the patch, please post them anyway, I'll read them when I’m back 😀

...and hey, Merry Christmas and Happy New Year to all of you !!

Kronuz
"Time is of the essence"

Reply 207 of 227, by GreatBarrier86

User metadata
Rank Newbie
Rank
Newbie

http://cvscompile.aep-emu.de/dosbox.htm

IBM ThinkPad X40
1.2Ghz with 2MB L2 cache
1.0GB DDR2 SDRAM
Intel 852/855GME Graphics Media Accelerator with 64MB
12'' LCD Screen
SoundMax Integrated Audio

Peas Pobie!

Reply 208 of 227, by XTale

User metadata
Rank Newbie
Rank
Newbie

i haven't updated the build yet, it's still the state of 12/12/2005
I think i'll update it once before christmas again (not now, I'm atm back in germany without the compile environment that is still in sweden 😉)

http://www.aep-emu.de - AEP Emulation Page
http://cvscompile.aep-emu.de - DosBox CVS builds

Reply 209 of 227, by Leolo

User metadata
Rank Member
Rank
Member
HunterZ wrote:

What happens if you set fullscreen=true to start in full screen?

It makes no difference. The big black borders are still there.

`Moe` wrote:

You have not enabled openglhq correctly. DOSBox is doing it's part correctly, but SDL_VIDEODRIVER is probably missing.

Thanks, I didn't know that. I've set SDL_VIDEODRIVER=openglhq, but Dosbox won't run. This is the error message:
Exit to error: Can't init SDL No available video device

Perhaps the build I'm using doesn't have openglhq support. I'll try with other builds and report back.

Kronuz wrote:

I'm glad the thing I did fixed the OpenGL issue (it did, right?)

Yes! It works very well now. Thanks a million.

Best regards.

Reply 210 of 227, by Leolo

User metadata
Rank Member
Rank
Member

OK. Problem solved. The latest Gulikoza's build (2005-12-14) works perfectly for me.

The black screen problem is gone, and the black borders problem with openglhq doesn't happen any more. Gone is also the dosbox "can't init sdl" error.

Many thanks to you all!

Reply 211 of 227, by whatever

User metadata
Rank Newbie
Rank
Newbie
oduverne wrote:

Your build doesn't work well at all with Micro Machines 2 Tournament.
It's very slow and parts of the screen are missing

oduverne wrote:
I know now what the problem is, if you put [render] aspect=true […]
Show full quote

I know now what the problem is, if you put
[render]
aspect=true

It doesn't work well.
I set it to false and it worked great.

Perhaps it's a bug, I hope that it will help you.

this problem still exists 🙁
mm2 is unplayable with aspect set to true

Reply 212 of 227, by mirekluza

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

I tried the version dosbox_kronuz-20051213.zip with Ravenloft 1 and it is completely unusable in window mode (fullscreen seems to work ok).
After starting there is an empty screen (though the music play). Mashing keyboard/mouse I get further but it seems to have big problems with screen updates... For example sometimes it updates the screen only on places where the mouse cursor was... See the picture from intro... In the game itself the mouse cursor is invisible or it its picture remains on the place where it used to be... In short - the screen update does not work properly...

I used the default settings in DOSBOX.CONF (just started DOSBOX.EXE and generated the new DOSBOX.CONF). I use Ravenloft 1 with DOS/32A extender (but I guess this should not have any influence here)
I have Athlon 1Ghz with 256 MB of memory, WXP SP2, GF2MX with 32 MB of memory, the driver file version is 6.14.10.78.01.

Edit: This seems to be a problem only when output=surface - this is broken, other output modes seem to work ok (though I did not check them extensively)...

Mirek

Attachments

  • rloft1.jpg
    Filename
    rloft1.jpg
    File size
    18.56 KiB
    Views
    1404 views
    File license
    Fair use/fair dealing exception

Reply 215 of 227, by TeaRex

User metadata
Rank Member
Rank
Member

Hello Kronuz,

I'd like to notify you that the big changes in CVS as of 2006-01-30 make it very difficult to apply this great (I'd even say vital) patch. 29 Hunks fail. If you, Kronuz, have the time for it, would you consider updating it another time?

It's too bad it isn't already in CVS.

Thanks a lot for this!!

tearex

Reply 216 of 227, by TeaRex

User metadata
Rank Member
Rank
Member

One more thing, I noticed problems with the 40 character modes (say MODE CO40 or MODE BW40 in DOS) with this patch. The display becomes unresponsive and largely stuck, sometimes it changes a little bit when scrolling. Though I also added the SVGA chipset patch, maybe that one might be the culprit as well. Can anybody test if 40-char modes work for him with the scaler patch?

EDIT: I should add that I run under SUSE 10.0, with Matrox G400 card. I'm using "surface" output, as it's the only one that works (overlay crashes, opengl(nb) reverts back to surface). The problem happens with all cores, and no matter whether in fullscreen or windowed. Only the display goes down the drain, you can still type commands blindly, for example "MODE CO80", after that it will work again.

Last edited by TeaRex on 2006-01-30, 15:54. Edited 1 time in total.

tearex

Reply 218 of 227, by TeaRex

User metadata
Rank Member
Rank
Member
rcblanke wrote:

Tearex, Qbix said here Post 75938 that one of the CVS changes as per jan. 30th, is because of functionality like the one Kronuz has implemented, so Kronuz' patch shouldn't be necessary anymore.

Ok, great, I can't view the above posting (for some readon "Topic does not exist" comes up), but after some testing it seems that it's very true - performance is very comparable to the Kronuz patch now.

Good job, guys!! Thanks!

Wouldn't this be a good time for 0.64? After some testing, I mean. IMHO this is the biggest improvment in CVS in a long time.

tearex