ScummVM has announced that Ultima VIII is now completeable under the daily development build of ScummVM. The compatibility is based on the open source engine Pentagram. This gives us another way to play the classic game on PC (or Android, or Ouya, or Dingux or any other platform ScummVM supports!)
Ultima VIII has been playable on modern PCs for quite some time using DOSBox, which is prepackaged in the GOG.com and Origin versions of the game.
One of the previous entries Ultima IV became compatible with ScummVM when xu4 became a subengine of ScummVM in April 11, 2020. Similarly Ultima VI gained compatibility with ScummVM when Nuvie became a subengine of ScummVM on April 12, 2020, however:
It would be interesting to see what players think of the new ScummVM compatibiltiy and whether it offers significant advantages compared to the widely used DOSBox versions, please comment if you've tried them both!
These are the decrypt tool Gibbed.SpecOpsTheLine.IniDecrypt.exe and encrypt tool Gibbed.SpecOpsTheLine.IniEncrypt.exe created by Rick/Gibbed (Twitter, GitHub) back in 2012 and first made public in this XeNTaX forum thread and retrieved as archived by Wayback Machine in December of 2015.
Kudos to LowSpecGamer whom documented the Wayback Machine archive link on his video about the game.
Download the decrypter. Unzip it in a handy folder. Such as %USERPROFILE%\Documents\My Games\SpecOps-TheLine\SRGame\Config\ Open the file you need to edit with Gibbed.SpecOpsTheLine.IniDecrypt.exe (drag-and-drop). Make the changes you want in the now unencrypted file. Save the file. Open the modified file with Gibbed.SpecOpsTheLine.IniEncrypt.exe, thus re-encrypting it.
Harmful misconceptions in Launch Options and Console commands/arguments for Source Engine based gamesBy capofantasma97
I've noticed that in a few articles there are bad commands/arguments for Launch Options and Console commands. These have been copypasted all over the internet since the dawn of Source engine tinkering, with many people improvising experts without any knowledge whatsoever.
Here's a list of commands that should NEVER be used and even removed if present in articles. As the all-knowing wiki for PC gaming, this place should be error free, especially considering the main reason people come here is because of the will to tinker with this kind of stuff.
-high it is not merely a matter of not being compatible with some stuff like the Origin updater, but detrimental to the overall performance. It is usually pasted because people think that setting an higher priority for the game, it will run better. In truth, High is a priority mode in Windows that is useful only for short, critical events, and processes that are not short and critical like games will cause an unbalance in resource usage with a decrease in performance. In addition, there's no visible benefit in running it, any anecdotal improvement is placebo.
-threads the Source engine automatically detects the amount of threads it has to run, and automatically caps the threads accordingly in case it would be detrimental for performance. Furthermore, a Valve developer once replied on Reddit saying such launch option should be removed.
- dxlevel is often wrongly used and recommended. For the best quality and optimal performance it shouldn't be used, and anyway if one wants to enforce it, the compatible and recommended values are 60, 70, 80, 81, 90, 91, 95 and 100 (some games do not support all of these). 98 should never be used as it is a value for Xbox 360 only, as also explained in the official documentation.
-preload / sv_forcepreload / cl_forcepreload should NEVER BE USED. Mocked by a Valve developer as "cl_massive_hitches_at_surprising_times 1", it commonly causes stuttering and lag spikes, and has been removed in many games.
-heapsize does not exist in Source since 2009. Heapsize related commands are not to be used as not only they should be disabled basically in every Source game, but if it happens to work somewhere, it may cause long Garbage Collection pauses in the software, with clear problematic performance issues and glitches.
Launch options and commands that affect window/fullscreen modes and resolutions like -noborder -fullscreen -w -h -full -sw are to be avoided if possible because they may cause "confusion" in the engine and create performance issues. Plus it will conflict with any changes applied in the game settings. For this kind of settings, video options in the game's settings should be the only way to interact with them. Almost all games have a selectable borderless windowed mode.
-nocrashdialog removes some windows crash messages. It has no effect on performance and makes crashes harder to troubleshoot.
There's also a series of bad network related values and commands. These should not be touched if you are not an expert. Only modern and updated config bundles like mastercomfig for Team Fortress 2 should be used to automatically apply these settings with the right values, if the game is well known to support them. For these and more settings, refer to Mastercomfig's well-researched documentation.
rate 60000 is a bad value. The default in many Source games is 80000, so applying it will lower the rate which obviously cripples network performance even for bad connections.
cl_interp 0.0152 causes bad interp with server, cl_interp 0.033 is a typo of the commonly used cl_interp 0.0303
cl_updaterate 60 and cl_cmdrate 60 are typos of cl_updaterate 66 and cl_cmdrate 66 which are the default values for most Source games as the usual tickrate for servers is 66. Some games like Apex Legends have a tickrate of 20, and these values are useless to try to enforce. Maximum tickrate is dictated by the server and doesn't give a damn of what you set.
Since I'm here, I may as well give some helpful launch options:
-novid disables the game developer/publisher startup logos/animations. It doesn't always work (like in Apex Legends).
-nojoy and -nosteamcontroller disable the joystick system and Steam controller system respectively. If the player is certain that they will not use joysticks/controllers of any kind, these launch options are useful to reduce memory usage and improve startup times as there's 2 less modules for the game to load, as well as potentially preventing input conflicts if a controller is connected.
-freq x , -refresh x and -refreshrate x are all the same thing but with alternative syntax names and only one should be used if need be. They enforce the refresh rate put in place of "x", which is useful for alternative refresh rates like 120, 144 and 240Hz, as the Source engine may not correctly detect the refresh rate of the monitor. Example: -freq 144
fps_max x is a command to input in a config file but could be used as launch option as +fps_max x. It sets the maximum framerate. It can be used to prevent excessive spikes which could result in inconsistent input lag or to give more resource space to other programs in the background. Generally is recommended to not set it or set it as +fps_max 0 in order to have uncapped framerate and benefit from the lowest input lag possible, or alternatively to set it a bit above your monitor's refresh rate, like +fps_max 160 for 144Hz, in order to not waste resources and value stability more.
m_rawinput 1 useful command if raw input can't be found or is difficult to find in the game's settings. It enables mouse raw input, meaning that the game picks the mouse sensitivity directly from the sensor of the mouse itself instead of passing through Windows's sensitivity settings, meaning that it will always give a true 1:1 consistent sensitivity and lower input lag.
Please add in Source games a section explaining both good and bad launch options and updating the wrong ones.
Who's Online 2 Members, 0 Anonymous, 184 Guests (See full list)
Recently Browsing 0 members
No registered users viewing this page.