I got the config file.

what settings do I need to get it to work in full screen mode. ?

I have used the folowing for windows mode and it looks great:
output=openglhq
hwscale=2.00

scaler=none

the rest are default.

:edit: every time i run xcom 1.4 my shstem reboots. 😖

:edit 2: updated my nvidia driver and now instead of a BSOD, dosbox closes with no error. I have a 6800 Ultra so I dont think it's a lack of hardware feature support. xcom 1.4 runs fine with output=surface just doesnt seem to like openglhq

For me openglmode doesnt work anymore with gulikoza's last cvsbuild.

To be exactly first it was running at fullspeed, than i run Blood and it crashed (nearly my hole system) and when I started dosbox the next time it was running very slow.
With all other mode like ddraw i dont have any trouble! 😜

It didn't go into some kind of safe mode did it?

Blade (and all others who'd like to try it), unless you know how to work with gdb, you will have to wait. This patch is very new, and I published it so people with some debugging experience can have a go at it. If it works, enjoy, but reports of crashes are only helpful if they are accompanied with some debugging info like priestlyboy does.

kekko, thanks. I'd be grateful if you tell me if it works in the next build (later today).

priestly, great job again. While it's not the fix I'd like to see, I hope the next build won't crash anymore. It seems the NV_pixel_data_range extension is less than well-understood by me, so I disabled it for the time being.

Build is uploaded and patch attached. Should it finally work without crashes, I will then try to see if I can find a better fix.

tested my patch with yesterday's cvs and works perfectly

kekko's patch isn't needed anymore. kekko and I resolved both issues.

Alright, it's working properly now 'Moe' 😀. Not a crash in sight. Window to Fullscreen A-OK!. I also tested with Opengl(nb) that VESA 16bit works (and 8-bit too).

My testing program was Star Trek: Final Unity which has the choice to use 8-bit, 15-bit, and 16-bit color modes using uniVESA (I assume this is uniVBE 2.0) and it works 😀. 15-bit is not implemented and the setup program noticed that 😀. 8-bit and 16-bit modes with VESA on works under OpenGL(nb). Openlgnb is now my favorite renderer instead of overlay. It is the most crisp for me now than overlay and opengl seems less crisp than overlay.

Finally it works 😀. I have no hardware to test openglhq so I'll have to leave that to you folks. Thanks MOE! I give this my stamp of approval 😅.

So I guess you can do that patch separation now I find no obvious fault now with the full patch. Also what is exact in yer FULL patch? HQ2X, OpenGL improvements and openglhq, VESA 16bit, Adlib warning and table fixing, ADDKey patch. I think that's all I know. Is there any more? Maybe you could write up a description on what this "particular" patch adds.

Oh yeah I forgot about the Speed Meter patch. I don't quite understand the use of that part.

Greets
~Priestlyboy~

EDIT: I think I need to break the Smilie barrier 😦 😮 😲 😕 😵 (hehe)

EDIT #2:
Forgot to mention. I'm not sure what this is about but here you go.

1render_templates_hq2x_tables.h:132: warning: alignment of 'Hq2x_factors' is greater than maximum object file alignment.  Using 16
2render_templates_hq2x_tables.h:31: warning: alignment of 'Hq2x_difftable' is greater than maximum object file alignment.  Using 16

The problem is that without NV_pixel_data_range opengl is still slower than other modes 🙁. It's certainly better than plain cvs but Tomb Raider for example will run at 60% cycles in opengl modes (sure, openglhq is even slower but that's to be expected). I'm still waiting for ati to implement pixel buffer object in their drivers 😁
How did you manage to get a final unity running? My setup program will hang if I select anything higher than 256 modes 😕

edit: `Moe`...I believe nvidia already supports PBOs. Perhaps you could try using that instead of pixel_data_range. And it even might work on future ati drivers 😁

Priestly, the "all-in-one" patch contains all my submissions to sourceforge, you can find them there. I think you got them all. The speed meter is meant as an aid to tune DosBox cycles manually to the maximum. I order to get good readings and to have virtually no performance impact, it outputs every 16 seconds (measured in emulated time) how much real time and dosbox time differ. 100% means that the cycles value is low enough for dosbox to keep up. It will never go above 100%. Values as low as 92% are usually OK, too, below that sound starts to drop out.I made it since all the available autocycle-patches had real bad performance for me, or interfered with some games doing their own timing (first encounters was especially horrible).

As for PBO/NV_pdr, I will try to check why it sometimes works and sometimes fails, but until then, I'll upload the patch to SF as it is now. Thanks for all of your help, I'll get back to you for testing as soon as I had an nvidia box in my fingers.

EDIT: These warnings are harmless. Win32 object files don't support cache-friendly 32-byte alignments and will align these tables at 16-byte boundaries instead, which is still OK. It's just "be nice to the cache" 😀

16-bit colour is great!

Abe's Oddysee works fluently (both: movies and game itself) with dynamic core (640x480x16bit). So it is a myth that 16-bit colour in dosbox will be too slow.

Abe's Oddysee works fluently (both: movies and game itself) with dynamic core (640x480x16bit). So it is a myth that 16-bit colour in dosbox will be too slow.

I didn't realize there was a DOS version of that game. I have the Windows version only? i think. Man, I'd like to see how it works in DOS 🙄

EDIT: 😅 Haha, I NEVER noticed the DOS directory when I looked at this CD. I'm soo blind. I've played and beaten this game HOW MANY TIMES? and I never saw THAT. 🤣. Thanks for the knock on the head, robertmo.

Greets

EDIT #2: Hmm, I can't seem to get the movies to run very smoothly (from the original cd.) It feels slow kinda choppy but the sound is correct. In-Game is quite excellent though. Especially when you quit, it takes a few extra seconds for it to run that fullscreen part for some reason. *not CPU overload as far as I can tell*

I just downloaded Moe's latest build from his site (http://garni.ch/Software/dosbox/) along with his DLL zip. At first it kept crashing, but I remembered something about it not supporting triple buffering. I have forced OpenGL triple buffering enabled in my video drivers, so turning that off got it working.

Is there a way to make it act more graceful if forced triple buffering is enabled?

Update: I tested it out with TES: Arena. I noticed that I could only get the cycles half as high with the dynamic core before the sound got choppy, but that the graphics would continue to get smoother as I raised the cycles. Odd.

Update 2: Okay, I'm stupid. I can only get the cycles to 8000 before maxing out my CPU, which is a bummer since I can go up to 50000 under stock CVS DOSBox with dynamic core and ddraw or overlay output and still have almost no audio burping (just once every 20-30 seconds). Arena needs at least 20000 or so to run smoothly at low detail.

@priestlyboy: OT but since you're all reading this thread...I finally managed to grab a ti4200 from a friend of mine and fixed that corruption bug you had with D3D. I will have an updated patch&build sometime later today 😁 😁

HunterZ, I know of no way how to detect/disable triple buffering. Feel free to help me there, any docs are appreciated (including hints on why that happens), but googling didn't help, ATI's website is less than unhelpful, so I'm lost there. If anyone has ideas, you'd do me a great favour.

Moreover, what surface, scaling and frameskip settings did you use? Are you using ATI hardware? Is vsync-swap enabled?

There are some possibilities for worse performance, but I think we can get them right with a little patience.

I'm using a Radeon 9800 Pro 256MB AGP, yes. I'm not sure what you mean by surface and vsync-swap settings (I do have forced vsync enabled in my drivers if that's what you're asking) - for output I was using openglhq (obviously). Scaling I kept at 1.0 and frameskip at 0 (no point in artifically making it choppy to keep it from being choppy in my opinion).

For the crashing: Is it possible that you're (or DOSBox) not checking the return value of some SDL call? I'd be surprised if something like simply setting the video mode would cause it to crash like that.

Openglhq is slower that plain opengl, even though most of the work is done in hardware. I found it to be comparable to software-hq2x, but with arbitrary scaling factors. x4 scaling (4 times as much pixels as x2) at the cost of x2. Another reason could be that on windows, ATI gives me 16-bit-per-channel, which means double the memory bandwidth compared to 8 bit per channel (which is sufficient for openglhq). SDL/OpenGL allows to set a minimum size, but I don't know how to get the smallest possible value above that minimum.

Also, I have done little profiling up to now, as I have been struggling to get it truly cross-platform. This will probably change.

By the way, frameskip 0 is not the best setting, IMHO. We're talking about 70Hz here, and frameskip 1 means 35fps, which is still more than any DOS game can possibly reach, even less so in dosbox.

Not for me. I can get at least 2.5 to 3 times the performance using any of the software scalers. Even with a frameskip of 1, I'm sure I would still only get single-digit framerates in TES:Arena when running my CPU at ~90% load.

priestlyboy wrote:

EDIT #2: Hmm, I can't seem to get the movies to run very smoothly (from the original cd.) It feels slow kinda choppy but the sound is correct. In-Game is quite excellent though. Especially when you quit, it takes a few extra seconds for it to run that fullscreen part for some reason. *not CPU overload as far as I can tell*

Movies require more cycles than game so set cycles to 200000 and use timesynched=true
Also read "Dosbox guides" -> "how to speed up dosbox" -> (fullscreen, no scalers - opengl is a scaler!)
I also use DOS/32A v7.33

The moveis are prefectly fluent. I cannot imagine them more fluent. Game itself is perfectly fluent too. I have the cheapest processor sold - the slowest Sempron 2200+ (1500MHz).

Hmm, I'll have to play with that timesynched setting.