IRC Logs for #zfx


2021-10-27

06:56:52 Schrompf joined the channel
07:05:49 Schrompf: Kjötz, verehrte Logger und Herren
07:06:23 xq: schit
07:06:28 xq: wecker vergeessen
07:07:14 Schrompf: upsi
07:07:48 xq: passiert
07:11:57 joeydee joined the channel
07:12:10 xq: moin joeydee
07:12:12 joeydee: moin
07:18:59 joeydee: Schrompf, wenn du mal was anderes clicken möchtest außer Cookies: https://orteil.dashnet.org/igm/?g=http%3A%2F%2Fdevelop.diehlsworld.de%2Fzfxhalloween%2Fzfxhalloween.txt
07:21:25 Schrompf: hübsch.
07:21:35 Schrompf: bin aber auf arbeit, kann hier nicht so ungehemmt klicken
07:21:49 xq: could not be found
07:22:35 xq: joeydee, du brauchst *dringend* HTTPS
07:54:40 joggel joined the channel
07:54:55 joggel: moin birls 'n goys
07:55:00 xq: huhu
07:55:05 joggel: hey xq
07:55:08 Magister joined the channel
07:55:17 Schrompf: joggooggooggel!
07:55:18 joggel: Ich habe mir gestern noch überlegt wie ich das ändere
07:55:24 joggel: huhu MC Schrompf
07:55:30 Schrompf: Magagagisteragister
07:55:40 Magister: tag die herrschaften
07:55:41 Schrompf: wie du was änderst?
07:55:45 Magister: und damschaften
07:55:50 Schrompf: und logschaften
07:56:02 Magister: logschatten eher
07:56:08 Magister: der olle spion
07:56:11 Schrompf: Das dritte Geschlecht: Frau, Mann, Logger
07:56:11 joggel: uuund zwar: Die Face/Edge/Vertex-Transformation ändere ich am InputNode. Der steht quasi am anfang der Chain...
07:56:55 joggel: Schrompf: xq hat mir gestern auf den Gedanken gebracht, dass ich "Müll" Programmiere...
07:57:46 joggel: Ich will in meinem Programm Faces/Edges/Vertices ändern... problem ist nur: wenn ich dann in der Node-Kette davor etwas ändere, die Änderungen futsch sind
07:58:17 joggel: weil durch vorherige Änderungen ja der Mesh verändert wird
07:59:58 Schrompf: ja, schwierig. du müsstest ein diff anwenden. und das kann nicht einfach bestimmte vertizes ändern, weil irgendwo davor ja in der reihe mal subtil andere setups entstehen könnten und du dann ganz andere vertizes änderst, als du willst
08:01:35 joggel: ja, genau
08:01:53 Schrompf: du müsstest räumliche änderungen anwenden
08:02:08 joggel: Aber wenn ich das gleich dem InputNode mitgebe; quasi dort gleich diese Änderungen vornehme, wäre das ok
08:02:08 Schrompf: also anstatt "vertex 13 auf position 7"
08:02:19 joggel: nee
08:02:23 joggel: oder?
08:02:24 Schrompf: sondern "alles in dem bereich um 5cm rausziehen"
08:03:06 Schrompf: was für änderungen willst du denn abbilden? sculpting? also beulen und senken reindellen?
08:03:37 joggel: nur Faces/Edges und Vertex-Änderungen. Als einzelne davon anfassen un bewegen. Faces evtl noch skalieren
08:03:47 Schrompf: ja, aber warum?
08:03:59 joggel: weil ichs cool finden würde
08:04:02 Schrompf: du bist beim "wie", aber du müsstest erstmal das "warum" beantworten
08:04:14 Schrompf: hm. damit ist es schwer zu arbeiten
08:04:21 joggel: na... weil man sowas brauchen könnte
08:04:26 Schrompf: ne
08:04:29 joggel: klar
08:04:33 Schrompf: du kriegst es nich tzuverlässig hin
08:04:46 joggel: wenn ich es am anfang der Kette mache, dann schon
08:04:54 Schrompf: es wäre gefährlich, sowas zu bauen, weil es sofort bricht, wenn in der reihe vorher was passiert
08:04:57 joggel: also als ersten Schritt
08:05:06 Schrompf: du willst also nur die ausgangs-formen editierbar machen?
08:05:09 joggel: da ist nichts vorher in der Kette
08:05:12 joggel: Ja
08:05:14 Schrompf: hm
08:05:17 joggel: nur die ausgangsform
08:05:35 Schrompf: das könnte klappen, auch wenn ich nicht so recht sehe, wofür man das brauchen könte
08:05:45 joggel: das würde zumindest das Problem umgehen.
08:05:47 joggel: Ja, okay
08:06:08 joggel: der ultimative Nutzen ist so vlt mehr so doll
08:06:18 joggel: ach... ich überlege mal noch etwas
08:09:03 xq: so kinners, ich roll mal ins büro
08:09:59 Schrompf: role er
08:10:26 xq: davor noch ein fettes LOL
08:11:22 xq: Das Emoji "📈" wird unter Discord als ":chart_with_upwards_trend:" gehandhabt
08:11:26 xq: unter Telegram
08:11:29 xq: :stonks:
08:11:56 Schrompf: höhöhö. nice
08:12:05 xq: Telegram macht viele Dinge richtig
09:00:26 joeydee: Pumpkin-Klicker läuft jetzt über Pastebin und einen Bilderhoster: https://orteil.dashnet.org/igm/?g=https%3A%2F%2Fpastebin.com%2Fraw%2F1uXCR4HE
09:02:02 xq: "specified game data could not be found"
09:02:08 joggel: kühl
09:02:11 joggel: bei tuts
09:05:40 xq: ah jetzt
09:12:00 joeydee: Weiß nicht wie das Weighting ist, müsste ich ja tagelang testen :D Aber es gibt ein Spielziel (das man auch im Laufe des Spiels erfährt): Baue ein Pumpkin-Halloween-Castle für die Kürbis-Weltherrschaft!
09:14:19 Schrompf: WELTHERRSCHAFT!
09:17:02 joeydee: Nichts Geringeres als das.
11:30:53 xq: Schrompf, joeydee: ich brauch mal euren Rat
11:31:01 xq: ich hab dinge im resource management design von zero-graphics hart verkackt
11:35:22 xq: https://bpa.st/GFDQ
11:35:28 xq: der flow aktuell sieht so aus
11:35:42 xq: das heißt, in initGraphics wird ein neuer renderer erzeugt
11:37:50 xq: das problem ist, dass ich "gpu available" gerne wegabstrahieren ürde
11:38:22 xq: dafür müsste der renderer selbst "initGraphics, killGraphics" als funktion haben, sodass ich das forwarden kann
11:38:54 Schrompf: du brauchst ein handling für "gpu wech" in der mainloop- willst das dort aber nicht explizit handlen?
11:39:28 xq: das problem ist grade, dass ich bei "gpu wech" alle resourcen komplett freigebe
11:39:49 Schrompf: sind dann ja eh weg, oder? dx9, mobile
11:40:09 xq: genau
11:40:25 xq: aber das heißt, dass ich die info darüber überall verliere
11:40:28 Schrompf: da fällt mir aber auf: du generalisierst gerade einen workflow, der eigentlich nur für mobile gilt. willst du das?
11:40:33 xq: ja, will ich
11:40:38 xq: weil er auch für wasm gilt ;)
11:40:46 xq: auf jeden fall:
11:40:58 Schrompf: aber nicht für linux, window, mac und opengl
11:41:04 xq: richtig
11:41:08 xq: mein problem ist, dass jedes ding, was grafik aufbaut, wissen muss, dass grade GPU available ist
11:41:13 Schrompf: du willst wirklich spezifisch nur mobil?
11:41:23 xq: das tut auf PC nicht weh
11:41:29 xq: da kommt der call halt einmal
11:41:33 xq: statt N mal
11:41:57 Schrompf: nuja, du könntest das if einfach in den renderer schieben
11:42:08 xq: ja, das ist grade n bisschen die idee
11:42:20 xq: also der renderer erstellt dann halt ggf. seinen OpenGL-Stuff neu
11:42:22 Schrompf: initApp macht initRenderer, und in renderer.Update() ist das checkGPUAndHandleIt
11:42:23 xq: wenn er ihn braucht
11:43:03 Schrompf: und in der mainloop lässt du das ebenso notwendige "focus loss", was nur auf mobile zufällig immer mit gpuloss zusammenfällt
11:43:12 Schrompf: daher habe ich den punkt oben so strapaziert
11:43:57 xq: das ist aber nicht mein einziges problem :(
11:44:10 xq: ich hab es aktuell so, dass der Renderer resource management für seine eigenen resourcen betreibt
11:44:19 xq: also ein Renderer2D kennt eine Renderer2D.Texture, die er selbst verwaltet
11:44:27 Schrompf: ja, das würde ich so erwarten
11:44:37 xq: was jetzt aber das Rroblem ist, wenn ich die selbe Textur aus zwei renderern verwalten möchte
11:44:50 xq: weil dann hab ich sie entweder zwei mal geladen
11:44:55 Schrompf: warum solte man das wollen?
11:45:12 xq: weil die renderer nicht global sind
11:45:17 xq: die sind stateful
11:45:25 Schrompf: aber der opengl-kontext isses doch, oder?
11:45:30 xq: ja, korrekt
11:45:39 Schrompf: also kannst du eh keine zwei renderer aufmachen?
11:45:42 xq: doch
11:45:51 xq: der Renderer hier ist kein "ich erschlag alle probleme"
11:45:59 xq: sondern eine relativ kleine, fokussierte einheit
11:46:03 xq: die kann dann halt nur 2D-Kram malen
11:46:07 xq: und für 3D gibts nen anderen Renderer
11:46:22 xq: und wenn ich unabhängig 2D-Dinge malen will, mach ich 2 2D-Renderer
11:46:39 xq: der eine für "render on texture", den anderen für UI mit DPI-Scaling
11:46:59 Schrompf: ich rieche probleme wachsen "ich muss im 2d-renderer states setzen, die der gar nicht kennt, weil sie das draw-ergebnis beeinflussen und der 3d-renderer im selben prozess, von dessen existenz ich gar nix weiß, die für seine zwecke gesetzt hat"
11:47:43 Schrompf: oder halt zwei ogl-kontexte, weiß nicht ob das geht, dann hast du keine probleme außer tausend bugs des OS
11:47:55 xq: nene, das letztere skaliert definitiv nicht
11:48:03 xq: vorallem malen ja beide renderer in den selben kontext rein
11:48:09 Schrompf: also gemeinsamer ogl-kontext
11:48:22 Schrompf: und wenn du jetzt geistig die texturen zum ogl-kontext zuordnest, passt es auch wieder
11:48:28 xq: ich glaube, wir verstehen auch grade was komplett unterschiedliches unter "renderer"
11:48:34 Schrompf: deine renderer benutzen dann nur eine global verfügbare abstaktionsschicht
11:48:55 xq: ja, meine idee war jetzt, die resourcen in einen ResourceManager oder sowas zu verschieben
11:49:09 xq: der hat dann die info, wie er eine resource regenerieren kann
11:49:22 xq: so hab ich dann auch übers gesamte programm hin statische pointer für sich wechselnde resourcen
11:50:13 Schrompf: kann man so machen, gefällt mir aber nicht
11:50:20 xq: wie würdest du das dann machen?
11:50:33 xq: dann wäre "resource lifetime" von "resource usage" getrennt
11:50:42 xq: und ich kann texturen in mehr als einem renderer verwenden
11:50:53 Schrompf: ein globales ding "GPU" oder so, bei dem man ressourcen anlegen und löschen und dinge malen kann
11:51:11 Schrompf: und das sagt dir auf zuruf "du, alles fort, lass gut sein"
11:51:17 Schrompf: oder "du kannst wieder"
11:51:30 Schrompf: und dann erzeugt der, der vorher schon die ressourcen angelegt hat, erneut die ressourcen
11:51:50 xq: ja, aber das löst erst mal das problem nicht, was ich habe
11:51:58 xq: nämlich das resource sharing zwischen zwei renderern
11:52:02 Schrompf: doch
11:52:15 Schrompf: weil beide renderer nur dieses GPU-ding benutzen, anstatt selbst OGL abzufeuern
11:52:21 xq: ja?
11:52:27 Schrompf: und fertsch?
11:52:31 xq: wenn jetzt renderer a texture X erstellt
11:52:38 xq: gibt renderer A auch texture X wieder frei
11:52:52 xq: jetzt ist lifetime von renderer A aber kleiner als von B, ich will aber texture X auch mit B verwenden können
11:53:07 Schrompf: dann hast du gesharte daten zwischen zwei objekten und musst dich kümmern?
11:53:15 xq: genau das will ich ja grade ,)
11:53:26 xq: darum will ich ja das resource manager ding haben
11:53:28 xq: damit sowas geht
11:53:35 Schrompf: na dann tu's doch? schalte ne schicht dazwischen, die ressourcen beim anlegen mit ner optionalen string-id versieht
11:53:36 xq: und der kram so lange lebt wie der resource manager und nicht wie die renderer
11:54:57 Schrompf: du verfolgst anscheinend immer noch das geistige bild eines hilfreichen typen in seinem kiosk, dem du texturwünsche durch's sprechfenster zurufst
11:55:03 Schrompf: und das mag ich nicht
11:55:23 Schrompf: bei mir wären ressourcen RAII-dinger, die sich jeder Renderer anlegt, und die gehen mit dem Renderer auch wieder down
11:55:53 Schrompf: und wenn ich ressourcen brauce, die beide renderer haben sollen, dann geb ich die dependency-injection-style beim renderer-ctor mit rein
11:56:15 xq: so
11:56:35 xq: paintMainmenu() { renderer.fillRectangle(background_image); }
11:56:42 xq: paintSplashscreen() { renderer.fillRectangle(background_image); }
11:56:48 xq: paintOptionsMenu() { renderer.fillRectangle(background_image); }
11:56:56 xq: jetzt sind aber die renderer unterschiedliche
11:57:05 xq: weil das ja andere draw lists sind, die sich da am ende ergeben
11:57:56 xq: (die renderer sind ja nur draw lists + shader, wie diese lists zu malen sind)
12:01:42 xq: https://mq32.de/public/0e7365bb02aa28b9be6f1e2c274d03d022454f94.png
12:01:47 xq: links wäre die neue architektur, rechts die alte
12:01:53 xq: *aktuelle
12:05:08 Schrompf: ok, das neue build nimmt die ressourcenverwaltung aus den renderern. kann ich so gutheißen.
12:05:14 Schrompf: und was ist jetzt das problem?
12:06:33 xq: naja, dass es das aktuell noch nicht tut ^^
12:06:48 xq: aber dann hatte ich recht vermutet, dass wir leicht aneinander vorbeigeredet haben
12:07:13 Schrompf: womöglich.
12:07:24 xq: aber bildchen helfen
12:07:28 xq: was ich dann nämlich auch machen kann:
12:07:29 Schrompf: du hast ja auch irgendwie mit ner mainloop eröffnet und nem bool "hab ich gerade fokus"
12:07:45 xq: ne, nix fokus. "hab gerade eine gpU"
12:07:51 Schrompf: auf mobile dasselbe
12:07:56 xq: ja, aber nicht auf desktop
12:08:07 xq: ich designe den Resource Manager dann auch so, dass er resourcen regenerieren kann
12:08:17 Schrompf: du hast explizit desktop ausgechlossen. deswegen habe ich doch xmal nachgefragt
12:08:18 xq: dann muss ich mich darum kümmern, dass ich dauerhaft renderer neu bauen muss
12:08:24 xq: hö?
12:08:31 xq: ich glaube, wir haben fies aneinander vorbeigeredet
12:08:39 xq: ich hab desktop, web und mobile
12:08:56 Schrompf: da fällt mir aber auf: du generalisierst gerade einen workflow, der eigentlich nur für mobile gilt. willst du das?
12:08:56 Schrompf: ja, will ich
12:09:03 Schrompf: dann trenne "fokus" und "gpu"
12:09:12 xq: ich hab "fokus" noch gar nicht
12:09:21 xq: der rendert auch im hintergrund fröhlich aktiv weiter
12:09:52 Schrompf: hm
12:10:40 xq: fokus kommt an einem anderen tag
12:10:46 Schrompf: die renderer sind bei dir doch nur ausführende, die ressourcen aus der zentralen verwaltung verwenden
12:10:52 xq: genau
12:10:58 Schrompf: warum musst du bei denen *irgendwas* neumachen, wenn die gpu wieder da ist?
12:11:33 xq: aktuell die shader, weil ich die noch nicht im resource management habe
12:11:57 xq: aber klar, die könnte ich auch dorthin verschieben
12:12:36 Schrompf: gerade die shader werden wirklich wiederverwendet. und sind sacklangsam zu erzeugen
12:12:50 Schrompf: bei texturen müsste man schon ne weile suchen, ehe man da wiederverwendungsmöglichkeiten findet
12:13:41 xq: gutes argument
12:13:52 xq: jetzt erst mal drüber nachdenken, wie ich resourcenhandles handhabe
12:13:59 xq: aber string hashen ist wahrscheinlich das klügste
12:14:15 Schrompf: als opfer einer hashkollision rate ich davon ab
12:14:31 xq: wus?
12:14:40 Schrompf: mach transparente handles, die nen arrayindex und nen generationenindex encoden
12:14:57 xq: errrm
12:15:02 xq: ich würde nicht "hash" als resourcenindex verwenden
12:15:09 xq: aber
12:15:14 xq: genau das hab ich geschrieben /o\
12:15:34 Schrompf: ich wollte gerade wieder ne geschichte von vorm krieg rausholen
12:18:23 xq: worüber ich grade nachdenke:
12:18:26 xq: wie komm ich an die resourcendaten
12:18:40 xq: ich hab den resource manager, der hat createTexture(w,h,pixels)
12:18:44 xq: soweit, sogut
12:19:36 xq: aber damit hab ich kein resource sharing
12:19:50 xq: also brauch ich irgendwas, wo ich sagen kann: "lade mir mal resource X"
12:22:50 Schrompf: najaaaa
12:23:03 Schrompf: da baut man ein "lade mal file soundso als textur"
12:23:08 Schrompf: und ist ein jahr lang zufrieden
12:23:25 Schrompf: dann willst du fürn modsupport auch aus einem der registrierten addon-zips lesen
12:23:47 Schrompf: und weil du das nicht in der ressourcenverwaltung haen willst, baust du irgendwelche data provider nach nem interface
12:23:53 Schrompf: und kommst in ner callbackhölle raus
12:24:21 xq: /o\
12:24:28 Schrompf: was du eigentlich brauchst, ist "mach mir ne textur aus dieser Image2DDescription"
12:24:40 Schrompf: und das öffnen der datei passiert draußen
12:24:44 xq: aber ja, idee wäre jetzt, dem ResourceManager erst mal loader "mach mir bitte aus diesem pfad bits"
12:25:06 Schrompf: wir können das hier abkürzen
12:25:22 Schrompf: du willst dem resourcemanager mittel an die hand geben, dass der sich die daten holen kann
12:25:33 xq: jo, so wollte ich das jetzt machen
12:25:37 Schrompf: und ich will das nicht. ich will ncith, dass der resourcemanager sich irgendwas holt
12:25:46 xq: why?
12:26:06 xq: ich wüsste grade nicht, wie ich das sonst lösen kann
12:26:18 xq: der resourcemanager hat keinen access auf I/O irgendeiner art
12:26:26 Schrompf: weil das die zuständigkeiten aufweicht und callbacks verursacht, die du in fünf jahren nicht mehr siehst. resourcemanager macht in meiner welt genau eins: ressourcen auf der GPU verwalten
12:26:48 xq: brb, work interrupt
12:28:00 Schrompf: und deswegen lädt der renderer oder dein startup-thread oder SONSTWER die bilder, meshes, shaderquelltexte, erzeugt sie prozedural oder aus ner skriptsprache, und die ressourcenverwaltung kriegt sie in form eines deskriptors als referenz gereicht
12:29:47 Schrompf: und für den fall von "GPU wech" müssen leute halt außerhalb die ressourcen erneut anlegen. refresh( handle, struct LiesDenMistVonHier dataref)
12:30:24 Schrompf: optional, komfortfunktion, kannste dir die referenzierten daten im resourcemanager kopieren und daraus rekonstruieren. kostet hauptspeicher, aber ist bequem.
12:31:11 Schrompf: ich mach das bei mir nach bequemlichkeit: den shaderquelltext zum erneuten kompilieren zu behalten ist nicht viel speicher, kann man machen
12:31:45 Schrompf: die texturdaten... ich hab seit jahren nix ernsthaftes mehr programmiert, und für gamejam-beiträge reicht ein "klar, behalte die ganze textur im hauptspeicher mit allen mips" völlig aus
12:32:23 Schrompf: aber früher hatte ich da ne andere verwaltung davor, die das file handling und so macht, und die wusste, als welchen quellen die texturen stammten, und hat sie erneut geladen
12:33:37 xq: also du würdest nur sowas machen wie "createTexture(data)" und dann bekomm ich halt handleX ?
12:33:58 Schrompf: und alltagssachen wie GUI, Fonts oder so können sich entweder selbst kümmern, oder wählen halt den "hauptspeicherkopie"-weg aus bequemlichkeit
12:34:04 Schrompf: genau
12:34:23 Schrompf: und wenn du dir das sharen bequem machen willst, dann optionaler dritter param "stringid"
12:34:35 Schrompf: über den andere, die das ding nicht angelegt haben, trotzdem rankommen
12:35:47 Schrompf: du verteilst damit das neuladen bei "gpu wech" aufs ganze programm. das ist mir bewusst. das muss man wollen. aber ich bevorzuge diese option gegenüber einer datenkraken-version, die mit callbacks und wildwuchs die daten aus dem ganzen programm ziehen kann, nur damit sie das bei "gpu wech" später nochmal machen kann
12:35:53 Schrompf: gehen tun beide optionen
12:36:18 xq: mir isses lieber, wenn die resourcen nur an einer geladen werden
12:36:22 xq: das ist viel weniger frickelig
12:36:28 Schrompf: wenn du die andere haben willst, dann übergibst du gar keine daten oder dateinamen, sondern abstrakte funktoren "hol 2dtextur-daten"
12:36:58 Schrompf: createTexture( func holDatenFürDieseTextur)
12:37:13 Schrompf: und dann musst du nur die Funktoren im Manager behalten und kannst sie jederzeit wieder aufrufen
12:37:21 xq: hm
12:38:28 Schrompf: mit allen folgen halt: proverbiales alt+tab im falschen moment und deine funktoren machen use-after-free
12:39:18 Schrompf: aber könnte für den anfang bequem sein. baust nen fertigen Accessor2DTexturAusDatei und übergibst den bei jedem createTexture() und hast deinen Standard-Usecase mit einer Zeile abgefeiert
12:39:52 xq: ich mach das mit @embedFile()
12:39:53 xq: ist bequemer :D
12:40:03 xq: macht zwar die executable dicker, dafür hab ich keine I/O failures at runtime
12:40:33 Schrompf: aber dafür brauchst du plötzlich nen png-loader in deiner ressourcen-verwaltung. oder bmp oder tga oder wasweißich
12:40:36 Schrompf: DDS
12:40:50 xq: DDS braucht keinen loader :D
12:41:03 Schrompf: wasauchimmer man heute nimmt, wenn man texturkompression nimmt
12:41:10 xq: aktuell finales ziel wäre aber, das spiel so zu bauen, dass es auf Linux/Windows ne EXE+ZIP ist
12:41:20 xq: und ich die resourcen relativ bequem aus dem file lesen kann
12:41:28 xq: aber das ist eine geschichte für einen anderen tag
12:41:53 xq: mein wunsch ist es, eine single-file application für windows(.exe),linux(...),mac(.dmg),android(.apk) zu machen
12:42:15 Schrompf: klar, warum nicht. mit nem functor liesDDSAusDiesemDatenblock kannst du dein callback-gesteuertes resource management bequem machen
12:42:28 xq: jo
12:44:17 Schrompf: hat Zig was für callbacks?
12:44:23 Schrompf: in dem fall ja stateful callbacks
12:44:34 xq: nur function pointer
12:44:43 xq: aber ich kann sowas in ne struct kapseln
12:44:56 Schrompf:
12:44:59 xq: why? :D
12:45:09 Schrompf: ne, passt schon
12:45:37 xq: createTexture(Accessor2DTexturAusDatei{.name = "C:\\Users\\Schrompf\\Desktop\\ohno.png});
12:45:40 xq: fertsch :D
12:45:44 Schrompf: du musst halt ne generische struct entgegen nehmen können, die ne methode "holMirDieDaten()" hat, und die sich alles notwendige merkt, um im fall des aufrufs arbeiten zu können
12:46:31 Schrompf: ob die struktur intern dann nen dateinamen speichert oder nen void* ins datensegment, sollte keine rolle spielen
12:51:14 Schrompf: je länger ich darüber nachdenke, desto besser gefällt mir die "verwalte ressourcen mittels functor"-idee
12:51:23 Schrompf: man muss halt böse auf dangling references aufpassen
12:51:36 xq: jo
12:51:41 xq: bin auch nicht abgeneigt
12:51:43 Schrompf: aber wenn man die rausgereichten resourceHandles als "owning" gestaltet, müsste man halbwegs safe sein
12:52:00 Schrompf: oh, Zig. naja, machste es halt von hand :-)
12:52:08 xq: owning in zig ist einfach
12:52:13 xq: /// this pointer owns the resource
12:52:17 Schrompf: zig ownt dich täglich :-)
12:52:22 xq: eher nicht
12:52:31 xq: was mir jetzt noch fehlt, ist ne möglichkeit, deduplikation zu machen *thinking*
12:52:50 xq: also wenn zwei dinge die selbe resource anfragen
12:52:58 Schrompf: stringid, und falls es die schon gibt, stillschweigendes verwerfen des zweiten aufrufs?
12:53:15 xq: hm, wäre ne idee
12:53:23 Schrompf: wär halt noch cooler, wenn der nur anhand des besorgungs-funktors merken könnte, dass es die selbe ressource ist
12:53:40 xq: könnte ich ggf. sogar machen
12:54:18 xq: wäre sogar #wenigAufwand
12:54:37 Schrompf: kommen dann auch rendertargets und dynamische VBOs in die verwaltung?
12:54:48 xq: muss ich mir noch überlegen
12:54:55 xq: wäre ja eigentlich nicht doof
12:54:57 Schrompf: nagut, die brauchen ja einfach ne eigene create()-methode ohne functor
12:55:13 Schrompf: und dann de-dupliziert da auch niemand aus versehen
13:11:43 Magister joined the channel
13:36:13 xq: Schrompf: https://bpa.st/2Y4Q
13:36:25 xq: sieht doch gut aus
13:36:35 Schrompf: womöglich
13:36:46 xq: createTexture nimmt *etwas*, das ein create() kann
13:36:49 Schrompf: hab gerade nicht den nerv, mich in ne fremde softwarearchitektur einzulesen
13:36:51 xq: was mir TextureData liefert
13:36:55 Schrompf: klingt gut
13:37:15 xq: try mgr.createTexture(DecodePng{ .source_data = ... });
13:37:25 xq: DecodePng ist beliebig austauschbar
13:39:24 Schrompf: fine fine
13:41:24 xq: kann jetzt also Png, Rohdaten, ... laden
13:41:33 xq: also, grade nur symbol
13:41:45 xq: das aufsetzen der textur ist grade ein ".opengl_resource = 1"
13:41:45 xq: :D
13:41:47 Schrompf: und wenn du mit den refs nix verkackst, kann dein manager auch ne halbe stunde später das file neuladen
13:41:53 xq: yep
13:41:56 xq: danke dir!
13:41:59 xq: sieht gut aus
13:42:12 Schrompf: nich dafür, das ist mir peinlich
13:55:15 xq: https://twitter.com/iquilezles/status/1453261503847702537
14:04:45 joeydee: LOL
14:33:48 Schrompf joined the channel
15:51:35 Schrompf: xq?
15:52:45 Schrompf: falls du trotz spritzophobie die covid-impfung haben willst: für solche zwecke impfen krankenhäuser mit überwachung durch anästhesisten und so, und man könne über den betriebsarzt (oder falls die firma zu klein für sowas ist, die Berufsgenossenschaft) rankommen
16:16:10 xq: Schrompf: Problem ist, dass ich Panicke wie sau
16:17:49 Schrompf: genau, dafür gibt's da dann profis
16:18:09 xq: ja, aber was soll der dann tun?
16:18:19 xq: mein hausarzt hat auhc keine idee, was man tun könnte
16:18:58 Schrompf: meine frau meinte, der betriebsarzt deiner firma könnte was organisieren, oder in ermangelung dessen die berufsgenossenschaft.
16:19:17 xq: betriebsarzt? :D
16:19:22 xq: was glaubst du, wie groß unsere firma ist? :D
16:19:24 Schrompf: reichlich diffuser vorschlag, ist mir bewusst, genauer wusste sie's auch nicht, weil sie halt als betriebsärztin nur mit den angestellten ihrer firma zu tun hat
16:19:41 Schrompf: japp, wenn sie zu klein ist, dann die berufsgenossenschaft
16:56:17 xq: käse
16:56:24 xq: resource management läuft
16:56:33 xq: designfehler gefunden :D
17:02:12 xq: aber danke Schrompf für die Idee mit dem zentralen Resourcenverwalter
17:02:15 xq: sieht gut aus
17:02:34 xq: nachdems jetzt im spiel compiliert, muss ich meine Demo wieder lauffähig bekommen
17:02:41 xq: wenn die Demo läuft, bin ich happy :)
17:19:14 Schrompf: gz
17:59:34 xq: noch läuft sie nich
18:02:56 joggel joined the channel
18:03:04 joggel: hey
18:03:08 joggel: ja... du
18:03:12 joggel: genau DU
18:03:19 joggel: Gruß
18:06:17 xq: huhu joggel
18:06:36 joggel: Im Log lese ich etwas von einer Demo, xq?
18:07:05 xq: https://github.com/MasterQ32/zero-graphics/blob/master/documentation/screen01.png
18:07:06 xq: das hier
18:08:18 joggel: ah, sehr cool
18:11:42 xq: wird zeit
18:12:56 joggel: also könnte ich bald anfangen auf Android ganz easy zu entwickeln?
18:13:05 joggel: nice
18:14:44 joggel: 157 Repositories hast du?!
18:14:47 joggel: wtf?!
18:17:27 joggel: shit.. ihr seid alle so produktiv :(
18:18:03 xq: haha :D
18:18:08 joggel: echt...
18:18:12 xq: und jop, Android geht :)
18:18:26 xq: muss jetzt mal gucken, dass der kram wieder auf android läuft
18:19:03 joggel: wie kann man als Entwickler arbeiten und dann noch in der Freizeit so viel tun?
18:19:10 joggel: verstehe ich nicht...
18:19:25 joggel: da "mache ich schon etwas Auge"
18:21:03 xq: joggel: ersetze leben durch code :D
18:21:13 joggel: welches Leben?! :D
18:21:17 joggel: habe ich ja auch nicht mal
18:21:28 joggel: also: ich kann da nichts ersetzen
18:21:31 joggel: xD
18:23:43 joggel: sehe gerade: hast auch viel geforked auf Github...
18:24:08 xq: mach mal die forks aus ;
18:25:05 joggel: wieviel dann? 100 eigene?^^
18:25:25 joggel: lol
18:25:26 joggel: 110
18:25:32 joggel: ich hasse dich
18:28:26 xq: :D
18:28:37 xq: joggel: schau mal, wie alt der account ist
18:28:41 xq: und nicht alles ist funktionsfähig
18:56:24 xq: so, compiliert wieder. jetzt wieder mehr kaputt machen
19:09:26 xq: Schrompf, jetzt brauch ich nochmal deinen Rat
19:13:34 Schrompf: mein hirn ist matsche, das einzige, was ich noch für dich tun kann, ist dein anliegen lächerlich zu machen
19:13:44 xq: alles klar
19:13:48 xq: let's fetz
19:14:17 xq: ich hab jetzt einen resource loader
19:14:38 xq: aber: mein geometrie-format enthält textur-/dateinamen
19:15:16 xq: wie lade ich jetzt die texturen passend zum modell?
19:15:50 xq: createGeometry(DecodeZ3D { .data = ... });
19:18:56 joeydee joined the channel
19:18:58 xq: jetzt dekodiert dessen create-funktion das Z3D-Modell und da purzeln pfade raus
19:25:26 Schrompf: ja, doof. du kannst mit einem call immer nur eine instanz einer ressource anlegen
19:25:36 xq: jop
19:26:22 xq: aber wie lös ich das nu?
19:26:46 Schrompf: vielleicht baust du dir ne MachAllesNeu-Funktion: createComplexResource(), deren Funktor ne Ref auf den Manager reingibt und der Funktor kann dann beliebige create() aufrufen
19:26:56 Schrompf: duplikate sind dann aber evtl. ein problem
19:27:18 Schrompf: und das korrekte erkennen und überschreiben der teilressourcen, wenn viel später mal recreate() nötig ist
19:28:01 Schrompf: vielleicht gibst du statt ner ResourceManager-Ref lieber ein Interface rein, über dass die Komplex-Ressource alles erzeugt, und damit kannst du es automatisch der einen Ressource zuordnen
19:39:12 Schrompf: ey, ich HABE einen sinnvollen beitrag geleistet. Würdige das!
19:39:21 Schrompf: paging Dr. xq
19:39:32 Schrompf: Not My Interesse?
19:39:38 xq: Non-Maskable-Interrupt
19:39:44 Schrompf: ah, $FRAU
19:39:48 xq: exakt
19:42:37 xq: aber ich bin mir nicht sicher, ob deine lösung so angenehm zu benutzen ist
19:43:20 xq: aktuell versteh ich noch nicht mal, was genau du da vor hast
19:44:02 Schrompf: du baust ne neue methode createMultiResource()
19:44:09 Schrompf: die nimmt wieder einen Functor, so wie die anderen
19:44:31 Schrompf: nur dass der Functor diesmal keinen Descriptor zurückgibt
19:44:41 Schrompf: sondern als Parameter ein Interface bekommt
19:45:13 Schrompf: das Interface supported die ganzen createSingleResource()-Methoden des ResourceManagers
19:45:28 Schrompf: so dass der Complex-Functor jetzt createTexture() createMesh() und so aufrufen kann
19:45:58 Schrompf: und dank des Interfaces legt das die Einzel-Ressourcen im ResourceManager an und verknüpft sie mit der ComplexResource
19:46:29 Schrompf: so dass, wenn später mal GPU wech und recreate() nötig ist, du die einzelnen Teile wieder der ComplexResource zuordnen kannst
19:47:27 xq: puh
19:48:03 xq: da muss ich glaube ich ne nacht drüber schlafen
19:48:10 xq: die komplexität davon schmeckt mir überhaupt nicht
19:48:53 xq: ich kann hier natürlich auch einfach nen rekursiven aufruf machen
19:50:08 Schrompf: andere idee: du machst den grundsätzlichen Model-Reader draußen
19:50:30 Schrompf: also irgendwo außerhalb readModel( filename)
19:50:49 Schrompf: und erzeugst jede teilressource, die du darin findest, mit nem speziellen functor
19:51:24 Schrompf: also createMesh( MySpecialFunctorToExtractTheMeshFromASTBFile())
19:51:47 Schrompf: und create2DTexture( MySpecialFunctorToExtractTheFirstTextureFromASTBFile())
19:52:14 Schrompf: und jeder der Functoren macht dann das File auf, liest die Grundstruktur, springt an die Stelle, wo er seine Ressource findet, und extrahiert die
19:52:37 Schrompf: Das heißt, Dein File wird dreimal geparsed, wenn es einen Mesh und ne AlbedoMap und ne NormalMap enthält
19:52:47 Schrompf: aber irgendeinen Tod musst du sterben
19:53:23 xq: das klingt richtig kacke
19:53:39 xq: da kann ich das file auch einfach laden, und komplett extern zusammenbauen
19:53:42 xq: ohne resourcemanager
19:53:53 xq: sonst parse ich die datei vier mal
19:55:11 xq: ne geometrie ist aktuell struct { vertices: []Vertex, indices: []u16, meshes: []struct { offset: u16, length: u16, texture: ?*Texture } }
19:55:23 xq: ich kann hier durchaus alles außer den texturen in einem rutsch laden
19:58:51 Schrompf: war nur ein vorschlag
19:58:56 xq: jo
19:59:01 xq: danke auch für den input :)
19:59:03 Schrompf: bei komplex-ressourcen kommst du halt mit dem callback echt in probleme
19:59:41 xq: ohne callback ebenso
19:59:59 xq: da wäre meine weniger generische lösung mit *einem* fetchResourceData(name):bytes jetzt bequemer gewesen
20:00:02 xq: aber: das bett ruft
20:00:32 Schrompf: adieu
20:00:53 xq: mal schauen, vllt. fällt mir morgen im ~~zig~~zug was ein