massiv-crap Mailing List for Massively multiplayer game middleware

>A vyzkousels zmenit to near_distance?
S hodnotou 0=2E5 jak psal markoid mi to taky slape=2E
Vypada to nadherne=2E
Octa

--------------------------------------------------------------------
mail2web - Check your email from the web at
http://mail2web=2Ecom/ =2E

>A vyzkousels zmenit to near_distance?

Kdyby si to zmenil, jak jsem psal, musi mu to uz fungovat. Holt dokud to =
nebude na cvs, muzem tu psat, co chcem, Octa si toho stejne nevsimne =
(viz createobject a "nemuzu to dva tydny prelozit").

>Jinak fakt nevim, budu muset zjistit, co je ten Radeon Mobility zac. =
Jestli je=20
>to neco jako Radeon 128 (nebo jak se to jmenovalo, takove to TNT), tak =
ty=20
>mely OpenGL drivery hodne mizerny, takze tak. Mozna nezvlada, ze =
prepinam=20
>orientaci front-face trojuhelniku sem tam, ale to jinak udelat nejde... =
(ne=20
>ze by tu nekdo mohl tusit o cem to mlzim...)

Jeden trojuhelbik je ve vertex array zadan clockwise druhy ccw?

-- Markoid
=00

On Wednesday 30 of July 2003 20:52, Ondrej Pecta wrote:

> Urcite mam 32bit, jak Z-buffer, tak barevnou hloubku. Navic mam
> nejvyssi kvalitu zobrazovani 3D ( jak Directx, tak OPENGL )
> Octa

A vyzkousels zmenit to near_distance?
Jinak fakt nevim, budu muset zjistit, co je ten Radeon Mobility zac. Jestli je 
to neco jako Radeon 128 (nebo jak se to jmenovalo, takove to TNT), tak ty 
mely OpenGL drivery hodne mizerny, takze tak. Mozna nezvlada, ze prepinam 
orientaci front-face trojuhelniku sem tam, ale to jinak udelat nejde... (ne 
ze by tu nekdo mohl tusit o cem to mlzim...)

-- Stoupik

>Ne, nejsou to zadne repository. Class kinds zni divne, ale repository =
to neni.

Proc ne? To je presne to co repository v Corbe, tj. Uloziste, kde jsou =
zaregistrovane nejake tridy. Repositorry zpristupnuje typeinfo techhle =
trid. Jediny rozdil je, ze v corbe se k repository databazi pristupuje =
dynamicky, u nas se repository staticky linkuje do exe.

-- Markoid
=00=0A=
>
>-- Stoupik
>
>
>
>

[Message truncated. Tap Edit->Mark for Download to get remaining =
portion.]
=00

On Wednesday 30 of July 2003 21:42, Marek Vondrak wrote:
> >1. Z-buffer problemy:
> >Pravdepodobne poustis Massiv na 16bit desktopu, takze mas 16bit zbuffer a
> >rozsah near-plane-far-plane je moc velky, takze je to znacne nepresne.
> > Zvetsi v camera.cpp hodnotu near_distance, 0.001 je naprasto silene male
> > cislo. Melo by to byt tak 0.1, ale pokud do bude porad blbnout, zvys to
> > klidne na 1.0. Nema moc smysl snizovat far_distance (dulezity je podil,
> > ne rozdil), takze pokud near_distance 1.0 nepomuze, je to v necem jinem.
> > Az najdes rozumnou hodnotu, u ktere to na 100% neblbne, commitni to.
>
> Staci tam frknout 0.05. Ale podivuje me, ze to na tom zalezi. Chapal bych
> to v SW rendereru, kde se do zbufferu bude z implemetnacnich duvodu ukladat
> 1/z, tudiz prilis blizke hodnoty muzou zpusobovat pretekani 16-bit hodnoty
> (tudiz omezeni, ze z >= epsilon, zajisti, ze 1/z < 65k). V HW se snad
> uklada primo z, ne?

Ne, taky 1/z, z tychz implementacnich duvodu. Pretekani nehrozi, ale kdyz je 
near distance hodne mala, vetsina hodnot z tech 16bitu pada do hrozne 
blizkych vzdalenosti a ve vetsich uz je ta kvantizace hrozne videt. Dej tam 
radsi vetsi cislo, tak 0.5.


-- Stoupik

On Wednesday 30 of July 2003 18:39, Petr Tovarys wrote:
> Caues,
> Co znamena tadle hlaska
>
> Warning: Nothing is known about directory 'src/demo/client/ui', determining
> depe
> ndencies for 'src/demo/client/ui/game_interface.cpp'.
> ?
> Asi to nejak souvisi s tim, ze neni .mkgen_cache
> soubor pro src__demo__client__ui (mel by tam vubec byt?).

Mel by tam byt.
Znamena to asi to, ze jsou nekde spatne includes - zjisti, pri jakem 
makefile.gen to dela, je tam napr. potiz, ze lib/client includi z client, ale 
nejak tak divne, ze se tam musej vsechny ty podadresare dopsat rucne, myslim. 
Podivej se na to, mel by tam byt uz takhle ohackovany renderer.

(posilam booviemu cc, protoze se zda, ze sourceforge blacklistuje neketere 
volny smtp servery :-)

-- Stoupik

On Wednesday 30 of July 2003 21:42, Marek Vondrak wrote:

> No, dale by se mely poklidit ty class kinds (prejmenovat na repository) a
> pak kdyby ses mezi reci nudil, asi zrusit i ten RemoteCall.

Ne, nejsou to zadne repository. Class kinds zni divne, ale repository to neni.
A nudit se budu 14 dni, ale nebudu mit comp, takze muzu leda tak vedecky 
badat.

-- Stoupik

Caues,
Na cvs sem hodil upravenou versi system.cpp jak
jsem psal v minulem mailu, takze ted by mel
klient jet uuuuuultra rychle :)

Petr

From: "Stepan Vondrak"


> On Monday 28 of July 2003 23:26, Petr Tovarys wrote:
> 
> > Takze migracni zpravy od klienta, ktere prijdou po
> > startu archivace se nebudou zalohovat.
> 
> A je to urcite dobre? Fakt uz do toho moc nevidim...


Jo, melo by to byt dobre.
Tyto objekty od klienta prijdou az po te,
co se provede takovy ten "distribuovany rez",
takze do archivace nepatri a ani nemohou
zmodifikovat objekt, ktery pude do zalohy.


Petr

>> Navic mam
>>nejvyssi kvalitu zobrazovani 3D ( jak Directx, tak OPENGL )

MV> Jo, to je prece videt z toho screenshotu, to nam nemusis prece psat.
MV> -- Markoid
 
No tak jasny to myslim neni. Kdyz si to clovek nejak ohackuje ( tweak,
overclock atd ) tak to muze vypadat sice hezky, ale bude to fungovat
treba spatne ( vypadavani textur atd. ). To ale neni muj pripad.
Octa

> Navic mam
>nejvyssi kvalitu zobrazovani 3D ( jak Directx, tak OPENGL )

Jo, to je prece videt z toho screenshotu, to nam nemusis prece psat.
-- Markoid
=00

>> To prave nevim. Preci jenom rozdil mezi Float32 a Float64 je zejmena =
v
>> presnosti, zatimco u Int32 a Int64 v rozsahu. -- Markoid
>
>Abych rekl pravdu nechapu, co ma ten typedef na int znamenat - k cemu =
se ma=20
>pouzivat? Pokud to ma byt "int typ majici stejny pocet bitu", pak to ma =
byt=20
>Int64. Pokud to znamena neco jineho, pak co?
>
S velikosti integeru v bitech to nema mit nic spolecneho. Je to typ, =
ktery se vraci z to_integer().
-- Markoid
=00age truncated. Tap Edit->Mark for Download to get remaining portion.]
=00

On Wednesday 30 of July 2003 00:04, Marek Vondrak wrote:
> >Zdar,
> >tak ten terrain renderer mi funguje nejak podivne, mam nejnovejsi
> >ovladace na ATI RADEON mobility a zda se, ze vzdycky jednu to stranu
> >to nejak spatne kresli - je videt to, co by melo byt schovane.
>
> To mi dela presne taky (plus na dalsich dvou kartach uplne stejne) a Stepan
> se me furt snazi presvedcit, ze je chyba u me.

Ne, chyba je v tom, ze nemam dost informaci, abych zjistil, v cem to je. 
Doufam, ze je to v tom 16bit zbuffer (i kdyz ten Octuv screenshot vypada o 
dost hroznejc nez od Markoida), jinak fakt nevim.

-- Stoupik

SV> On Tuesday 29 of July 2003 23:43, Ondrej Pecta wrote:
>> Zdar,
>> tak ten terrain renderer mi funguje nejak podivne, mam nejnovejsi
>> ovladace na ATI RADEON mobility a zda se, ze vzdycky jednu to stranu
>> to nejak spatne kresli - je videt to, co by melo byt schovane.
>> Octa

SV> Fakt divny, je to hodne blbe. Mohlo by to byt 16bit zbufferem, ale nevim. 
SV> Vyzkousej zmeni near_distance v camera.cpp na 1.0 (viz muj jiny mail), jinak 
SV> nevim, leda pucit si radeon.

SV> -- Stoupik

Urcite mam 32bit, jak Z-buffer, tak barevnou hloubku. Navic mam
nejvyssi kvalitu zobrazovani 3D ( jak Directx, tak OPENGL )
Octa

On Wednesday 30 of July 2003 00:02, Marek Vondrak wrote:
> >Vydrzel jsem 2 minuty,
> >breaknul jsem to a spustil znovu a texturu terenu si v pohode stahnul
>
> Zatim feature, protoze update textury by znamenal nutnost pregenerovat
> teren.

Oprava: update textury funguje v pohode - smazte si jenom adresar s texturami 
a uvidite (celkem cool imo). Update materialu je problem.

-- Stoupik

On Tuesday 29 of July 2003 23:52, Ondrej Pecta wrote:
> ahoj, smazal jsem u klienta cely adresar data, pustil ho a nechal ho, aby
> si to na pozadi stahnul. Nevim proc, ale stahnul se mi jenom backgroud a
> kosticek misto textury terenu jsem se nezbavil. Vydrzel jsem 2 minuty,
> breaknul jsem to a spustil znovu a texturu terenu si v pohode stahnul

To je "dobre", popisoval jsem to v jinem mailu. Teren se buildi do render 
struktur (pouzije se material default) a pokud se stahne material "grassy" az 
potom, je nutne teren prebuildit cely znovu, coz asi bude delat 
TerrainManager.

-- Stoupik

On Tuesday 29 of July 2003 23:43, Ondrej Pecta wrote:
> Zdar,
> tak ten terrain renderer mi funguje nejak podivne, mam nejnovejsi
> ovladace na ATI RADEON mobility a zda se, ze vzdycky jednu to stranu
> to nejak spatne kresli - je videt to, co by melo byt schovane.
> Octa

Fakt divny, je to hodne blbe. Mohlo by to byt 16bit zbufferem, ale nevim. 
Vyzkousej zmeni near_distance v camera.cpp na 1.0 (viz muj jiny mail), jinak 
nevim, leda pucit si radeon.

-- Stoupik

On Tuesday 29 of July 2003 22:55, Marek Vondrak wrote:
> >Nema to byt Int64?
>
> To prave nevim. Preci jenom rozdil mezi Float32 a Float64 je zejmena v
> presnosti, zatimco u Int32 a Int64 v rozsahu. -- Markoid

Abych rekl pravdu nechapu, co ma ten typedef na int znamenat - k cemu se ma 
pouzivat? Pokud to ma byt "int typ majici stejny pocet bitu", pak to ma byt 
Int64. Pokud to znamena neco jineho, pak co?

-- Stoupik

On Wednesday 30 of July 2003 00:08, Ondrej Pecta wrote:

> V dokumentaci windows se vyskutuje, ze navratova hodnota muze byt jak
> SOCKET_ERROR, tak i hodnota mensi nebo rovna pocetu bytu, ktere posilam.
> U Unixu jsem zadnou takovou zminku nenasel. Co jsem ale nasel, ze je v
> win32/unix sockets ( opet ) peknej rozdil v tom, co ty prikazy vraci.
> Dokonce kazdy unix vraci neco jineho ( jeden EWOUDLBLOCK, jiny treba
> EAGAIN a pry je mezi tim nejaky rozdil, to jsem se docetl zase jinde
> ), navic pry ve Win95 to funguje vubec vselijak a pokud to vrati
> WSAEWOULDBLOCK, tak to jeste nemusi znamenat vubec nic. No a mam
> pocit, ze windows taky klidne vrati mensi pocet bytu odeslanych, pokud
> jsou buffery plne a musi se to poslat bud blokujicim send prikazem
> nebo pres prikaz select, ktery je zase tak nespolehlivy, ze se na
> nejakych platformach neda pouzit. Tohle je fakt orisek.

Dival jsem se do headeru od linuxu a EAGAIAN a EWOULDBLOCK je ta sama hodnota. 
Ale radsi to zmen na if( result == EAGAIN || result == EWOULDBLOCK ), ukodit 
to nemuze. To by melo v Unixu stacit, rozhdone by to nemelo vracet zadne jine 
zaporne cislo nez -1 (error).

-- Stoupik

Caues,
Co znamena tadle hlaska

Warning: Nothing is known about directory 'src/demo/client/ui', determining
depe
ndencies for 'src/demo/client/ui/game_interface.cpp'.
?
Asi to nejak souvisi s tim, ze neni .mkgen_cache
soubor pro src__demo__client__ui (mel by tam vubec byt?).


Petr

Sorry tenhle mail se zatoulal, posilal jsem ho rano, ale vecer mi to
uz po vasich commitech slo zkompilovat.
Zapomente na to.
Octa

omc> Cau,
omc> uz me to trosku toci, furt to nejde zkompilovat, situace je jako minuly
omc> tyden.

omc> c:\Projekt\massiv\massiv\src\core\pointer\pointer_wrappers.h(89) : error
omc> C2664: 'Massiv::Core::ObjectPointer<Base>::ThisObjectPointer
omc> &Massiv::Core::ObjectPointer<Base>::operator =(const Massiv::Core::ObjectId
omc> &)' : cannot convert parameter 1 from 'const
omc> Massiv::Core::CreateObject<Type>' to 'const Massiv::Core::ObjectId &'
omc>         with
omc>         [
omc>             Base=Massiv::Core::StackPointerBase<Massiv::Core::StrongPointerT
omc> raits<Massiv::Core::ResultObject,Massiv::Core::DefaultCast<Massiv::Core::Res
ultObject>>,Massiv::Core::LocalProxy<Massiv::Core::ResultObject>>>
omc>         ]
omc>         and
omc>         [
omc>             Type=Massiv::Core::ResultObject
omc>         ]
omc>         Reason: cannot convert from 'const
omc> Massiv::Core::CreateObject<Type>' to 'const Massiv::Core::ObjectId'
omc>         with
omc>         [
omc>             Type=Massiv::Core::ResultObject
omc>         ]
omc>         No constructor could take the source type, or constructor overload
omc> resolution was ambiguous
omc>         c:\Projekt\massiv\massiv\src\core\object\rpc.cpp(212) : see
omc> reference to function template instantiation
omc> 'Massiv::Core::Pointer<Type,Cast>
omc> &Massiv::Core::Pointer<Type,Cast>::operator =(const Ptr &)' being compiled
omc>         with
omc>         [
omc>             Type=Massiv::Core::ResultObject,
omc>             Cast=Massiv::Core::DefaultCast<Massiv::Core::ResultObject>,
omc>             Ptr=Massiv::Core::CreateObject<Massiv::Core::ResultObject>
omc>         ]

omc> Nerikejte mi, ze to vsem funguje...nebo neco delam blbe?
omc> Octa

omc> --------------------------------------------------------------------
omc> mail2web - Check your email from the web at
omc> http://mail2web.com/ .

SV> Takze tedka odstreleni klienta funguje (vsechno jede dal), po odstreleni
SV> service spadne server na panic v net_buffers.cpp: Cannot restore connection 
SV> to a server (coz nevim jestli je dobre, ale rekneme ze ano).

Jo tohle je zatim v _poradku_.

SV> - Handlovani EWOULDBLOCK (nebo kdyz se neposle vsechno, coz netusim jestli se
SV> vubec muze stat) by takhle do budoucna byt nemohlo. Nevim, kdy k tomu vubec 
SV> muze dojit, asi pri zahlceni site kdyz se preplnej systemove buffery? Nebo 

V dokumentaci windows se vyskutuje, ze navratova hodnota muze byt jak
SOCKET_ERROR, tak i hodnota mensi nebo rovna pocetu bytu, ktere posilam.
U Unixu jsem zadnou takovou zminku nenasel. Co jsem ale nasel, ze je v
win32/unix sockets ( opet ) peknej rozdil v tom, co ty prikazy vraci.
Dokonce kazdy unix vraci neco jineho ( jeden EWOUDLBLOCK, jiny treba
EAGAIN a pry je mezi tim nejaky rozdil, to jsem se docetl zase jinde
), navic pry ve Win95 to funguje vubec vselijak a pokud to vrati
WSAEWOULDBLOCK, tak to jeste nemusi znamenat vubec nic. No a mam
pocit, ze windows taky klidne vrati mensi pocet bytu odeslanych, pokud
jsou buffery plne a musi se to poslat bud blokujicim send prikazem
nebo pres prikaz select, ktery je zase tak nespolehlivy, ze se na
nejakych platformach neda pouzit. Tohle je fakt orisek.

SV> - Melo by tam vsude pribyt rozumnejsi handlovani chyb (Unix i Win32):

Souhlas. Bude to reportit errno nebo WSAGetLastError podle platformy.

Octa

>Nema to byt Int64?
To prave nevim. Preci jenom rozdil mezi Float32 a Float64 je zejmena v =
presnosti, zatimco u Int32 a Int64 v rozsahu.
-- Markoid
=00

On Tuesday 29 of July 2003 18:47, mas...@li... 

> Index: math.h
> ===================================================================
> RCS file: /cvsroot/massiv/massiv/src/core/global/math.h,v
> retrieving revision 1.5
> retrieving revision 1.6
> diff -C2 -d -r1.5 -r1.6
> *** math.h	23 Jul 2003 19:34:17 -0000	1.5
> --- math.h	29 Jul 2003 16:41:47 -0000	1.6
> ***************
> *** 166,169 ****
> --- 166,171 ----
>       /// The type.
>       typedef Float32 FloatType;
> +     /// Paired integer type.
> +     typedef Int32 IntegerType;
>
>   public:
> ***************
> *** 350,353 ****
> --- 352,357 ----
>       /// The type.
>       typedef Float64 FloatType;
> +     /// Paired integer type.
> +     typedef Int32 IntegerType;

Nema to byt Int64?

-- Stoupik

Cau,

Tak bych se chtel omluvit panu Markoidu, protoze nejaky screenshot mi poslal. 
Ne ze bych z nej teda neco poznal. Jak se to chova kdyz to rotuje? Muzes 
poslat vic screenshotu za sebout?

Mne to tady funguje :-)

-- Stoupik