dlab-developer — The connection between teacher and students

[Dlab-devel] =?iso-8859-1?Q?config.h?=

[<ma...@io...>]

R2VudGUgaG8gaW5pemlhdG8gYSByYWdncnVwcGFyZSBpIGRlZmluZSBjaGUgc2Vydm9ubyBw
ZXIgc2V0dGFyZSBsZSANCm9wemlvbmkgZGkgZ2lvY28gc3UgQ09ORklHLkgNCkFuY29yYSBu
b24gaG8gdG9sdG8gbmllbnRlIGFnbGkgYWx0cmkgZmlsZXMgbmUgYWdnaXVudG8gbnVsbGEN
Ck5vbiDoIG5lbW1lbm8gbGlua2F0byBuZWwgbWFrZQ0KVmkgdm9sZXZvIGRpcmUgY2hlIGRh
IG9yYSBkb3ZldGUgbWV0dGVyZSBs7CBkZW50cm8gaSBkZWZpbmUgY29uIGxlIA0KdmFyaWFi
aWxpIGRpIGdpb2NvIHNlZ3VlbmRvIGxhIGxvZ2ljYSBkZWwgZmlsZSBjaGUgaG8gZmF0dG8g
aW8NCmUgc2NyaXZlbmRvIElOQ0xVREUgY29uZmlnLmggbmVsIGZpbGUuYyBjaGUgZmF0ZSB2
b2kNCg0KRScgYXR0dWFsbWVudGUgaW4gbGF2b3JhemlvbmUgcmlwZXRvDQpjaWFv

[Dlab-devel] zZzzzZzzzzzZzzzZip Implementato

[Duca <sen...@gm...>]

A dire il vero zip non =E8 ancora finita, =E8 diciamo ad uno stadio beta
che puo essere utilizzato, volevo includere nel file zip l'elenco
dei file con le propriet=E0 con dodice xml, immaginavo una struttura del =
tipo
<gfx:list>
 <gfx:item alpha=3D23 ...>media/graphics/asteroid_xl.png</gfx:item>
...
..

In memoria l'affare si presenterebbe cos=EC:
var x:^array of ^info;

info =3D record
 nome : String;
 nfo  : Pointer;
end;

dove nfo verr=E0 interpretato in un certo modo da Gfx e da un'altro in Sf=
x

In questo modo chi deve aggiungere qualcusa a Gfx non fa altro che modifi=
care il file=20
"contenuto" nello zip
(o cmq un file sull'hard disk) e l'enum di Gfx.h

Inoltre l'elenco dei file come appare su Gfx.c deve essere eliminato xch=E8=
 non serve=20
+.

Credo invece sia necessario specificare completamente il path xch=E8 sia =
Gfx che Sfx=20
accedono allo zip, se questo
non  =E8 vero si pu=F2 sempre ritornare alla versione precedente

[Dlab-devel] =?iso-8859-1?Q?Forse=20ci=20sono=20quasi=20arrivato=2E?=

[<sou...@ti...>]

Ho notato che in molti giochi multiplayer in tempo reale, utilizzano il
tempo del gioco (nel nostro caso il g->game_time), per calcolare la quant=
ita'
di informazioni massime trasmissibili.
Per fare un esempio starcraft utilizza un tempo di circa 1/4 di secondo
come unita di tempo nel gioco(in realta 1/4 e' il massimo si puo giocare
anche con una latenza di 2 3 secondi), il che pensandoci bene nn farebbe
male nemmeno a noi se avessimo un tempo fisso e nn variabile per eseguire=

le varie azioni del sistema.
Cosi ci semplificheremo di molto ogni quanto tempo mandare e ricevere i
nostri pacchetti.
Abbiamo detto di costruire un server/client che manda le informazioni a
tutti e tutti le mandano a lui.
L'idea nn e' brutta ma risulta scomoda con la storia chiamata colli di bo=
ttiglia.
Supponiamo che la mia idea venga accettata e che si riesca a fare in modo=

che ogni ciclo completo di gioco si sviluppi SEMPRE al di sotto di questo=

tempo,
facendo qualche calcolo qua e la si arriva  a supporre che noi mandiamo,
con un modem 56k (4,7k/s di dl e 1,2k/s ul se nn ricordo male), circa 300=

bit di informazioni,
il che si arriva a supporre che il server possa al massimo mandare 300 bi=
t
di informazioni ogni ciclo di gioco.
Fare una ricerca di un server che lagga di meno potrebbe essere in teoria=

utile ma se tutti laggano nella stessa maniera nn si risolve un granche'.=

Ora supponiamo invece che creiamo un server VOLATILE ^_^.
Il gioco cambia, perche' ora una macchina nn deve per forza mandare a tut=
ti,
ma deve solamente scrivere su se stessa o su un altra macchina le varie
azioni eseguite nel gioco, gli altri fanno la stessa cosa scrivono li e
leggono li.
Quindi i passi dovrebbero essere.
Ogni macchina manda le proprie informazioni sul server volatile, alla fin=
e
del ciclo di gioco (1/4 di sec), legge tutte le informazioni sul server
volatile (comprese quelle degli altri giocatori), e visualizza cosa e' su=
ccesso
e cosi' via.
Tecnicamente nn ci ho ancora pensato a quanto sia difficile da realizzare=
,
ma a parer mio mi sembra un ottima idea ^_^.
Ora risolto il problema della latenza, c'era il problema di "chi aveva fa=
tto
cosa prima di chi" dico c'era perche' con questo sistema il primo che arr=
iva
meglio alloggia
se il giocatore A con il suo laser spacca un asteroide e anche il giocato=
re
B lo spacca, B(piu' lento) trovera nell'area dedicata per il controllo di=

chi a distrutto un asteroide gia scritto da A, e quindi nn va a sovrascri=
vere.
Immagino che il tutto sia un bel po' incasinato da capire, ma nn importa
^_^.

Alex message.



__________________________________________________________________
TuttoTISCALI e' il tuo nuovo contratto di telefonia!
Chiami in tutta Italia, giorno e notte, al prezzo di un'urbana
Ti colleghi ad Internet e spendi meno di un'urbana
http://point.tiscali.it/tuttotiscali/webmail.html

[Dlab-devel] DARPA

[Bernardo I. <be...@de...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Vi ricordate quando vi ho raccontato in classe che l'attuale
Internet ed il TCP/IP furono sviluppati dal DARPA durante la
guerra fredda per ragioni militari?

 Ecco, ho scoperto ora che il progetto e' ancora vivo e
sembra che stiano facendo cose da fantascienza:

  http://science.slashdot.org/science/02/05/29/239228.shtml?tid=126

 Non vedo l'ora!

- ----------------------------------------------------------------------
Try our multiplatform arcade classic: http://www.sf.net/projects/dlab/
- ----------------------------------------------------------------------

  // Bernardo Innocenti - Develer S.r.l., R&D dept.
\X/  http://www.develer.com/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE89YF7ltU4TfxqZsoRAifjAJ9/s8f3igmP5T3fEkE2s2XPlvxgwgCdHrAw
SC0YEoeuOuBWRUaY+4cHLqo=
=/dbx
-----END PGP SIGNATURE-----

[Dlab-devel] zZzzzZzzzzzZzzzZip Implementato

[Duca <sen...@gm...>]

Allora gente, se volete provare l'ebrezza dei media compressi dite al Winzip di comprimervi la cartella Media in un file chiamato Media.Zip i 
file dovrenno avere path Media/graphics/cicciolina.png. e questo e' quanto.

[Dlab-devel] Perle di saggezza

[Bernardo I. <be...@de...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Salve,

sul Kernel Traffic di questa settimana ho trovato questa perla
di Saggezza, volevo condividerla con voi ;-)

 Il contesto e' che un certo Anton Altaparmakov si e' lamentato
sulla mailing list del kernel di Linux dicendo che Martin Dalecki,
il mantainer del sottosistema IDE, da mesi sta solo togliendo
cose senza aggiungere niente di nuovo. Al che, Linus Torvalds ha
risposto:

 --------------------------------------------------------------------

  Who cares? Have you found _anything_ that Martin removed that
 was at all worthwhile? I sure haven't.

  Guys, you have to realize that the IDE layer has eight YEARS
 of absolute crap in it. Seriously. It's _never_ been cleaned up
 before. It has stuff so distasteful that t's scary.

  Take it from me: it's a _lot_ easier to add cruft and crap on
 top of clean code. You can do it yourself if you want to.
 You don't need a maintainer to add barnacles.

  All the information that /proc/ide gave you is basically
available in hdparm, and for your dear embedded system it
apparently takes up less space by being in user space.
So what is the problem?

 My vote is to remove as much as humanly possible.
 
   "Everything should be made as simple as possible,
   but not simpler" - Albert Einstein

  Think about it, and really _understand_ it.

 --------------------------------------------------------------------


- ----------------------------------------------------------------------
Try our multiplatform arcade classic: http://www.sf.net/projects/dlab/
- ----------------------------------------------------------------------

  // Bernardo Innocenti - Develer S.r.l., R&D dept.
\X/  http://www.develer.com/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE89CorltU4TfxqZsoRAqlSAJ93HPYJmtuw3QJEApJ3Lxbo+43XIgCeMBLF
/tHvSKg3hreJOzRffigeihU=
=3y+Z
-----END PGP SIGNATURE-----

Re: [Dlab-devel] Idee

[Bernardo I. <be...@de...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Monday 27 May 2002 18:23, Mattix wrote:

 > Pensavo a una cosa...
 > Ditemi se conviene: perche non mettiamo tutti i #define in un file .h
 >  (ad esempio defines.h) in modo da averli tutti sott'okkio?
 > Chiaramente dovranno essere commentate accanto le loro funzioni.
 > Questo ci farà risparmiare un po' di spazio perchè sarà sufficente 
 > scrivere "#include defines.h" in ogni file che abbia bisogno dei 
 > #define.
 > Inoltre penso che sia molto più comodo anche perchè per settare le 
 > OPZIONI sarà sufficente andare a frugare in quel file invece di dare 
 > ogni volta una directory diversa.

 Si', e' un'ottima idea, ma non _TUTTE_ le definizioni. Direi di
identificare quelle definizioni che riguardano tipicamente la
configurazione del gioco (numero vite, velocita' spari, etc.) e
metterle magari in un include "config.h".

 Cosi' un eventuale playtester o utente finale puo' customizzare il
gioco secondo le proprie esigenze, pur non essendo un programmatore.

 Se ti va di farlo, non esitare!


 > Per quanto riguarda il mio personale lavoro volevo ringraziare chi ha
 > ulteriormente incasinato le cose cambiando i nomi dei bonus senza
 > rimettere i loro nomi nei files da compilare. Il quadratino rosso che
 > appare è una "cosa di sicurezza" che abbiamo inserito su idea di
 > bernardo per evitare che tutto crashi. In pratica quella dovrebbe
 > apparire quando l'oggetto bonus richiamato non è trovato.

 Si, infatti... il quadratino rosso fa capire che manca un'immagine...
Credo che ad aver rinominato le immagini sia stato mostro, ma vedo che
adesso il codice non torna neanche con i nomi, chi e' stato?

 > E pensare che avevo appena scritto a proposito del LASCIARE LE COSE A
 >  META'... VEDIAMO DI PROVVEDERE

 Approposito: le armi erano una cosa a meta' ma ora ci sta lavorando
qualcuno (chi? non ricordo...)


 > C'era anche il problema che quando il player prende un bonus dovrebbe
 >  succedere qualcosa: allora tutto quello che succedeva era che
 > venivano assegnati dei punti (cosa che ho tolto perchè non è quella la
 > funzione dei bonus) e nient'altro.

 A fare questo e' stato fede ;-)

 > C'era solo uno strano effetto collaterale che un bonus errato faceva 
 > cambiare tipo di sparo...

 Si ho visto... adesso e' a posto'?


 > Il bonus della vita invece non implementa la vita (e non è solo un 
 > discorso di SUPER-TEXT) e io non sono riuscito ancora a trovare dove
 > va  fatta la modifica perchè come ho già detto è tutto
 > incasinatissimo. Ora, io non sono abbastanza bravo per rimettere tutto
 > a posto come avevo proposto (ovvero ordinare tutte le collisioni per
 > argomenti in un unico file ad esempio, e non un pezzo quì, un pezzo là
 > delle stesse cose) e quindi vorrei sollecitare qualcuno che ci capisce
 > a fare questa cosa, altrimenti si rischia, come ha detto anche
 > bernardo, di arrivare a un punto in cui si fa prima a riscrivere tutto
 > che a riordinare i files.

 Un momento, sto guardando come sono fatte le collisioni e non mi
sembrano malissimo. I criteri sono:

 - nessun oggetto deve permettersi di alterare le variabili di
   un altro oggetto quando collide (ognuno pensa per se)

 - nella collide() non si puo':
    - cambiare la propria posizione
    - cambiare la propria velocita'
    - suicidarsi

 La seconda regola serve perche' la collide() viene chiamata sempre
su due diversi oggetti, ma non e' specificato in che ordine. Ogni
oggetto deve avere l'opportunita' di vedere posizione e velocita'
dell'altro.

 Per onorare questa regola, molti oggetti si salvano delle variabili
e cambiano stato al momento della collide() e poi fanno quello che
devono fare nella move().

 Una soluzione piu' semplice poteva essere di salvare velocita', tipo
e posizione di ciascun oggetto nella CollisionDetection() e poi passare
solo questi valori alla collide() di ognuno. Tra l'altro questo
design avrebbe garantito anche il rispetto della prima condizione!

 Pero' a pensarci bene, quasi sempre un oggetto ha bisogno di cambiare
stato e gestire la collisione nella move() perche' alcuni azioni durano
un certo tempo...


 > Se non ci avete fatto ancora caso, adesso non si compila più come un 
 > tempo: non si sa come ma adesso ci sono dei problemi con la libreria 
 >  time.h che prima non c'erano... che è successo? Qualcuno ha fatto
 > casino?

 Ah, si'... e' davvero un baco nell'include time.h del GCC 2.95.3.
Le due soluzioni sono:

 - aggiornarsi al gcc 3.1 (meglio)

 - commentare il prototipo doppio di time() in time.h (zozzo!)

- ----------------------------------------------------------------------
Try our multiplatform arcade classic: http://www.sf.net/projects/dlab/
- ----------------------------------------------------------------------

  // Bernardo Innocenti - Develer S.r.l., R&D dept.
\X/  http://www.develer.com/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE88+7ZltU4TfxqZsoRAnvNAJ4oyDix7zs4Gii24GToJZ7ZyO3dmACfcVTZ
on4jUHaZv2NgzdJvYXYYXyE=
=PaDy
-----END PGP SIGNATURE-----

Re: [Dlab-devel] INFO 27/5/02

[Bernardo I. <be...@de...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Monday 27 May 2002 17:25, Daniela Sarocchi wrote:
 > Aggiornamento lavoro da fare!

 10x! (thanks!)

 > PS: Scusate se mi sono divertita con Word ... mi sarei
 > divertita di più con LateX!!!!

 Hmmm... se vuoi io ce l'ho... mi vergogno ad ammetterlo,
ma non lo so usare ;-)


- ----------------------------------------------------------------------
Try our multiplatform arcade classic: http://www.sf.net/projects/dlab/
- ----------------------------------------------------------------------

  // Bernardo Innocenti - Develer S.r.l., R&D dept.
\X/  http://www.develer.com/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE88+i7ltU4TfxqZsoRAt07AJ44CtShzFOsGeLl4YxIKiPYCzxtwQCfQwac
U1a8XMUhLjpx/VTmmdNG7UU=
=ZY2j
-----END PGP SIGNATURE-----

[Dlab-devel] schema codice "starshocks"

[<sar...@ya...>]

 
 

______________________________________________________________________
Scommetti gratis sui Mondiali con Unibet.com!
http://it.yahoo.com/mail_it/foot/?http://ads.unibet.com/adverts/it/yahoo/

[Dlab-devel] Documentazione

[Francesco B. <jx...@ti...>]

Per favore, cercate da ora in poi di commentare in qualche modo ogni
modifica che venga fatta al codice, in particolar modo i nuovi moduli, anche
per facilitare il lavoro di chi deve mettere le mani su cose fatte da altri.
Se vi fa troppa fatica scriverle in inglese, scrivetele pure in italiano,
poi ci pensiamo io e la Daniela a tradurle. Per lo meno negli header mettete
in testa ad ogni funzione una breve spiegazione di quello che fa, delle
variabili che le vengono passate e dei valori ritornati. Non sarebbe male
(leggi: va fatto) che riprendiate in mano anche i moduli vecchi lasciati
senza uno stralcio di documentazione. Grazie.

ciao,
Cecco
---------
Visit: www.sourceforge.net/projects/dlab
Home Page: http://dlab.sourceforge.net/
Dlab-developer mailing list
https://lists.sourceforge.net/lists/listinfo/dlab-developer

[Dlab-devel] =?iso-8859-1?Q?Idee?=

[<ma...@io...>]

UGVuc2F2byBhIHVuYSBjb3NhLi4uDQpEaXRlbWkgc2UgY29udmllbmU6IHBlcmNoZSBub24g
bWV0dGlhbW8gdHV0dGkgaSAjZGVmaW5lIGluIHVuIGZpbGUgLmggDQooYWQgZXNlbXBpbyBk
ZWZpbmVzLmgpIGluIG1vZG8gZGEgYXZlcmxpIHR1dHRpIHNvdHQnb2traW8/DQpDaGlhcmFt
ZW50ZSBkb3ZyYW5ubyBlc3NlcmUgY29tbWVudGF0ZSBhY2NhbnRvIGxlIGxvcm8gZnVuemlv
bmkuDQpRdWVzdG8gY2kgZmFy4CByaXNwYXJtaWFyZSB1biBwbycgZGkgc3BhemlvIHBlcmNo
6CBzYXLgIHN1ZmZpY2VudGUgDQpzY3JpdmVyZSAiI2luY2x1ZGUgZGVmaW5lcy5oIiBpbiBv
Z25pIGZpbGUgY2hlIGFiYmlhIGJpc29nbm8gZGVpIA0KI2RlZmluZS4NCklub2x0cmUgcGVu
c28gY2hlIHNpYSBtb2x0byBwafkgY29tb2RvIGFuY2hlIHBlcmNo6CBwZXIgc2V0dGFyZSBs
ZSANCk9QWklPTkkgc2Fy4CBzdWZmaWNlbnRlIGFuZGFyZSBhIGZydWdhcmUgaW4gcXVlbCBm
aWxlIGludmVjZSBkaSBkYXJlIA0Kb2duaSB2b2x0YSB1bmEgZGlyZWN0b3J5IGRpdmVyc2Eu
DQoNClBlciBxdWFudG8gcmlndWFyZGEgaWwgbWlvIHBlcnNvbmFsZSBsYXZvcm8gdm9sZXZv
IHJpbmdyYXppYXJlIGNoaSBoYSANCnVsdGVyaW9ybWVudGUgaW5jYXNpbmF0byBsZSBjb3Nl
IGNhbWJpYW5kbyBpIG5vbWkgZGVpIGJvbnVzIHNlbnphIA0KcmltZXR0ZXJlIGkgbG9ybyBu
b21pIG5laSBmaWxlcyBkYSBjb21waWxhcmUuIElsIHF1YWRyYXRpbm8gcm9zc28gY2hlIA0K
YXBwYXJlIOggdW5hICJjb3NhIGRpIHNpY3VyZXp6YSIgY2hlIGFiYmlhbW8gaW5zZXJpdG8g
c3UgaWRlYSBkaSANCmJlcm5hcmRvIHBlciBldml0YXJlIGNoZSB0dXR0byBjcmFzaGkuIElu
IHByYXRpY2EgcXVlbGxhIGRvdnJlYmJlIA0KYXBwYXJpcmUgcXVhbmRvIGwnb2dnZXR0byBi
b251cyByaWNoaWFtYXRvIG5vbiDoIHRyb3ZhdG8uDQoNCkUgcGVuc2FyZSBjaGUgYXZldm8g
YXBwZW5hIHNjcml0dG8gYSBwcm9wb3NpdG8gZGVsIExBU0NJQVJFIExFIENPU0UgQSANCk1F
VEEnLi4uIFZFRElBTU8gREkgUFJPVlZFREVSRQ0KDQpDJ2VyYSBhbmNoZSBpbCBwcm9ibGVt
YSBjaGUgcXVhbmRvIGlsIHBsYXllciBwcmVuZGUgdW4gYm9udXMgZG92cmViYmUgDQpzdWNj
ZWRlcmUgcXVhbGNvc2E6IGFsbG9yYSB0dXR0byBxdWVsbG8gY2hlIHN1Y2NlZGV2YSBlcmEg
Y2hlIHZlbml2YW5vIA0KYXNzZWduYXRpIGRlaSBwdW50aSAoY29zYSBjaGUgaG8gdG9sdG8g
cGVyY2joIG5vbiDoIHF1ZWxsYSBsYSBmdW56aW9uZSANCmRlaSBib251cykgZSBuaWVudCdh
bHRyby4NCkMnZXJhIHNvbG8gdW5vIHN0cmFubyBlZmZldHRvIGNvbGxhdGVyYWxlIGNoZSB1
biBib251cyBlcnJhdG8gZmFjZXZhIA0KY2FtYmlhcmUgdGlwbyBkaSBzcGFyby4uLg0KSWwg
Ym9udXMgZGVsbGEgdml0YSBpbnZlY2Ugbm9uIGltcGxlbWVudGEgbGEgdml0YSAoZSBub24g
6CBzb2xvIHVuIA0KZGlzY29yc28gZGkgU1VQRVItVEVYVCkgZSBpbyBub24gc29ubyByaXVz
Y2l0byBhbmNvcmEgYSB0cm92YXJlIGRvdmUgdmEgDQpmYXR0YSBsYSBtb2RpZmljYSBwZXJj
aOggY29tZSBobyBnaeAgZGV0dG8g6CB0dXR0byBpbmNhc2luYXRpc3NpbW8uDQpPcmEsIGlv
IG5vbiBzb25vIGFiYmFzdGFuemEgYnJhdm8gcGVyIHJpbWV0dGVyZSB0dXR0byBhIHBvc3Rv
IGNvbWUgDQphdmV2byBwcm9wb3N0byAob3Z2ZXJvIG9yZGluYXJlIHR1dHRlIGxlIGNvbGxp
c2lvbmkgcGVyIGFyZ29tZW50aSBpbiB1biANCnVuaWNvIGZpbGUgYWQgZXNlbXBpbywgZSBu
b24gdW4gcGV6em8gcXXsLCB1biBwZXp6byBs4CBkZWxsZSBzdGVzc2UgDQpjb3NlKSBlIHF1
aW5kaSB2b3JyZWkgc29sbGVjaXRhcmUgcXVhbGN1bm8gY2hlIGNpIGNhcGlzY2UgYSBmYXJl
IHF1ZXN0YSANCmNvc2EsIGFsdHJpbWVudGkgc2kgcmlzY2hpYSwgY29tZSBoYSBkZXR0byBh
bmNoZSBiZXJuYXJkbywgZGkgYXJyaXZhcmUgDQphIHVuIHB1bnRvIGluIGN1aSBzaSBmYSBw
cmltYSBhIHJpc2NyaXZlcmUgdHV0dG8gY2hlIGEgcmlvcmRpbmFyZSBpIA0KZmlsZXMuDQoN
ClNlIG5vbiBjaSBhdmV0ZSBmYXR0byBhbmNvcmEgY2FzbywgYWRlc3NvIG5vbiBzaSBjb21w
aWxhIHBp+SBjb21lIHVuIA0KdGVtcG86IG5vbiBzaSBzYSBjb21lIG1hIGFkZXNzbyBjaSBz
b25vIGRlaSBwcm9ibGVtaSBjb24gbGEgbGlicmVyaWEgIA0KdGltZS5oIGNoZSBwcmltYSBu
b24gYydlcmFuby4uLiBjaGUg6CBzdWNjZXNzbz8gUXVhbGN1bm8gaGEgZmF0dG8gDQpjYXNp
bm8/DQoNCkUgcXVlc3RvIOggcXVhbnRvLi4uIGNvbWUgZGlzc2UgcXVlbCBmaXNpY28uLi4N
Cg==

[Dlab-devel] INFO 27/5/02

[<sar...@ya...>]

Aggiornamento lavoro da fare!

PS: Scusate se mi sono divertita con Word ... mi sarei
divertita di più con LateX!!!!

______________________________________________________________________
Scommetti gratis sui Mondiali con Unibet.com!
http://it.yahoo.com/mail_it/foot/?http://ads.unibet.com/adverts/it/yahoo/

[Dlab-devel] =?iso-8859-1?Q?Net_gaming?=

[<ma...@io...>]

LS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KRnJvbTogIkJlcm5hcmRvIElubm9jZW50
aSIgPGJlcm5pZUBkZXZlbGVyLmNvbT4NClRvOiAiRHVjYSIgPHNlbmR0b21lQGdteC5pdD4N
CkNjOiAiTWFpbGluZyBMaXN0IiA8RGxhYi1kZXZlbG9wZXJAbGlzdHMuc291cmNlZm9yZ2Uu
bmV0Pg0KU2VudDogU3VuZGF5LCBNYXkgMjYsIDIwMDIgODozOCBQTQ0KU3ViamVjdDogUmU6
IFtEbGFiLWRldmVsXSBXQy1OZXQ/DQoNCj4gIElvIGNvcGllcmVpIHF1ZWxsbyBjaGUgZmEg
UXVha2U6IGlsIHNlcnZlciBlJyBsJ3VuaWNvIGNoZSBoYSByYWdpb25lOg0KPiBzZSB2ZWRl
IHByaW1hIGxvIHNwYXJvIGRpIEEsIGFsbG9yYSBsJ2FzdGVyb2lkZSBlJyBzdGF0byBjb2xw
aXRvIGRhIEENCj4gZSBpIHB1bnRpIHZhbm5vIGFkIEEuIFNpYSBBIGNoZSBCIHBvc3Nvbm8g
YWdnaW9ybmFyZSBsbyBzY2hlcm1vIGUgaWwNCnByb3ByaW8NCj4gcHVudGVnZ2lvIGFuY2hl
IHN1Yml0bywgbWEgcHJpbWEgbyBwb2kgZ2xpIGFycml2ZXJhJyB1biBwYWNjaGV0dG8gZGFs
DQpzZXJ2ZXINCj4gY29udGVuZW50ZSBsYSBzaXR1YXppb25lIHJlYWxlIGUgYWxsb3JhIEIg
c2kgdmVkcmEnIHNjYWxhcmUgaSBwdW50aSBlDQp2ZWRyYScNCj4gZ2xpIGFzdGVyb2lkaSBp
biB1bmEgcG9zaXppb25lIGRpdmVyc2EgOy0pDQo+DQo+ICA+IENyZWRvIGNoZSBxdWVzdGEg
Y29zYSB2YWRhIGNtcSBwcmV2aXN0YSBzZSBzdXBwb25pYW1vIGRpIGF2ZXJlIHVuIA0KbGFn
DQo+ICA+IHZhcmlhYmlsZS4gY21xIGRvdnJlbW1vIHJhZ2dydXBwYXJlIGkgcGxheWVyIGNv
biBsYWcgc2ltaWxlLCBzZSBjafINCj4gID4gbm9uIOggcG9zc2liaWxlIGNyZWRvIHNpYSBv
cHBvcnR1bm8gbWVtb3JpenphcmUgcGVyIG9nbmkgY2xpZW50IHVuDQo+ICA+IGFsYmVybyBk
aSBpbmZvcm1hemlvbmkgcmVsYXRpdmkgYWdsaSBhc3Rlcm9pZGksIGNoaSBsaSBoYSANCmRp
c3RydXR0aSwNCj4gID4gcXVhbnRpIHB1bnRpIGhhIHByZXNvIGV0YyBwZXIgZXZlbnR1YWxt
ZW50ZSBhbm51bGxhcmUgdW4gYXppb25lDQo+ICA+IGVycmF0YS4NCj4NCj4gIFF1ZXN0YSBz
aXR1YXppb25lIGF2dmllbmUgcmFyYW1lbnRlIGUgc29sbyBxdWFuZG8gaWwgbGFnIGUnIGVs
ZXZhdG8sIA0Kbm9uDQo+IGNyZWRvIHNpYSB1biBwcm9ibGVtYSBncmF2ZS4uLg0KPg0KPiAg
UHJvdm8gYSBmYXJlIHVuJ2FmZmVybWF6aW9uZS4gTm9uIGhvIGxlIHByb3ZlLCBtYSB2b2ds
aW8gdmVkZXJlIHNlDQpxdWFsY3Vubw0KPiByaWVzY2UgYSBzbWVudGlybWk6DQo+DQo+ICJM
J3VuaWNvIG1vZG8gcGVyIGF2ZXJlIHVubyBzdGF0byBjb25zaXN0ZW50ZSBkZWwgZ2lvY28g
cGVyIHR1dHRpIGkNCmdpb2NhdG9yaQ0KPiBpbiB1biBkYXRvIG1vbWVudG8gZScgYXZlcmUg
dW4gdW5pY28gbm9kbyAoaWwgc2VydmVyKSBjaGUgbWFudGllbmUgaQ0KdmFsb3JpDQo+IHVm
ZmljaWFsaSBwZXIgdHV0dGUgbGUgdmFyaWFiaWxpIGRlbCBnaW9jby4gSW4gY2FzbyBkaSBs
YWcsIGkgY2xpZW50DQpwb3Nzb25vDQo+PiBmYXJlIGVsYWJvcmF6aW9uaSBzcGVjdWxhdGl2
ZSBhbCBzb2xvIHNjb3BvIGRpIGF1bWVudGFyZSBsYSANCmZsdWlkaXRhJywNCj4+IG1hIGRl
dm9ubyByaW1ldHRlcmUgdHV0dG8gYSBwb3N0byBhcHBlbmEgZ2xpIHZpZW5lIGNvbXVuaWNh
dG8gdW4gDQpudW92bw0KPj4gc3RhdG8gZGFsIHNlcnZlci4iDQoNCj5JbyBobyB1bidhbHRy
byBzaXN0ZW1hIGRhIHByZW5kZXJlIGluIGNvbnNpZGVyYXppb25lOiBjaGkgcHJpbWEgYXJy
aXZhDQo+bWVnbGlvIGFsbG9nZ2lhLCBvdnZlcm8sIHBvc3NpYW1vIF9ub25fIHR1dGVsYXJl
IGNoaSDoIGxhZ2dhdG8sIG1hIGRhcg0KPmNvbXVucXVlIHJhZ2lvbmUgYSBjaGkgY29tdW5p
Y2EgcGVyIHByaW1vIGFsIHNlcnZlciBpbiBjYXNvIGRpIA0KPmNvbmZsaXR0aS4NCj5JbiBx
dWVzdG8gbW9kbyBzaSBldml0YSBkaSBkb3ZlciByaW1ldHRlcmUgbGUgY29zZSBhIHBvc3Rv
IGRvcG8gdW4NCj5jb25mbGl0dG8sIGEgc2NhcGl0byBkZWxsJy1vbmVzdOAtIGRlbCBnaW9j
bywgc2ljdXJhbWVudGUgYSBmYXZvcmUgDQo+ZGVsbGEgZmx1aWRpdOAuDQoNCklvIHNvbm8g
ZGFjY29yZG8gY29sIGRpc2NvcnNvIGZsdWlkaXTgIGEgZGlzY2FwaXRvIGRlbGwnb25lc3Tg
IHNlIA0Kdm9sZXRlIHNhcGVyZSBsYSBtaWEuLi4NClNlIHVubyBoYSBsYSBjb25uZXNzaW9u
ZSBtaWdsaW9yZSDoIGNoaWFybyBjaGUgc2Fy4CBhdnZhbnRhZ2dpYXRvLg0KQSBtZSBmYXJl
YmJlIG1vbHRvIHBp+SBpbmthenphcmUgY2hlIGxhICJ0cmFtYSIgZGVsIGdpb2NvIG1pIGNh
bWJpIA0Kc290dG8gZ2xpIG9jY2hpLg==

[Dlab-devel] Nuova grafica

[Bernardo I. <be...@de...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Salve,

 Massimo "mostro" Santoro ha dedicato buona parte della
sua Domenica di riposo a ritoccare e migliorare la
nostra grafica.

 In particolare, ha convertito alcune PNG da 24bit a
pochi colori (64 o 16), ottenendo cosi' un notevole
risparmio di spazio (500% e passa). La qualita' e'
pressoche' inalterata: io non noto alcuna differenza.

 E' stato anche aggiunto il bonus mancante, converito
in PNG lo sfondo con il pianeta e cambiato il titolo
del gioco. Se il nuovo titolo non dovesse piacere,
si puo' sempre ripescare quello originale dal CVS.

 Adesso la grafica del gioco occupa meno di 800KB,
mentre la musica occupa ben 4.4MB... Dobbiamo
assolutamente fare qualcosa...

- -- 
  // Bernardo Innocenti - Develer S.r.l., R&D dept.
\X/  http://www.develer.com/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE88YEzltU4TfxqZsoRAv2WAJ99czaop/dshhxa+9tEwJDi96iLmgCgpae+
jY228hCcuNKkAtn1CQCcJIs=
=SadV
-----END PGP SIGNATURE-----

[Dlab-devel] Release 0.2

[Bernardo I. <be...@de...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Salve a tutti,

la release 0.2 e' uscita, bella piu' che mai!

 Ringrazio tutti per il lavoro svolto ed in particolare
Federico "pippolino" Soldani per aver lavorato tutto
il week end al completamento della release.

 Vi invito a scaricare gli archivi di distribuzione
da SourceForge per fare un po' di QA e playtesting:

 http://sourceforge.net/project/showfiles.php?group_id=47074


 Se trovate dei bug non ovvi, potete segnalarli con
l'interfaccia di SourceForge:

  http://sourceforge.net/tracker/?group_id=47074&atid=448378

- -- 
  // Bernardo Innocenti - Develer S.r.l., R&D dept.
\X/  http://www.develer.com/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE88X9IltU4TfxqZsoRAl2YAJ9LICyRhPV0y2OFtxu7uEjjDxnyWQCaAxDQ
WpYnx6ed1rpV2VK0X3YOhyg=
=EDA5
-----END PGP SIGNATURE-----

Re: [Dlab-devel] WC-Net?

[Lorenzo S. <lor...@li...>]

----- Original Message -----
From: "Bernardo Innocenti" <be...@de...>
To: "Duca" <sen...@gm...>
Cc: "Mailing List" <Dla...@li...>
Sent: Sunday, May 26, 2002 8:38 PM
Subject: Re: [Dlab-devel] WC-Net?

>  Io copierei quello che fa Quake: il server e' l'unico che ha ragione:
> se vede prima lo sparo di A, allora l'asteroide e' stato colpito da A
> e i punti vanno ad A. Sia A che B possono aggiornare lo schermo e il
proprio
> punteggio anche subito, ma prima o poi gli arrivera' un pacchetto dal
server
> contenente la situazione reale e allora B si vedra' scalare i punti e
vedra'
> gli asteroidi in una posizione diversa ;-)
>
>  > Credo che questa cosa vada cmq prevista se supponiamo di avere un la=
g
>  > variabile. cmq dovremmo raggruppare i player con lag simile, se ci=F2
>  > non =E8 possibile credo sia opportuno memorizzare per ogni client un
>  > albero di informazioni relativi agli asteroidi, chi li ha distrutti,
>  > quanti punti ha preso etc per eventualmente annullare un azione
>  > errata.
>
>  Questa situazione avviene raramente e solo quando il lag e' elevato, n=
on
> credo sia un problema grave...
>
>  Provo a fare un'affermazione. Non ho le prove, ma voglio vedere se
qualcuno
> riesce a smentirmi:
>
> "L'unico modo per avere uno stato consistente del gioco per tutti i
giocatori
> in un dato momento e' avere un unico nodo (il server) che mantiene i
valori
> ufficiali per tutte le variabili del gioco. In caso di lag, i client
possono
> fare elaborazioni speculative al solo scopo di aumentare la fluidita',
> ma devono rimettere tutto a posto appena gli viene comunicato un nuovo
> stato dal server."

Io ho un'altro sistema da prendere in considerazione: chi prima arriva
meglio alloggia, ovvero, possiamo _non_ tutelare chi =E8 laggato, ma dar
comunque ragione a chi comunica per primo al server in caso di conflitti.
In questo modo si evita di dover rimettere le cose a posto dopo un
conflitto, a scapito dell'-onest=E0- del gioco, sicuramente a favore dell=
a
fluidit=E0.

Re: [Dlab-devel] WC-Net?

[Bernardo I. <be...@de...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Saturday 25 May 2002 16:46, Duca wrote:

 > > Il problema e' che quando c'e' un lag notevole la cosa puo' avvenire
 > >di frequente. Nel gioco si spara a ripetizione ed e' possibile che
 > >un giocatore frammenti un asteroide due o tre volte prima di scoprire
 > >che l'aveva gia' fatto un altro.

 > Hai ragione, ma questo problema si presenta in qualsiasi
 > configurazione sceglieremo, anche con un server centrale che dirama a
 > tutti i giocatori l'informazione. Inoltre servirebbe all'interno dei
 > client una logica aggiuntiva per tutelare i client con lag elevato.
 > Faccio come hai fatto te l'esempio di 2 (A e B) che sparano allo
 > stesso asteroide, A colpisce l'asteroid ma ha un lag elevato, anche B
 > colipisce l'asteroide ma ha un lag minore, il server distribuisce
 > l'informazione "B colpito sprite xx" a tutti i giocatori, quindi
 > arriva l'informazione A colpisce asteroide e si scopre che A ha
 > colpito prima di B. Ci sono 2 problemi A deve essere tutelato
 > dall'informazione ERRATA del server e TUTTI i giocatori devono essere
 > riportati ad una diversa configurazione degli sprite!

 Io copierei quello che fa Quake: il server e' l'unico che ha ragione:
se vede prima lo sparo di A, allora l'asteroide e' stato colpito da A
e i punti vanno ad A. Sia A che B possono aggiornare lo schermo e il proprio
punteggio anche subito, ma prima o poi gli arrivera' un pacchetto dal server
contenente la situazione reale e allora B si vedra' scalare i punti e vedra'
gli asteroidi in una posizione diversa ;-)

 > Credo che questa cosa vada cmq prevista se supponiamo di avere un lag
 > variabile. cmq dovremmo raggruppare i player con lag simile, se ciò
 > non è possibile credo sia opportuno memorizzare per ogni client un
 > albero di informazioni relativi agli asteroidi, chi li ha distrutti,
 > quanti punti ha preso etc per eventualmente annullare un azione
 > errata.

 Questa situazione avviene raramente e solo quando il lag e' elevato, non
credo sia un problema grave...

 Provo a fare un'affermazione. Non ho le prove, ma voglio vedere se qualcuno
riesce a smentirmi:

"L'unico modo per avere uno stato consistente del gioco per tutti i giocatori
in un dato momento e' avere un unico nodo (il server) che mantiene i valori
ufficiali per tutte le variabili del gioco. In caso di lag, i client possono
fare elaborazioni speculative al solo scopo di aumentare la fluidita',
ma devono rimettere tutto a posto appena gli viene comunicato un nuovo
stato dal server."

- -- 
  // Bernardo Innocenti - Develer S.r.l., R&D dept.
\X/  http://www.develer.com/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE88SukltU4TfxqZsoRAjgbAJwIkfW3oriw+TIQj0oX9Rp3hTgYbQCfe7QI
ae9klBQ1tIHJLkBNPXPT1ZM=
=O/TX
-----END PGP SIGNATURE-----

Re: [Dlab-devel] WC-Net?

[Bernardo I. <be...@de...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Saturday 25 May 2002 13:19, Lorenzo Stacchini wrote:
 > Secondo me potremmo cercare di ridurre al minimo i movimenti casuali,
 > sostituendo la generazione delle direzioni degli asteroids con degli
 > algoritmi più o meno complessi ma di generazione univoca a partire dal
 > contesto. Questo potrebbe permetterci di calcolare lato client le
 > divizioni degli asteroidz, a questo punto potremmo permetterci di
 > inviare addirittura un pacchetto tcp di conferma.

 Si', hai ragione... Tra l'altro lo spezzamento casuale e' proprio
 brutto. Potremmo usare le velocita' relative o la posizione tra lo sparo
 e l'asteroide al momento della collisione per calcolare le traiettorie
 dei due pezzi... verrebbe molto piu' realistico.

 > Generalizzando un po' questo criterio petrebbe andar bene un po' per
 > tutto, anche per esempio nei bonus, dove ci sarebbe comunque la
 > necessita' di dare l'impressione della casualità.

 Beh, comunque vi ricordo che la rand() e' deterministica: se non
 settiamo un seme casuale all'inizio (e non non lo facciamo), la sequenza
 di numeri che genera e' sempre la stessa!

 Purtroppo per il network game questo non basta: macchine diverse possono
avere versioni diverse della rand() che non generano gli stessi numeri.
Dobbiamo fare un generatore di numeri casuali nostro...

 > In più ho un'altra idea che mentre scrivevo mi ha frullato in tezta:
 > zi potrebbe pensare ad un sistema client che cerca di calcolare il più
 > possibile da solo gli eventi, memorizzando di volta in volta a tempi
 > fissati le posizioni (magari dentro le move()) su una variabile
 > struttura 'globale' dentro game (o dove decideremo, non ha
 > importanza). Ogni tanto il server manderà dei pacchetti di
 > sincronizzazzione tcp in broadcasting, i client controlleranno poi se
 > i loro parametri sono corretti.
 > Ancora non ho assolutamente pensato alla fattibilità dal punto di
 > vizta dell'efficenza, inoltre potremmo rischiare che i pacchetti tcp
 > arrivino talmente in ritardo da complicarci troppo la vita.
 > Comunque questo sistema mi sembra implementabile per lo meno in parte
 > usandolo ad intervalli relativamente lunghi.

 Penso che sia il modo giusto di procedere. Quake 3 fa in questo modo:
tu vedi tutto che si muove come dovrebbe, ma ogni tanto il server invia
la vera posizione degli oggetti e, se e' molto discorde da quello che
avevi previsto tu, vedi la roba che riappare e gli omini che tornano
dove erano prima ;-)

 E' brutto, ok, ma succede di rado ed e' molto meglio cosi' che
aspettare tutto il tempo prima di veder spostare qualcosa.

- --
  // Bernardo Innocenti - Develer S.r.l., R&D dept.
\X/  http://www.develer.com/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE88Sj1ltU4TfxqZsoRAmSrAJwIbXdRgehSpPbJ7vncEbCTXiRZcgCgijlM
VKMMmchfEa6M9Y6nhaes5QE=
=2TSx
-----END PGP SIGNATURE-----

Re: [Dlab-devel] WC-Net?

[Federico S. <sol...@te...>]

From: "Lorenzo Stacchini" <lor...@li...>

>Generalizzando un po' questo criterio petrebbe andar bene un po' per =
tutto,
>anche per esempio nei bonus, dove ci sarebbe comunque la necessita' di =
dare
>l'impressione della casualit=E0.

Il nostro tipo di gioco non e' stato fatto per fare apparire gli oggetti
casualmente...quando implementeremo anche i livelli (aspettiamo XML ) i
bonus e gli asteroidi (e tutti gli altri oggetti), appariranno sempre =
nello
stesso punto, anche perche' il bello di questi giochi e'  che uno impara =
il
livello a memoria (vi ricordate giochi come 1942...).


Per ora e' tutto...
Ancora non posso esprimere la mia idea perche' non e' chiara nemmeno a =
me
!!! :)

Visit: www.sourceforge.net/projects/dlab
Home Page: http://dlab.sourceforge.net/
Dlab-developer mailing list
https://lists.sourceforge.net/lists/listinfo/dlab-developer

Re: [Dlab-devel] WC-Net?

[Duca <sen...@gm...>]

25/05/02 1.49.22, Bernardo Innocenti <be...@de...> wrote:

> E come risolviamo il problema della "concorrenza" tra giocatori
>sfasati? Mi spiego con parole comprensibili: se in due sparano allo
>stesso asteroide e lo colpiscono, ciascuno crede di essere stato il
>primo perche' ci vuole del tempo prima che arrivi il messaggio
>dell'altro. A questo punto lo stato del gioco deve essere
>risincronizzato in qualche modo. Per esempio, ogni client potrebbe
>aggiungere un "timestamp" ai propri messaggi (per esempio il numero
>di millisecondi dall'inizio della partita). Quello con il timestamp
>minore ha ragione e l'altro deve togliersi i punti e rimettere gli
>asteroidi come ha detto il vincitore.
>
> Il problema e' che quando c'e' un lag notevole la cosa puo' avvenire
>di frequente. Nel gioco si spara a ripetizione ed e' possibile che
>un giocatore frammenti un asteroide due o tre volte prima di scoprire
>che l'aveva gia' fatto un altro.

Hai ragione, ma questo problema si presenta in qualsiasi configurazione
sceglieremo, anche con un server centrale che dirama a tutti i giocatori
l'informazione. Inoltre servirebbe all'interno dei client una logica aggi=
untiva
per tutelare i client con lag elevato. Faccio come hai fatto te l'esempio=
 di 2 (A e B)
che sparano allo stesso asteroide, A colpisce l'asteroid ma ha un lag ele=
vato, anche B
colipisce l'asteroide ma ha un lag minore, il server distribuisce l'infor=
mazione "B colpito=20
sprite xx" a tutti i giocatori, quindi arriva l'informazione A colpisce a=
steroide e si scopre
che A ha colpito prima di B. Ci sono 2 problemi A deve essere tutelato da=
ll'informazione ERRATA
del server e TUTTI i giocatori devono essere riportati ad una diversa con=
figurazione degli sprite!

>
> Ritornare alla situazione originale dopo questo casino e' molto
>difficile: l'oggetto Asteroid originale non c'e' piu', al suo posto
>ci sono degli Asteroid piu' piccoli che devono essere tolti e
>sostituiti con quelli dichiarati dall'altro giocatore. Ma i messaggi
>possono arrivare sfalzati in vari modi... inoltre gli spari che hanno
>colpito i nostri asteroidi sono gia' stati eliminati, invece
>avrebbero dovuto colpire qualcos'altro.

Credo che questa cosa vada cmq prevista se supponiamo di avere un lag var=
iabile.
cmq dovremmo raggruppare i player con lag simile, se ci=F2 non =E8 possib=
ile credo sia opportuno
memorizzare per ogni client un albero di informazioni relativi agli aster=
oidi, chi li ha
distrutti, quanti punti ha preso etc per eventualmente annullare un azion=
e errata.

Fwd: Re: [Dlab-devel] WC-Net?

[Duca <sen...@gm...>]

------- Start of forwarded message -------
From: Bernardo Innocenti <be...@de...>
To: Duca <sen...@gm...>
Organization: Develer
Subject: Fwd: Re: [Dlab-devel] WC-Net?
Date: 25/05/02 1.49.22

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Friday 24 May 2002 21:25, Duca wrote:

 > Senza incasinare troppo le cose potremmo utilizzare un server centrale
 > che gestisce le varie connessioni: Add, rm, etc. player (utilizzando
 > magari un UDP un po' pi=F9 incasinato) Dopo di che i client si
 > comunicano a vicenda gli eventi:
 > player spare, player collide etc.

 Hmmm... potrebbe andare... Quindi il server dovra' dire a ciascun
giocatore gli IP address di tutti gli altri, e ciascuno deve mantenere
aggiornata una lista dei giocatori. Non e' grave... ma dobbiamo prevedere
che i giocatori si connettano e sconnettano alla partita in qualsiasi
momento.

 > sparo del player collide con asteroide =3D [casino]
 > [Quando uno sparo collide con un asteroide, quest'ultimo si divide in
 > 2 parti con direzioni casuali, le direzioni vengono elaborate solo da
 > chi ha generato lo sparo, gli altri attendono(per un po') il
 > risultato.]

 Ok... e mettiamoci anche i bonus: il fatto che venga fuori un bonus ed
il tipo di bonus li determina chi ha colpito l'asteroide.

 Ma gli altri intanto sono andati avanti con l'asteroide intero, non
basta dare gli angoli: bisogna anche dire la posizione iniziale perche'
deve essere identica per tutti i giocatori.


 > Il movimento degli asteroidi =E8 ovvio ogni player se lo calcola da
 > solo.

 Temo pero' che ogni tanto sia necessario risincronizzarsi perche'
i computer vanno a velocita' diverse e gli errori di approssimazione
si accumulano in modo diverso. A lungo andare non torna piu' nulla...

 E come risolviamo il problema della "concorrenza" tra giocatori
sfasati? Mi spiego con parole comprensibili: se in due sparano allo
stesso asteroide e lo colpiscono, ciascuno crede di essere stato il
primo perche' ci vuole del tempo prima che arrivi il messaggio
dell'altro. A questo punto lo stato del gioco deve essere
risincronizzato in qualche modo. Per esempio, ogni client potrebbe
aggiungere un "timestamp" ai propri messaggi (per esempio il numero
di millisecondi dall'inizio della partita). Quello con il timestamp
minore ha ragione e l'altro deve togliersi i punti e rimettere gli
asteroidi come ha detto il vincitore.

 Il problema e' che quando c'e' un lag notevole la cosa puo' avvenire
di frequente. Nel gioco si spara a ripetizione ed e' possibile che
un giocatore frammenti un asteroide due o tre volte prima di scoprire
che l'aveva gia' fatto un altro.

 Ritornare alla situazione originale dopo questo casino e' molto
difficile: l'oggetto Asteroid originale non c'e' piu', al suo posto
ci sono degli Asteroid piu' piccoli che devono essere tolti e
sostituiti con quelli dichiarati dall'altro giocatore. Ma i messaggi
possono arrivare sfalzati in vari modi... inoltre gli spari che hanno
colpito i nostri asteroidi sono gia' stati eliminati, invece
avrebbero dovuto colpire qualcos'altro.

 Argh!!!


 > Io l'ho sparata, che ne pensate?

 Penso che sei il primo ad aver rotto il silenzio stampa sull'argomento
e quindi hai fatto molto bene.

 Se non siamo capaci di discuterne a parole, figuriamoci farlo! ;)

- --=20
  // Bernardo Innocenti - Develer S.r.l., R&D dept.
\X/  http://www.develer.com/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE87tGCltU4TfxqZsoRAorHAJ9P2du9Afyvg0UCDL458Tx7Z64odQCgi3nc
+MlBwE3LOtHrkktz0Bdb7NU=3D
=3DHc37
-----END PGP SIGNATURE-----


-------- End of forwarded message --------

Re: [Dlab-devel] WC-Net?

[<jx...@ti...>]

>-- Messaggio originale --
>From: "Lorenzo Stacchini" <lor...@li...>
>To: "Mailing List" <Dla...@li...>
>Subject: Re: [Dlab-devel] WC-Net?
>Date: Sat, 25 May 2002 13:19:44 +0200
>
>
>
>----- Original Message -----
>From: "Duca" <sen...@gm...>
>To: "Mailing List" <Dla...@li...>
>Sent: Friday, May 24, 2002 9:25 PM
>Subject: [Dlab-devel] WC-Net?
>
>
>Senza incasinare troppo le cose potremmo utilizzare un server centrale
che
>gestisce le varie connessioni:
>Add, rm, etc. player (utilizzando magari un UDP un po' pi? incasinato)
>Dopo di che i client si comunicano a vicenda gli eventi:
>player spare, player collide etc.
>sparo del player collide con asteroide = [casino]
>[Quando uno sparo collide con un asteroide, quest'ultimo si divide in 2
>parti con direzioni casuali, le direzioni
>vengono elaborate solo da chi ha generato lo sparo, gli altri attendono(per
>un po') il risultato.]
>
>Il movimento degli asteroidi ? ovvio ogni player se lo calcola da solo.
>
>
>Io l'ho sparata, che ne pensate?
>
>
><<<<<<<<<<<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>>>>>>>>
>
>Secondo me potremmo cercare di ridurre al minimo i movimenti casuali,
>sostituendo la generazione delle direzioni degli asteroids con degli
>algoritmi pi? o meno complessi ma di generazione univoca a partire dal
>contesto. Questo potrebbe permetterci di calcolare lato client le divizioni
>degli asteroidz, a questo punto potremmo permetterci di inviare addirittura
>un pacchetto tcp di conferma.
>Generalizzando un po' questo criterio petrebbe andar bene un po' per tutto,
>anche per esempio nei bonus, dove ci sarebbe comunque la necessita' di
dare
>l'impressione della casualit?.

Avevo pensato anche io che la cosa migliore fosse quella di eliminare qualunque
generazione casuale di oggetti, e nel caso specifico dello "spacco" di un
asteroide mi sembra anche l'ipotesi pi? corretta. Il problema secondo me
? che, per rendere il gioco un p? pi? divertente, non ? possibile determinare
tutto a priori: ad esempio, quando inizia un livello, sarebbe meglio che
posizione e velocit? degli asteroidi vengano generati casualmente.

>In pi? ho un'altra idea che mentre scrivevo mi ha frullato in tezta:
>zi potrebbe pensare ad un sistema client che cerca di calcolare il pi?
>possibile da solo gli eventi, memorizzando di volta in volta a tempi fissati
>le posizioni (magari dentro le move()) su una variabile struttura 'globale'
>dentro game (o dove decideremo, non ha importanza). Ogni tanto il server
>mander? dei pacchetti di sincronizzazzione tcp in broadcasting, i client
>controlleranno poi se i loro parametri sono corretti.
>Ancora non ho assolutamente pensato alla fattibilit? dal punto di vizta
>dell'efficenza, inoltre potremmo rischiare che i pacchetti tcp arrivino
>talmente in ritardo da complicarci troppo la vita.
>Comunque questo sistema mi sembra implementabile per lo meno in parte
>usandolo ad intervalli relativamente lunghi.

Dunque, non ho capito bene come dovrebbe funzionare secondo te la cosa,
ma quello che ho capito ? che il problema fondamentale sia quello di determinare,
ad ogni evento, quali oggetti sono in gioco e farli sapere
all'altro client. Non sarebbe meglio concentrarsi su cosa aggiungere all'implementazione
gi? esistente, partendo dal presupposto di utilizzare *solo* l'UDP, piuttosto
che pensare a come intrecciare insieme tra di loro i vari protocolli? Ad
esempio, non si potrebbe usare un campo "ID" in ogni sprite, per far sapere
all'altro client quali siano esattamente i due oggetti che si sono scontrati:
magari potremmo anche utilizzare una struttura dati (tipo una tabella hash,
che sia la stessa per tutti i client) che contenga i puntatori a tutti gli
oggetti, e che in base all'ID si possa accedere al puntatore all'oggetto
direttamente?

Ciao,
Cecco

Re: [Dlab-devel] WC-Net?

[Lorenzo S. <lor...@li...>]

----- Original Message -----
From: "Duca" <sen...@gm...>
To: "Mailing List" <Dla...@li...>
Sent: Friday, May 24, 2002 9:25 PM
Subject: [Dlab-devel] WC-Net?


Senza incasinare troppo le cose potremmo utilizzare un server centrale ch=
e
gestisce le varie connessioni:
Add, rm, etc. player (utilizzando magari un UDP un po' pi=F9 incasinato)
Dopo di che i client si comunicano a vicenda gli eventi:
player spare, player collide etc.
sparo del player collide con asteroide =3D [casino]
[Quando uno sparo collide con un asteroide, quest'ultimo si divide in 2
parti con direzioni casuali, le direzioni
vengono elaborate solo da chi ha generato lo sparo, gli altri attendono(p=
er
un po') il risultato.]

Il movimento degli asteroidi =E8 ovvio ogni player se lo calcola da solo.


Io l'ho sparata, che ne pensate?


<<<<<<<<<<<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>>>>>>>>

Secondo me potremmo cercare di ridurre al minimo i movimenti casuali,
sostituendo la generazione delle direzioni degli asteroids con degli
algoritmi pi=F9 o meno complessi ma di generazione univoca a partire dal
contesto. Questo potrebbe permetterci di calcolare lato client le divizio=
ni
degli asteroidz, a questo punto potremmo permetterci di inviare addirittu=
ra
un pacchetto tcp di conferma.
Generalizzando un po' questo criterio petrebbe andar bene un po' per tutt=
o,
anche per esempio nei bonus, dove ci sarebbe comunque la necessita' di da=
re
l'impressione della casualit=E0.

In pi=F9 ho un'altra idea che mentre scrivevo mi ha frullato in tezta:
zi potrebbe pensare ad un sistema client che cerca di calcolare il pi=F9
possibile da solo gli eventi, memorizzando di volta in volta a tempi fiss=
ati
le posizioni (magari dentro le move()) su una variabile struttura 'global=
e'
dentro game (o dove decideremo, non ha importanza). Ogni tanto il server
mander=E0 dei pacchetti di sincronizzazzione tcp in broadcasting, i clien=
t
controlleranno poi se i loro parametri sono corretti.
Ancora non ho assolutamente pensato alla fattibilit=E0 dal punto di vizta
dell'efficenza, inoltre potremmo rischiare che i pacchetti tcp arrivino
talmente in ritardo da complicarci troppo la vita.
Comunque questo sistema mi sembra implementabile per lo meno in parte
usandolo ad intervalli relativamente lunghi.

?

[Dlab-devel] Release schedule

[Bernardo I. <be...@de...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Salve,

eccovi un buon esempio di release schedule:

  http://www.mozilla.org/roadmap.html

Incredibilmente, stanno anche rispettando i tempi previsti ;-)


 Da come e' andata questo Venerdi', penso che per Lunedi'
avremo una buona versione da far vedere ai nostri ospiti.

 Di importante mancano solo le pause tra i livelli ed il
Game Over.

- -- 
  // Bernardo Innocenti - Develer S.r.l., R&D dept.
\X/  http://www.develer.com/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE87vQGltU4TfxqZsoRAoq9AJ9TSdJjvZadQ6ODtXsVXkzjvNuJcQCfXSsB
GAQP91cK6A/GMG9ao+RJf+Q=
=BD5a
-----END PGP SIGNATURE-----

Re: [Dlab-devel] Sigh...

[Bernardo I. <be...@de...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Friday 24 May 2002 19:36, Mattix wrote:

 > Ragazzi a me me vien da piangere a zazzicare sui files .c e .h
 > C'è troppo casino!!!
 > Si fanno troppe cose senza commentarle e poi non ci si capisce più una
 >  sega!
 > Va bene abbreviare però non si riconosce più niente se non si
 > commenta!!

 Ottima osservazione, mi fa piacere scoprire che non sono il solo
a pensarlo.

 Ragazzi, abituatevi a fare le cose pulite, ordinate e documentate:
ci vuole solo un pelo di fatica in piu'.

 Se oggi quello che abbiamo e' ancora un minimo comprensibile e'
in gran parte merito di Lorenzo che da tempo ormai svolge il
lavoro ingrato di ripulire la sporcizia che lasciano gli altri.

 Ma in questo modo non si impara mai: ognuno e' responsabile di
mantenere ordinato il proprio codice e quello degli altri dopo
averlo modificato.

 D'ora in poi, comincero' a postare alcuni esempi di catttivo
stile nella mailing list, con tanto di riferimenti all'autore.

 Per esperienza vi assicuro che se la manutenzione viene
trascurata troppo a lungo, l'intero codice diventa cosi
illeggibile che conviene riscriverlo di sana pianta.


 > Ma chi è che inizia le cose e poi non le finisce! Non si può lasciare
 >  le cose a metà così!!!

 Qua ci vorrebbe lo stile Linus Torvalds:

"Show me the patch, and I can consider it. It would certainly be
nicer than what it is now (the include/linux/sysctl.h file is
EVIL, and a perfect example of the kind of idiotic brokenness
we used to have in /proc before it was cleaned up)." 

 In pratica: prima di ammettere una modifica in un grosso
progetto il mantainer dovrebe valutarla, criticarla...
e spesso rifiutata. Meglio non avere una feature che averla
implementata male o scritta con i piedi.

- -- 
  // Bernardo Innocenti - Develer S.r.l., R&D dept.
\X/  http://www.develer.com/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE87u5LltU4TfxqZsoRAh5lAJ9H+xGhFN43R07/keAalXclnfgcEgCfdDt0
pu/hiQ0Xg2QaE3FfxuKRFSs=
=1+2L
-----END PGP SIGNATURE-----