11-04-2010, 05:19 PM
I woke up this morning and thought of a better way to handle login packets and
what not. I'll see if I can do that this weekend.
Right now, land is cached in memory on the silverlight client. Every tile of land is
cached in memory on the server with the x/y/height/byte[] for artwork
(compressed to Png). On load, the client asks the server for all of the map
EXCEPT the artwork bytes... so basically I have a collection of map tiles without
art which is a pretty small request. As you move around, it's looking a few
screens out and finding if it needs to request any new artwork from the server
and updating the local artwork cache as needed.
I'm trying to think of a better way to handle art distribution. If I host the
service inside RunUO, I might be able to use a duplex service for new art and
instead of polling a regular service, pump the artwork into a response queue
OnMovement in RunUO. Did that make sense? Instead of making a new
request on client movement, cache the StaticId's of what's been sent to each
client on the server and only serve back what's needed when it's needed
without the client having explicitly ask each client movement.
I'm still debating if I want to run the artwork service as a self-hosted WCF
service in RunUO (because then I can extend the client to communicate in
more ways than just art) or if I want it to be hosted in IIS. I'm leaning toward
RunUO, but that would require a core modification for any server that wants
to enable use of the silverlight client.
It should also be noted that not having artwork from the server doesn't
affect the clients ability to interact/move... hooray for silverlight and not letting
me lock the UI thread! It knows all of the technical information about the tiles,
just not what the tiles "look" like ;p
Also... I have Team Foundation Server 2010 installed on my server... not
using it yet though. I'd put it on codeplex, but I don't want this open source.
Another Note: I have no idea how I'm going to do lighting without OpenGL
or DirectX. WriteableBitmap can probably handle it, but I kinda suck with numbers
what not. I'll see if I can do that this weekend.
Right now, land is cached in memory on the silverlight client. Every tile of land is
cached in memory on the server with the x/y/height/byte[] for artwork
(compressed to Png). On load, the client asks the server for all of the map
EXCEPT the artwork bytes... so basically I have a collection of map tiles without
art which is a pretty small request. As you move around, it's looking a few
screens out and finding if it needs to request any new artwork from the server
and updating the local artwork cache as needed.
I'm trying to think of a better way to handle art distribution. If I host the
service inside RunUO, I might be able to use a duplex service for new art and
instead of polling a regular service, pump the artwork into a response queue
OnMovement in RunUO. Did that make sense? Instead of making a new
request on client movement, cache the StaticId's of what's been sent to each
client on the server and only serve back what's needed when it's needed
without the client having explicitly ask each client movement.
I'm still debating if I want to run the artwork service as a self-hosted WCF
service in RunUO (because then I can extend the client to communicate in
more ways than just art) or if I want it to be hosted in IIS. I'm leaning toward
RunUO, but that would require a core modification for any server that wants
to enable use of the silverlight client.
It should also be noted that not having artwork from the server doesn't
affect the clients ability to interact/move... hooray for silverlight and not letting
me lock the UI thread! It knows all of the technical information about the tiles,
just not what the tiles "look" like ;p
Also... I have Team Foundation Server 2010 installed on my server... not
using it yet though. I'd put it on codeplex, but I don't want this open source.
Another Note: I have no idea how I'm going to do lighting without OpenGL
or DirectX. WriteableBitmap can probably handle it, but I kinda suck with numbers