|
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:
|
#
?
Jun 15, 2018 23:17
|
|
|
|
| # ? Apr 16, 2024 17:15 |
|
|
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) 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.
|
|
#
?
Jun 15, 2018 23:44
|
|
|
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. 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?
|
|
#
?
Jun 17, 2018 00:18
|
|
|
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:
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.
|
|
#
?
Jun 17, 2018 00:34
|
|
|
What bug/issue trackers do gamedevs use? Do they have special issue trackers like they have perforce and poo poo for vcs?
|
|
#
?
Jun 19, 2018 20:27
|
|
|
We use JIRA, and I think it's relatively common.
|
|
#
?
Jun 19, 2018 20:40
|
|
|
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.
|
|
#
?
Jun 19, 2018 20:45
|
|
|
Depends on the studio, but we also use JIRA. I've been places that used TTP, Hansoft, perforce, and others.
|
|
#
?
Jun 19, 2018 20:54
|
|
|
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.
|
|
#
?
Jun 22, 2018 16:57
|
|
|
Jira isn't free?
|
|
#
?
Jun 22, 2018 17:34
|
|
|
Studio posted:Jira isn't free?
|
|
#
?
Jun 23, 2018 01:09
|
|
|
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?
|
|
#
?
Jun 25, 2018 17:25
|
|
|
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 
|
|
#
?
Jun 25, 2018 17:38
|
|
|
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.
|
|
#
?
Jun 25, 2018 18:16
|
|
|
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 18:45 on Jun 27, 2018 |
|
#
?
Jun 27, 2018 06:17
|
|
|
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%?
|
|
#
?
Jun 28, 2018 08:32
|
|
|
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%? 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.
|
|
#
?
Jun 28, 2018 13:39
|
|
|
Just say you’re reticulating splines like the sims
|
|
#
?
Jun 28, 2018 14:04
|
|
|
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%? 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.
|
|
#
?
Jun 28, 2018 17:22
|
|
|
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
|
|
#
?
Jun 28, 2018 18:08
|
|
|
ChickenWing posted:machine learning-integrated loading bars
|
|
#
?
Jun 28, 2018 18:50
|
|
|
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
|
|
#
?
Jun 28, 2018 19:08
|
|
|
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. 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.
|
|
#
?
Jun 29, 2018 08:30
|
|
|
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.
|
|
#
?
Jun 29, 2018 08:41
|
|
|
The answer to this all is obviously waiting rooms or loading screen games, duh.
|
|
#
?
Jun 29, 2018 16:33
|
|
|
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.
|
|
#
?
Jun 29, 2018 18:16
|
|
|
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.
|
|
#
?
Jun 29, 2018 22:51
|
|
|
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.
|
|
#
?
Jul 1, 2018 18:08
|
|
|
Goreld posted:You can blame Namco for the lack of these. Also a fine example of how stupid software patents are.
|
|
#
?
Jul 1, 2018 18:15
|
|
|
Many (most?) games these days don't have loading screens long enough to warrant minigames, anyway.
|
|
#
?
Jul 1, 2018 21:36
|
|
|
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).
|
|
#
?
Jul 2, 2018 04:15
|
|
|
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.
|
|
#
?
Jul 2, 2018 07:36
|
|
|
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.
|
|
#
?
Jul 5, 2018 21:32
|
|
|
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 
|
|
#
?
Jul 5, 2018 21:45
|
|
|
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.
|
|
#
?
Jul 7, 2018 14:20
|
|
|
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.
|
|
#
?
Jul 7, 2018 14:44
|
|
|
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.
|
|
#
?
Jul 8, 2018 02:53
|
|
|
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.
|
|
#
?
Jul 11, 2018 11:49
|
|
|
What languages do you write the most?
|
|
#
?
Jul 12, 2018 07:28
|
|
|
|
| # ? Apr 16, 2024 17:15 |
|
|
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.
|
|
#
?
Jul 12, 2018 08:25
|
|
