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)