Register a SA Forums Account here!
JOINING THE SA FORUMS WILL REMOVE THIS BIG AD, THE ANNOYING UNDERLINED ADS, AND STUPID INTERSTITIAL ADS!!!

You can: log in, read the tech support FAQ, or request your lost password. This dumb message (and those ads) will appear on every screen until you register! Get rid of this crap by registering your own SA Forums Account and joining roughly 150,000 Goons, for the one-time price of $9.95! We charge money because it costs us $3,400 per month for bandwidth bills alone, and since we don't believe in shoving popup ads to our registered users, we try to make the money back through forum registrations.
«34 »
  • Post
  • Reply
SupSuper
Apr 8, 2009

At the Heart of the city is an Alien horror, so vile and so powerful that not even death can claim it.


Warmachine posted:

This is a general programming question, since it has been a sore spot with regards to a certain game I like. People ask for multi-threading/64-bit all of the time with Rimworld, and I tend to brush off the whole multi-threading thing because that is a can of worms I can't currently wrap my head around, and see as unnecessary compared to the constant headache of running out of addressable memory. I understand it isn't as simple as flipping a switch on the compiler, but what I don't understand is WHERE in the process it starts to become an issue. So my question boils down to two things:

1) Why in TYOOL 20XX since the release of Windows 7 would someone decide not to compile a game nativly to 64-bit even if initial design requirements don't predict addressing requirements to exceed the limits of 32-bit addressing.

2) What and where are the hurdles in taking a finished product from 32-bit to 64-bit addressing?
Middleware, probably. To use Rimworld as an example, it uses the Unity engine, so they are bound by whatever Unity supports (which seems to do 64-bit builds, but has very poor multithreading support). And any native libraries and plugins they use have to also support 64-bit. And now they have to support two separate builds.

Adbot
ADBOT LOVES YOU

mastermind2004
Sep 14, 2007



Warmachine posted:

This is a general programming question, since it has been a sore spot with regards to a certain game I like. People ask for multi-threading/64-bit all of the time with Rimworld, and I tend to brush off the whole multi-threading thing because that is a can of worms I can't currently wrap my head around, and see as unnecessary compared to the constant headache of running out of addressable memory. I understand it isn't as simple as flipping a switch on the compiler, but what I don't understand is WHERE in the process it starts to become an issue. So my question boils down to two things:

1) Why in TYOOL 20XX since the release of Windows 7 would someone decide not to compile a game nativly to 64-bit even if initial design requirements don't predict addressing requirements to exceed the limits of 32-bit addressing.

2) What and where are the hurdles in taking a finished product from 32-bit to 64-bit addressing?

1) At least until recently (don't know if it's still true or not), China still had a significant amount of Windows XP boxes, which would not support 64 bit.

2) Ensuring that there aren't cases where type conversion causes loss of data is important in the conversion. If you don't use explicitly sized types, things that you expect to be the same in 32 bit can be different in 64 bit, such as size_t versus int. You also have to deal with a change in the size of pointers and other types, so if you were doing anything clever with pointers to do something funky like serialization (or marshaling data or anything), that could all break. Also, the hurdle of convincing people that it is worth the investment of any amount of time on something that is already complete and well tested. Just because you change the build target to x64 and it compiles doesn't mean it is going to run, so you would need to go through whatever QA or cert process on whatever platforms you are shipping on.

Warmachine
Jan 30, 2012

I've got a bad feeling about this.


mastermind2004 posted:

1) At least until recently (don't know if it's still true or not), China still had a significant amount of Windows XP boxes, which would not support 64 bit.

2) Ensuring that there aren't cases where type conversion causes loss of data is important in the conversion. If you don't use explicitly sized types, things that you expect to be the same in 32 bit can be different in 64 bit, such as size_t versus int. You also have to deal with a change in the size of pointers and other types, so if you were doing anything clever with pointers to do something funky like serialization (or marshaling data or anything), that could all break. Also, the hurdle of convincing people that it is worth the investment of any amount of time on something that is already complete and well tested. Just because you change the build target to x64 and it compiles doesn't mean it is going to run, so you would need to go through whatever QA or cert process on whatever platforms you are shipping on.

So the shift in architecture, all else held equal, can result in something that was addressed in 32 bit space being in a different location in 64 bit space, and things that reference the 32 bit location won't be able to find the 64 bit location?

Cocoa Crispies
Jul 20, 2001

Vehicular Manslaughter!



Pillbug

Warmachine posted:

So the shift in architecture, all else held equal, can result in something that was addressed in 32 bit space being in a different location in 64 bit space, and things that reference the 32 bit location won't be able to find the 64 bit location?

Yeah, but figuring out exactly where in memory is the linker's job.

From personal experience literally yesterday, I was trying to get Zandronum, a Doom 1 & 2 runtime, to work on 32-bit ARM (armv6l, on a Raspberry Pi Zero W). This involved:

  1. Getting the source
  2. Getting libraries with binaries available (a one-liner in Raspbian Linux)
  3. Letting the build process discover what libraries had to be downloaded and compiled as source (because Raspbian doesn't distribute them in the way Zandronum wants)
  4. Letting the build process start compiling it, i.e. turning C & C++ files into object files
  5. Discovering that p_spec.cpp assumes that char types are 8 bits and signed, as they are on i386 and x86-64, but on armv6l they're unsigned.
  6. Fixing that file by hand.
  7. Starting the build again
  8. Compiling succeeds, build links it. Linking is how one or more object files (which are basically CPU bytecode and references to memory locations that bytecode needs) get turned into an executable (which is broken into sections for CPU bytecode, sections for constants (like chunks of text or hard-coded values), sections for global & static variables (variables that there only needs to be a single place for in memory), and instructions on which parts of memory those sections map to.

Porting something between architectures (and i386 and x86-64 are different architectures) means lots of fixing bugs like that type problem I had. I lucked out in that I only had to change one variable declaration. Worst case scenario would be rewriting a huge chunk of Zandronum, rewriting libraries it depends on, and that's only even remotely workable because it's running on a fairly common open-source stack. If it was doing weird poo poo inside a closed-source engine and didn't work, I'd've just locked the computer and played Splatoon instead.

bob dobbs is dead
Oct 8, 2017

one day bob dobbs will live again

Nap Ghost

What bug/issue trackers do gamedevs use? Do they have special issue trackers like they have perforce and poo poo for vcs?

mastermind2004
Sep 14, 2007



We use JIRA, and I think it's relatively common.

leper khan
Dec 28, 2010
Honest to god thinks Half Life 2 is a bad game. But at least he likes Monster Hunter.

bob dobbs is dead posted:

What bug/issue trackers do gamedevs use? Do they have special issue trackers like they have perforce and poo poo for vcs?

We use JIRA, and I really wish we didnít use perforce for code.

BULBASAUR
Apr 6, 2009

ASK ME ABOUT SWEET CONVERSIONS


Soiled Meat

Depends on the studio, but we also use JIRA. I've been places that used TTP, Hansoft, perforce, and others.

SilentW
Apr 3, 2009

my It dept hgere is fucking clwonshoes, and as someone hwo used to do IT for 9 years it pains me to see them fbe so terriuble

Yam Slacker

The studio I'm currently at uses Jira, but I've used TestTrack Pro as well - there seems to have been an overall push towards Jira recently because it's free, and integrates with confluence.

Studio
Jan 15, 2008




Jira isn't free?

ShadowHawk
Jun 25, 2000

The company has no assets of any significant value.


Nap Ghost

Studio posted:

Jira isn't free?
It's free until you hit a certain number of users.

djkillingspree
Apr 2, 2001
make a hole with a gun perpendicular

SilentW posted:

The studio I'm currently at uses Jira, but I've used TestTrack Pro as well - there seems to have been an overall push towards Jira recently because it's free, and integrates with confluence.

from experience setting up a bug database, Jira can be more readily customized than TTP so that's another reason to prefer it. It also has a nice workflow for tracking tasks and bugs in the same DB. Honestly they're all basically fine though?

djkillingspree
Apr 2, 2001
make a hole with a gun perpendicular

Warmachine posted:

So the shift in architecture, all else held equal, can result in something that was addressed in 32 bit space being in a different location in 64 bit space, and things that reference the 32 bit location won't be able to find the 64 bit location?

It's less that it would be a different location, and more that there are assumptions that are either explicitly or implicitly made that could no longer be the case in 64-bit.

The difficulty in porting from 32 to 64 bit is entirely caught up in how portably the code was written. If the code never intentionally or unintentionally assumes the width of variables, it could be as simple as telling the compiler to compile in 64 bits and you're done.

On the other hand, it's pretty easy to accidentally write code that isn't portable, because you'd never see the bugs until you try to port, and you may not even realize your code is making assumptions that aren't portable. What would actually happen in these cases is often that some parts of the program are now expecting and using longer variable sizes, which means that they can write or read past their allocated memory, which can cause crashes, weird bugs, or nothing, depending on what the code does!

Long story short, it can either be really easy to port to 64bit (just compile to 64bit and you're done), or it can be an incredibly laborious process of identifying and fixing all of the points where your code was relying on the system being 32bit. Which you may not be able to discover quickly or easily, and which may only cause rare crashes or bugs. Like everything with porting, the answer is it's somewhere between trivial and impossible, but hard to know without knowing the codebase

Chev
Jul 19, 2010


Switchblade Switcharoo

Even worse, you need to know the codebase and the platform it was originally written for in depth, to root out some of those assumptions.

OneEightHundred
Feb 28, 2008

Soon, we will be unstoppable!


For games at least, using 32-bit numbers everywhere isn't usually too big of a deal in practice because it's extremely rare to have buffers or pointer diffs that span over 2GB. Most of the problems from 64-bit porting are from union types breaking, and from schemes involving bytewise compares/hashing/etc. breaking due to the pointer size change introducing padding that contains uninitialized data.

I've also seen at least one case of "let's serialize this structure containing a pointer to disk, and we'll just fill in the pointer after it loads!" introducing a compatibility break.

OneEightHundred fucked around with this message at Jun 27, 2018 around 17:45

Heran Bago
Aug 18, 2006





Why is it so hard to make a loading bar that cleanly and smoothly goes from start to finish and immediately gives way at 100%?


I don't think I've ever seen a loading bar that doesn't hitch up at some point outside of a single file transfer. I imagine it's just impossible - even spinning or glowing loading icons hitch up.
Wouldn't a more verbose loading dialog (graphics... check. collision... check.) be more useful and interesting for everyone than a bar that sticks somewhere around 80% and then on 100%?

Red Mike
Jul 11, 2011


Heran Bago posted:

Why is it so hard to make a loading bar that cleanly and smoothly goes from start to finish and immediately gives way at 100%?


I don't think I've ever seen a loading bar that doesn't hitch up at some point outside of a single file transfer. I imagine it's just impossible - even spinning or glowing loading icons hitch up.
Wouldn't a more verbose loading dialog (graphics... check. collision... check.) be more useful and interesting for everyone than a bar that sticks somewhere around 80% and then on 100%?

First you have to consider what the goal of the loading bar is. Most games, it's to show that the game isn't stuck, and a vague sense of how long until it's fully done.

Second, you have to consider what it's covering for. Let's say that the game has to: A) load 1000 files, B) build 25 shaders, C) instantiate 1000 game objects.

Let's go through these in order:

Before we start, how long does each section take? There might be 1000 files and only 25 shaders, but the time it takes is gonna be different for each one. 1 file does not take as much time as 1 shader. So we can't say for sure how much % should be A, how much should be B, etc. We can't even take all of the individual tasks and divide them up equally, because some are faster than others.

Well this is complicated but let's just assume 33% for A, 33% for B, 33% for C.

A) We've got 1000 files to load, from small text files to large texture resource files. We could assume they're mostly the same size and increment by 1% every time we reach a set number of files. Or we could vary depending on size and run a few extra calculations. If we load some files in parallel though, well this becomes a lot more complicated.

B) We've got to build 25 shaders. This uses a lot of CPU and/or GPU, and we want to do it in parallel as fast as possible. So we max out the processor to run as many as we can in parallel. How many can we run at once? Welp, hard to guess. Let's just start all of them at once and let them sort themselves out. Except now you're stuck on 33% until one's done, and then the rest might not be too far behind so it's a jump from 33% to 50% to 66%. It even speeds up as shaders finish building and there's more processing power available.

C) At least this should be simple. Let's say game objects take about the same time to instantiate, regardless what they are. So you start instantiating them, one by one and you increment the loading bar every X game objects. This instantiation tends to spike your CPU/GPU as stuff needs to get prepared, maybe textures need to get streamed, etc. The UI thread/processing tends to be less of a priority in this case because you want the loading to finish as quickly as possible. So even if it's a steady increase, the bar might jump around as a frame gets skipped.

In the end you've got: an unreliable, jumpy, freeze-y, stuttering loading bar, whose actual value doesn't correspond with anything that's happening in the back-end really. So you just give up and make it mostly time-based, or just interpolate between intermediate states and add funny messages like 'reticulating splines' as the output to keep people entertained.

Or you replace it with some sort of list showing loading progress in depth, telling you what exactly it's loading. And then the players ask you why you've done that because it's a bunch of things that don't matter to them, and they just want to know roughly how long until it's done and not have to figure out which ones take longer themselves.

Phobeste
Apr 9, 2006

never, like, count out Touchdown Tom, man

Grimey Drawer

Just say youíre reticulating splines like the sims

snowshovelboy
Apr 13, 2006



Heran Bago posted:

Why is it so hard to make a loading bar that cleanly and smoothly goes from start to finish and immediately gives way at 100%?


I don't think I've ever seen a loading bar that doesn't hitch up at some point outside of a single file transfer. I imagine it's just impossible - even spinning or glowing loading icons hitch up.
Wouldn't a more verbose loading dialog (graphics... check. collision... check.) be more useful and interesting for everyone than a bar that sticks somewhere around 80% and then on 100%?

The only way to really make it load smoothly is to time how long it takes and move the bar over time, instead of having it show the actual loading progress. I shamefully admit I have shipped a console game that worked this way.

ChickenWing
Jul 22, 2010



Fun Shoe

snowshovelboy posted:

The only way to really make it load smoothly is to time how long it takes and move the bar over time, instead of having it show the actual loading progress. I shamefully admit I have shipped a console game that worked this way.

machine learning-integrated loading bars

mastermind2004
Sep 14, 2007



ChickenWing posted:

machine learning-integrated loading bars
For fully accurate loading bars, upgrade to a Titan X.

OneEightHundred
Feb 28, 2008

Soon, we will be unstoppable!


A huge complication is dependency trees, caching, and reuse. If you know exactly what assets you'll have when you start loading and exactly how much when you finish, then maybe you can time it reliably. But let's say you drop the player into a random location on the map in an open world game, and there are like 25 world chunks to load. A bunch of those are going to have assets used in multiple chunks, but they only need to be loaded once (and might already be loaded!), so the cost of loading each chunk is variable, and the only way to actually figure out the full set is something like per-chunk manifests, and then you have to spend time and memory de-duping the manifests and looking up all of the file sizes.

The alternative is to say "each world chunk is 4%."

My favorite is how City of Heroes did it for a long time (it was eventually patched to be more accurate). It would fill the loading bar by a fixed amount for each asset it loaded and then just speedily ran through the rest of the bar when it was done, and it was just spaced in a way that the worst-case scenario would only fill up like 2/3 of the bar.

ChickenWing posted:

machine learning-integrated loading bars
This will only be a joke for so long.

ShadowHawk
Jun 25, 2000

The company has no assets of any significant value.


Nap Ghost

snowshovelboy posted:

The only way to really make it load smoothly is to time how long it takes and move the bar over time, instead of having it show the actual loading progress. I shamefully admit I have shipped a console game that worked this way.
I don't think this is shameful at all. It's the best result, and given the consistency of console hardware it's not even wrong.

If a player is going to load the same thing on the same machine more than once, games should be able to learn from that too. The first time I load the game it can be a big jumpy mess, but the next time it should know about how long it'll take because it's done it before.

eshock
Sep 2, 2004


Also iirc it breaks TCR to have a loading bar get "stuck" at a certain level if it's doing a lot of work there--on both PS and Xbox you have to have something on the screen moving at all times during loading to show that the game hasn't hard-locked. It's one reason you see so many games with spinning gears or wheels to indicate loading even if there's a progress bar.

mutata
Mar 1, 2003

You walk in with the Turnips, you leave with the Bells.


The answer to this all is obviously waiting rooms or loading screen games, duh.

1337JiveTurkey
Feb 17, 2005



College Slice

Speaking of progress bars, do you have any sort of special API for tracking the progress? I'm used to getting a setProgress() method that takes an integer percentage and sets the bar to that amount. In practice getting the progress bars to do anything useful is near impossible when there's three different developers implementing different parts. It usually ends up going 0%, 33%, 66% and then 100%. I imagine adding in multithreading makes it even messier.

Hyper Crab Tank
Feb 10, 2014

The future of crustacean-based warfare


We don't show progress bars at all because literally no one has ever asked to have it and it's an annoying amount of work for a feature almost no one wants. (We just do animated loading screens.) We just throw a bunch of function calls in a queue on a separate thread, then wait until it's all finished and move on. Optimally, all loading should happen on a separate thread during load screens; we still can't predict how long it will take for reasons already explained, but at least it avoids frame stutters since the main thread is dedicated to painting a pretty loading screen for you while the other thread does the work. Except, some things can't always be done on the other thread, usually because they require some graphics context poo poo that's only available on the main thread (texture uploading is a great example). Usually those operations are fast enough that you don't notice, but that's one reason why you could see a frame hitch during a loading screen.

1337JiveTurkey posted:

Speaking of progress bars, do you have any sort of special API for tracking the progress? I'm used to getting a setProgress() method that takes an integer percentage and sets the bar to that amount. In practice getting the progress bars to do anything useful is near impossible when there's three different developers implementing different parts. It usually ends up going 0%, 33%, 66% and then 100%. I imagine adding in multithreading makes it even messier.

Multithreading doesn't really complicate things much; you should be loading assets on another thread anyway, like I said. Figuring out a clean way to split the loading task into a number of sub-tasks that make sense is the greater problem and requires writing a lot of annoying code that's rarely worth it and no one wants to do because we have better things to do with our time. But if you forced me to, I'd make it mandatory for your "job that loads a thing" class to have some kind of progress getter that indicates how far along it is and make the main thread poll as required.

Goreld
May 8, 2002

"Identity Crisis" MurdererWild Guess Bizarro #1Bizarro"Me am first one I suspect!"

mutata posted:

The answer to this all is obviously waiting rooms or loading screen games, duh.

You can blame Namco for the lack of these. Also a fine example of how stupid software patents are.

mastermind2004
Sep 14, 2007



Goreld posted:

You can blame Namco for the lack of these. Also a fine example of how stupid software patents are.
That patent is actually expired now, so developers are free to do it, now it's probably more to do with the development time and load time tradeoffs of having a mini-game than anything. I would personally rather try to spend more effort on reducing loading times than developing a mini-game to cover the load time.

Hyper Crab Tank
Feb 10, 2014

The future of crustacean-based warfare


Many (most?) games these days don't have loading screens long enough to warrant minigames, anyway.

OneEightHundred
Feb 28, 2008

Soon, we will be unstoppable!


Reducing load times is kind of hard because of annoying hardware bottlenecks. If you want a game to look nice, you want to fill up memory with as much high-resolution stuff as will fit. If you want that memory to be used efficiently, you want stuff that hopefully has a fairly compact in-memory representation, and doesn't compress well, so that means that "ideally," load times are about as long as it takes to pull ~8GB of data off of the hard drive.

A 5400 RPM 2.5" magnetic drive only reads like 100-130MB per second though, so that's like a minute.

This is also one reason that unskippable intro movies can exist (to act as a flashy loading screen, essentially).

Hyper Crab Tank
Feb 10, 2014

The future of crustacean-based warfare


OneEightHundred posted:

This is also one reason that unskippable intro movies can exist (to act as a flashy loading screen, essentially).

Also elevators. Have you played the new God of War, for example? The realm travel room is just a glorified loading screen, and so is the Realm Between Realms, but it really helps improve the immersion. It's especially bad for games that read off of disc; but even then, it's pretty much only photorealistic AAA games that need to load that much stuff.

The main thing you can do to reduce load times is to ensure you don't unload things unnecessarily, but keep it in memory once loaded and reuse it.

Chronojam
Feb 20, 2006

This is me on vacation in Amsterdam
Never be afraid of being yourself!

Really the confusing thing is when a loading bar jumps backwards at some point. More of an early 00s problem. Even if your old estimate was wrong, don't slide progress displays backwards.

repiv
Aug 13, 2009



College Slice

Hyper Crab Tank posted:

Also elevators. Have you played the new God of War, for example? The realm travel room is just a glorified loading screen, and so is the Realm Between Realms, but it really helps improve the immersion. It's especially bad for games that read off of disc; but even then, it's pretty much only photorealistic AAA games that need to load that much stuff.

The worst is when those hidden loading transitions have fixed-length animations or conversations timed by roughly how long it took to load on a 360/PS3, then the PC port is stuck waiting for that amount of time even if it's running on an SSD.

Mass Effect

Sunning
Sep 14, 2011
Nintendo Guru

Mass Effect 1 had a lot of tricks for loading different segments of a large area. There is a large wall in the center Presidium that forces players to walk around it so the game can load in the other half of the place.

Hyper Crab Tank
Feb 10, 2014

The future of crustacean-based warfare


Yeah, whenever a game can predict with reasonable accuracy where the player is going to go next - usually because there is only one way to go from a given spot - it can do a lot of loading in the background. This is also one reason why some games with a open-world-like style make you go through chokepoints, usually interiors, to get to certain parts of the world; it's so that they can load the rest of the world while you're indoors and can't see it being loaded. The main reason for things like the realm travel room in God of War is because the game can't predict where you're going until you've pressed the button to select your destination, so it needs some kind of loading screen and chooses to hide it behind a pretty light show and some banter between the main characters.

ninjewtsu
Oct 9, 2012



are there any goons here that work in video game marketing? i've been curious what that whole side of the industry even looks like. what does the very beginning look like? do a bunch of marketing guys sit in a conference room and examine the game and identify its selling points, then go form there on how best to market that? or is marketing involved way earlier, and dictate specific selling points to the developers that they want the game to have? what kinds of specific things are game marketers generally looking out for when they're figuring out how to market a game? i feel like game marketing gets talked a lot, but the perspective of the marketer is almost never actually seen.

cKnoor
Nov 2, 2000

I built this thumb out of two nails, a broken bottle and some razorwire.


Slippery Tilde

ninjewtsu posted:

are there any goons here that work in video game marketing? i've been curious what that whole side of the industry even looks like. what does the very beginning look like? do a bunch of marketing guys sit in a conference room and examine the game and identify its selling points, then go form there on how best to market that? or is marketing involved way earlier, and dictate specific selling points to the developers that they want the game to have? what kinds of specific things are game marketers generally looking out for when they're figuring out how to market a game? i feel like game marketing gets talked a lot, but the perspective of the marketer is almost never actually seen.

I can ramble on about this as a Marketing Producer at Paradox.

We usually start with reading the Game Design Document, trying to figure out what games compete for the same space and such. We have a lot of meetings so, yes some of this is done in conference rooms.
At Paradox we do not dictate selling point for the devs, however the content team (that I am part of) is on the game producers a lot to make sure that the features we need to market the game are available to us. This means things like observer modes, in game free camera through debug mode and other things we need to be able to capture gameplay. But we do share out opinions with the producers on the publishing side, and then have a lot more input on that kind of stuff. It also depends a lot on what type of publishing deal we have with the devs, internal devs are a lot closer to the marketing team, than external teams are.

There is also a lot of talk about price points and what different SKUs the game should be sold at, since the Sale team is part of Marketing, and putting together a full marketing campaign, and then following it. For me personally a lot of my time is spent making sure we have the trailers and other social content we need to follow the campaign.

Usually a marketing campaign runs up and through release, and then with expansions we make a new one.

Digirat
Sep 14, 2011



Taco Defender

What languages do you write the most?

Adbot
ADBOT LOVES YOU

Nice piece of fish
Jan 29, 2008





Ultra Carp

Asking a probably stupid question that may have been asked before, because I'm out of the loop on this one: What's your opinion on gaming for linux, and what's the real difficulty making games linux compatible/making linux games from a dev perspective? If it wasn't for gaming, I would absolutely be using linux on most of my home computers, but gaming and linux seems an impossible combination and I don't see why that doesn't change. Not that I'm expecting it to. I'd love your opinion on this as actual computermen. Haven't looked at this for ages.

  • 1
  • 2
  • 3
  • 4
  • 5
  • Post
  • Reply
«34 »