Re: XARCHON Data files

[hursh <hursh@infonet.isl.net>]

	If I understand you right, The theme should be 1 copy of each unique 
image, 1 (or more) file(s) describing how they should be used and avoid 
screwy file formats that will hide the data.  You like it where the 
theme is a group of flat files in a directory (or sub tree).  That 
sounds good to me, at least for now.  Eventually, I would lean toward 
allowing (but certainly now requiring) a theme to be packaged and used 
from a zip file.  (Tar is good too, but everybody uses zip for this sort 
of thing.  Why?)
	I'm thinking of a functionality in the Allegro library where you could 
setup a search path that could point at zip filea and/or directories. 
It's spiffy.  It would be nice to pack a theme into 1 usable file, but 
there are other priorities I think for now.  A zip file shouldn't be 
that big of a barrier for anyone capable of creating digital art.

Dan

Joerg Osarek wrote:

> Hello Ronen,
> 
> I have the following feedback about your suggestion to put everything into one
> datafile.
> My point of view is from a theme creators angle.
> 
> At the moment it is easy to create new themes because we use low level standards
> like
> XPM files that can be edited by hand or can be wonderfully manipulated by using
> NetPBM Tools (as I do).
> 
> My actual way of working  is: create an able-to-animate 3D file, render all the
> resulting
> images by script, convert them to xpm, make them transparent and reduce colours
> also by script and voila - there is the result.
> 
> Yes, one problem is the thing with symbolic links for double images. My opinion
> is
> that this way to slow down animation is not tat pretty clean because you never
> know how fast computers will be in 2 to 5 years. We have seen lots of good
> DOS games
> that are absolutely unplayable today if you don't have a CPU slowdown program (a
> time
> wasting program that consumes CPU time).
> 
> Therefore my suggestion is to do two things:
> 1) have every image only once. But have a config file in every image directory -
> or
> if you like that better - a central config file per theme where you can define
> how long
> each image of a certain character shall be displayed in milliseconds. The
> rendering
> machine of XARCHON would be responsible to guarantee the update to the next
> image to happen only after the defined time in milliseconds. This would ensure
> that XARCHON is playable in 10 years.
> 
> 2) Keep the file based structure for every image because it is an easy way for
> theme developers to create and test themes. The concept is simple and good.
> A theme developer should not have to program in C to submit a new theme.
> I think this would prevent people from doing work for XARCHON.
> The strength today is that XARCHON themes are based on open standards.
> If you do think the one-datafile-attempt is a good Idea it should at least
> be built that way that a theme developer can develop the way it is now and then
> for example call a script the programmers provide to "pack" the theme into one
> file.
> 
> What do you all think about my viewing angle?
> 
> regards
> Joerg Osarek
> 
> 
> Ronen Tzur wrote:
> 
> 
>>Hello everyone!
>>
>>I've been thinking a bit about the data files in xarchon.  Most notable is the
>>issue with symlinks:  the sprite loading routines can identify two or more
>>data items that are the same (one being a real file, the others being a
>>symlink to it).
>>
>>In the move to cvs, all the symlinks have disappeared.  Perhaps this can be
>>fixed, but I vote for one large data file containing all the data items,
>>instead.   It feels more clean, and might even speed up the initialization.
>>
>>I may be thinking a little too much ahead here, but it should also ease the
>>deployment of new themes.
>>
>>How does that sound?
>>
>