Crossfire Mailing List Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Porting CF to Amiga, help needed.



Hello all you crossfire freaks!!

This is a general posting about the Amiga-port of CrossFire.
If you don't own an Amiga, but like to see CF on your system,
I could supply you with some ideas too; just read the 3 parts
of this message. The 4th it about some limitations one has on low-end
machines, and the way I handled them. (space for improvement!!)

If you feel like helping me, PLEASE send a message with some information
about _what exactly_ you'd like to help me with.
Any other reply is welcome too.

Below, I will discuss some topics:
1 - changes I made to the structures, so the game speeds up (drasticly)
2 - ideas for the game (not Amiga-related)
3 - potential of CF (is the base strong enough to hold the development??)
4 - problems I encountered (solved and unsolved) HELP!

(Note: I base all my knowledge of the game on CF 0.88.5 and my own port.)
(Yes, I know 0.89.2 is the youngest version, I hope it doesn't differ much.)


1. Speeding up crossfire

It's a fact that when you port CrossFire 1:1 to another system (which
is inferior to SUN/HP etc) it will _CRAWL_.
Thus, one of the most important parts of porting CF to lesser machines is 
speeding it up.  Porting CF, I changed two of things:
- put all ANIMATING & ALIVE in a separate 'map->alive' list
- put all HANDLES & BUTTONS in a seperatre 'map->buttons' list
This made the turns handled more quickly, because:
- ANIMATING & ALIVE objects didn't have to be searched every turn
- HANDLES  & BUTTONS don't need to search the whole map for DOORS etc
Some other speedups are discussed in chapter 4.


2. Ideas

I have some ideas about some more flags:
-for shop-floors:
 make a flag 'DROP_APPLY' which reacts to an object dropped on it.
 It can be used not only for shop-floors, but also for a back-office
 (change gold into local currency).
-for local-currency:
 IS_MONEY which indentifies something as money (nice touch he?!)


3. Potential of CF

The game is growing steadily, my question is if it can uphold it's
growth??? Things related to this might be:
- changeing the graphics (step to 3D textures a-la UW2 on MS-DOS)
- intelligent characters who interact with you

I don't think the graphics will change in the near future, but still,
If it happens, will the main part of the game stay the same???
I don't think so... Think about the current map-structure;
it consists of a 2d-array of object-stacks. If the graphics change to
(for example) a 3d world (maybe one day everybody can afford a head-set!),
the stacks are not effectie anymore, and there should be thought about....

The idea posted 2 weeks ago about a script-language can have enough
power to achive NPS which can interact. Some commands I'd like to see are:
- 'object = Find_Arch_in_Stack ([archetype],[amount])' : which let
   Characters react at things given to them.
- 'if(result) { commands() } else { commands() }' : obvious reasons...
- 'result = Pickup_Object([object])' : let NPC's pickup
- 'result = Heard([string])' : give 'em ears
- 'Say([string], [loudness]) : and and adjustable mouth


4. Problems

The main problem is speed. It is drained by routines like
'remove_ob', 'check_apply' and others called often..
I reducted a lot of overhead in 'remove_ob', but other routines
need to be changed yet.. This is the point where I could use some
help. If you are interested, mail me, I have an archive with my
code, and another one with the data needed.


That's it (sore fingers by now!)

slash U l8r

   //| Patrick van Logchem; stud. Computer Science, The Hague, The Netherlands.
  //_| EMail: v912152@si.hhs.nl   School-system: Sun SparcStation 10 w/ X11.
\//  |miga-owner (std. A1200HD).  Main interests: fast gfx[2d|3d|vector|grid].