massiv-devel Mailing List for Massively multiplayer game middleware

----- Original Message -----
From: "Stepan Vondrak" <sv...@vo...>
To: <mas...@li...>
Sent: Thursday, February 14, 2002 11:42 PM
Subject: [Massiv-devel] updates


> Tak jsem provedl par zmen v CVS:
> -opravy aby to v linuxu chodilo
> -zmeny v buildovacim systemu
> Tak to ozkousejte a opravte pripadne chybky.

Pod msvc funguje ok.
Jinak ohledne stlportu - i kdyz se projekt linkuje debug (s msvcrtd.dll) tak
ten automaticky vyber dll stlportu vybere vzdy release (s msvcrt.dll) pokud
se mu nerekne definem jinak (_STLP_USE_DEBUG_LIB nebo _STLP_DEBUG). Jinak se
to klidne slinkuje soucasne s msvcrt.dll i msvcrtd.dll, coz se mozna muze
chovat divne.

Petr

Tak jsem provedl par zmen v CVS:
-opravy aby to v linuxu chodilo
-zmeny v buildovacim systemu

To druhe muze privodit nejake chybky ve win32, co ja vim. Zmeny:
-ALWAYS makro - zavisi na nem knihovny v jinych adresarich, aby se vzdy 
zkousely prebuildovat
-SDL,OpenGL,Crypto++ poradne (SDL a OpenGL vas snad zatim nemusi zajimat, ale 
me to i ve windozech chodi - to byl ale jiny projektik pouzivajici nahodou 
taky mkgen)
-Zmena knihoven - msvcrt misto libc. To by se melo asi nejdriv prodiskutovat, 
ale ted uz je pozde. Rozumi nekdo presnym rozdilum? Zda se mi, ze cely svet 
pouziva msvcrt a to s tim libc byl jenom ondrejuv vymysl jeste z dob Quarka. 
Zmena byla nutna pro kompatibilitu se SDL knihovnami.

Tak to ozkousejte a opravte pripadne chybky.

-- Stepan

Pro ty, kdoz vedi, o co tu bezi (p. Tuma), posilam par poznamek k
zalohovani.
Prosim o upresneni zalohovaciho algoritmu.

1) rozsirovani kodu

>
> Rozsirovani kodu za "uplneho" behu zatim nevidim realne. Moje predstava
> vzdycky byla:
> -save (zaloha) vsude
> -reload game libs (natahat nove)
> -load ze zalohy (pripadne nejak magicky transformovane)
> Coz znamena pauzu po dobu loadovani ze zalohy. +problemy s tim, jak udrzet
> spravne napojeni klientu na objekty reprezentujici hrace apod.
>
> IMHO by ani nic vic nemelo byt nutne, updaty herniho kodu v C++ by se mely
> dit minimalne (teda pokud si predstavime, ze "hra" je v stadiu jako dejme
> tomu ultima online a uz se jenom rozsiruje svet, pridavaji nove dungeony,
> modifikuji vlastnosti existujicich priser, ceny veci, atd. - to by melo
jit
> beze zmen zdrojaku).
>

2) zalohovani

> Jestli to spravne chapu, na serveru _i_ to ma probihat takto:
> 1. _i_ vyrobi vektor v[i] a zacne slozky v[i][j] posilat serverum v[j].
> _i_ zacne vsechny svoje objekty stinovat (*).
> 2. _i_ ceka, az ode vsech _j_ dostane v[j][i] a objekty do casu v[j][i]
jemu
> zaslane (prijde mi, ze nejlepsi by bylo poslat u prvniho objektu novejsiho
> nez v[j][i] oznaceni "tendle uz nearchivuje _i_, ale _j_"; preposilat ten
cas
> pres nekoho tretiho je nebezpecne, pokud jsem teda neminul zakladni
myslenku
> algoritmu). Tyto objekty "vzniknou" v podobe oznacene "k archivaci", tedy
pri
> modifikaci se udela jejich stin.
> 3. Pokud serveru _i_ prijde uz moc novy objekt (tj. od nejakeho _j_
novejsi
> nez v[j][i]), uz nebude oznacen "k archivaci". Pripadne se asi muze zacit
> stinovat az ted misto (*).
> 4. Az dorazi od vsech serveru _j_ vsechny objekty s casem <=v[j][i], _i_
> zacne zalohu ukladat. To asi lze ruzne modifikovat:
> -lze zacit ukladat uz po startu stinovani (budto v 1. nebo v 3.)
> -podminka spis "az dorazi od kazdeho _j_ tag 'todle uz patri _j_ a
nearchivuj
> to'", viz 2.
>
> To uz by asi mohlo fungovat a dela to vice-mene skoro totez co vymyslel
> boovie.

-- Markoid

Nazdar,

(1) pointery
========

tak jsme se rozhodli po zrale uvaze zrusit saskarny ohledne ClassComponents.
K cemu tam vlastne dosud byly?
Cilem bylo dat moznost programatorum "skriptu" udelat ObjectPointer na
jakoukoliv "cast"
objektu. Takze treba kdyz se provede oblastni dotaz, dostane se neco jako

 ObjectPointer<Object> // Object == ScriptObject

a ty chces mit moznost napsat neco jako;

 if( ptr->inherits( MONSTER_CLASS_ID ) ) {
   ObjectPointer<Monster> mp = ptr;
 }

Tady by teda melo stacit, ze se zna ukazatel typu Object * na ptr a z nej se
pomoci "dynamic_cast<Monster *>" ten ukazatel ziska - tendle dynamic_cast
funguje zarucene, ale jen pokud je Monster v hierarchii jednou. V pripade,
ze
se vyskytuje vicekrat, musi byt nejak upresnen (napr. pomoci pretypovani
na sveho potomka a z nej pak jiz jednoznacne na Monster *).

Cilem ClassComponents bylo jednoznacne identifikovat "komponentu" objektu
a odlisovat tak vicenasobne vyskyty stejne zakladove tridy (Monster).
Pointer na Monster tak byl doplnen o informaci, jakou komponentu prave
pozadujeme.
Podobne pri pretypovavani objektu se krome ciloveho typu urcovala i cilova
komponenta.
Bohuzel vsak takove pouziti bylo celkem tezkopadne.

Nyni jsme se rozhodli tyhle veci prepracovat:

1) doporucujeme vyhnout se hierarchiim, kde by se najaka zakladova trida
vyskytovala vicekrat
    (stejne to je blbost) - ale nezakazujeme to
2) pokud se dodrzi 1), podobjekt je jednoznacne identifikovat pomoci sveho
Type *
    a vsechno funguje samo a bez problemu
3) v pripade, ze programator potrebuje ziskat pointer na Type, ktere ale
nebude urceno
    jednoznacne, doplni svuj pointer o informaci, jakym zpusobem se k Type
dostane
    z Object *
    (pretypovani Object * -> pozadovany Type *)

template <class Type>
class Cast
    {
    static Type * do_cast( Object * ptr )
            {
            return dynamic_cast<Type *>( ptr );
            }
    };

template < class Type, class C = Cast<Type> >
class ObjectPointer
    {
    Type * get_pointer()
            {
            return C::do_cast( ptr );
            }
    };

// Cast objekt popisuje, jak se pretypuje z Object * na Type *;
// v pripade potreby muze programator zadefinovat svoje "C" a upresnit tak
svuj ObjectPointer

(2) object factories
=============

Budou nadale generovany skriptem, namisto templatized kodu, cimz se zbavime
nutnosti
starat se o dynamicke registrovani properties, member objectu, zakladovych
trid apod.

Replikacni kod bude rovnez generovan.

-- Markoid