Possible client-side changes/improvements ...

Got something on your mind about the project? This is the correct place for that.


Forum rules

This forum is for feature requests, content changes additions, anything not a Bug in the software.
Please report all bugs on the Support Forums

Post Reply
zick
Novice
Novice
Posts: 194
Joined: 21 Feb 2007, 03:30
Location: City Of Champions Again

Possible client-side changes/improvements ...

Post by zick »

Hey, I thought I'd make some suggestions for the client that might make the world a little more interactive. I think it'd be it interesting if NPC's eyes followed your player, or at least they turned and looked at you. This could be done by adding frames to an NPC's graphics. We are already gonna add animations to NPC's right? So let's add some extra frames so that they interact with your player.

While I'm on the subject of client changes, I have another. But let me preface by saying that the current way we do player spritesets doesn't really require that we make this change, but if we were to ever use artwork that had anti-aliasing and/or alpha channels the current system really wouldn't work. Like right now when we draw pants for a spriteset we leave a chunk out of it so the players hand can be drawn there. However if the hand wasn't pixelled as a square (let's say it was a anti-aliased circle) it would be almost impossible to make this shape be taken out of the pants and making it look right. The anti-aliased areas wouldn't quite match up right, the colors would be slightly off.

My idea is that if we used more layers and full layers (like actually a full pair of pants as opposed to a pair of pants with a hole in them to allow a hand to be drawn over top). It'd mean we'd have to use more layers but it'd be easier to do artwork (as in not having to remove sections of a layer for the layer that appears above). Because of the extra possible load on the client, I propose that the client cache all the combined layers for your player into a temporary spritesheet. It can also do this for other players and NPC's. Maybe the client would make a PNG by combining all layers for a player whenever he logs in or changes a piece of equipment, when a new (unseen) player enters a map. This could even be used with monsters, like a monster that may actually wear armor or equip a weapon. And since the image is cached, it doesn't need to be recreated all the time.

Just an idea ...
User avatar
Jaxad0127
Manasource
Manasource
Posts: 4209
Joined: 01 Nov 2007, 17:35
Location: Internet

Re: Possible client-side changes/improvements ...

Post by Jaxad0127 »

zick wrote:Hey, I thought I'd make some suggestions for the client that might make the world a little more interactive. I think it'd be it interesting if NPC's eyes followed your player, or at least they turned and looked at you. This could be done by adding frames to an NPC's graphics. We are already gonna add animations to NPC's right? So let's add some extra frames so that they interact with your player.
TMWServ supports moving NPCs, so that will make it rather odd if they turned to face you. It would also be rather creepy.
zick wrote:While I'm on the subject of client changes, I have another. But let me preface by saying that the current way we do player spritesets doesn't really require that we make this change, but if we were to ever use artwork that had anti-aliasing and/or alpha channels the current system really wouldn't work. Like right now when we draw pants for a spriteset we leave a chunk out of it so the players hand can be drawn there. However if the hand wasn't pixelled as a square (let's say it was a anti-aliased circle) it would be almost impossible to make this shape be taken out of the pants and making it look right. The anti-aliased areas wouldn't quite match up right, the colors would be slightly off.

My idea is that if we used more layers and full layers (like actually a full pair of pants as opposed to a pair of pants with a hole in them to allow a hand to be drawn over top). It'd mean we'd have to use more layers but it'd be easier to do artwork (as in not having to remove sections of a layer for the layer that appears above). Because of the extra possible load on the client, I propose that the client cache all the combined layers for your player into a temporary spritesheet. It can also do this for other players and NPC's. Maybe the client would make a PNG by combining all layers for a player whenever he logs in or changes a piece of equipment, when a new (unseen) player enters a map. This could even be used with monsters, like a monster that may actually wear armor or equip a weapon. And since the image is cached, it doesn't need to be recreated all the time.

Just an idea ...
That idea has been kicked around a bit already.
Image
zick
Novice
Novice
Posts: 194
Joined: 21 Feb 2007, 03:30
Location: City Of Champions Again

Re: Possible client-side changes/improvements ...

Post by zick »

For cached spritesheets you can do something like a PNG with a filename like PC_Gato_F247EA.png ... PC stands for playable character, you could use NPC for an NPC or MOB for an enemy, or whatever you want. I think it's probably a good idea to differentiate what type of spritesheet it is because probably an NPC wouldn't have as many frames. Gato is a player's name, this name area could be the name of an NPC, or a temp name given to a particular enemy like SCORP001 for a scorpion. The hex string would stand for items/colors/options that player's spritesheet uses ... it would probably be longer than 6 characters, but I just put that there for the sake of an argument. Then the client could ask the server something like "Is Gato still F247EA?" to which the server can respond "Yes" or "No, he is now F376AE" and then a new spritesheet is compiled. Also, the client can see if a spritesheet has been compiled for a particular "variation" already and just copy the file and fix the filename. Maybe also when the player logs off these temp files are deleted.

Just an idea of how I imagined something like this might work. Of course it's up to the developers.
User avatar
Crush
TMW Adviser
TMW Adviser
Posts: 8046
Joined: 25 Aug 2005, 16:08
Location: Germany

Re: Possible client-side changes/improvements ...

Post by Crush »

...or you could just use a round wheel instead of a square one and save the combined spritesheet of each character in memory.

But there is also a much less technical problem. The timings of the animations a sprite is combined from do not necessarily have to be identical. This means that the combined spritesheet would have more frames than each single one. In the worst case the automatic combination of two animations can lead to hundreds or even thousands of frames. Combination of the spritesheets into one would thus require that each of them uses exactly the same animation. But considering that we 1. do not make use of this possibility for most equipment sprites and 2. are talking about a minor performance tweak which can just be omitted in problematic cases this is not really an issue.
  • former Manasource Programmer
  • former TMW Pixel artist
  • NOT a game master

Please do not send me any inquiries regarding player accounts on TMW.


You might have heard a certain rumor about me. This rumor is completely false. You might also have heard the other rumor about me. This rumor is 100% accurate.
zick
Novice
Novice
Posts: 194
Joined: 21 Feb 2007, 03:30
Location: City Of Champions Again

Re: Possible client-side changes/improvements ...

Post by zick »

Crush wrote:...or you could just use a round wheel instead of a square one and save the combined spritesheet of each character in memory.

But there is also a much less technical problem. The timings of the animations a sprite is combined from do not necessarily have to be identical. This means that the combined spritesheet would have more frames than each single one. In the worst case the automatic combination of two animations can lead to hundreds or even thousands of frames. Combination of the spritesheets into one would thus require that each of them uses exactly the same animation. But considering that we 1. do not make use of this possibility for most equipment sprites and 2. are talking about a minor performance tweak which can just be omitted in problematic cases this is not really an issue.
Huh ... That was a little too technical for me :? What I was saying was if a spriteset was 36 frames (6 walking in each direction, 6 attack, and 6 various frames - I'm sure there would be more, I'm just using it as an easy example), then we stack all 36 frames from each of the separated spritesheets (nude base, pants, sword, etc.) in the appropriate order and make a PNG snapshot that is a finalized version of that current spriteset. The client then uses that until the player changes his equipment. Each of those separated spritesheets line up exactly with each layer, or maybe in the case of a hat or something with only a couple of frames (as opposed to the 36) there's some kind of xml file (like currently) to stack those images in the appropriate place. I guess this new spriteset could be stored in memory, I was just thinking that might make it laggy if it's gotta store all of the spritesets in memory for all sorts of players and monsters and npc's instead writing them to disk (especially if it's something that has entered the map but is unseen yet - like when you enter a town all the npc's could be compiled on disk and wait there until they come into view and that's when they go to memory).

Just thought I'd clarify.
User avatar
Crush
TMW Adviser
TMW Adviser
Posts: 8046
Joined: 25 Aug 2005, 16:08
Location: Germany

Re: Possible client-side changes/improvements ...

Post by Crush »

I already understood what you meant. What you didn't understand is that a subsprite (like equipment sprites) consists of two parts: 1. the spritesheet and 2. the animation file which defines which sprite is showed when.
I guess this new spriteset could be stored in memory, I was just thinking that might make it laggy if it's gotta store all of the spritesets in memory for all sorts of players and monsters and npc's instead writing them to disk
Reading from disk is horribly slow compared to reading from memory. Memory usage only becomes a performance killer when an application needs more memory than the system can provide because in that case the disk has to be abused as memory (called "pagefile" in windows and "swapfile" in linux).

A player character spriteset needs a bit more than 1 MB memory when loaded. You needn't store the spriteset for every single being in the game at once. The current caching strategy keeps every loaded graphic (and other resource) in memory after loaded and removes it when it isn't on screen for a while.
  • former Manasource Programmer
  • former TMW Pixel artist
  • NOT a game master

Please do not send me any inquiries regarding player accounts on TMW.


You might have heard a certain rumor about me. This rumor is completely false. You might also have heard the other rumor about me. This rumor is 100% accurate.
zick
Novice
Novice
Posts: 194
Joined: 21 Feb 2007, 03:30
Location: City Of Champions Again

Re: Possible client-side changes/improvements ...

Post by zick »

Sorry ... wasn't sure if I was clear.
I was thinking along the lines of almost eliminating the xml file for the animation and just using a large image for each subsprite (face, pants, sword, etc.) comprised of properly spaced out images that if you stacked all of these subsprites one on top of the other in a specific order, it made a spritesheet for all of the required frames of a spritesheet. I was thinking more along the lines of Photoshop (or GIMP) layers that if you turned on the viewability of all the layers you get the final product, but you could turn off all but one layer and have a subsprite. I was thinking this mainly because right now we don't have support for a whole lot of layers, compared to what we could have, say like a nude base with some pants with a belt and a shirt with a sweater overtop of it and a long coat over that.
I also thought that if it was compiled to disk when a player was not yet viewable, it would be faster overall. I guess I didn't mention what was on disk was read to memory when needed, but I thought that was obvious. I know disk is slower than ram. I guess I was thinking along the lines of when you go to a website, the images are stored in your cache so when you revisit that site they don't need to be downloaded again.
Sorry for any confusion ...
User avatar
Jaxad0127
Manasource
Manasource
Posts: 4209
Joined: 01 Nov 2007, 17:35
Location: Internet

Re: Possible client-side changes/improvements ...

Post by Jaxad0127 »

zick wrote:Sorry ... wasn't sure if I was clear.
I was thinking along the lines of almost eliminating the xml file for the animation and just using a large image for each subsprite (face, pants, sword, etc.) comprised of properly spaced out images that if you stacked all of these subsprites one on top of the other in a specific order, it made a spritesheet for all of the required frames of a spritesheet. I was thinking more along the lines of Photoshop (or GIMP) layers that if you turned on the viewability of all the layers you get the final product, but you could turn off all but one layer and have a subsprite. I was thinking this mainly because right now we don't have support for a whole lot of layers, compared to what we could have, say like a nude base with some pants with a belt and a shirt with a sweater overtop of it and a long coat over that.
I also thought that if it was compiled to disk when a player was not yet viewable, it would be faster overall. I guess I didn't mention what was on disk was read to memory when needed, but I thought that was obvious. I know disk is slower than ram. I guess I was thinking along the lines of when you go to a website, the images are stored in your cache so when you revisit that site they don't need to be downloaded again.
Sorry for any confusion ...
That system reduces the variety we can have in sprites.
Image
Post Reply