Re: God sommer!

[Anders Reggestad <andersr@pvv.ntnu.no>]

On Thu, 10 Jun 1999, Mathias Mølster Lidal wrote:

> Eg har tenkt å begynne ein av dei næraste dagane (Når eg får sett i gang
> maskina mi).  I første omgang har eg planar om å læra meg Open-GL
Mye kule greier på http://www.opengl.org/Coding/Coding.html Bli også en
spesialist på vertex lists. Dette er noe jeg ikke har brukt men som mange
andre bruker!
> skikkeleg, så får me sjå kva det blir til..  Forslaget til rendering (Å
> traversera grafen tre ganger) høyrest fornuftig ut.  Ei avklaring av
> grensesnittet mellom dei forskjellige delane av klienten bør me heilt
> klart gennomføra, spesielt mellom core client code og resten.  GUI-koden
> blir vel den minste delen, og kan vel til ei viss grad integrerast med
> render-koden.
 
Nei! Det kan bli ønsklig å støtte flere rendere med samme GUI! Ta f.eks
win som både DirectX 3D og openGL er aktuelle rendere. Hvis noen skulle
ønske å porte til mac så har den også openGL og en til! Dessuten på pc så
kommer det stadig kort som en kan få bedre ytelse ved å skrive dedikerte
rendrere. Så jeg tror at en kommer best ut av situasjonen hvis en deler
clienten i 3 vel definerte deler:

1. Core client code
=====================
* Nettverkskommunikasjon med serverene. 
* Bygger/holder styr på det lokale verdenstreet.
* Utfører animasjoner i verdenstreet.

2. Client GUI
=====================
* Viser hovedvindu/fullscreen
* Viser menyer
* Konvertering mellom userinput og logiske kommandoer som sendes
  til core client.
* Velge rendrer

3. Client rendere
=====================
* Viser verden på et gitt område av skjermen.


Forslag til interface for renderen:

class CRender : public CObject {
  CWorldWorld * m_world;
public:
  CRender(CWorldWorld * world);
  virtual ~CRender();

  virtual void initialize();
  virtual void draw();
  virtual void resize(int cx,int cy);

  // Option handling (Har ikke helt peiling på hvordan dette bør gjøres,
  // tree muligheter)
  // 1.
  virtual void option(char * name,double doublevalue);
  virtual void option(char * name,int int value);
  // etc. for de typene vi trenger

  // 2. Spesifikke funksjoner for hver option
  virtual void setGama(double gama);
  virtual void textureCorrection(BOOL texCorrect);
  // etc. men dette betyr at for mange rendere vil kansje ikke
  // alle disse funksjonen gi noe mening!

  // 3. Ingen slike funksjoner men spesifikke funksjoner i alle som 
  // arver fra denne så må det når det skal settes options avgjøres 
  // hvilken render som brukes for så å typecastes.
  // if (strcmp(render.getName(),"openGL")==0)
  //   ((CRenderGL)render)->setGama(gamaValue);

};

Hvilken av disse tre som er best må avgjøres fra hvordan en ønsker å gjøre
det i GUI delen. Tenker nå på slike option panel som en f.eks har i Quake. 

Vi har litt mindre frihet når det gjelder core client code. Dette da
dagens kommunikasjon allerede legger en del begrensninger. Dvs. vi må ha
en mekansime som sier fra når det er noe å lese på de froskjellige
socketene som clienten har åpnet. Dessuten så trengs en timer for å gjøre
animasjoner.

class CClientCore {

public
  CClientCore();
  virtual ~CClientCore();

  virtual void animate(double time);

  // virtual void some_thing_on_some_socket ???? Har ikke peiling på
  // hvordan dette skal være. Må forske litt på hvordan kommunikasjonene
  // funker. Dessuten så snakket steinerh om noe omskriving av CTimeKeeper
  // som brukes i serverne. Kansje vi kunne få denne til å være kompatibel
  // med clienten også. 

  // Hva vi trenger av userCommand funksjoner er ukjent??  
  virtual void userCommand(WORD command);
  virtual void userCommand(WORD command,char * msg);
  // etc.

};

Da er det GUI delen igjen. Hva denne skal være har jeg ikke tenkt noe på!
Det kan hende at den bare er hovedprogramemt med mye dill rundt! Tror ikke
den kan generalliseres ned til en classe som så enkelt kan startes fra
main. Dessuten så må det et eller annet sted nødvendigvis bli noe os
spesifikk code! Kan denne deles ut i egen modul? Hva med et lyd system?
Dessuten så har ikke strukturen over løst problemet med at det kan være
spesielle ting som er GUI/Render avhengig. Dette kan løses med at en GUI
classe gis som argument til renderen slik at denne kan kalle de GUI
spesifikke delene fra de enkelte GUIene.

Mye å tenke på her og det er ikke sikkert vi kan greie å tenke ut alt før
vi sitter å koder de enkelte bitene. Har du kommet frem til en GUI du
ønske å bruke for den første test versjonen av denne nye strukturen?

 -Anders
 ----------------------------------------------------------------------
|    ******   Anders Reggestad                                         |
|  *   *   *  Mobil tlf.   : 95044443                                  |
| *    *   *  E-Mail       : andersr@pvv.ntnu.no                       |
| *********   Post adresse : Haug Prestegård 3300 Hokksund             |
| *    *   *  Jobb adresse : FFI avdeling for Undervannsforsvar Horten |
| *    *    * Hjemmeside   : http://www.pvv.ntnu.no/~andersr           |
 ----------------------------------------------------------------------