Re: [crossfire] Face overlays
On 07/16/11 01:45 AM, Nicolas Weeger wrote: Ah - so it sounds like you are looking at one of these 2 possibilites: snip Correct :) My gut instinct is that #2 would actually be easier. For #1, I think it may require potentially more protocol changes (there may be issues with number of layers, so some extension for that, and the map send code would have to look at the object and see if that given object has overlays that need to get sent, look those up) - I'm just not sure how efficient that would be. #2 seems nice too, but this also means there will be a need for many temporary images. Imagine the player with a basic armor, and the associated overlay. There will be 4 (for most races) directions * 3 pictures (for most animations) so 12 composite images. Now the player casts a spell - that's another animation, so 4*3 pictures again. I wonder if the composite images could also include the animations - for some, that may not work if it is a single run action, but for others, one could imagine it would work . In particular, I'm thinking auras might be something animated to some degree, but the timing on those really isn't critical (if the aura animation is a little off from what the server things it should be, no big deal). But likewise, if the armor or weapon is animated (flaming swords, special armor), same thing - those are basically a loop, and if the timing is off on the client, no problem. Casting is trickier (as may be attacks), as you do those once (more for spells). OTOH, attacks maybe should also be a cycle. So one could imagine that if you add a composite image protocol command (cmpimage), it could be something like: cmpimage type[face|anim speedanimation](and repeat those) Type could basically just describe the next set of data that follows. If that data is an animation, the server would have to send the animation. Of course same is true for face - if the face has not been sent, has to get sent to the client also. Directions would still be an issue, as that is 4x or 8x the number of images. So I'm wondering how many pictures that will imply at total... One way would be for the server to find all action-related animations (so player_fenx_spellcasting and friends) and for each regenerate temporary faces for any face. That could mean 200 faces for a player. Maybe not that a big evil deal... On the server, that is not much a concern - the amount of data for each one probably would not be that much (50 bytes?) A bigger concern I would have would be that if one used a simple method (new composite face = composite face +1), on a long running server, one could go beyond 16 bits (65536 composite faces), which may mean that the server is unable to properly send the data to the client. Realistically, probably want to use a hash table that can hash the faces/animations for the composite image - that makes lookup much faster, and one could limit the hash table size to how many bits the protocol can handle (nearest prime less than 65535 for example). If the hash table fills up, the server could basically just give up an die. A more complex approach could be that each client connection has a lookup table - while it is conceivable that the server will go beyond 16 bits, it is pretty unlikely that a client would see all of those. So for each client, the server could literally start at zero and start increasing as that client encounters more and more composite faces. But that does not have to be in the original design - if that proves to be an issue, it could always be added later. Also it seems the server will need to send faces updates at almost each equipment change. Probably not that a big deal either, but still. Yes - for each equipment change, there is the potential of a composite face protocol command. But if the player is not changing equipment all the time (eg, the change in question lasts for a little time) or the player cycles between a few established ones (casting, combat, moving, certain aura going up and down), it probably would not take too long (and many composite image commands) for the client to get all of those, and the server now saves bandwidth on those future updates. For example, if one has to send all the images that make up the player, than that may be 8 bytes (base + armor + weapon + aura) for that, but once it is established, it is just 2 bytes (composite image). The composite image command itself is probably something like 20 bytes? Protocol command (cmpimage?) + 2 bytes for the number + the 8-12 of the actual images. So one doesn't have to use it too many times to come out ahead. For clients not having this support, the fallback would be simply to send the regular player face, imo. Yes - the only thing would be that in this case, the composite image, if it exists, should probably be stored in a different field in the object, and not replace the face - then it is very
Re: [crossfire] Face overlays
Ah - so it sounds like you are looking at one of these 2 possibilites: snip Correct :) My gut instinct is that #2 would actually be easier. For #1, I think it may require potentially more protocol changes (there may be issues with number of layers, so some extension for that, and the map send code would have to look at the object and see if that given object has overlays that need to get sent, look those up) - I'm just not sure how efficient that would be. #2 seems nice too, but this also means there will be a need for many temporary images. Imagine the player with a basic armor, and the associated overlay. There will be 4 (for most races) directions * 3 pictures (for most animations) so 12 composite images. Now the player casts a spell - that's another animation, so 4*3 pictures again. So I'm wondering how many pictures that will imply at total... One way would be for the server to find all action-related animations (so player_fenx_spellcasting and friends) and for each regenerate temporary faces for any face. That could mean 200 faces for a player. Maybe not that a big evil deal... Also it seems the server will need to send faces updates at almost each equipment change. Probably not that a big deal either, but still. For clients not having this support, the fallback would be simply to send the regular player face, imo. Regards Nicolas -- Mon p'tit coin du web - http://nicolas.weeger.org signature.asc Description: This is a digitally signed message part. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Face overlays
But is the client assembling these images, or have all these images been pre-assembled on the server (and thus, they are valid images)? That's one my questions, and something I'm asking other people for opinion :) Two options, server sends all needed faces at the same time (overlays to the player face) ; or server sends a special face the client knows to be a combination of faces. If the client is left to do this layering, then somehow, it needs to know what faces to layer for any given object (typically players, but one could see reason to add this to monsters). Overlays will be attached to a face in the map2 command, so a specific layer. From my reading, which could be wrong, it sounds like the server would have these composite images - thus, the server itself would have a lot more images, but really no change in the protocol is needed - the server would just know to use different faces and send those to the client, which would just display it. That's what I'm thinking about. Server has all images, and looks for correct animations. For a small number of combinations, that works pretty well. But if you start to have multiple things you may layer, the combinations multiply up pretty fast. For example, weapon + armor + aura could be hundreds of new images (say 5 weapons, 5 armors, and 5 auras = 125). These would all have to either be images in the arch directory tree, or created during the collect process. Err no, I see it as 5 weapons, 5 armors, and 5 auras. And they get stacked to produce the final picture. Regards Nicolas -- Mon p'tit coin du web - http://nicolas.weeger.org signature.asc Description: This is a digitally signed message part. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Face overlays
On 07/14/11 06:35 AM, Nicolas Weeger wrote: But is the client assembling these images, or have all these images been pre-assembled on the server (and thus, they are valid images)? That's one my questions, and something I'm asking other people for opinion :) Two options, server sends all needed faces at the same time (overlays to the player face) ; or server sends a special face the client knows to be a combination of faces. Ah - so it sounds like you are looking at one of these 2 possibilites: 1) Server sends all needed faces for the player - this means that for a player, it may have to send 4+ images for the player (aura, armor, weapon, base image) - of course, this could be higher. 2) Server generates a composite face, sends information on what that composite face is, and thus only needs to send 1 face in the protocol command, but it may end up sending a bunch of other information for to tell the server what that composite face is. My gut instinct is that #2 would actually be easier. For #1, I think it may require potentially more protocol changes (there may be issues with number of layers, so some extension for that, and the map send code would have to look at the object and see if that given object has overlays that need to get sent, look those up) - I'm just not sure how efficient that would be. In case #2, all the map logic is basically unchanged (note that some extra logic would be needed to send non layered face information for old clients) - the generation of the composite face can all be done when the player equips the items/does those actions. But I guess it really depends on how hard it is to check the layered faces for an object, or maybe additional structures are needed to hold those. I'm just thinking that in a more generic usage, one might want to use overlays for monsters (I'm thinking more for auras and not armor/equipment), so probably good to make sure a solution is chosen that works for everything, not just players. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Face overlays
My question here is does this means that each of those combos above (overlay_armour_fenx_player_sword, overlay_rage_fenx_player) correspond to a unique face/png image on the server? I see animations and overlays working like that: - player has a standard animation, fenx_player - each action (using skill or item) can have a temporary animation, like it is currently ; thus fenx_player_sword or fenx_player_spellcasting - each equippable item defines an overlay ; so armour would give the overlay_armour face on top of the player's face Of course, items can be specialized for player ; so overlay_armour could be overlay_armour_fenx_player_spellcasting for a specific spellcasting animation, or overlay_armour_fenx_player for the general armour. With fallback so not have to explicitely define everything. Or is there some level of trickiness going on with how the client assembles those faces? I see it merely as adding new pictures on top of the player's main face. Regards Nicolas -- Mon p'tit coin du web - http://nicolas.weeger.org signature.asc Description: This is a digitally signed message part. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Face overlays
On 07/13/11 01:25 PM, Nicolas Weeger wrote: My question here is does this means that each of those combos above (overlay_armour_fenx_player_sword, overlay_rage_fenx_player) correspond to a unique face/png image on the server? I see animations and overlays working like that: - player has a standard animation, fenx_player - each action (using skill or item) can have a temporary animation, like it is currently ; thus fenx_player_sword or fenx_player_spellcasting - each equippable item defines an overlay ; so armour would give the overlay_armour face on top of the player's face Of course, items can be specialized for player ; so overlay_armour could be overlay_armour_fenx_player_spellcasting for a specific spellcasting animation, or overlay_armour_fenx_player for the general armour. With fallback so not have to explicitely define everything. Or is there some level of trickiness going on with how the client assembles those faces? I see it merely as adding new pictures on top of the player's main face. But is the client assembling these images, or have all these images been pre-assembled on the server (and thus, they are valid images)? If the client is left to do this layering, then somehow, it needs to know what faces to layer for any given object (typically players, but one could see reason to add this to monsters). From my reading, which could be wrong, it sounds like the server would have these composite images - thus, the server itself would have a lot more images, but really no change in the protocol is needed - the server would just know to use different faces and send those to the client, which would just display it. For a small number of combinations, that works pretty well. But if you start to have multiple things you may layer, the combinations multiply up pretty fast. For example, weapon + armor + aura could be hundreds of new images (say 5 weapons, 5 armors, and 5 auras = 125). These would all have to either be images in the arch directory tree, or created during the collect process. I'd personally think that having the client do the layering would be much better - one could have the number of combinations be much larger without having issues (eg, 10 armors x 10 weapons x 10 auras x 50 monsters = 50,000 image combos). ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Face overlays
On 07/11/11 01:17 PM, Nicolas Weeger wrote: Hello. I've been thinking on how to show what equipment a player is actually using during the gameplay. My current idea is to add overlays on faces. It would work something like that: - base player animation doesn't show anything - the eg armour overlay is displayed on top of the player, to show the armour being worn - for compound animations (eg attacking, and thus), use the same overlay, or a specific overlay This could also be used to add effects for long-time spells, eg a red aura for protection from cold, and such. Examples: - base animation fenx_player - for armour, use overlay_armour_fenx_player if it exists, else overlay_armour for an armor with overlay_armour overlay specification - if the Fenx attacks, compound animation is fenx_player_sword, so use overlay_armour_fenx_player_sword if it exists - if the Fenx cast the rage, add overlay_rage_fenx_player if it exists, else overlay_rage simply This would of course mean many potential animations... And more face information sent to the client. My question here is does this means that each of those combos above (overlay_armour_fenx_player_sword, overlay_rage_fenx_player) correspond to a unique face/png image on the server? Or is there some level of trickiness going on with how the client assembles those faces? One other option I thought of is to use a dynamic face, in which server tells the client face (max_face + 2) is a combination of this, this and this face, use this special face for the map2 command, and inform client of face changes when the equipment changes. This of course adds some more complicated logic. Answer to the above question sort of determines that answer. Using a unique face (max face +2, +3, +4) probably isn't as hard as one might think - if that face is created (and assigned to the player) when the objects are equipped, most of the sending logic remains the same - the only additional logic would be to communicate what faces make up that unique face value. The method used to currently inform about animation sequences could be used, just with the addition to say 'this is a composite face, not an animation'. The one advantage I see with this approach is that a lot of the code can be re-used. For example, the elf equips a sword. The server sees if there is any animation stacking already created that matches - it finds there is none, so it creates elf_sword, and at the given time, sends it to the client. The elf then casts a protection spell, which adds an aura around the player. Once again, server checks, finds no such animation, and creates a new one (elf_sword_aura), which gets sent to the client. Now at some point, the spell expires, so now we are back to just elf_sword - server checks, it already has this, so it just updates the fact to that value, and is done. It would be the actual map sending code which would see if the client (which may not be the elf players client, but another players client) knows about that animation, and if not, would do the normal routine to send the animation information as well as information about the faces. Note that the animation names above are really used for illustrative purposes - I think when it comes time for the server to see if it is new or old animation, it would have to check the actual image numbers, and not go on name. The compositing of images probably becomes the harder case - in your example above for armor, this means you need different armor images that will properly overlay on the given race - for small and big ones, this probably does not work very well. For more generic things, like auras, size on those is not as important, so they probably work in all cases. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
