05:27:55 IceMichguest: xq, ach cool :) wessen Laptop ist das, Schnappsgirls? :D
05:28:16 IceMichguest: hm und das ist jetzt einfach heavy cross-compiled?
05:30:26 Schrompf joined the channel
05:32:06 IceMichguest: moin Schrompf!
05:32:13 Magister joined the channel
05:32:23 IceMichguest: yo Magister
05:34:03 Schrompf: hallompfo!
05:57:17 Magister joined the channel
05:57:24 Magister: moin
05:57:42 Schrompf: hi
06:09:15 Schrompf: sudo
06:09:16 Schrompf: nein
06:09:18 Schrompf: nicht hier
06:46:29 xq: IceMichguest: mein Laptop, und ja: selber source, sehr andere Plattformen
06:46:48 xq: sudo echo "Hallo Schrompf" > /net/irc/#zfx
06:49:36 IceMichguest: Schrompf, wollt schon sagen, du willst doch wohl deinen Mod-Status hier nicht missbrauchen
06:50:23 Schrompf: sudo kick -a
06:50:25 IceMichguest: gefällt mir. Cross-compilest du das von Linux aus für die anderen oder brauchst schon mehrere Systeme? Ich schätze, iOS ist nicht dabei aber alles andere? :D
06:50:31 IceMichguest: @xq
06:50:46 Schrompf: ne, werde ich natürlich nicht. nicht weil ich's nicht könnte, sondern weil... äh... naja... ich mag euch.
06:50:48 Schrompf: so ein bissl
06:50:49 Schrompf: manchmal
06:50:50 xq: nur ein quellsystem
06:50:53 Schrompf: wenn ich ausgeschlafen bin
06:51:04 xq: IceMichguest: müsste aber von windows oder macos genauso für alles cross-compilierbar sein
06:51:10 xq: nur das mit SDL2 wird etwas nervig
06:51:34 xq: oh und ich sehe einen neuzugang
06:52:09 IceMichguest: nice. Und welche Zielsysteme sind dann alle mögliche von einem Quellsystem?
06:58:43 xq: die idee ist "ja"
06:58:45 xq: aktuell:
06:59:35 xq: Linux (x86_64, aarch64), (theoretisch, habs nicht getestet) Windows (x86_64), Android (aarch64, x86_64, arm, i386), Wasm32
06:59:47 xq: theoretisch durch SDL noch möglich: guck dir die target-liste an :D
07:00:42 xq: mac: keine ahnung
07:00:48 xq: theoretisch gibts da auch SDL
07:00:53 xq: aber ich hab kein Plan
07:01:36 xq: aber ich sags mal so: aktuell hab ich kein Bestreben, mehr Plattformen abzudecken
07:01:46 xq: bin mit der aktuellen auswahl relativ glücklich
07:02:02 xq: kann vorallem jetzt auch einfach anfangen, kleine android-games damit zu bauen oder ähnliches
07:03:05 xq: was noch fehlt im toolkit/framework ist einfacher input (zwei "maustasten", ein zeiger, nur text-input)
07:10:31 IceMichguest: okay, klingt ja ganz gut. Ist für mein cross-platform-Empfinden dann leider unvollständig, aber darf ja auch
07:10:45 xq: inwiefern?
07:10:53 xq: ich supporte halt nu diese plattformen
07:11:01 xq: wenn du mir nen mac zahlst, schau ich auch gerne nach MacOS
07:11:10 xq: zig selber compiliert sowieso überall hin
07:39:21 IceMichguest: klar, ich zahl dir nen mac :D
07:39:33 IceMichguest: btw. damn, LA kommt erst in 31 Tagen
07:39:41 joeydee joined the channel
07:39:42 IceMichguest: da muss das Motorprojekt wohl erstmal ruhen
07:39:47 joeydee: moin
07:39:47 IceMichguest: moin joeydee
07:48:23 xq: moin joeydee
07:48:37 xq: IceMichguest: das mit dem Mac war ja auch nicht sonderlich ernst gemeint *grins*
07:48:46 xq: und LA: Jo, aus China dauert üblicherweise
07:49:54 joeydee: @xq: erstmal glückwunsch zum Cross-Compilen!
07:50:01 xq: dankeschön!
07:50:11 xq: der große Spaß kommt ja erst noch /o\
07:50:31 xq: aber: schriftart rendern klappt schon sehr gut, ich glaub ich hab meine neue lieblingsschriftart zum testen gefunden :D
07:52:52 Schrompf: oha, neuzugang? Moin Thor!
07:53:10 Schrompf: könnte auch effjam sein. mal ehrlich, wie oft verirren sich hier neue nasen her?
07:53:45 joeydee: Zu SDL und Mac: hatte ich mit C++ unter CodeBlocks am Laufen, das war baugleich zu Windows (mein komplettes Framework (Input und OpenGL über SDL) war mit gleichem Source auf beiden Plattformen unter CodeBlocks compilierbar)
07:54:43 joeydee: Ich glaube es gab nur 1 Änderung an 1 Stelle zu einem HW-Fallback, was anders war.
07:57:22 xq: joeydee: jo, ich denk nicht, dass das großer aufwand ist
07:57:29 xq: ich kanns nur nicht testen 🤷♂️
08:00:29 IceMichguest: xq, schon klar :) und ja, macs sind leider teuer, sogar ältere, gebrauchte modelle. Es gibt kein Billoteil, was einfach mal so läuft
08:33:30 Schrompf: Ich hätte hier eins
08:33:37 Schrompf: allerdings zu alt, fürchte ich
08:33:43 Schrompf: 2011 powerbook oder so
08:34:11 Schrompf: apple wird schon zu verhindern wissen, dass du das noch benutzen kannst
08:37:34 IceMichguest: nen rechner von 2011 läuft heutzutage auch nicht mehr, oder?
08:37:59 IceMichguest: das Problem ist, du kannst darauf halt kein neues macOS installieren, weil es zu viele Resourcen frisst, genauso wie es bei Win10 auch ist
08:38:21 IceMichguest: wobei ich eingestehen muss: wenn das Teil die powerpc-Architektur verwendet, ist das natürlich allein deswegen nicht mehr kompatibel
08:41:03 Schrompf: ne, das ding ist schon x86, soweit ich weiß. PowerPC ist ja BigEndian-Speichermodell, das hätte ich bei der Portierung gemerkt
08:41:22 Schrompf: könnte auch 2013 sein, aber ich weiß es nicht mehr
08:41:36 Schrompf: du kriegst wohl keine neuen OSse mehr installiert. nich wegen ressourcen, sondern weil Apple
08:41:51 Schrompf: das ding hat nen quadcore und 4GB RAM, glaube ich
08:43:48 IceMichguest: hm, was ist denn dann der Fehler? Also 4GB ist halt einfach zu wenig. Aber bei Win10 wäre mir 4GB auch einfach zu wenig
08:44:01 Schrompf: ja, zum sinnvollen arbeiten wahrscheinlich schon
08:44:15 IceMichguest: ja und zum einfach laufen ohne eine App offen... das ginge schon auch mit dem neusten macos
08:44:29 IceMichguest: sind aber alles irgendwie hypothetische Szenarien
08:44:44 IceMichguest: man braucht aber für viele Programme einfach neuere macOS-Versionen
08:44:56 Schrompf: ich hab den seit fünf jahren nicht mehr angehabt. ich hab halt nur im internet mitgelesen, dass du mit irgendner os-version nicht mehr updaten kannst
08:45:11 IceMichguest: C++17 wird z.B. auf älteren gar nicht unterstützt, weil da ne alte Version von libc++ (oder dem andren Teil) drauf ist, das will man nicht supporten
08:45:36 IceMichguest: was dazu kommt: das neuste macOS bricked alte Rechner eh, allein deswegen würd ich es nicht drauftun
08:45:54 IceMichguest: hm, aber 2013 sollte tatsächlich noch ganz gut laufen
08:45:57 IceMichguest: so alt ist das nicht
08:46:13 IceMichguest: na ja, gut, RAM halt...
08:46:34 IceMichguest: ich find meine 16GB schon zu wenig. Hätte gern 32 oder 64 :(
08:47:54 Schrompf: dann... äh... kauf dir welchen? oder ist da der gemeine cryptominer im weg?
09:24:33 xq: so
09:24:47 xq: auf jeden Fall brauch ich mal MacOS devices daheim
09:41:53 IceMichguest: Schrompf, macbooks lassen sich im RAM natürlich nicht upgraden
09:42:38 Schrompf: ahso
09:42:52 Schrompf: ich dachte, das wäre jetzt auch ein opfer der cryptominer geworden
09:43:12 IceMichguest: hm, wieso, was haben die Cryptominer denn kaputt gemacht letztens?
09:48:59 xq: Na, erst Grafikkarten, jetzt Festplatte
09:50:10 Schrompf: ich hoffe ja immer noch auf einen crash, so dass dann ne menge gebrauchte GPUs billig abzugeben sind
09:50:23 Schrompf: also dass sich irgendwas am prinzip ändert
09:50:33 Schrompf: etherium will ja weg vom "Proof Of Work"
09:52:02 xq: ohja
09:52:11 xq: ich würde mich ja sehr über eine RTX 2070 freuen
09:52:16 xq: oder auch gleich die 3070
09:59:35 xq: warum supported eigentlich kein einziges tool außer C++Builder und GIMP 32-Bit-Bitmap files
10:27:12 IceMichguest: aber wieso kaputt gemacht dann?
10:27:17 IceMichguest: also heavy use seh ich und dann?
10:41:09 Schrompf: du kriegst keine zu kaufen. und wenn, dann nur zu mondpreisen
10:42:47 Schrompf: weil die cryptominer schiffscontainer voll mit GPU-Schränken bauen, mal locker ein paar Dutzend KW strom absaugen, nur um number crunching zu betreiben. und bei den aktuellen Preisen für die diversen Crypto-Währungen lohnt sich das.
10:56:17 Schrompf: Das sieht dann zum Beispiel so aus: https://imgur.com/gallery/hRH6z
10:56:32 Schrompf: und es macht sehr anschaulich, warum man aktuell keine Grafikkarten mehr zu kaufen kriegt
10:56:44 Schrompf: und warum Crypto inzwischen mehr Strom verbraucht als ganz Dänemark
11:03:26 xq: jo
11:03:33 xq: Crypto skaliert nicht
11:03:37 xq: nicht mit den aktuellen ansätzen
11:03:48 xq: entweder, die ansätze sind von vornherein bullshit (proof of time)
11:04:13 xq: fressen unmengen an energie (proof of work) oder unmengen an material (proof of space)
11:04:21 xq: und die kombinationen sind dann halt absurd (proof of time and space)
11:04:27 xq: auch wenn das sehr poetisch klingt
11:08:03 joeydee: https://www.phoximages.de/uploads/2021/05/i68447b04ktj.jpg
11:08:32 joeydee: 4 Layer-Modes aus Photoshop mit Standard-Blend-Funcs nachgebaut
11:08:57 joeydee: links psd-ref, mitte die einzelnen Layer, rechts mein Ergebnis
11:09:45 Schrompf: feinfein
11:11:13 joeydee: war jetzt mal experimentell, wollte wissen was mit BlendFuncs tatsächlich geht.
11:20:27 xq: joa, sieht doch gut aus
11:20:32 xq: was ist denn "screen" blending eigentlich?
11:20:36 xq: also, wofür nutzt man das?
11:24:15 joeydee: Es hellt auf, aber addiert nicht. D.h. kein Color-Bleeding, eher "neblig/staubig machen" beim Painten.
11:24:36 xq: ah, spannend
11:34:00 joeydee: Ich bin dann aber trotzdem bei den eigenen Buffern, da ich ja noch ganz andere Filter einbauen möchte.
11:37:11 Schrompf: du baust gerade ein klassisches post processing-framework für spiele :-)
11:38:32 xq: Schrompf: nicht wirklich, wenn ich joeydee richtig verstanden habe
11:38:47 xq: spiele machen normalerweise eine texture für 4 kanülen
11:39:00 Schrompf: implementationsdetail
11:39:10 joeydee: ja, nur mit fokussiertem Schwerpunkt. Und sollte ich eines Tages alles verwirklichen, ist auch noch ein halber Deferred Renderer mit drin
11:39:21 Schrompf: ja, das glaub ich gern
11:39:24 Schrompf: viel spaß
11:39:57 joeydee: aber erstmal nicht :)
11:41:47 xq: ich brauch dringend ein immediate mode gui toolkit
11:42:01 xq: also wird mein aktuelles rumgebastel noch ausgebaut
11:43:40 joeydee: immediate mode ist cool :) ich hab allerdings 3 getrennte passes
11:45:01 xq: wie meinste?
11:46:34 joeydee: erst werden alle Elemente layoutet (nur Rechtecke verteilt und spätere Typen festgelegt), dann das Handling, dann Rendering. Original IM macht ja alles ... ja immediate eben ;)
11:46:50 xq: achso
11:47:02 xq: ne, ich mach nur direktes immediate layouting
11:47:04 xq: also
11:47:32 xq: if(ui.button(10, 20, 100, 30, "Hello")) { doStuff(); }
11:49:28 xq: wo ich aber grade n bissi probleme habe:
11:49:40 xq: wie manage ich aufrufe in einer schleife?
11:51:02 joeydee: if(ui.button(10, 20, 100, 30, "Hello"+i)) { doStuff(i); }
11:51:16 xq: naja, "Hello" ist ja das Label
11:51:23 xq: da ist "Hello"+i doof :D
11:51:29 xq: aber ich weiß, was du meinst
11:51:43 xq: wobei,...
11:51:44 xq: Idee!
11:51:46 joeydee: "Button1","Button2","Button3", ...
11:51:57 joeydee: Das ist für mich Schleife
11:52:10 xq: ja, aber die buttons können ja durchaus das selbe aussehen haben
11:52:12 joeydee: (Koods natürlich auch noch angepasst)
11:52:18 xq: if(ui.button(...,.{})) { doStuff(i); }
11:52:23 xq: das hier löst mein problem *grins*
11:52:41 xq: zig hat ein paar ... spezielle ... eigenschaften
11:52:54 joeydee: if(ui.button(10, 20,+30*i 100, 30, labels[i])) { doStuff(i); }
11:53:17 xq: joeydee: das geht aber nur, wenn labels[i] != labels[j]
11:53:28 xq: dotbraces (.{ ... }) sind anonyme tuple oder strukturen, und ich kann deren typename queryen
11:53:59 xq: ergo => ich erhalte durch den anonymen typen direkt die einzigartigkeit
11:54:07 xq: und dann kann ich einfach noch nen laufindex reinspeichern, wenn notwendig
11:55:16 joeydee: dachte "Hello" wär nur die Caption
11:55:22 xq: ja, isses ja auch
11:55:37 joeydee: Warum dürfen die dann nicht gleich sein?
11:55:42 xq: aber du kannst ja keine identifikation machen, wenn die Caption für 10 buttons gleich ist
11:55:59 xq: also, woher soll ich wissen, dass button(i) gedrückt wurde?
11:56:02 xq: ich hab auch schon ein schönes memory management pattern :)
11:56:19 joeydee: Daher habe ich "Name" und "Caption"-Eigenschaft getrennt.
11:56:28 xq: jo
11:56:36 joeydee: Für Eingabetext ist "Caption" dynamisch, aber "Name" konstant.
11:56:36 xq: name kann ich jetzt implizit berechnen
12:00:19 joeydee: Ich hab außerdem noch "type", da haben die Buttons in so einer generierte Liste z.B. alle den Typ "Paint-Ebene", heißen aber "Ebene 1", "Ebene 2",... (unique) und angezeigt wird z.B. "Haus", "Baum", ... (nicht unique)
12:01:27 joeydee: Da ich ja das Layout vorprozessiere ist das fein
12:09:07 xq: jo
12:09:16 xq: ich will explizit kein layouting in dem layer, den ich jetzt schreibe
12:09:39 xq: Jedes Widget hat ein benutzerdefiniertes Rechteck
12:15:18 joeydee: Layouting ist bei mir halt unabhängig. Der UI-Handler verlangt eine Liste "Hotspots" (dürften bei dir die "Widgets" sein), die ein Rechteck haben und im Prinzip alles sein können. Also statt z.B. myOption=ui.checkbox(rect,label,...,myOption) mache ich nur ui(rect,type,name,...) und dann erst später if(type, name, ..)myOption=spot.checkbox(myOption)
12:15:49 joeydee: (Will damit nur sagen, wie das bei mir in mehreren Passes aussieht, nicht, dass du das so machen sollst)
12:16:21 xq: ah
12:17:26 xq: übrigens, ein pattern, was mir am anfang super-weird vorkam, aber in zig eigentlich ein standard-pattern ist:
12:17:31 xq: pub fn deinit(self: *UserInterface) void {
12:17:31 xq: self.* = undefined;
12:17:31 xq: }
12:17:37 xq: deinit ist quasi sowas wie ein destruktor
12:17:58 xq: und "self.* = undefined" ist die aussage, dass man sich ab dieser stelle für die bits, auf die self zeigt, nicht mehr interessiert
12:18:16 joeydee: Ich hab nen Garbage Collector, na und ... ? ;)
12:18:24 xq: "undefined" ist der hint an den compiler, die dinge im release-fast mode nicht zu initialisieren
12:18:44 xq: im debug-mode schreibt dir der compiler dort aber einfach ein bit-pattern rein
12:18:54 xq: joeydee: hat mit GC erst mal nix zu tun ;)
12:19:42 xq: auf jeden fall: das pattern ist sehr nice, da man damit beim debuggein use-after-"free" sehr gut erkennen kann
12:26:57 joeydee: Zu Debug-Time also?
12:27:39 xq: jo
12:27:43 xq: also
12:27:44 xq: Debug builds
12:29:09 joeydee: Ich glaubs dir einfach mal dass es für dich fein ist und ich es so dringend bräuchte wie du exotische Blend-Modes ...
12:31:37 xq: also, hat mir schon den ein oder anderen bug gefangen
12:32:12 joeydee: Dann mach halt keine Bugs, musste auch keine einfangen :D
12:33:47 xq: klassiker :D
12:35:16 joeydee: Console.WriteLine() reicht zum Bug-fangen
12:36:45 xq: heh
12:36:54 xq: du glaubst nicht, wie oft ich kram einfach per writeline debugge :D
12:39:06 joeydee: weiß nicht mehr genau was das war, aber "früher" (TM) hab ich mit Sprachen/Compilern/Interpretern gearbeitet, da ist der Kram tatsächlich einfach eingefroren, bei fast jedem Fehler. Half nur, ne Menge WriteLines einzufügen und zu schauen was die letzte Ausgabe war :D
12:39:35 xq: hehehe
12:40:15 xq: aber ich finds lustig, wenn leute mir vorschlagen, breakpoints zu verwenden. Un nu? 5500 mal F5 drücken?
12:40:29 xq: oder ne halbe stunde warten, bis der conditional breakpoint tatsächlich hitted?
12:40:48 joeydee: hab ich bewusst nie mit gearbeitet
12:42:10 xq: conditional breakpoints?
12:42:20 joeydee: Breakpoints an sich.
12:42:24 xq: achso
12:42:29 xq: ja, nutz ich auch immer seltener
12:42:37 xq: generell: code lesen ist meist genauso effizient
12:43:43 joeydee: Achja, bei InDesign-Scripting ist das u.U. so wie ich beschrieben hatte. Man schreibt JavaScript, und InDesign ackert das durch ohne nach links oder rechts zu gucken. Und macht was oder nicht. Oder friert ein oder nicht.
12:43:52 xq: jo
12:43:53 xq: browser auch
12:43:56 xq: while(true) {}
12:44:01 xq: killed den tab
12:44:24 joeydee: Ja stimmt, als ich noch mit Webseiten experimentiert hatte war das auch
12:45:00 joeydee: Flash hatte anfangs dafür einen Timeout "Dieses Script läuft bereits länger als 15 Sekunden ..."
12:45:24 joeydee: Also nur Frame-Time, nicht Gesamt-Laufzeit natürlich
12:47:09 xq: joa
12:47:14 xq: 1/15 FPS
12:47:16 xq: \o/
12:49:39 joeydee: Vorberechnen einer Landschaft musste man dann asynchron coden, Daten laden etc. war dann ab AS3 schon asynchron angelegt, erst AIR hat das wieder optional ausgehebelt.
12:50:34 joeydee: Dass die ganze Community dann erstmal AS3 gehasst hatte, war dem Eventsystem zuzuschreiben. Da ist keiner mit zurechtgekommen.
12:51:00 joeydee: Wie für manche GFX-Programmierer der Umstieg auf Shader quasi :D
12:52:28 xq: ah :D
12:56:23 xq: jo, ich kenn genug, die sich da immer noch dagegen wehren :D
12:56:46 joeydee: (zu den Shadern hat irgendwer im Forum da so ein passendes Zitat in der Signatur ... ;))
13:00:38 joeydee: Es gab damals leider auch kaum gute Beispiele, die Bsp aus den AdobeDocs waren Crap und viel zu kompliziert für das was sie eigentlich erklären sollten, und daneben gabs nur ein paar Betatester, die das aber genauso schlecht erklärt hatten.
13:03:00 joeydee: Standardfrage war dann immer, wenn man mehrere Events (Ladevorgänge, oder auch nur Buttonklicks) in einem gemeinsamen Handler fangen möchte, wie komme ich darin an mein Ursprungsobjekt? Oder Zugriff auf Daten, die zwar vorher im Code stehen, aber noch gar nicht aufgerufen wurden, da das Ready-Event schon früher als gedacht geworfen wurde ... so Zeugs
13:04:21 joeydee: Da gabs ziemlich viel rap-Code, damals ... *inErinnerungenSchwelg* :D
13:04:25 joeydee: crap
13:04:39 xq: hrhr
13:05:29 joeydee: ja, ich hab gerade dein JCL-Zitat auf dem Schirm, das ist echt goldig :D
13:06:53 joeydee: Ich hab zwar beim Eventsystem durchgeblickt, aber das hat soviel Infrastruktur gefordert, da hatte ich mir geschworen mein eigenes UI zu bauen, ohne Events. Das hab ich heute noch.
13:07:07 joeydee: Womit sich der Themenkreis schließt ;)
13:10:20 xq: hehe
13:24:41 Biolunar joined the channel
14:00:28 Magister joined the channel