Veyrdite

More generally are you thinking about singleplayer or multiplayer? Melee or ranged FPS? (Singleplayer) The original Red Faction levels toyed with the idea of linear progression. There would be branches in the pathway that then lead to dead ends a bit later, but you wouldn't realise this. Instead you would get caught in a loop (like a circle drawn at the end of a terminating line), convinced that you must be missing some doorway off the to the side somewhere. After checking a walkthrough you would find you need to backtrack quite a way and eg jump into a ventilation fan to get back on a path that isn't a dead end. (Multiplayer) Tremulous/Unvaquished had some interesting level design problems because of it asymmetric teams (aliens: mostly melee, humans: ranged). Big open spaces vs tight corridors favoured one over the other, and it got a lot more complex with the first-person base building mechanics (which interacted in weird an interesting ways with level geometry, esp to form traps with turrets). (Multiplayer) Most modern online first-person shooters give heavy advantage to a person walking around a corner or doorway, due to the inherent problems of ping and player prediction. Interestingly some gameplay mechanics (eg accuracy of weapons depending on movement speed) can help counteract this. This is what makes corners in games like Counterstrike so "random" feeling, there is a big advantage given to both the walker and the camper watching the corner, so the outcome is very unstable. Specific level of interest in Tremulous (asymmetric aliens vs humans): ATCS. The small base area with its complex mini-walls and two levels allowed for interesting base building layouts. You could hide the giant, main central reactor somewhere clever in there but a jumping alien would then be able to get on top and damage it whilst hiding from your turrets. Big, heavy aliens would have to rush through defences on the floor but nimbler ones could crawl the walls or jump up to the second floor, interacting with defences in interesting ways. The centre room of the map (a big outside building with a ramp to the roof and walkway around both sides) allowed some verticality, but only when the humans and aliens evolved their jetpacks and jumping forms later on. Entirely new gameplay strats would appear as things progressed, eg to trap or ambush humans from above. The second path of the map was a kinked tunnel between the bases. It was a very different kind of combat, not as much fun but it served its purpose as something to prevent one strategy dominating the map. Specific level of interest

Ross: I've put a big reply up on my site, with some detailed thoughts on technical direction, unexpected outcomes and ethical issues relating to 3D gameplay capture and 3D world reconstruction: https://halestrom.net/darksleep/blog/044_3dto3d/ Apologies to everyone who has been commenting here, I have not read through things yet. I spent quite a bit longer on this reply than I anticipated. I'll get there. I only found out about Ross' video a few days ago; Ross' RSS feed is being blocked by his site's Cloudflare setup, so my (and everyone elses'?) feed reader can't access it.

This is exactly what I just came here to report. I completely missed this months' video (a week weeks ago now ).It turns out my feed reader was hiding failed feed fetches (my fault, I wrote the reader myself). I can't fix this problem because cloudfare wants javascript and captchas to even view that feed. I don't think _any_ feedreaders will be getting through the current setup, making the RSS feed effectively useless for the time being.

Awesome episode Ross, enjoyed it thoroughly. I have a love-hate relationship with games that punish you with harder sections if you don't find the secret ways of making them easier. It gives you a legitimate feeling challenge that your friends will also get stuck on, but it's also easily spoiled by one person sharing the secret (or a walkthrough). Hazardous Course 2 (hl1 mod) had a whole bunch of these, I had no idea that it was even a theme until I watched someone else's walkthrough. I glitched and spammed my way through most of these sections legitimately and in my defence I consider it a life achievementTM (along with the lava-surfing section from Conker, brrr). I definitely got HL1 vibes at 58:19 : That's the outdoor area where you hear grunts talking about freeman and where a sniper starts shooting you if you grab a medkit off a padmount transformer. Is this area from the base game or the expansion (ie after Hl1's release)? Your graphics drivers check the executable name to work out what list of hacks to apply to the game. This is a big tradition, both for fixing stuff in current games (AAA releases tend to have big graphics driver updates released afterwards) and stuff for older more popular games (so they don't break with modern drivers). I think I even recall Mesa (a common Linux graphics driver stack) has such things. A lot of graphics devs hate game devs, rumours like this are all over the place: The low fade distance for the vegetation probably didn't have to do with polygon counts, but more to do with the fact they're transparent. Transparent objects require more passes to render and (worst of all) proper sorting before you render them, because they depend on what was rendered behind them (unlike opaque stuff). Sorting is expensive if you don't have a clever system. The doom, build & quake engines have massively effective ways of handling terrain (brush) sorting, but I'm not sure about transparent object poly sorting in quake2, it might have been a super-slowdown case where even having three plants onscreen brings on the tremors. White edges around characters with some versions of AA: could be bleed from an atlassed charset maybe? Normally you stretch the texture UVs ever so slightly larger than the mesh quads to get rid of this problem, but that must somehow be getting ruined by the AA method. Some graphics drivers used to auto-stretch/twiddle UVs in weird ways sometimes too; I recall stories about some game engines having to detect this (to-counteract it) and other ATI vs Nvidia emulating or not each other's behaviour? I'm not sure.

Eek bundleware? Is it optional during the install or mandatory? I'll whip open a VM. EDIT: Well f** it bundles InstallCore and you are not given an option to opt out. Your consent is hidden far down in the EULA you agree to. That's beyond a dark pattern of automatically ticking something by default, that's flat out misleading and deceptive. Having a title on the EULA saying one thing and then another unrelated thing halfway down it violates simple & old-fashioned reading comprehension rules; you can't claim people are legitimately consenting if you hide soul-contracts in the restaurant menu. Thankyou for the cleaner build links Ratchet. Is it just the 'licence expiry' notice? In general: humour of all types will be taken in bad taste by some people, it's something you have to live with. Everyone has different rulesets on how it does or does not belong in software/media/art/hardware/etc. You should have seen some of the stuff my coworkers used to hide in their software; oh god!

I didn't just watch this Ross, I felt it. This game deserves to be cheated. Cheating: memory editors Q1: Is your XP shown clearly as a number onscreen somewhere? (I'm not watching that video again!) Q2: Does this game bother to implement anti-cheat? (I'll presume not as the trainer partly worked) A memory editor (like CheatEngine on Windows) will let you search for that XP number step by step and then let you edit it live; no need to use someone else's trainer. EDIT: Don't download the version from the cheatengine website, it's silently bundled with crapware in order to earn money for the author. This apparently started happening a few years back, it's been a long time since I used Cheatengine/Windows. Technically you are asked permission & agree to it if you read through the entire EULA, but there is no checkbox or opt-out (I just had a look). Ratchet has links to builds without this crapware bundled in the next few posts of this topic. This process takes a few minutes of you iteratively performing steps like this: Search for values in the game's memory that are equal to my XP Play the game for a bit to increase my XP slightly Search again for the new XP value to narrow down the list Repeat steps 2 & 3 until we only have a few results that reliably reflect my XP as it changes Set value of these locations to any number you want. Lots of guides on the web to this effect. Once you have found the correct memory locations to edit: you can keep changing the values in these locations until the game decides to re-arrange data. This typically happens on player death, on game load and on map transition; but it depends on the engine design. Who cares, your changes should be permanent anyway If the game doesn't show your XP as an exact number eg if it's shown as a progress bar instead; then things are a little bit more annoying. Searching will take longer and will require more iterations, but it should still take less then 10 minutes (if you don't accidentally make mistakes and end up with 0 results, which happens): Snapshot all of game memory (I've forgotten what this is called in Cheat Engine) Play game for a bit to increase XP slightly Narrow down list by searching for "increased values" Play game for a bit and DO NOT increase or change XP (eg walk for a few seconds) Narrow down list by searching for "equal/same values" Repeat steps 2-4 until we only have a few valid-looking results Set value of these locations to any number you want If the game implements anti-cheat Common forms include: Game detects you attaching a debugger (like Cheat Engine) & closes Memory values are scrambled or moved around regularly to annoy you IIRC Cheat Engine has some workarounds for the former. Dealing with the latter is more painful and probably not worth it; don't try and escape hell by going to niflhel.

It took me a few sittings to get through this video. It was worth it, thanks Ross. Why have GUI themes gone backwards? (& high emotions against non-conforming UIs) In short: (1) GUI frameworks (win32, qt*, gtk*, etc) have become much more difficult to theme for. Constantly changing targets, horridly complicated codebases, etc. When you make a theme it's a pain to start and it doesn't stably last. This is an important reason why many of the theme sites (for both Win & Linux) have not had much added to them since the late 2000's. (2) Audiences now automatically react negatively to any sort of UI experimentation. People are getting constantly burned by bad UI changes that they can't opt out of (eg Google & Microsoft products) so now they hate all UI changes regardless of who they are from. Any sort of difference or change is "OMG THIS IS HORRIBLE I CAN'T COPE" as if we now have an uncanny valley of UI appearance. This is getting really psychologically entrenched, I can't emphasise enough how much of an issue this is. I recently came across someone who creates crazy UIs as part of the experience of her games & programs: Unfortunately they were getting pushback from people, which I think is a bit sad to do to those who experiment, suggesting that they somehow hurt society by daring to publish their fun little programs. My response to the page I just linked goes into some more detail: Expect more high emotions from UI discussions If there is something people hate more than UI problems, its when their UIs get changed from underneath them. This makes people feel vile right to their core, especially if they feel any sort of ownership or comfort with their computer. Ross: even the slightest discussion of UIs will bring up an extreme fear in people that you are somehow affiliated with those that do this Don't let this misunderstanding end your world. Commandline vs GUI I use both extensively. One is not universally better than the other, but you are on the right path by saying that one points out faults in the other. Comparisons and competition are good things, if there was only one (eg only CMDline or only GUI) then we would be much much worse off. Just as we need more GUI variants and experimentation to help show people how bad the stuff we already have is. Case in point: Windows powershell. The fact it can do things that you can't do in the UI anymore (eg remove Windows 10 pre-installed crap) shows the UI had failed, not that powershell is any good.

Whilst I'm here: http://dege.freeweb.hu/dgVoodoo2/dgVoodoo2.html DgVoodoo is more than just a 3dFx->DX shim, it's also a DX(all up to 9?)->DX11 shim. It lets you force certain things like AA, mipmapping, scaling and resolution. Given that it's doing it at the graphics API level it's a good alternative to forcing things in graphics driver settings. I used to only use it for getting 3DfX games working, didn't realise it also does directX.

> but I originally wrote AMD off, since my understanding was they got rid of the option to force AA in games at the driver level on Linux. I would recommend you try both AMD and Nvidia cards/drivers. Sadly forcing things like AA reliably seems to be outside primary goals of any vendor, so it's hit and miss regardless of the philosophy. The AMD ones are first-class open source and do not come with a GUI configuration tool. Instead they're compatible with the "standard" open source tools (xrandr, driconf, Xorg.conf, etc) as well as a wide variety of hacks & library replacements (libstrangle, etc). The Nvidia ones come with a GUI tool, but replace several system libraries so other tools do not work. The GUI tool they come with is basically the _only_ source of configuration you can do. Also note the potential difficulties with older Nvidia cards (you will have to make sure the right [old] version of the Nvidia drivers are installed). > If the scaling can be done on the card / OS itself and it's downsampling the image to be sent back at native resolution, great. Yes, that's what xrandr --scale does. The monitor does not even flicker (or notice), it's still being sent whatever resolution it was already set to. N.B. xrandr is a standard X11/Linux tool for playing with screen resolutions, rotations, arrangements etc. Many GUI monitor configuration programs use it (or the xrandr interfaces) behind the scenes. It's not hard to use or learn, esp compared to many other command-line tools. Will not 100% work with Nvidia drivers. > I'm not going the custom resolution route that can send rates that the monitor can be incompatible with [...] being good for the monitor Note 1: not true with LCDs, their mux/decoder flatout rejects out-of-spec signals. Some are more forgiving (eg allow more than a few % timing stretch) but that's about it. Yes a potential problem if you are using a CRT. Note 2: you won't be able to do this accidentally, adding new modelines to X11/Linux requires long commands full of numbers (and modeline calculator programs (unless you're crazy). Not something to worry about unless you want to. > Is a Geforce 770 really not enough muscle to run 15-20 year old games on Linux? The "on Linux" factor is "it depends". Some games run faster under Wine than Win, others visa versa. Some stutter more, some less. Also the variables of whether or not you are using dxvk & what graphics drivers (radeon, amdgpu, nouveu, Nvidia, etc) make a big different. There is a whole stack of libraries between the game and your human peripherals that differs from Windows: wine .dll libs, directx->opengl (wine default) or vulkan (dxvk) shim libs, userspace opengl/vulkan (eg mesa), kernel opengl/vulkan drivers (eg radeon, amdgpu) and of course video card firmware. I've been playing some Tony Hawks games under Wine on my desktop the past week. THPS 4 has a horribly laggy level even on a good computer. THUG2 runs a lot better. These are games from 2000-2004 that may or may not be able to run faster than period computers because either of the different system stackup or perhaps in-built limitations, I don't have a fast system with period OS (XP) to test on. > Say I have a DirectX 8 game and a DirectX 9 game that's not in any Linux game database. That's most of the games I play I've got a folder of notes over the years of individual tweaks, methods or manual cracks I've had to implement for some more obscure stuff, I should probably write some of it up. > What steps would you recommend I take for: > 1. Getting each game to run There is no one correct approach to step 1, other than: 1. Try 2. Furiously Google error messages 3. Ask for help on Wine forums or mailing lists if you can't proceed (I've had what I thought were impossible problems answered with simple magic. Summon the gods of the d3dx8->d3dx9 shim dlls :D) Some of the steps of my approach these days: 1. Create a fresh Wineprefix for each game, so installing arbitrary DLLs does not affect the other games I have. If you're only starting then just ignore this step, learn it later when you start having issues. 2. Try and run and install the game. 3. If something goes wrong: check to see if the game is on WineHQ. 4. If not, google around. Often the fixes required for playing the game on modern Windows also apply. 5. Run the game from the console, so you can see if it's spitting errors about a certain DLL or feature. Often you just need to install some arbitrary windows stuff (d3dx9 libraries, etc). Again, follow the fixes Windows users have to use. Winetricks is a good shortcut program for getting & installing stuff. 6. Pull out the big guns. WINEDEBUG=+dll,+reg wine program.exe and then lots of perusal. Sometimes it's stupid stuff, other times it's multithreaded mayhem and I have no hope of working out what's going on. When I get to the point of disassembling I know I'm lost and crazy. 7. Ask for help in a sqeaky voice on the WineHQ forums. As per above, some nice people there I don't use any of the GUI frontends (Lutis now?) so I can't comment on those. > 2. Attempting to force antialiasing on said games. Try all of the methods mentioned in this thread. No single method will work everywhere. Every game initialises and uses its graphics api (dx7/8/9/etc, opengl, glide, etc) in completely unique and arbitrary ways, what works for one will not work for another. Things are less standard in the 3D world than you think, remember your custom 3D-in-every game programs? The xrandr --scale option will "always" work (provided the game can be made to play at the higher resolutions it now thinks your monitor uses) but you will end up with tiny HUD+text unless the game is smart enough to scale these with resolution. It will also potentially be the slowest, but I doubt rasterisation is going to be a bottleneck or FPS limiting factor for old games unless they are in a software-rendering mode.

I've been watching a few of this guy's game reviews, they remind a little of Ross' https://www.youtube.com/user/perochialjoe/videos?disable_polymer=1 Very low view count (few hundred per video). Hope someone finds them interesting.

Hmm. @Ross Scott, I probably shouldn't have used your site's artwork there without asking. Please tell me if it offends.

Publishers changing games from goods to services VS allowed 2nd hand goods markets I am going to imagine that the large games publishers are going to want to feel the minimum disruption possible. The less change, the better, especially if you are a manager in a big company. In your video you give the argument that changing the appearance of games from being goods to services will impact image and sales. You specifically mention the idea of games having to state that they will only last X years and be a subscription service. I think this is being optimistic of how honest you expect the game companies to be. I'm imagining they would instead do something like this: Positive spin on 'subscription' to make it look normal. Lever the existing microtransactions as a partial explanation for it being subscription. Perhaps make a couple of transactions that "complete the game content" that are monthly, and say that if you don't pay you are not seeing the "full game". This would be so much easier for them, they basically have to change nothing other than boxes, their license texts and what they say publicly. No company structure change, no budget changes, no planning changes. This is the least resistance path. Debating your Impacts of demanding 2nd hand games be tradable (for the big game publishers) I don't think "more money to the developer" is directly linked to "more games" and "lower prices". The exact relationships are more complex. I would like to think of "a sale" and "money going to the publisher" as two separate but very connected concepts. "Money going to the publisher" does not directly lower prices. Prices are set based on research and marketing of what price is going to maximise the overall volume of money in. How much the game cost to make or how much it profits are irrelevant variables when deciding the sale price, you don't price based on demand or costs, you don't have to (this isn't a "limited" physical good). "Money going to the publisher" may or may not make more games get released. I'm a bit sceptical, I would assume that game release quantities and schedules are just as gamed as game prices. For smaller developers: definitely yes, most of this money goes toward game creation. But for the bigger boys: big chunks of it (possibly most of it?) goes towards marketing, corporate and planning. "A sale", if we now consider everything other than the financial gain part of it, is more of a numerical concept. This game sold X copies over Y time in Z pattern. It's a bit like a hit counter -- a potential indicator of success, but not an indicator of future success (ie making more games & lowering their prices). Take for example Valve: used to make games, got rich from it, decided to stop making games. If you throw money at a publisher or game developer is does not get used for what you want it to get used for, instead they choose how to use it, and they will always run their sales at what they think is the optimal pricing strategy (not the lowest pricing strategy to reward consumers). How would a 2nd hand market be implemented? I think it's worth investigating all of the options here. Fundamentally it's hard to do 2nd hand stuff for digital goods: Allow anyone with a copy to install & play (GoG-style) Force there to be only one owner/player at a time via DRM Iron-hand the 2nd hand market by restricting it to your platform. Option (1) is the most liked by consumers, but there's no way to confirm transmission of ownership. I like this model, and I think there are arguments out there that this might lead to more sales (because people like this freedom), but I'm not sure. Option (2) requires phone-home DRM to make certain that only one person can use the game at a time. I have some games I picked up off the street at a council cleanup a few years back, including a copy of GTA4. "Awesome", I thought, "these are mine now". Nope, many of these games refuse to activate : ( Option (3) is where the courts give the companies enough lee-way to run a closed-house 2nd hand market. This would be rife for exploitation unless there is a lot of governance. There's not much point of the 2nd hand market if it's controlled by the same people as the 1st hand market, especially since there is no easy way of confirming that products are not being artificially "destroyed" to game the 2nd hand market prices. This final implementation detail is what matters. This may even end up being a whole second stage of proceedings. If companies are allowed to run their own 2nd hand markets then they could game them just as they game the 1st hand market. They don't even have to be transparent about it: "destroying" and "creating" a copy of a game is free to them. Deabating the benefit on shady key sellers I don't think a 2nd hand market is going to help shady sellers like G2A. They will still operate in the same way and be just as shady: 2nd hand games cost more than free/dodgy/scammed keys Claiming a key is a valid 2nd hand game takes zero effort Their services would still have the same prices and users would still (mostly) see them as just as dodgy as they are now. Perhaps if someone goes to extra effort of creating a decent-looking 2nd hand game trade platform this might change, but they would have to be very wary of distancing themselves from traditional shady key sites.

Great video Ross. I hate invisible walls, so I'm really glad to see a game where you can keep on going. I remember editing the maps single-player maps for a game once to remove the walls. It completely broke the linear progression of the level, but being able to explore the island my own way made me so happy. The tone was completely different, something the original experience lacked.

Ooh, thankyou for the suggestion. The Mint installs on my folks' laptops are now ancient and I want something else to put them on.

Ross: Ignore Ubuntu's stance. They have announced lots of bad decisions before and had to backstep later, or never gone through with them. It sounds like the people who made this decision don't play games (luddites I say!). Keep using whatever Linux distro you prefer. If and when you encounter problems then (and only then) consider changing to one of the almost-identical-distros-with-a-different-name-and-colour-scheme that abound. The wires are indeed alpha textures on large rectangular polys. I think this game is too old to be a shader-mess, it's more likely some fixed-pipeline variant. There are a few more reg keys in the doc I link that could have an effect, I'll give them a try. 16-bit. Ie games and programs from around the Win1,2,3,95 era. There are quite a few, as even into the reign of Win98 many games would still use 16bit executables to provide compatibility with older systems. 32-bit executables gave programmers a lot less headache (no 64K limit, proper memory management done for you, etc) but it was a still a new option. I believe Windows has dropped supported for WOW64 (16 bit support on 64-bit windows) completely now. On 32-bit versions you might still be able to enable it manually? But on 64-bit I believe you are SOL. The Linux world is unfortunately almost as bad at the moment. Wine supports 16-bit executables perfectly, but you also need your kernel to support them. This is an optional feature when the kernel is being compiled, to change it you have to recompile your kernel (easier these days, but still not something most ordinary users will want to do). Different distros choose different options to compile their kernels. I'm unsure what Ubuntu does (try it to find out), but I know my distro (Void) has it disabled. If you are lacking 16bit LDT then you will get messages like this when trying to run old 16-bit Windows programs: $ wine esheep.exe [...] 0032:err:winediag:build_module Failed to create module for "krnl386.exe", 16-bit LDT support may be missing. 0032:err:module:LdrInitializeThunk "krnl386.exe16" failed to initialize, aborting $ Once upon a time 16-bit LDT was enabled by default in basically all distros, then some security flaws were found in it and as a result many distros changed their build settings to disable it. I've heard that the problems have since been fixed, but few distros have bothered changing the settings back. After all, who cares about old software? Pfft!