The return of The Gigantic Gob ( queue Scooby-Doo scary music now )
Why is there a gigantic gob of....
So, I've been having a look at the extra colors that are added to the channel palette for the banner ads with regards to using them for channel icons.
Some of the stuff I have been talking about with regards to this I have just been assuming based on the results I see being rendered in glorious 8-bit color on my monitor. Understanding how graphics hardware works, there can be no doubt about what is happening (things weren't too complicated in '96), however not having access to the server I could never actually try any of it out. After a recent conversation with Mousey (thanks for your help with that =) I now realise that some of the steps that I was assuming were happening server-side are actually being performed automatically by the client, I suspect in battle.snp or maybe storm.dll. Most notably the color matching.
if you want to take a picture from a bitmap with one palette and display it using another palette, you have to do color matching......Get a SS from the channel. This is an 8-bit palette base pcx file. Convert it into a .BMP file, but make sure it stays 8-bit
...etc
This is stilll a good idea because you will be able to see exactly what your icon will end up looking like, and you won't wate your time designing with colors that just aren't there when it eventually hits the screen, however it turns out that when the icons leave the server they aren't 8-bit palette images at all, they are sent as full 24-bit tga files. So the color-matching must be happening client-side.
The same process takes place, but unfortunatey it's being done automatically somewhere in one of the code modules loaded by the exe. This is nice programming from our friends at Blizz - saving extra steps for themselves later on when developing new stuff as bnet progressed, but sadly for us, it takes away the extra control we might have had by doing it manually and then just sending the finished product to the client.
Mousey tested this out, and despite the fact that the channel screen gets a whole gob of new colors from the banner ads, it seemed the icon color matching refused to use those entries. This puzzled me for a bit, as it would seem to be masive overkill to write in checks that deliberately rejected a certain range of palette entries from the color matching 'just in case' someone at blizz got a bit confused designing icons sometime. So why do it?
Well, maybe one of the programmers was just really anal-retentive and did it anyway...OR... as it dawned on me a bit later (duh) theres a much more likely reason why this is happening: --> As the icons are being served as 24-bit images, then it seems they're mixed down to the 8-bit palette when the client is constructing the channel screen from its various components, then it makes sense that a similar thing is probably happening with the banner ads, only the banners get a much more personalised color conversion, which allows them to import up to 64 new entries into the palette.... and again this would be done automatically by the client.
So... what it seems to me would be happening is: when you log in and the client constructs the channel screen, it starts off with the 'standard' palette that is hard-coded into the exe (or for the channel more likely one of the lib modules) which includes the infamous
Gigantic Gob of 64 blank entries. Next the icons are imported and color matched to the existing palette, then finally the banner is imported and the extra palette entries are added.
The icons are never matched to the extra palette entries, because at the time the icons are imported, those new entries still havn't been added.
So where does this leave us for extra icon colors? Well unfortunately it seems it would have to be some sort of war2combat client mod, no way around that. Maybe if we're lucky we could get away with just a simple war2patcher mod or perhaps something a bit more substantial would be required. On the face of it, you could easily just overwrite
The Gob with a bunch of new entries at its source, then they would already exist when the icons are color-matched and hey-presto... more colors. That's all well and good until the banner loads, at which point it overwrites those entries with it's own and the colors go bleh.
So we can cheat and use the palette from the banner, so the correct entries from the banner are already there so when it overwrites them it does so with exactly the same values and everything works. Cool... well thats if you never want to change the banner, because as soon as you do, the palette changes and we're back to bleh again :/...
Lambchops scratches his head.... thinks hard (ouch)... then scrambles for the mouse and pulls up a SS with a colorful banner ...Cool. So i just did a quick crop of just the banner part of a SS, then pasted it back onto a reduced size 8-bit bitmap saved that, then loaded it with Irfanview and it says: "63 unique colors." Nice, so it looks like the banners
only use their extra 64 colors (I probably cropped one off at an edge somewhere) and they don't do any color-matching to the standard palette entries. This means that if the people waving the banners are happy settling on having only one palette, we can write that in to the client they can still change the banners without messing up the icons.... Maybe.
Yeah there's always a maybe. The other problem that
might occur is that by rights, according to the official specs ... certainly for .bmp format.. and possibly for others as well... palette entries are supposed to be ordered according to their frequency of use... i.e. if your picture contains a heap of a certain shade of green, then that color should be placed at the start of the palette, followed by the color that has the next highest amount of pixels using it, right down to the color that is only used for a handfull of dots at the end. The theory being that this reduces cpu usage as the rendering routine doesn't have to search as far through the palette to locate the colors its more frequently using.
In practice it's such a tiny amount of data anyway that it really doesn't matter in the slightest, and many libraries don't bother doing it............
If you still don't know what im referring to, 'it' is the process of, when saving or constructing a new palettised image, going through each unique color that occurs in the image one by one and counting up the number of pixels that use each of those colors, then resorting the palette entries according to this associated frequency data .......So if Captian Anal was programming that bit, there's a chance that even if a new banner contains all the same colors as the old one, they might possibly end up in a completely different order..... and we're back to bleh again. But I dont think this is a big chance, its far quicker and easier to just copy the imported palette straight over
The Gob. Anyway it's something that's relatively easy to test.
But REALLY what we want to do is have the client just load the banner ad first, then load the icons after it, and everything would be fine. At first thought that didnt seem too hard - these processes would undoubtably be written as seperate subroutines, then we could just put a debug watch on the memory addresses where
The Gob lives and track down the instructions that write to that location, then its relatively simple to trace it back to the call that enters that sub. The icon matching might be a little bit trickier to find, but once we have those, just exchanging their call targets so that they are executed they other way round is easy-peasy.
Seemed like a nice idea for about 1 minute before the obvious smacked me in the face (story of my life). Problem is that this stuff is part of a conversation between the client and the server, and its very unlikely that the client receives all of the info from the server and piles it up in a great big heap and
then starts processing it... that would be very inefficiant and make it a resource hog... most likely each section of data is received from the server and processed on-the-fly ...first it gets icons.bni which is then processed into whatever format the client ends up using it in at which point the client is finished with it, then the next bit - maybe the banner, or the list of players in the channel, or whatever - is received and it overwrites the received copy of icons.bni which is still sitting in the input buffer. So if we wanted to change the order that these are processed in we would have to either:
a) Change the order that the server sends the info to the client or b) allocate another buffer and make a backup copy of icons.bni then replace it in the input buffer later on before we call the color matching subroutine.
Method a) would, at worst, require modding not only the client but also the server (yuck.. bugs... headaches... crashes... stuff that), although depending on the actual structure of the client- server conversation, it could be as simple as just getting the client to request the various bits in a different order, and the server might happily comply without a care in the world. If we we're really lucky the network requests from the client might be housed in the same subroutine as their relative graphics importing code and we're back to the simple switcheroo again. But thats a lot of maybes, and a lot of tracing, debugging and swearing at screens full of disassembly to even start testing the theory.
Method b) is technically a bigger mod as it would be actually adding new code to the client, but allocating a buffer and copying a bit of data back and forth is pretty basic stuff and would probably be quite painless to insert, however to get there you still have to do a whole pile of debugging to find the right places to put it.
.... and then there's the cheating method. Just an idea, but one way to avoid the whole client- server transaction and image import routine head-fuck is just to sneak a little bit of code in right at the end that simply saves the 64 entries that make up
The Gob to a disk file then have the war2patcher or something write those in when the module is first loaded. The only drawback would be that when the banner is changed, the first time you log in the icon colors would be bleh, but it would only be a matter of exiting out and restarting , and everything would be perfect until the next banner change.
To continue thinking about this I need a bit of info on how the banners are produced. What format are they in when they server sends them to the client? The .bni writer doesnt seem to have anything to handle banners so its some other related format? Are they 24-bit when they leaves the server or already paletised?.... anybody?
