[Kryonet] Serializing and transmitting a JOGL Texture object over Kryonet

Networking & Multiplayer
#1

Posted in JOGL Devleopment as well.

We are currently implementing Kryo. When trying to serialize things across the network, we would like to find the best way to send JOGL Texture object. Since this object isn’t serializable by Kryonet, we can’t send it with our Image wrapper. Is there a way to deconstruct/reconstruct the Image Data from the JOGL Texture object, in a form that we can serialize (i.e. a class or data structure that ends up just holding primitives)? Instinct tells me there must be some way to get the raw pixel data from a Texture and rebuild the Texture using TextureIO, but I’m not sure.

#2

If you have access to the TextureData used to create the Texture, then you can call getBuffer() on the TextureData to get at the primitive data in an nio buffer. Looking through the API, it doesn’t appear as though Texture has any way by itself to get the data, this is likely so that it’s possible to store the data only on the GPU or use an FBO where there is no data in CPU memory.

However, I have to ask why do you need to send textures across the network? That seems like a lot of overhead. Wouldn’t everyone playing have the same assets installed locally? If you have dynamic texture modifications, I feel like it would be more efficient to sent the operations on the texture over the network and have everyone compute them locally.

#3

Interesting, so only send the changes. We can look into this option. From valve’s wiki:

Detect changes in the server-side object
Serialize (transform into a bit-stream) the changes
Send the bit-stream as a network packet
Unserialize the data on the client and update the corresponding client-side object.

It sounds like this is what you’re saying; essentially the Image and Texture objects are already constructed/loaded clientside. Our job is just to let the client know whether anything about the image has changed, rather than outright overwriting the object with an unpacked copy from the server.

#4

Exactly, and images are fairly large objects that, unless you’re doing fancy destruction or world manipulation are unlikely to change in the course of a game. I think the wiki is likely referring to changes in the state such as position, health, or equipment for objects in the game.

#5

Why are you sending a texture in the first place? Either have it on each client from the start, or if it’s computed, just send a seed or whatever data you need to reconstruct it on the client too.

#6

To be clear we aren’t sending the Texture, that’s the point of making it transient. We’ve decided to just re-obtain it the same way we would when building a new Image object, using the reference string, which is enough. Needed Textures are loaded into memory when the level is loaded, so they exist on the client, it’s just a matter of getting them.

#7

As everyone has already pointed out, it is probably better just to have the textures preloaded by the clients and send the reference from the server.

However if you encounter another object that you need to send with kryonet but can’t serialize it try this:

Have the object implement Serializable

Then when you register the object with Kryonet try:

kryo.register(nameofyourobject.class, new SerializableSerializer()); // this will cause it to be seralized (inefficiently) by Java's built-in serialization

You can also try:
You will need to create an empty constructor in your object for the serializer to use.


public nameofyourobject(){} //put this in your object to be serialized
----
//Put the following where you register your classes with kryo
FieldSerializer ObjectSerializer = new FieldSerializer(kryo, nameofyourobject.class); //kryo is your kryonet object
ObjectSerializer.setCanBeNull(true); //optional - set if some of the object's parameters might be null
kryo.register(nameofyourobject.class, ObjectSerializer);

If your object has non-primitive parameters you may need to create a fieldserializer for each of these datatypes as well. This method will be much more efficient than the first since it uses Kryo’s serializer.

#8

Such an old thread! Why revive it?!

#9

Sorry new to the forum, not really sure how active it is and therefore what constitutes “old”

Also, it doesn’t just help the original poster but anyone else who is searching the web with a similar problem.

#10

Well thanks for your contribution :slight_smile: