You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(3) |
Aug
(3) |
Sep
(5) |
Oct
(12) |
Nov
(11) |
Dec
(12) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
(7) |
Feb
(4) |
Mar
(5) |
Apr
(3) |
May
(4) |
Jun
|
Jul
(19) |
Aug
(20) |
Sep
(43) |
Oct
(91) |
Nov
(195) |
Dec
(123) |
| 2003 |
Jan
(67) |
Feb
(140) |
Mar
(151) |
Apr
(110) |
May
(146) |
Jun
(141) |
Jul
(163) |
Aug
(228) |
Sep
(91) |
Oct
(129) |
Nov
(215) |
Dec
(268) |
| 2004 |
Jan
(210) |
Feb
(204) |
Mar
(161) |
Apr
(16) |
May
(24) |
Jun
(19) |
Jul
(4) |
Aug
|
Sep
(28) |
Oct
(7) |
Nov
|
Dec
(2) |
| 2005 |
Jan
(1) |
Feb
(1) |
Mar
(1) |
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
(4) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2007 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2008 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
1
(4) |
2
(8) |
3
(14) |
4
(11) |
5
(6) |
|
6
(11) |
7
(2) |
8
|
9
(1) |
10
|
11
(1) |
12
(2) |
|
13
(6) |
14
(9) |
15
(4) |
16
(1) |
17
|
18
|
19
(9) |
|
20
(6) |
21
(5) |
22
(5) |
23
(7) |
24
(5) |
25
(8) |
26
(2) |
|
27
(1) |
28
(7) |
29
(15) |
30
(9) |
31
(4) |
|
|
|
From: Petr T. <pto...@ss...> - 2003-07-31 18:11:02
|
Caues, Asi hlavne pro stepana. Pokud nemas nic proti, zavedu do overlay objektu relaci parent/child - pri kresleni se nakresli nejdrive parent a pak jeho children. V overlay manageru se bude registrovat pouze top-most parent. Soucasne s tim, pokud bude invisible parent, nenakresli se ani childi. A hlavne pozice childu bude relativne k parentu. Hlavnim duvodem pro todle je, aby sly childi a parenti animovat - bez child/parent k tomu je potreba childy registrovat v overlay manageru, ale zde nastava problem, ze neni moznost rozumne skryvat/odkryvat childy, a vubec je posunovat relativne k parentu. Petr |
|
From: Marek V. <mar...@ce...> - 2003-07-31 14:13:41
|
Ahoj, Tedka mi to spadlo v tcpobuffer::flush(), protoze benc je Null. Bylo by = dobre net projit a dat tam minimalne asserty, v tomhle pripade zjistit, = proc je to null, a pokud je to valid hodnota, proc se to nekontroluje. -- Markoid =00 |
|
From: Marek V. <mar...@ce...> - 2003-07-31 09:50:24
|
>Zbezne jsem prolitnul server lib a vypada to uz celkem hotove, tj. uz = by mel=20 >Markoid a Boovie dohodnout a rozdelit praci na jednotlivych entitach = jako=20 >jsou itemy, prasata apod. - nacrtnout, co by to melo umet a nechat Hafa = s=20 >Octou se s tim nejak potrapit. No muj plan je nasledujici: Otestovat soucasnou verzi. Udelat tam ty materialy (dalsi enum map), modifikace vyskove mapy = (diferencialni vyskova mapa), oblastni dotazy, tridy entit. Dale se podivat na hierarchii do Quark a udelat zakladni tridy pro = chodici a letajici entity. V core zacit dElat statistiky pro lokalni swapovani a load balancing. Cili je toho dost. Pokud by nekdo mel dojem, ze by s tim mohl vypomoct, = tak ma moznost se domluvit. Nekdo dalsi zatim muze vylepsit ui konzole - = skrolovani, barvy, podklad, ... -- Markoid =00 pozdravy pro Honzika. -- Markoid =00 |
|
From: Stepan V. <sv...@vo...> - 2003-07-31 09:30:15
|
Cau, Zbezne jsem prolitnul server lib a vypada to uz celkem hotove, tj. uz by mel Markoid a Boovie dohodnout a rozdelit praci na jednotlivych entitach jako jsou itemy, prasata apod. - nacrtnout, co by to melo umet a nechat Hafa s Octou se s tim nejak potrapit. Testim se na nove cool featury, ktere tam za tech 14 dni pribudou :-) Vyhrady k soucasne implementaci (to malo co jsem procetl nemam), mozna az na rezervaci tiles: - Upozorneni: sync volani je-li objekt lokalni _neni_ zatim nijak optimalizovano, takze pokud driv nez bude zpracovano nekdo jiny zavola sync RPC nelokalne, dokonceni toho lokalniho bude zaseknuto (kvuli te divne stackove implementaci). Melo by byt trivialni todle zmenit, ale radsi to tedka delat nebudu, abych neco v rpcgenu nerozbil. - Jestli spravne chapu rezervovani, funguje to diky tomu, ze v rezervacni mape muze byt jedna entita vickrat - takze pokud se stary a novy box prekryvaji, release zrusi jenom jednu ze dvou rezervaci, ktere tam jsou. Dost me to zmatlo a uz jsem to psal, jak je to blbe. Radeji bych to videl poradne zdokumentovane, je to celkem tricky (klidne v kodu, ne v doxygenu). - Ten FIXME s tim, ze se orientace ignoruje, bych zmenil na Note :-) To je tak vsechno, neco bych sice napsal jinak, ale rozhodne nic vyznamneho. -- Stoupik |
|
From: Petr T. <pto...@ss...> - 2003-07-30 22:36:31
|
From: "Stepan Vondrak"
> Dneska vecer commitnu asi posledni featuru pred odjezdem a to:
> osvetleny teren
> 1. Funguje to. Tecka. Pripadne jak rychle a tak. Pod Linuxem mi to v Mese
> (software OpenGL renderer) beha na terenu 32*32 s osvetlenim, mipmappingem
a
> bilinearnim filteringem na Athlon/500MHz uplne v pohode rychle (asi
10fps),
> takze by se vam to melo hybat aspon tak.
Na mem stroji pod w2k to funguje dobre a vypada to dobre (mnam mnam).
K rychlosti:
Verse pro debug na CVS ma limit 25 fps maximum, tak bacha na to.
V system.cpp si zmente funkci do_next_tick() na
void do_next_tick()
{
System::next_tick();
#ifdef OPTION_DEBUG
if( !System::is_client() )
{
Thread::sleep( 40 );
}
#endif // OPTION_DEBUG
}
S toudle modifikaci bude dostavat klient maximum cpu.
U me pak jede se svetly plynule, >= 60 fps.
Petr
|
|
From: Petr T. <pto...@ss...> - 2003-07-30 22:36:30
|
Caues, asi pro Markoida pouze:
Na DEBUG=3 nejde zkompilit sector.cpp.
Hlasi to, ze PDictionaryBase nemuze pristupovat
na private membery v PDictionaryBase::Iterator.
Bud msvc6 nezvlada toho frienda na PDictionaryBase,
nebo nejaky problem s debug_storage.h
a OPTION_LIBDEBUG?
Na DEBUG=2 kompilace projde.
Petr
cl /nologo /Zm200 /W3 /G5 /ZI /MDd /Fp"..\..\..\..\.bin\win32.x86_msvc6
.libdebug.stlport\src\demo\lib\server\precompiled.pch"
/Fd"..\..\..\..\.bin\win3
2.x86_msvc6.libdebug.stlport\src\demo\lib\server\debug_database.pdb" /GX /GR
/c
/Fo..\..\..\..\.bin\win32.x86_msvc6.libdebug.stlport\src\demo\lib\server\sec
tor.
obj /I. /I..\.. /I..\..\..\core /DSYSTEM_WIN32 /DCOMPILER_MSVC /DARCH_X86
/DOPT
ION_STLPORT /DOPTION_DEBUG /DOPTION_LIBDEBUG
/Ie:\apps\develop\libs\STLport\stlp
ort /DWIN32_LEAN_AND_MEAN /DHASH_AUTO_PTR_IS_STRUCT /D_STLP_DEBUG
/D_STLP_DEBUG
_ALLOC /D_STLP_DEBUG_UNINITIALIZED /Ie:\apps\develop\msvc\vc98\include\sdl
/Tp
sector.cpp
p:\projects\massiv\massiv\src\core\property\prop_dictionary.h(969) : error
C2248
: 'dictionary' : cannot access private member declared in class
'Massiv::Core::P
DictionaryBase<class Massiv::Core::PInt<int,32>,class
Demo::Lib::Sector::TileRes
ervation,class Massiv::Core::DefaultPropertyHashKey<class
Massiv::Core::PInt<int
,32> >,class Massiv::Core::DefaultPropertyEqualKey<class
Massiv::Core::PInt<int,
32> > >::Iterator'
p:\projects\massiv\massiv\src\core\property\prop_dictionary.h(669) :
see
declaration of 'dictionary'
p:\projects\massiv\massiv\src\core\property\prop_dictionary.h(966) :
whi
le compiling class-template member function 'void __thiscall
Massiv::Core::PDict
ionaryBase<class Massiv::Core::PInt<int,32>,class
Demo::Lib::Sector::TileReserva
tion,class Massiv::Core::DefaultPropertyHashKey<class
Massiv::Core::PInt<int,32>
>,class Massiv::Core::DefaultPropertyEqualKey<class
Massiv::Core::PInt<int,32>
> >::erase(const class Massiv::Core::PDictionaryBase<class
Massiv::Core::PInt<in
t,32>,class Demo::Lib::Sector::TileReservation,class
Massiv::Core::DefaultProper
tyHashKey<class Massiv::Core::PInt<int,32> >,class
Massiv::Core::DefaultProperty
EqualKey<class Massiv::Core::PInt<int,32> > >::Iterator &)'
p:\projects\massiv\massiv\src\core\property\prop_dictionary.h(970) : error
C2248
: 'check_validity' : cannot access protected member declared in class
'Massiv::C
ore::DebugStorage::DebugIterator'
p:\projects\massiv\massiv\src\core\global\debug_storage.h(115) : see
dec
laration of 'check_validity'
p:\projects\massiv\massiv\src\core\property\prop_dictionary.h(966) :
whi
le compiling class-template member function 'void __thiscall
Massiv::Core::PDict
ionaryBase<class Massiv::Core::PInt<int,32>,class
Demo::Lib::Sector::TileReserva
tion,class Massiv::Core::DefaultPropertyHashKey<class
Massiv::Core::PInt<int,32>
>,class Massiv::Core::DefaultPropertyEqualKey<class
Massiv::Core::PInt<int,32>
> >::erase(const class Massiv::Core::PDictionaryBase<class
Massiv::Core::PInt<in
t,32>,class Demo::Lib::Sector::TileReservation,class
Massiv::Core::DefaultProper
tyHashKey<class Massiv::Core::PInt<int,32> >,class
Massiv::Core::DefaultProperty
EqualKey<class Massiv::Core::PInt<int,32> > >::Iterator &)'
|
|
From: Marek V. <mar...@ce...> - 2003-07-30 19:43:46
|
>Jeste par poznamek: >1. Color jsem samozrejme udelat stihnul :-) Mozna by se to mohlo vyuzit v konzoli, namisto tech "P", "C" prikazu pro = barvy. >2. Nic jineho z linearni algebry neni potreba. Jestli neco, pak matice, = ale=20 >bez tech se ja v pohode obejdu, zadne slozite skladani neni potreba, = zbytek=20 >obstara bez problemu Orientation a Vector3. Teda pokud nechces delat=20 >kvaterniony. Myslel jsem treba Plane napr. Pro ucely oblastnich dotazu. To se ale = muze zadefinovat jako ValueType. >K value types: >Pokud te tak boli, ze to jsou property, klidne si to predelej na value = type,=20 Samozrejme to necham byt tak jak to je. Ale aby to bylo pouzitelne, je = potreba zajistit ty konverze. Bud jako u Vectoru pres nejakou vectordata = tridu nebo jak jsem spis navrhoval zdednim POrientation z obecneho = Orientation a dodefinovat vhodne konstruktory, podobne SOrientation. -- Markoid =00ik > > >------------------------------------------------------- >This SF.Net email sponsored by: Free pre-built ASP.NET sites including >Data Reports, E-commerce, Portals, and Forums are available now. >Download today and enter to win an XBOX or Visual Studio .NET. >http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01= /01 >_______________________________________________ >Massiv-devel mailing list >Mas...@li... >https://lists.sourceforge.net/lists/listinfo/massiv-devel > > > =00 |
|
From: Marek V. <mar...@ce...> - 2003-07-30 19:43:35
|
>Nevim, jestli stihnu nejak pred odjezdem uklidit factgen, asi bych tam = frknul=20 >dedicny class attribute "value_type", ktery bude mit ValueType a = uzivatel by=20 >to nemel nikde rucne psat. Tridy s atributem "value_type" pujdou = pouzivat=20 >jako argumenty apod. [to jenom proto, abych nemusel testovat "if dedi z = >ValueType", prijde mi to cistsi]. Jo, tak nejak jsem to v podstate myslel. >Je jeste neco nutne uklidit nez odjedu? Koukal jsem, zes neco zmenil v=20 >metaobject, ale presne jsem nepochopil o co jde a co s tim mam ja = delat. Zrusil jsem z ObjectProperty tu nacachovanou hodnotu complete_object. = Takze tedka se vzdycky provadi downcast(). Z backward kompatibility = (protoze to pouziva factgen) tam zustalo get_complete_object(). Ale obe = funkce by mely byt ekvivalentni. Ja bych asi zrusil ten downcast() a = nechal get_complete_object() [ resp. zrusil stary get_complete_object() = a downcast() prejmenoval na get_complete_object() ]. No, dale by se mely poklidit ty class kinds (prejmenovat na repository) = a pak kdyby ses mezi reci nudil, asi zrusit i ten RemoteCall. -- Markoid =00-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 >_______________________________________________ >Massiv-devel mailing list >Mas...@li... >https://lists.sourceforge.net/lists/listinfo/massiv-devel > > =00 |
|
From: Marek V. <mar...@ce...> - 2003-07-30 19:43:24
|
>1. Z-buffer problemy: >Pravdepodobne poustis Massiv na 16bit desktopu, takze mas 16bit zbuffer = a=20 >rozsah near-plane-far-plane je moc velky, takze je to znacne nepresne. = Zvetsi=20 >v camera.cpp hodnotu near_distance, 0.001 je naprasto silene male = cislo. Melo=20 >by to byt tak 0.1, ale pokud do bude porad blbnout, zvys to klidne na = 1.0.=20 >Nema moc smysl snizovat far_distance (dulezity je podil, ne rozdil), = takze=20 >pokud near_distance 1.0 nepomuze, je to v necem jinem. Az najdes = rozumnou=20 >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 >=3D epsilon, zajisti, ze 1/z < = 65k). V HW se snad uklada primo z, ne? >2. Riva128 blending problemy: >Trochu jsem to zmenil, prednasobuji barvu vertexu alphou, takze = blending je=20 >uplne trivilani aditivni, coz musi fungovat vsude. Pokud ne, je tam = nekde=20 >bug. Tohle jsem jeste nezkousel, protoze jsem si to jeste neupdatnul z CVS. -- Markoid =00SF.Net email sponsored by: Free pre-built ASP.NET sites including >Data Reports, E-commerce, Portals, and Forums are available now. >Download today and enter to win an XBOX or Visual Studio .NET. >http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01= /01 >_______________________________________________ >Massiv-devel mailing list >Mas...@li... >https://lists.sourceforge.net/lists/listinfo/massiv-devel > > =00 |
|
From: Stepan V. <sv...@vo...> - 2003-07-30 18:35:04
|
Pro Markoida... Co me tak napadlo ze by mohlo zpusobovat ty chybky: 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. 2. Riva128 blending problemy: Trochu jsem to zmenil, prednasobuji barvu vertexu alphou, takze blending je uplne trivilani aditivni, coz musi fungovat vsude. Pokud ne, je tam nekde bug. -- Stoupik |
|
From: Petr T. <pto...@ss...> - 2003-07-30 18:34:38
|
From: "Stepan Vondrak" > Kdo dela replica manager? Ja? Ty nebo ten, koho tim poveris :-) (teda ne ze by bylo moc na vyber) > > Ja to zatim videl tak, ze to bude stejne jako se sektory - klient bude > > udrzovat nacachovany inventory ve vlastnich strukturach, pri updatnuti > > repliky postavy si vycuca znovu vsechno info o batohu, vyresi kolize > > (objekt drzen v kurzoru uz neexistuje) atd. > > Takze UI si vlastne zaregistruje pouze callback, kdyz se updatne > > replika hrace (jeho batohu). > > Ok, todle delas asi ty, ze? Asi jo. > > Abilities bude ukazovat to vylepsovani. > > Co radek to nejaka schopnost, sloupce budou jak moc je > > upgradovana. Tzn. ikonka boty bude rychlost. Kdyz hrac > > obuje rychlobotku, v abilities bude v jednom radku > > botky dve nebo tri podle sily upgradu. > > Takze abilities nejsou stacke vlastnosti svazane s postavou ale muzou se menit > podle toho, co ma za veci? Nebylo by pak lepsi mit jenom seznam abilities > (jmeno) a hodnota ability ciselne (napr. base ability [vlastnost postavy] a > current ability [kdyz se pricte vliv veci)? No ono je to asi celkem jedno... Ook, to bude jednodussi - ikonka bude bota, cislo u ni bude jak moc je v tom dobry. Diky tomu muzem mit az 40 abilities :-) > > Spellbook zatim teda neuvazujem, pokud tam nebudeme mit > > teda tu strelu/fireball. > > Ok. Jaky je vlastne duvod odlisovat spells a abilities? Lisi se to > principielne necim? Abilities nejde pouzivat, aspon v puvodnim navrhu, spells lze pouzivat jako itemy v inventorari (pick/select_target). Ale v podstate je to to same, abilities vlastne muzou byt specialni "kouzla". > > Tak vymenime cely model postavicky, to by jit melo jednoduse :) > > A kde ho vlastne vezmem? (natozpak dva ruzne) No tos byl prece ty kdo rikal, ze vybrat modelky z quaka nebo odkud bude trivi? Ja samozrejme muzu sehnat od Undeada libovolny pocet modelu i s animacema v libovolne kratkem case :) Problem je ve 3d formatech fajlu... > > Tzn. pokud u hrace stoji cunik jmenem pepa, hrac muze rict > > "pepa follow" a pepik ho bude nasledovat. > > A to "follow" muzeme doplnovat na tabu :-) Pokud teda pepa hrace driv nesezere :) Petr |
|
From: Stepan V. <sv...@vo...> - 2003-07-30 18:29:21
|
For Markoid's eyes only: Nevim, jestli stihnu nejak pred odjezdem uklidit factgen, asi bych tam frknul dedicny class attribute "value_type", ktery bude mit ValueType a uzivatel by to nemel nikde rucne psat. Tridy s atributem "value_type" pujdou pouzivat jako argumenty apod. [to jenom proto, abych nemusel testovat "if dedi z ValueType", prijde mi to cistsi]. Je jeste neco nutne uklidit nez odjedu? Koukal jsem, zes neco zmenil v metaobject, ale presne jsem nepochopil o co jde a co s tim mam ja delat. (tj. nekoukal jsem na to, tedka nejak nemam moc casu, snad zejtra dopoledne a pak uz nic - porad se nekdo vraci z daleke cesty do zahranici a ja musim poslouchat vesele prihody, misto abych pracoval, coz by samozrejme delal mnohem radsi :-) -- Stoupik |
|
From: Stepan V. <sv...@vo...> - 2003-07-30 18:29:20
|
On Tuesday 29 of July 2003 22:56, Stepan Vondrak wrote: > On Tuesday 29 of July 2003 19:20, Marek Vondrak wrote: > > Ahoj, > > soucasna Orientation je uplne nepouzitelna, protoze je na tom z hlediska > > property/stype kompatibility hur nez Vector. Neexistuje totiz zadny > > zpusob, jak prevadet mezi s-typem a p-typem, cilize se nesmi pouzit v > > signaturach funkci pro IDL. Jinak dle me takovehle veci vubec nemaji v > > jadre co delat, protoze je to lib-specific typ. Klidne to muze byt > > naimplementovano jako nyni konecne povoleny "value typ". Skoda, ze se na > > to nemyslelo driv, protoze to same plati treba pro Color a jine typy z > > linearni algebry, ktere nastesti Stepan zatim nestacil naimplementovat. > > No ze by napsani nejakeho toho konvertovani bylo tak smrtelne tezke mi > neprijde. A opravdu nehodlam ve vsech renderer strukturach a vypoctech mit > veci dedene z Object, dekuji pekne. Jeste par poznamek: 1. Color jsem samozrejme udelat stihnul :-) 2. Nic jineho z linearni algebry neni potreba. Jestli neco, pak matice, ale bez tech se ja v pohode obejdu, zadne slozite skladani neni potreba, zbytek obstara bez problemu Orientation a Vector3. Teda pokud nechces delat kvaterniony. K value types: Pokud te tak boli, ze to jsou property, klidne si to predelej na value type, ale stejnym zpusobem, tj. template ktery umi byt jak stype tak value type (misto property). Pokud by zmeny v clientu mely byt slozitejsi nez zmena using ::Massiv::Core::SOrientation; na using ::Demo::Lib::SOrientation; // nebo kde to bude a kdyby SOrientation melo byt vetsi nez ty 3 floaty nebo melo mit virtualni metody, pak se to zakazuje. -- Stoupik |
|
From: <oc...@ma...> - 2003-07-29 23:50:15
|
Cau,
uz me to trosku toci, furt to nejde zkompilovat, situace je jako minuly
tyden=2E
c:\Projekt\massiv\massiv\src\core\pointer\pointer_wrappers=2Eh(89) : error=
C2664: 'Massiv::Core::ObjectPointer<Base>::ThisObjectPointer
&Massiv::Core::ObjectPointer<Base>::operator =3D(const Massiv::Core::Objec=
tId
&)' : cannot convert parameter 1 from 'const
Massiv::Core::CreateObject<Type>' to 'const Massiv::Core::ObjectId &'
with
[
Base=3DMassiv::Core::StackPointerBase<Massiv::Core::StrongPoin=
terT
raits<Massiv::Core::ResultObject,Massiv::Core::DefaultCast<Massiv::Core::R=
es
ultObject>,Massiv::Core::LocalProxy<Massiv::Core::ResultObject>>>
]
and
[
Type=3DMassiv::Core::ResultObject
]
Reason: cannot convert from 'const
Massiv::Core::CreateObject<Type>' to 'const Massiv::Core::ObjectId'
with
[
Type=3DMassiv::Core::ResultObject
]
No constructor could take the source type, or constructor overload=
resolution was ambiguous
c:\Projekt\massiv\massiv\src\core\object\rpc=2Ecpp(212) : see
reference to function template instantiation
'Massiv::Core::Pointer<Type,Cast>
&Massiv::Core::Pointer<Type,Cast>::operator =3D(const Ptr &)' being compil=
ed
with
[
Type=3DMassiv::Core::ResultObject,
Cast=3DMassiv::Core::DefaultCast<Massiv::Core::ResultObject>,
Ptr=3DMassiv::Core::CreateObject<Massiv::Core::ResultObject>
]
Nerikejte mi, ze to vsem funguje=2E=2E=2Enebo neco delam blbe?
Octa
--------------------------------------------------------------------
mail2web - Check your email from the web at
http://mail2web=2Ecom/ =2E
|
|
From: Marek V. <mar...@ce...> - 2003-07-29 22:09:43
|
>po dnesnim zkompilovani jsem zjistil, ze nefunguje autocomplete napr u >prikazu createobject, call atd. Patrne nefunguje doplnovani object id? Myslim, ze jinak se nic za = posledni mesic nemenilo. -- Markoid =00 |
|
From: Marek V. <mar...@ce...> - 2003-07-29 22:05:48
|
>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. -- Markoid =00 |
|
From: Marek V. <mar...@ce...> - 2003-07-29 22:03:14
|
>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. -- Markoid =00 |
|
From: <mvo...@ce...> - 2003-07-29 22:02:51
|
> Tohle klidne udelam, jen rekni, kde ma byt makro definovano ( aby ti > pak nestoupal adrenalin, az ho hodim treba do system, ze ) a priklad, > co mam jak nahradit a ja to vsude udelam. Object.h? Pouziti je stejne jako u NO_COPY_CONSTRUCTOR apod. > Test uz nezkompiluju asi 2 mesice, nevim, jaka je situace ted, pokud > zkompiluju core, tak se na to mrknu. To ho nezkompilujes ani ted. Vhodne zapoznamkuj obsolete casti (zejmena = serializace systemovych zprav a veci souvisejicich s objectid) a hlavne r= ozchod inicializaci, aby slo pustit to ostatni. -- Markoid |
|
From: Ondrej P. <oc...@ma...> - 2003-07-29 22:00:49
|
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 |
|
From: Ondrej P. <oc...@ma...> - 2003-07-29 21:58:31
|
ahoj, po dnesnim zkompilovani jsem zjistil, ze nefunguje autocomplete napr u prikazu createobject, call atd. Muze me nekdo, kdo v tom ma prsty, navest, co se tam zase menilo, abych to mohl opravit? Bude to rychlejsi, nez ze to budu hledat sam. Octa |
|
From: Ondrej P. <oc...@ma...> - 2003-07-29 21:55:09
|
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 Octa |
|
From: Ondrej P. <oc...@ma...> - 2003-07-29 20:58:32
|
>> - Zadefinuj to makro, treba neco jako: >> #define MASSIV_OBJECT( Type ) \ >> friend class ::Massic::Generated::MetaObjectImpl< Type >; \ >> friend class ::Massiv::Generated::ObjectFactoryImpl< Type >; >> - Dopis jeho pouziti do _VSECH_ managed objectu v celem massivu, v MV> src/core >> (vcetne object/lib) a v demo/lib. MV> Mohl by to udelat nekdo z nevytizenych clenu? Treba Octa? 14 dni mi ted neslo core zkompilovat, vypada to, ze ted uz to pujde. Tohle klidne udelam, jen rekni, kde ma byt makro definovano ( aby ti pak nestoupal adrenalin, az ho hodim treba do system, ze ) a priklad, co mam jak nahradit a ja to vsude udelam. MV> Taky by neskodilo poradne rozchodit core/test, tj. kouknout se do demo, jak Test uz nezkompiluju asi 2 mesice, nevim, jaka je situace ted, pokud zkompiluju core, tak se na to mrknu. Octa |
|
From: Stepan V. <sv...@vo...> - 2003-07-29 20:57:36
|
On Tuesday 29 of July 2003 19:20, Marek Vondrak wrote: > Ahoj, > soucasna Orientation je uplne nepouzitelna, protoze je na tom z hlediska > property/stype kompatibility hur nez Vector. Neexistuje totiz zadny zpusob, > jak prevadet mezi s-typem a p-typem, cilize se nesmi pouzit v signaturach > funkci pro IDL. Jinak dle me takovehle veci vubec nemaji v jadre co delat, > protoze je to lib-specific typ. Klidne to muze byt naimplementovano jako > nyni konecne povoleny "value typ". Skoda, ze se na to nemyslelo driv, > protoze to same plati treba pro Color a jine typy z linearni algebry, ktere > nastesti Stepan zatim nestacil naimplementovat. No ze by napsani nejakeho toho konvertovani bylo tak smrtelne tezke mi neprijde. A opravdu nehodlam ve vsech renderer strukturach a vypoctech mit veci dedene z Object, dekuji pekne. -- Stoupik |
|
From: Stepan V. <sv...@vo...> - 2003-07-29 20:26:48
|
Cau,
Dneska vecer commitnu asi posledni featuru pred odjezdem a to:
osvetleny teren
(fanfary, jasot obecenstva)
Komu to bude blbnout, melo by se to dat vypnout zapoznamkovanim radky
render_manager.set_lighting( true );
v terrain_manager.cpp.
Nove vetsi (3D modely) radeji uz nebudu rozdelavat, rozhodne ne commitovat.
Takze pokud nekomu neco blbne, at se rychle ozve. Booviemu se renderer libil,
Markoid mi psal osobni flames jak mu to vubec nefunguje (ale ani jednou se
nevyjadril, co presne a jak mu to nefunguje), ostatni mlci. Takze neco
napiste, moznosti mate 2:
1. Funguje to. Tecka. Pripadne jak rychle a tak. Pod Linuxem mi to v Mese
(software OpenGL renderer) beha na terenu 32*32 s osvetlenim, mipmappingem a
bilinearnim filteringem na Athlon/500MHz uplne v pohode rychle (asi 10fps),
takze by se vam to melo hybat aspon tak.
2. Nefunguje to. S presnym popisem jak se to chova a s rozumne velkym
screenshotem (kolem 50kB). Pokud nebude prilozen rozumny bugreport, budu
zpravu ignorovat.
Odjizdim v patek, po tydnu se na den vratim (nedele/pondeli) - to tak
maximalne prectu postu, mozna odpovim, ale nic neudelam - a pak jeste na
tyden pryc. Tak si tu uzivejte.
-- Stoupik
|
|
From: Marek V. <mvo...@ce...> - 2003-07-29 17:33:58
|
> > Ahoj, > > pripominam, ze furt nefunguje nastavovani friendu pro factories a > > metaobjects. Takze by se na to Stepan mohl konecne kouknout. -- Markoid > > To je takzvany vserikajici bug report. Protoze tu tedka byl bratranek, za > chvili prijede bracha z Ameriky a pak budu 14 dni pryc, moc toho tedka > nestiham ani stihat nebudu. Takze pokud chces, abych se na to vubec kouknul: > - Zadefinuj to makro, treba neco jako: > #define MASSIV_OBJECT( Type ) \ > friend class ::Massic::Generated::MetaObjectImpl< Type >; \ > friend class ::Massiv::Generated::ObjectFactoryImpl< Type >; > - Dopis jeho pouziti do _VSECH_ managed objectu v celem massivu, v src/core > (vcetne object/lib) a v demo/lib. Mohl by to udelat nekdo z nevytizenych clenu? Treba Octa? Taky by neskodilo poradne rozchodit core/test, tj. kouknout se do demo, jak se zmenilo spousteni systemu, a podle toho to updatnout. Skutecne nemate co na praci? To ani nemuzete treba vylepsit konzoli, net, odstranit fixmes, popr. vybrat si nejakou jinou praci, ktera sice vubec nemusi byt udelana, ale kdyz bude, bude to jenom plus [ kdyz nestacite na to, ce je ted nutne ]? -- Markoid |