It seems that you're using an outdated browser. Some things may not work as they should (or don't work at all).
We suggest you upgrade newer and better browser like: Chrome, Firefox, Internet Explorer or Opera

×
Since several people here (including myself) have stability problems with the dgVoodoo wrapper, I looked a bit further into the syntax of the glide_wrapper.zbag.ini.

Luckily, there are a few settings which can ramp up quality by quite a bit by letting the wrapper use more fancy shaders, anisotropic filtering. Note that it will not run in the full 1600x1200 resolution like dgVoodoo, but it will look way better than the default config.

Give this a try:

[*]
tmu_megs=16
vsync=3
mipmaps=2
lod_bias=0.00
fix_lod_bias=0
aniso=16
refresh=60
res_limit_x=1600
res_limit_y=1200
render_to_client_window=0
fix_gamma=1
default_gamma=1.30
feature_limit=2
high_res=1
thread_policy=0
allow_sse=1

Depending on the settings in your graphics card's control panel, you might get small borders due to the scaling factor (or the lack of it). The game natively runs at 640x480, the high res flag of the config file doubles that, bringing it to 1280x960. Since my screen cannot display this resolution, the graphics card adds little borders to pad it up to 1280x1024.

DON'T use the -800x600 flag on iwar.exe or it will run in this resolution instead of 1280x960. Just call iwar.exe with -b -16 and it should work fine.

I had my machine consequently crash in the Nav Advanced tutorial at the end when I attempt to dock with the station when using dgVoodoo. This is a thing of the past now without sacrificing too much of the good looks. Tested on an i7 920 with an Ati 5870 running Win7 x64.
Post edited October 01, 2010 by mhe
Dude, you rock! Those settings worked wonders for me. After seeing how dgVoodoo was ultimately unstable, I had resigned myself to using the less attractive default wrapper. Wow, thanks for the research.
My only observation was that the nebulae looked a bit weird, but I'd rather have nice looking ships than nebulae.
Care to explain some of the setting switches? What excatly do the values of vsync correspond to? (I noticed it is on 3, and I know vsync On is =1.) Mipmaps=2 seems to give me some wierd issues. And what is feature_limit=2 and fix_gamma do?
Post edited July 16, 2010 by sfried
Because of the filename of glide_wrapper.zbag.ini, I found out GoG actually uses the so-called Zeckensack Glide wrapper. Zeckensack is a member of the german 3center forums and the writer of this wrapper. "Sack" in german means "bag" in english, so the filename gave it away.
To get to this config file, I installed his full wrapper package, which comes with a configurator frontend and I started tweaking. The ini-file also can hold game-specific override settings, which is quite handy if you have more than one game using the wrapper. I-War in conjunction with Interstate 76 would be such a case for example.
The full documentation of every parameter (for the configurator)supported in the ini-file can be found here.
Buatha:
Thanks man :) The nebulae look good at my setup, at least as good as I remember them from back in the days when the game came out originally. Could you post a screenshot of the weird nebulae? Perhaps we can work out what causes it. Perhaps you just experience color banding, which the dgVoodoo wrapper fixes by enforcing 32-bit color depth. The Zeckensack wrapper unfortunately doesn't support that.
sfried:
Vsync=3 forces vsync whilst 1 just leaves the control of vsync to the game itself.
Mipmaps=2 forces the generation of mipmaps even if the games doesn't do so by itself. Mipmaps=1 would mean to force just trilinear filtering, but this wouldn't work on a game which doesn't have mipmaps to start with. I haven't tested it so far, as it looks good on my machine, perhaps 1 would better suit your setup.
feature_limit=2 sets, to which shader model the wrapper is allowed to translate to simply speaking. It corresponds to the "most fancy shaders" setting of the configurator frontend and should be usable on any graphics card sporting a PCI-E interface.
Look at the readme I linked, it's all there, it only lacks the description of which numeric value corresponds to which configurator frontend setting. But that is not a problem since the configurator works like a charm. The whole installer package can be found here.
avatar
mhe: sfried:
Vsync=3 forces vsync whilst 1 just leaves the control of vsync to the game itself.
Mipmaps=2 forces the generation of mipmaps even if the games doesn't do so by itself. Mipmaps=1 would mean to force just trilinear filtering, but this wouldn't work on a game which doesn't have mipmaps to start with. I haven't tested it so far, as it looks good on my machine, perhaps 1 would better suit your setup.
feature_limit=2 sets, to which shader model the wrapper is allowed to translate to simply speaking. It corresponds to the "most fancy shaders" setting of the configurator frontend and should be usable on any graphics card sporting a PCI-E interface.
Look at the readme I linked, it's all there, it only lacks the description of which numeric value corresponds to which configurator frontend setting. But that is not a problem since the configurator works like a charm. The whole installer package can be found here.
Thanks for the link, but the site doe not make mention of any ini flags and their corresponding values, only the features to turn on/off when running Zeckensack.
I'm also confused as to why aniso is set to 16. Is that bit size? Also I read something about actually setting the resolution (which is different from resolution limit or the res_limit_x/y values). Whats the flag suppose to be?
Post edited July 16, 2010 by sfried
avatar
mhe: sfried:
Vsync=3 forces vsync whilst 1 just leaves the control of vsync to the game itself.
Mipmaps=2 forces the generation of mipmaps even if the games doesn't do so by itself. Mipmaps=1 would mean to force just trilinear filtering, but this wouldn't work on a game which doesn't have mipmaps to start with. I haven't tested it so far, as it looks good on my machine, perhaps 1 would better suit your setup.
feature_limit=2 sets, to which shader model the wrapper is allowed to translate to simply speaking. It corresponds to the "most fancy shaders" setting of the configurator frontend and should be usable on any graphics card sporting a PCI-E interface.
Look at the readme I linked, it's all there, it only lacks the description of which numeric value corresponds to which configurator frontend setting. But that is not a problem since the configurator works like a charm. The whole installer package can be found here.
avatar
sfried: Thanks for the link, but the site doe not make mention of any ini flags and their corresponding values, only the features to turn on/off when running Zeckensack.
I'm also confused as to why aniso is set to 16. Is that bit size?

Sorry, let me clarify - the readme states, which setting of the configurator does what with the graphics. The configurator is nothing but a fancy frontend for writing the ini-file. It is way easier than hand-editing, because you don't need to remember which numerical value stands for which setting. But I could also write a complete list, which value of which parameter does what. Would take a bit of time, but nothing that could not be done.
Aniso controls the setting for anisotropic filtering, which has nothing to do with bit size or colour depth (I think you meant the latter).16 simply means Aniso 16x. A very detailed explanation for that graphics feature is offered by Wikipedia.
avatar
mhe: Sorry, let me clarify - the readme states, which setting of the configurator does what with the graphics. The configurator is nothing but a fancy frontend for writing the ini-file. It is way easier than hand-editing, because you don't need to remember which numerical value stands for which setting. But I could also write a complete list, which value of which parameter does what. Would take a bit of time, but nothing that could not be done.
Sure, I'll wait for the list. It's better than having to install the wrapper just for the sake of figuring out myself.
Ok, here we go...
high_res - controls the upscaling feature.
0 -> disable
1 -> enable, doubles the original game resolution. 640x480 becomes 1280x960 etc. Be careful about what you set as resolution limit, because this could possibly prevent the upscaling from working properly.
tmu_megs - How much memory you virtual Voodoo graphics board shall have in megabytes.
2 -> 2 MB
4 -> 4 MB
8 -> 8 MB
16 -> 16 MB
vsync - controls the vsync behaviour
0 -> vsync always off, regardless of application preference
1 -> Vsync set by application
2 -> So called "pedantic mode". Compatibilty setting for games that use refresh as their timer. Use only when having problems with vsync.
3 -> Vsync always on, regardless of application preference
4 -> frame limiter mode. Vsync disabled, but framerate limited to 180fps.
mipmaps - controls how the wrapper handles mipmapping
0 -> Set by application (i.e. what an actual voodoo card would do)
1 -> Use trilinear filtering. Only useful if a game has mipmaps. Blends mipmap transitions.
2 -> Generate mipmaps. For games without mipmaps. Uses trilinear filter too.
lod_bias - a numeric value which controls which mipmap is used for which viewing distance. A very game-dependent setting. Positive values will make textures look more blurry but conserve video memory, negative values will make the textures look sharper but increase video memory usage. If you use fix_lod_bias=1, then this value will be used regardless of application preference. If you don't fix it, the value of lod_bias will be added to the application preference. If for example a game sets bias to 1 and you set -1, the result will be 0.
fix_lod_bias - fixes the lod (level of depth) bias.
0 -> not fixed
1 -> fixed
aniso - the level of anisotropic filtering applied to the textures. Higher values will look better.
0 -> disable
2 -> 2x filtering
4 -> 4x filtering
8 -> 8x filtering
16 -> 16x filtering
refresh - controls the refresh rate.
0 -> Always sets your in-game refresh rate to the desktop refresh rate.
1 -> Refresh rate set by application.
60 -> Refresh set to 60Hz
70 -> Refresh set to 70Hz
72 -> Refresh set to 72Hz
75 -> Refresh set to 75Hz
85 -> Refresh set to 85Hz
90 -> Refresh set to 90Hz
100 -> Refresh set to 100Hz
120 -> Refresh set to 120Hz
res_limit_x, res_limit_y - a relic from the ancient times of CRT monitors without sanity checks on their input. Some CRT screens would simply self destruct if fed with a video signal exceeding their display capabilites. This setting ensures, that even when using high_res=1, the resolution never goes above this limits, thereby protecting your screen. Also, this can only be placed in the global section of the ini-file (see bottom of this post).
render_to_client_window - from the readme: Never, never, never touch this option unless you really need to. You'll know that you need to, if your game is missing textures and is flickering badly all the time.
0 -> disabled
1 -> enabled
fix_gamma - locks the value set by default_gamma and/or prevents a game from changing it while running.
0 -> not locked
1 -> locked
default_gamma - gamma is something like a brightness value. High values equal brighter screen. 1.3 was the default value of the last voodoo drivers.
feature_limit - controls, how many shader features of the actual graphics card the wrapper is allowed to use.
-1 -> disables Glide support completely. Useful for games where you want to use another graphics API but the game itself would pick Glide if available. Obviously to be avoided as a global default setting.
0 -> Basic stuff only. To be used for very old and feature limited graphics cards. Think Geforce 4 MX and below.
1 -> Uses simple shaders. Also a legacy setting. Think Geforce 3 or 4(non-MX).
2 -> Best quality setting. Should work on everything. Geforce 6 and above, Radeon 9500/X300 or higher.
allow_sse - controls usage of the SSE CPU extensions.
0 -> disabled
1 -> enabled
thread_policy - Controls threading of the wrapper (uses excerpts from readme).
0 -> "Classic" doesn't care about threads. This is the default setting.
1 -> "Use system thread" uses a dedicated thread to perform dealings with the operating system.
2 -> "Use render thread" that will basically shield the OpenGL driver from multithreaded rendering code.
3 -> "Crazy" combines the above two. It will run both a dedicated system thread and a dedicated rendering thread.
4-> "One thread for both" runs one extra thread that deals with the OS and with OpenGL.
Game-specific config file syntax - It is possible to set global defaults and override them on a per-game basis. You just need to know the name of the games executable file. If in doubt, use the task manager, since GoG sometimes uses launchers for their games.
A config section is terminated by at least one empty line.
[*]
<all global parameters go here>
[game.exe]
<game-specific settings overriding global defaults go here>
Thanks for the list mhe! This should help others get the wrapper to run optimally on their systems too.
Edit: For the Game-specific config file syntax, does that mean I could just put the -b -16 arguments in the ini file and it will run just as if I have put these in the icon shortcut?
Like:
[Iwar.exe]
-b -16
Post edited July 16, 2010 by sfried
No problem :)
The wrappers config file syntax has nothing to do with the arguments passed to the iwar.exe via the shortcut. You don't need to specify them, I think it might even break the config a bit if you do. The -b -16 MUST be in the shortcut to enable the game's Glide mode (and thereby starting to use the wrapper) in the first place.
Iwar itself is not aware that it is run via a wrapper, since the game engine only calls functions of the glide2x.dll (which does abstract the Glide calls to OpenGL behind Iwar.exe's back). So if the game would start in software renderer mode, it would never call the glide2x.dll file, the wrapper wouldn't start and couldn't possibly pass these parameters specified in the ini-file to iwar.exe since the wrapper simply doesn't run in that case. So game executable parameters ALWAYS have to be passed to the exe via shortcuts and the ini-file specifies how the wrapper handles glide2x.dll-calls of the game
Thank you for all that, mhe!
You're welcome, we aim to please. :)
Post edited July 18, 2010 by mhe
Thank you very much mhe, I'd almost given up hope trying to get I-War running on my laptop, tried dgVoodoo and nGlide with no success but this worked a treat!
Another thanks here, this solution works perfectly for me. IWar looks fantastic now.

I'm tempted to start a new question thread simply linking to this post, because it's useful enough to deserve an entry in the troubleshooting section of the site.
I'm trying to get this working but it seems that iwar_start.exe doesn't read the command line arguments and if I try to run IWar.exe it just crashes after the intro movies.

Guess I'm stuck with 640x480.