[quote]Okay, maybe I am misunderstanding you.
Are you telling me you have done nothing to the encoding and onlymodified the decoiding logic?
What happens if the existing object is not of the right version? How are you dealign with mismatched SerialVersionUIDs ??
[/quote]
Jeff, you’ve got to read the code I posted. The whole SS process has nothing to do with regular Serialization. I borrow none of their code and I use none of their classes. Indeed, I tried, but its all locked up in private methods and fields. There are no SUID codes or anything. To see how it works, just look at my code, its very short and simple.
Thanks. I’ve heard it being called ‘Agile’ programming - since you can change your game objects as you go without having to modify your communication mechanism. The default write and readSS methods of those game objects implementing SSObject (or extending SSAdapter) allow for this since the fields they write aren’t hard-coded. This method allows you to run your game over the network before you’ve fully built it (or even planned how it will work >> lowers design time and costs). The SS streams are good because after you’ve settled on a final design, you can make the process a lot more efficient by over-riding the default write and reads methods (this avoids the default methods’ Reflection API calls to get and set the fields).
[quote]Not so much “for a special purpose” as “not intended to be a high-performance system”. I’d say it’s a poor implementation done in minimal time and effort just enough to provide a basic service (nothing wrong with that - efficient use of development resources).It’s not like the optimised Math.* methods, it’s more like autoboxing - it provides the functionality at bare-bones performance. If you want better, pay for it or do it yourself.
[/quote]
The SS streams may not be quite as quick as custom byte packets, but the SS process is as simple, quick and elegant as possible while staying flexible and general (as far as I can limitedly see) . I must repeat that the SS streams have nothing to do with regular Serialization, they extend the DataIn/OutputStreams, just the ones your custom binary packets would have been constructed from.
[quote]In modern VMs pooling generally is a net-loss v. the eden space with regards to short-lived obejcts,.
So I think you are likely creating yourself problems here ratehr then solving them.
[/quote]
I have to pool the objects so they can be recycled, or else we will create new ones just like regular Serialization >> wasteful constructors and GC problems.
[quote]As I said before, if you find a need to pool arboitrary objects then you are holding onto short lived obejcst too long. Which means you need to revist your app architecture.
[/quote]
The objects that are deserialized need to be held onto at least until they are fully painted to the screen, which is probably long enough to be pushed into the VM’s retirement-home space. This needs to happen for any dumb-client architecture so it’s unavoidable and that’s why normal Serialization is unsuitable (as well as the more important disappearing references problem).
I’m about to try to get the clients in my game to think for themselves - ie run their own game world so GC problems and graphical smoothness can be taken care of by the client on its own. I’ll try to use the SS streams, if they are suited, to coordinate the server’s game world with that of the clients, and I’ll let you know how it goes.
If any more insightful people like yourselves could look at the code and suggest any improvements that can boost performance or functionality - I’d love to hear it.