Crossfire Mailing List Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Ideas for speeding up
>
>
> > Well, coding the AMIGA-port of Crossfire, I had a nice time finding any
> > speed-ups and here is what I found (contributions are welcome) :
>
> > - Place all gates and handles in 'object *map->gates'.
> > This results in far faster handling of handles/buttons, because only
> > map->gates has to be checked for corresponding gates (not the whole map!)
>
> Yes, I think this was even TODO list.
>
> > - put all ALIVE, MONSTER and ANIMATE objects in 'object *map->alive'.
> > This way we only parse the needed stuff, not all the passive treasure,
> > handles, food, etc...
> > (This REALLY speed up the amiga-version!)
>
> This is probably even more efficiently, when all walls are changed
> objects.
Walls are no objects, they are just an FontIndex (swapped int)
in the map->omap struct.
>
> > - Place more data in the archtype.
> > Not for the speed, but more for the memory-usage.
>
> I'm not quite sure, if this is good idea generally. I would like in
> future versions see more 'individual' objects, so players can't
> assume that when you have seen one goblin, you have seen them all.
> Maybe these special items could be implemented some other way, but
> currently it seems easieast way just add editor support allowing edit
> objects. Another way save memory could be try organize object struct
IMHO, it is better to enlarge the archetype struct, because stronger
goblin's (or whatever) can be made in the archetype-file (just create
another monster (ex: gobling_strong) with the same graphics, but better
hp, dam, etc..)
> better (hp have meaning only monsters), but this probably won't help
> much, since those variables are already used other meanings too.
> unions might help or good documentation and few defines (crossfire.doc
> is good, but even it misses special meanings some variables)
>
> I'm not tried compile crossfire in Amiga, so I don't know how
I didn't -patch- crossfire for the amiga, I REWROTE it.
> important it to reduce memory usage. True problem might be size of
> maps, since crossfire keeps only currents maps in memory.
Yep, you're right, maps are _BIG_. The only way to reduce memory usage, is
to reduce the size of an object. (a map almost totally consists of objects)
That is done, as I already said, by moveing data to the archetype. Which
is used via a pointer > only 4 bytes (+ sizeof(archetype) ) covering
a lot of data.
>
> One thing which might speedup loading and saving maps is binary files,
> but I'm not sure if it's a good idea has two different map formats.
> Original maps should still be in text format, since it much more
> portable and easier read. If I remember right, most time in loading
> is used parsing mapfiles, which would not be problem with binary files.
>
Well, this is not a bad idea, but who wants to develop a file-format???? :?
> These were only my opinions,
>
> - Tero
>
Thanx, patrick van logchem (v912152@si.hhs.nl)