• Hey Guest. Check out your NeoGAF Wrapped 2025 results here!

Why arent more devs using differential/delta updates?

pants

Member
I don't understand what the constraint is here and i'm hoping someone can explain it to me. Why in general are more devs not using diff updates? Yesterday I had a 3GB update patch on a 5GB game and it got me wondering why this is a thing. Anyone have theories/answers?
 
It probably has to do with the situation when you've got multiple patches... Say there are three versions of the game, base, patch 1, and patch 2. Patch 1 is easy -- you just have the difference between base and patch 1. Patch 2 also seems easy... Until you remember that not everyone has patch 1. So now you need two patches, one for patch 1-2, and one for base-patch2. So on so forth.

Alternatively, you could just do sequential patching, where if you have base, it gives you patch 1, then 2, but I'm sure MS has some stupid ass rule where it makes it easier to just have a single patch instead.

Feep I think he means on Consoles, which regularly get huge updates... For what should be very small changes. And instead of having a patched just make the small changes in the files themselves, (which can be huge), it just redownloads the whole file all over again.
 
I don't understand what the constraint is here and i'm hoping someone can explain it to me. Why in general are more devs not using diff updates? Yesterday I had a 3GB update patch on a 5GB game and it got me wondering why this is a thing. Anyone have theories/answers?

I thought it had something to do with the package manager/whatever the PS4 uses (if we're discussing new consoles).
 
All Steam games use differential updating. What game are you talking about?

I dont want to bog this down into a game specific topic, I notice in general that a lot of games have humongous updates when they hardly even touch ingame assets. This was one of them.
 
Another constraint I just realized is the case of patching with a physical game, and a somewhat meatier patch. A delta patch would either have to run every time that you loaded the game, or just run it once (using data off the disk) and plant the files on the HDD. But that sounds a bit more difficult, and also would need a "patch processing time" requiring the disk to be in, and also take up the same amount of room overall on the HDD.
 
I think what he means by differential, and what everyone else is hearing with differential are two different things. You can have a patch that is differential in the scope of the entire game, but not be delta patching the files themselves.

Here's what I (and probably OP) means:

Game A is made up of an exe and five large, compressed archives of content, which are viewable as single overall files. Patch comes out that makes a small adjustment (about 30 lines of code are changed) in File A of Game A. File A is 3GB large.

With delta patching, you would only download a few MB of patch, which would run a program that would change those 30 lines' worth of data inside of File A. With what we have now, you currently download the entire, new, File A, which is 3GB, but not B or C.
 
It probably has to do with the situation when you've got multiple patches... Say there are three versions of the game, base, patch 1, and patch 2. Patch 1 is easy -- you just have the difference between base and patch 1. Patch 2 also seems easy... Until you remember that not everyone has patch 1. So now you need two patches, one for patch 1-2, and one for base-patch2. So on so forth.

Alternatively, you could just do sequential patching, where if you have base, it gives you patch 1, then 2, but I'm sure MS has some stupid ass rule where it makes it easier to just have a single patch instead.

Feep I think he means on Consoles, which regularly get huge updates... For what should be very small changes. And instead of having a patched just make the small changes in the files themselves, (which can be huge), it just redownloads the whole file all over again.
I develop business software myself and although the file sizes are generally small 50MB - 100MB, we do differential updates, it's so weird in a space where people deal with assets the size of Kim Kardassian's butt they arent. I just cant. It's not entirely that hard either, you keep list of the of the versions on the client machine and spawn a get/whatever request based on that and have the updater do a scan before hand to make sure the list of stock is still good/spawn a new one anyway.
 
The PS4 uses differential updating, though, so not sure what you mean here.

I must have been misinformed. I personally don't pay attention to the size of patches, my Internet connection is fast enough for me to not notice or care.
 
I don't understand what the constraint is here and i'm hoping someone can explain it to me. Why in general are more devs not using diff updates? Yesterday I had a 3GB update patch on a 5GB game and it got me wondering why this is a thing. Anyone have theories/answers?

Long story short, usually games use archive files, ie lots of files are combined and possibly compressed into a few big ones. Depending on the change and file format sometimes even what should effectively be a small change will produce a huge differential patch just because the whole structure of the archive was rewritten.

Johnathan Blow wrote about that once: http://the-witness.net/news/2012/08/fun-with-package-sorting/
 
Long story short, usually games use archive files, ie lots of files are combined and possibly compressed into a few big ones. Depending on the change and file format sometimes even what should effectively be a small change will produce a huge differential patch just because the whole structure of the archive was rewritten.

Johnathan Blow wrote about that once: http://the-witness.net/news/2012/08/fun-with-package-sorting/

Thanks, this is exactly the kind of information I was hoping to find.
 
Another description of how even a small source code change can result in a large delta between two binaries, taken from a white paper:

Unfortunately, any source code modification will usually
cause changes throughout an executable file. Adding or
removing a small number of bytes of code or data will
change the relative position of blocks of code, adjusting
the displacement of relative branches which jump
over the modified region; similarly, any data located after
the modified region will have a different address,
causing data pointers to be modified throughout the file.
This causes patches generated with the traditional copyand-insert
method to be much larger than necessary; a
one-line source code patch in a 500kB executable could
translate into a 50kB patch file.


Still, anything has to be better than re-downloading the entire god damned file.
 
Another description of how even a small source code change can result in a large delta between two binaries, taken from a white paper
Correct, but it's not like atomic binary patches aren't possible, though.
The problem is more that the frameworks devs (must) rely on to install/update a game may not support them.
 
In the end, it's just hard as hell to only patch part of a binary file. Games with small patches have small patches because their game is broken up into lots of small files, so only the small files that need updating need to be redownloaded. When a game is just a few big files, though, there's really little that can be reasonably done.
 
My guess is the OS of the consoles (Steam does this by the way) doesn't support delta patches and the devs aren't allowed to distribute their patches (delta or not) through other channels, so they (we?) are screwed.
 
Top Bottom