Tweaked the palette layout a bit to make the colors more consistent.
Looks great! Thanks.
Lots of exciting stuff in this release... I'll have to play around with it!
ID:259208
 Aug 27 2000, 5:07 am
|
|
Looks great! Thanks. Lots of exciting stuff in this release... I'll have to play around with it! | |
On 8/27/00 10:35 am Deadron wrote:
Let's say you've taken a nasty poison, and every few ticks you get redder and redder until you either take an antidote or keel over. My first thought was for lighting effects... say, if you've got a torch, the turfs around you turn reddish. Oh, the possibilities! The problem with BYOND lighting effects is that they'll always be squarish, until... someone... writes code that will let us do otherwise. EverQuest does a pretty excellent job of providing lag-free movement by using movement prediction on the client side. If a mob is moving, the client assumes it will keep moving at about the same pace, and if no data is coming over the line, the client just keeps moving the mob along until the next data set comes in. If the client and server are out of sync at this point, then the client resets the mob location. Ah, so that's what Diablo II has been doing to me... I'll be running around in a battle.net game and suddenly get jerked back to where I was a second ago. What's funniest, though, is when a critter I was attacking appears to run away from me, then keels over and dies on the spot from a hit I gave it a few seconds before. Z | |
On 8/27/00 10:35 am Deadron wrote:
Anyway, I'd be curious to get any performance clues about icon arithmetic! Right now it is quite inefficient, because the entire icon (colormap + pixels) is sent over from the server to the client on any of these operations. We have it setup such that the instructions that only modify the colormap will account for this and only resend that. I'm sure Dan will optimize this when he gets the chance. Even so, the current system shouldn't be prohibitive assuming that it isn't abused. The blending operations are pretty simple, so I don't think that cpu overhead is an issue. If it turns out to be a factor, I suppose the system could be made to queue up the icon instructions, attach them to the icon, and do the processing client-side. Client processing is pretty subtle though, because the client doesn't store much data on its end. Right now it doesn't evne have the full information about each transmitted icon. Of more concern is the network overhead, but once the colormap stuff gets optimized it should be fine for most cases. We've got a couple other internal functions for doing some other graphics tweaks. For instance, one of them just swaps colors in the map. This could allow you to designate, say, "shirt and pants" colors and let the user change them. | |
Client processing is pretty subtle though, because the client doesn't store much data on its end. Right now it doesn't evne have the full information about each transmitted icon. I have to admit this is not what I'd been picturing all along... I figured the client used whatever was in the rsc file (otherwise what's the point of downloading it all?). I can't complain, since the speed of network games is quite zippy (months ago my test of The Fungus Among Us, with flashlights in dark rooms and fecund flamethrowers, convinced me of that) but it's still, to reuse a word from a few days ago, counterintuitive! We've got a couple other internal functions for doing some other graphics tweaks. For instance, one of them just swaps colors in the map. This could allow you to designate, say, "shirt and pants" colors and let the user change them. Nifty! Although I'm curious how it might account for variations in shading. Well, I'll just put my trust in Dantom... it's always been justified so far! | |
On 8/27/00 9:03 pm Guy T. wrote:
I have to admit this is not what I'd been picturing all along... I figured the client used whatever was in the rsc file (otherwise what's the point of downloading it all?). I should clarify: the client does in fact receive all of the resources, but it currenly only uses that data to generate the relevant bitmaps and from then on refers to them simply as ids sent from the server. In other words, in the current system generic icon information (eg: when should frame 6 play?) is essentially ignored by the client (aside from its usage in the initial generation). Perhaps more clearly, things like "frame delay"--while technically stored in the file sent to the client-- are only used by the server to determine when to transmit the icon id. It probably wouldn't be too difficult to do more processing client-side, but I'm not sure if it is really more efficient, since all changes to icons would have to be stored with the passed in data to the client. We'll see what kind of results we get in the current framework and optimize it accordingly. I'm really speaking for Dan here, though, so I'll shut up. Not that this should affect anyone. Sometimes it's good to know what's going on internally, though. [Edited] -- rereading my previous message, I should make one thing clear: right now when any of these icon modification functions is called, a new icon is created on the server (via some blending algorithm) and transmitted to whatever clients are in view of it. I say this is unoptimized not because the process is done on the server-- I don't think that is too relevant-- but because it is not currently accounting for certain obvious efficiencies. Mainly, a lot of these icon modifications only change the colormap, which is fairly negligeable compared to the pixels in the icon. In that case, we should only resend the colormap and an id of an existing icon, rather than an entire new icon (including duplicate pixel data). The server can recognize this case and it is my hope that we handle it soon. Again, this probably won't affect anyone, aside from the peace of mind that the operation is fairly efficient. | |
On 8/27/00 11:06 am Tom H. wrote:
Even so, the current system shouldn't be prohibitive assuming that it isn't abused. Well I'm sure we'll put that to the test! Right now I've started using icon addition to solve a problem I had just been grappling with -- the best way to show how hurt someone is using the map. I tried playing with health meters showing up on the map a bit, but that's a tough one given the size of a mob's icon. So I'm adding red to the icon for every 10% of health they lose, which means their color could be changing pretty rapidly. This is pretty effective (it certainly shows that Zilal's torch idea would work), but it doesn't work with all colors for my purpose (some things don't get very red). What I need to do is a second operation also subtracting green and blue each time -- but I'm worried about the overhead. I wonder if it would make any sense to allow addition and subtraction within an rgb() call, like so: icon += rgb(28, -28, -28) I just tried this, but it doesn't seem to do it. | |
On 8/27/00 11:01 am Zilal wrote:
On 8/27/00 10:35 am Deadron wrote: Dang! Caught me right in the middle of a brand spanking new light-sourcing library. (Oh, by the way, so people don't chase after me with red-hot cattle brands, my spl_missile() library is delayed until I can figure out an alternate method to my currently failing angles code; everything except the actual generation of the angles works, though. I'll give myself two weeks' sliding time, just in case I have to jump through hoops.) Ah, so that's what Diablo II has been doing to me... I'll be running around in a battle.net game and suddenly get jerked back to where I was a second ago. What's funniest, though, is when a critter I was attacking appears to run away from me, then keels over and dies on the spot from a hit I gave it a few seconds before. That happens in Total Annihilation online, too. I think everyone in the bigwig evil corporations uses client-side movement extrapolation. (CSME! Nice acronym, eh? ;-) | |
This icon addition stuff is letting us play with fire!
(Uh, literally even!)
What are the performance considerations we should keep in mind with this?
Let's say you've taken a nasty poison, and every few ticks you get redder and redder until you either take an antidote or keel over.
Could this ground things to a halt? At first I was thinking so, because I was assuming all the pixel changes have to be communicated -- but for color changes I assume DM is just sending the color change instruction to the client...
If that's true then the more expensive one might be adding icons together. But, well, I imagine all of this processing could be done on the client side, which would make it very efficient. (Our very powerful computers are no doubt twiddling their thumbs anyway while waiting for the next data to come over the line.)
EverQuest does a pretty excellent job of providing lag-free movement by using movement prediction on the client side. If a mob is moving, the client assumes it will keep moving at about the same pace, and if no data is coming over the line, the client just keeps moving the mob along until the next data set comes in. If the client and server are out of sync at this point, then the client resets the mob location. In most cases the result is very smooth movement for you, because the client keeps you moving steadily even if data is coming in spurts.
Anyway, I'd be curious to get any performance clues about icon arithmetic!