Re: [Algorithms] Complexity of new hardware

[Adrian B. <ad...@gm...>]

If you can break off a script by diffing two sets of type metadata is
that hard coded?  It would be unnecessary maintenance work, unless you
want to be able to change your data and can't do it within your
framework :P.  Maybe there's a way I haven't thought of.  Every time I
look at C# serialization, I've come up with a number of things I
wouldn't be able to do very easily (rename B, break A into 2 pieces,
etc.).

I certainly hadn't thought about it from a middleware perspective, but
all middleware needs a data upgrade path between versions.  Otherwise
you get stuck in time and become another point in favor of rolling
one's own tech.

Unless I'm missing something, you can't strip off all the class/type
information unless all your data is in the final format.  At that
point, you've solved your upgrade problem.  Linearly allocating
_definitely_ helps.  For some, though, even running simple
serialization code may not be fast enough.

Cheers,
Adrian

On Sun, Apr 19, 2009 at 3:53 PM, Jarkko Lempiainen <al...@gm...> wrote:
> Hand coding data coversion just sounds awful lot of unnecessary maintenance
> work which I rather avoid when constantly adding/removing variables to/from
> classes. Batch processing data for data conversion code clean-up also
> assumes you got all the old data available for processing, which may cause
> problems particularly if you are a middleware developer.
>
> For improving loading performance and reducing data size I can strip off all
> the type information data for final build, in which case loading becomes
> straight forward linear data streaming.
>
>
> Cheers, Jarkko
>
>
> -----Original Message-----
> From: Adrian Bentley [mailto:ad...@gm...]
> Sent: Monday, April 20, 2009 12:30 AM
> To: Game Development Algorithms
> Subject: Re: [Algorithms] Complexity of new hardware
>
> Hand coding incremental conversions is really easy.  Seems to me the
> problem is how to flush out old versions so you don't end up with a
> rats nest of compatibility code.  Fortunately, it's only a matter of
> writing other code :).
>
> Combining an easily editable source format (e.g. text) for your assets
> with a translation application allows these sorts of rebuilds easily.
> Layering incremental versioning on top is not hard.  There are
> certainly trade offs: mergeability, better abstraction in some cases,
> more code, more time to get to preview, etc.
>
> Or, if you want to keep your source in a compiled format, providing
> some form of mass translation mechanism should work.  E.g.
> snapshotting version changes into a file which can be run across all
> assets.  I haven't done this personally, and it comes with a different
> sort of baggage, but seems doable all the same.
>
> Pick your poison, but there are alternatives to brain dead simple
> serialization that have better long term usability.  Also, unless you
> have a baking step (hello translation), it feels like this would be
> important for loading performance anyways.
>
> Cheers,
> Adrian
>
> On Sun, Apr 19, 2009 at 3:17 AM, Jarkko Lempiainen <al...@gm...>
> wrote:
>> Otherwise you would have to hand-code the conversion which
>> could get quite a taunting task.
>
> ----------------------------------------------------------------------------
> --
> Stay on top of everything new and different, both inside and
> around Java (TM) technology - register by April 22, and save
> $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
> 300 plus technical and hands-on sessions. Register today.
> Use priority code J9JMT32. http://p.sf.net/sfu/p
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list
>
>
> ------------------------------------------------------------------------------
> Stay on top of everything new and different, both inside and
> around Java (TM) technology - register by April 22, and save
> $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
> 300 plus technical and hands-on sessions. Register today.
> Use priority code J9JMT32. http://p.sf.net/sfu/p
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list
>