JAACOB: jo, ale prusery jako zkurvene scalovani, protoze curaci pridali podporu pro nintendo ds pro vice obrazovek a posrali to, takze to blblo na dvoumonitorovych sestavach, atd, se s tim vyresit daly... a bylo to lepsi nez ngui, se kterym jsem musel delat predtim (a taky ho hackovat jak vztekly), rozhodne pouzitelny oproti predchozim podivnym pokusum :)
psal jsem vlastni gui do unity dvakrat a obcas si rikam ,ze jsem si mel postavit hlavu a do dread efektu narvat to svoje a dodelat do nej potrebne veci :) ted uz to opravdu nehrozi, pokud teda nezmenim dodavatele penez na alkohol a zbrane (uz se "tesim", az se pridam k ostatnim a jebne mne z unrealu, ale s ohledem na to, co mi za posledni dva tri roky obcas udelalo unity....)

JAACOB: jooo, unity a gui.... a to je ten posledni pokus pridany ke konci ctverky aspon jakztakz pouzitelny, i kdyz jako obvykle s unity je tak extremne snadne s tim udelat neco, co ti totalne zabije vykon...
(hlavne... jsou k nemu zdrojaky... takze kdyz uz neco zkurvi, nebo se tam neco kurvi, je jakas takas sance s tim neco udelat)

BYDK: hele ono na osobni mikroprojekty to nebyva kriticke, takze se staci vyhnout nejvic heavy vecem (napr. FindObjectOfType v updatu) a nemusis to moc resit, pokud nebudes mit pech a nevyrobis omylem treba extremne heavy GUI - coz se v Unity da i pri relativne jednoduchem layoutu, protoze jejich GUI je fakt pruser...
Problem pak nastava v pripade, ze delas velky projekt, zdimes z telefonu maximum a potrebujes kazdej prd optimalizovat. U nas treba pro Shadowgun Legends aktualne pisem vlastni GUI renderer aspon pro ingame HUD, protoze ty spajky, ktere vyrabi unitacke GUIcko je neco nepochopitelne otresneho...

JAACOB:Zdravim, jak Vas tak posloucham, tak jsem rad, ze nejsem nejaky extra programator a porad delam primitivni datove struktury a vyuzivam parenteni komponent, proste jednoduche programovani, nejlepe v JS. Defakto jsem nenarazil na nic, co bych nemohl dat dohromady a zda se, ze jsem si usetril hodne nervu. :)

SHIGORBIRDMAN: Ono celkove je na kriticke party nejlepsi pouzivat uplne nejprimitivnejsi datove struktury a prakticky se vyhnout celemu OOP. Jestli budem chtit v budoucnu zneuzit ten Uniti jobsystem, tak se budem muset nejdriv naucit psat vsechno zase trochu jinak...viz:
Unite Austin 2017 - Writing High Performance C# Scripts
https://www.youtube.com/watch?v=tGmnZdY5Y-E

SHIGORBIRDMAN: k temu enumum - mam nejasny pocit, ze v 5.6 tohle uz vyresili, stejne jako par dalsich problemu s boxingem a generovanim garbage, ale jelikoz ja budu jeste nejakou dobu zakousnuty na 5.4 (a ke svemu neuveritelnemu nasrani na 4.7...)

JAACOB: omg... dobre vedet, ze je lepsi pouzivat cisty virtual nez interface :/ (coz obcas kvuli snaze udrzeni nejake cistoty a decouplingu kodu pouzivam...)

APH: ahem, comparery a hashe a mono v unity, prosim nepripominat :) zjisteni ze pro kazdy dictionary pouzivajici jako klic custom struct (cili i ENUM!!!) musim pripisovat vlastni komparer, jinak to sype pri pristupech garbage... eh... ale serializace dictionary aby to fungovalo jak to funguje je kurva primitivni, za predpokladu, ze klice budou samy o sobe serializovatelny. Jenze ne, unity... takze kdyz uz to nekde mam, musim mit serializovatelny seznam klic / polozka a pak si ho v aktivaci prevest na dict...

Listy pridali uz v 2.6? njn... kdyz ja se s tim nemsylem zkousel srat uz za doby, kdy byl mac only a neco v nem prasim uz od nejake 2.1... kurva, ten cas leti :)

nj bezny den s unity dalo by sa zhrnut ;0)
- inak tie shadery - z unity stock shadermi to robi tiez ? - lebo napr. custom editory pre shadery/materialy su cirkus samy osebe a neni to trivialne dobre integrovat do editora
nemozem si spomenut ze by to v serializovanom text subore prehadzovalo polozky - ale ja tak max nastavim trochu pohybem s hybatkami a moc nespekulujem

s dictionaries by - kvoli tomu ze su unordered - museli viac prplat do mona kvoli hashtable a comparerom imho

btw som to vyhrabal - List pridali v 2.6 (minus dve petiletky nazad aTo je pekne)

APH: dela mi to 5.4, obcas pri zmene materialu ma tendence nahodne prehazet poradi textur. Proste sahnu na material a neco zmenim (nastaveni, texturu, cokoli) zmenim mu texturu, preserializuje se a prehazi poradi. Kdyz na nej sahnu znovu, preserializuje se jinak. Jsou to modifikovane uber shadery, ale proc to tohle dela, to mi fakt hlava nebere... beru to proste jako jednu z tech unity dark magic fuckupu, ktere tam proste obcas jsou. Tohle je aspon jen lehka pruda oproti jinym vecem - jako nahodne poskozeni odkazu na interni dll vedouci k nutnosti kompletniho reimportu, jinak nefunguje treba gui, obcasny instant auto crash po smazani predkompilovane dll a jejim nahrazeni zdrojaky, ktery pak zpusobuje tichy crash pri kazdem spusteni, dokud se nesmazou script libraries...
Aktualne me nejvic vyprudil lightmapper v 5.6, a to natolik, ze jsem vzdal upgradovani. Prejebat skripty a lighmap builder a materialy a nejak zase nahackovat funkcnost normalmap pro lightmapy, to bych nakonec nejak zvladl...

Ale kdyz lightmapper v nekterych levelech "crashne", resp si zabere 32 giga fyzicke ram a k tomu plny swap soubor a pak pocitac nedela nic nez ze swapuje, dokud to necrashne (jednou jsem to nechal bezet pres noc)...

Driv to byvalo Unity of Love and Hate, od petky mam pocit ze uz je to jen pure hate :(
zacinam se tesit, az mi to skonci a prejdu za ostatnimi na unreal (kde mi bude praskat zilka z jinych veci, o tom nepochybuju :) minimalne z "bleskove" kompilace c++ nebo tech blueprintovych klikacich sracek ;)

Jinak poradi ve slovniku neni z podstaty nijak definovane, neni to ordererd collection. coz neznamena, ze by ji unity sakra nemohlo serializovat, ale jak rikam, i List<> zacali serializovat az nekdy od 3 neco.

Ad ty promichane properties materialu - neupdatoval jsi mezitim? Muze se stat, ze ti libovolny asset zacne serializovat novejsi verzi (je to videt v textovych assetech - verze serializace).
Plus jeste jsem resil v praci "procistovani" nepouzitych properties materialu pro grafiky a nas resource analyzer. Protoze kdyz na materialu prepinas shadery, on si interne pamatuje vsechny nastavene parametry. Tzn. nastavis material s shaderem1, nastavis props, nastavis mu jiny shader2 a nastavis props, pak se rozhodnes, ze chces radsi pouzit zase shader1 a on si pamatuje nastaveni predesle properties pro shader 1 (a zustanou mu i nepouzite props pro shader 2 zejo). AFAIK treba pripadne reference na textury pri buildu vyhaze, ale v editoru zustavaji...nemuze to souviset?

"proc do prdele po sahnuti do materialu unity prehazi naprosto nahodne vsechny polozky, takze to uz pak fakt nejde comparovat"
to mozno snad v 3.5 ( no dobre 4.6 ) ne ?
determinizmus serializacie sa ak uz nic ine, tak postupom case aspon zlepsuje

to btw suvisi aj s tymi slovnikmi - v 'normalnom' .NETe nie je zarucene poradie, co je imho jeden z dovodo preco to nejak moc neriesia

JAACOB: pred chvili mi unity spadlo a po restartu oznamilo, ze mam mismatch v asset databazi a ze bude delat reimport... uz to bezi hodinu a to jsem rad, ze se mi to stalo na VR repozitari :D (reimport androidu jsou ted diky genialite unity den, jestli ne vic... :D)

ze furt neni serializace dictionaries, to povazuju za naprostou curakovinu (nicmene... dlouho nesla serializace listu, jen arrays, protoze all hail unity :). Uz jsem davno vzdal nadeji, ze to nekdy daji dohromady, protoze to by proste cele museli vyhodit a predelat nejak rozumneji a to oni ne :) kdyz jednou pochopis tu zkurvenou logiku, tak se kolem toho da bruslit, ale je to obcas strasna nasiracka... Opravdu neverim, ze zrovna tohle kdy daji nejak dohromady :/

jak jsem rikal, mam tendence radsi vsechno srat do jsonu / xml, kdyz uz nic, tak se to da aspon rozumne verzovat, narozdil od obcas neskutecne zmateneho jejcih yaml (proc do prdele po sahnuti do materialu unity prehazi naprosto nahodne vsechny polozky, takze to uz pak fakt nejde comparovat).


Ceka me jeste par mesicu nahaneni v unity, ale uz jsem se zarekl, ze pristi vikendovy "toy project" radeji zkusim znovu Godot :)

JAACOB: ScriptableObject (SO) a MonoBehaviour su v c++ interne prakticky totozne [ z toho bude mozno vyplyvat niekolko odpovedi ] akurat s tym ze SO sa daju serializovat ako .asset ( a callbacky )

ale chapem ze odpovede mozno ani necakas a bol to hlavne (opravneny) rant - tiez sa snazim po predchadzajucich skusenostiach pouzivat serializacnych featur iba nevyhnutne mnozstvo ]

SHIGORBIRDMAN: Poprve ne, ale tentokrat jsem se opravdu potopil az po usi do hoven.. :)

Nepochopim celou tunu veci kolem serializace. Namatkou:
Proc vlastne nefungujou Dictionaries?
Proc jedine rozumne editovatelne objekty musi byt Unity.Objecty (ScriptableObject)?
Proc kdyz uz musim na rozumny editor pouzivat ScriptableObjekty, tak proc nemuzou byt ScriptableObjecty nested?
Proc kdyz kurva Unity dokaze pro ScriptableObject-nested Serializable classu automaticky vytvorit editor, proc dorite neumi udelat simple editor pro jednoduchou Serializable classu bez scriptable objectu? Kdyz uz, tak proc jedine pres retardovane PropertyDrawers a jine vyfikundace?
Proc proste nemuzu vytvorit SerializedObject z jakekoliv Serializable classy?
Proc dela takove problemy generika u ScriptableObjects?
Proc si kurva Unity nedokaze zapamatovat a spravne seserializovat typ podedene classy, kdyz clovek pouzije polymorfismus? [OMG!?]
Proc do rite kdyz uz si budu ladit nejakou serializaci pres ISerializationCallbackReceiver, tak proc se editor snazi serializovat prakticky nonstop omg...i treba pri prekreslovani layoutu nebo jezdeni mysi do okna/z okna editoru!?
Proc kurva kdyz chci nakrasne vytvorit Editor.Create pro nejaky ScriptableObject, tak mam moznost leda zavolat OnInspectorGUI, ktery bude vykreslovat CustomEditor anebo DrawDefaultInspector, ktery je schopny trasovat pripadne zmeny (podobne jako Begin/EndChangeCheck). To si kurva musim nejake "IsDirty" posilat sam pres Editor, ktery si stejne musim pro kazdou classu nakonec napsat sam?

Jsem za vikend fakt zestarl aspon o pulrok. Jakoze ja ty zakladni srance kolem serializace znam, ale vzdycky si rikam, ze prece nebudu cely navrh dat prizpusobovat retardovane serializaci a ze to pujde nejak ohnout. Jako ono to treba i jde, ale clovek skonci s totalne dohackovanou srackou, ve ktere se za chvilku i prestane orientovat jen proto, ze si dovolil udelat datovou konfiguraci pekne OOP...

Uplne jsem citil to zoufalstvi, kdyz jsem narazil na plugin od paska [Vexe], ktery dokazal serializovat fakt "vsechno", ale borec se na to nakonec stejne vykaslal a mam pocit, ze i kvuli tem vsem issues, ktere musel s Unity resit, se nakonec obratil na viru, ze nas spasi uz jedine proceduralni programovani... :)

Fakt uplne nejdebilnejsi na tom je (jako i na tune dalsich Unity "featur"), ze si tim proste musi fakt uplne kazdej projit a trochu u toho zesedivet. Tolik promrhaneho casu kvuli serializaci, kvuli retardovaneho GUI, kvuli zmrsene AssetDatabase a Resourcu a janevimcemu jeste...

JAACOB: na to jsi narazil az ted? tohle je bohuzel jedna z pojebanych veci uz od zacatku a neverim, ze to kdy spravi :/ Data tohohle typu, kde to jde (tj kde nepotrebuju odkazy na nejake unity objekty) radeji serializuju externe pres json nebo xml.

(kdyz jsem do toho vrazil rypakem poprve, taky jsem vytekl)

<rant>Lidi, co maji na svedomi serializaci v Unity, bych nechal vyklestit, aby se uz nerozmnozovali!!!</rant>

Kdo si s tim jeste neuzil dost, tak protip - nepouzivejte pro svoje editory uvnitr ScriptableObjectu Serializable classes + polymorfizmus. Usetrite si hodne trapeni...

JAACOB: heh... a ja stravil o vanocich par dni updatem sveho stareho poly editoru pro unity, protoze jsem si chtel s necim hrat... prave na polybuilder a par dalsich jsem se koukal a premyslel, jestli je nekoupit a nezmodovat, misto abych fixoval / prepisoval stary kod :)