Hier kann über allgemeine Themen diskutiert werden, die sonst in kein Forum passen.
Insbesondere über Szene, Games, Kultur, Weltgeschehen, Persönliches, Recht, Hard- und Software.
struct ErrorType
{
char const* Description;
//Weitere Fehlerinformationen falls sinnvoll.
//Oder ein Callback für die Description anstatt die Description selbst. Dann kann man die Meldung an der Callsite dynamisch mit mehr Informationen versehen. (Dein "more")
};
extern const ErrorType ErrorOutOfMemory = { "The process is unable to allocate the required memory" };
extern const ErrorType ErrorOutOfBoundsAccess = { "An access occured outside the bounds of a datastructur" };
...
Ein großer Vorteil ist, dass der Linker den Fehlermeldungen "IDs" zuweist. (In Form der Adressen zu den Variablen)
Außerdem kann man weitere Informationen mitgeben.
Sorry – ich dachte an ein Klasse pro Fehler. (Aktuell haben 90 % der Fehler keinen Typ, und für den Rest eigene Strukturen.)
Ich bin immernoch strikt dagegen, irgendwelche Beschreibungen (oder Callbacks dafür) in der Logik zu parken. Die Logik sollte keine Ahnung von String-Repräsentation (nutzt die UI Unicode, ANSI, oder ASCII?) oder Lokalisierung (du willst alles auf Englisch, ich will halt auch Chinesisch) oder Informationsumfang (einfach nur Fehlermeldung ausgeben, oder dem User erklären, was passiert sein könnte?) haben. Da wir jetzt einen Funktionszeiger exportieren, landet die Formatierungsfunktion selbst dann im Logikmodul, wenn der Client keine Fehler ausgibt und sofort abbricht, meine Shell Extensions sind nun also alle viermal so groß (zusätzlich dazu, dass wir Lokalisierung und Kontrolle über Character Sets verloren haben).
Machen wir weiter und nehmen an, dass die IDs nun immer synchron sind. Wie genau fange ich nun im C#-Code eine FileAccessDenied-Exception und sage (nach Aufforderung an den User, die Datei zu schließen), dass der Client es erneut versuchen soll?
Ziemlich gemischte Gefühle, aber doch mehr zu freuen als zu jammern: Meine Tochter, Lilja Ziegenhagen, geboren am 4.9.2016. Es gab einige hässliche Komplikationen, aber wir sind alle noch am Leben. Und das war scheiße knapp.
Wird noch ne Weile dauern, ehe ich wieder an den heimischen Rechner oder gar zu was Produktivem kommen werde, aber egal: wir sind alle noch am Leben.
Übrigens an dieser Stelle auch noch vielen Dank dafür, dass ihr das Forum nicht irgendwo in die Cloud geschoben habt. CloudFlare z.B. ist mit Tor eine katastrophale Captcha-Orgie. Auf vielen Seiten laden die Bilder nur Schrittweise, und ich muss ca. zehn Mal aktualisieren bis von einem Bild mehr als der obere Rand da ist.
ZFX und fefe sind so ziemlich die einzigen nichtkommerziellen Seiten, die ich problemlos ansurfen kann.
MasterQ32 hat geschrieben:Ist das Haus jetzt das Haus, das ihr mitgefunded haben wolltet? Sieht auf jeden Fall alt, aber schön aus.
Nein, das Funding hat exakt 0 Euro eingebracht. Wir mussten dann umsatteln auf ein anderes Haus, das nicht so sanierungsbedürftig war wie das aus dem Funding; sprich: Wir müssen jetzt nichts mehr sanieren und haben den reinen Kaufpreis und Renovierungskosten. Ofenheizung und Sanitär sind vorhanden.
Voxel und SIMD … ein Traum! Ich kann mir gar nicht mehr vorstellen, dass man das in skalarem Code irgendwie performant hinkriegt.
Mein recht besonderes Flood Fill ist bei 20 Befehlen für 16 Voxel. Oder für 32 mit AVX. Oder für 64, wenn AVX-512 kommt :) Und das bei nur fünf Registern – ich kann die innerste Schleife komplett abrollen, und habe trotzdem keine Speicherzugriffe außer dem eigentlichen Laden und Speichern. Der Hammer.
OpenVDB bringt’s auf eine mittlere dreistellige Zahl. Aber dafür haben sie ja Multi-Threading!!!
Ich hatte es irgendwann schonmal geschrieben, aber: Bei Multi-Threading immer die teuren Jobs zuerst starten! Je weniger Jobs es sind, desto wichtiger wird das. Und der Aufwand ist winzig.
Selbst bei 100.000 Flood Fill-Jobs in acht Threads messe ich hier noch 10 % Verberesserung, wenn ich vorher ihre ungefähre Länge abschätze und ein std::sort drauf mache.
Chromanoid hat geschrieben: Als ich wegen der ZFX-Action mit Haxe und JTransc rumgebastelt habe, ist mir Dein Beitrag eingefallen. Jetzt hab ich mir Unity endlich mal genauer angeschaut und bin genauso begeistert. Vielleicht wird's ja doch was mit meinem Beitrag :roll: Auch der WebGL-Export scheint echt gut zu funktionieren.
Kannst du kurz deinen Workflow mit Unity beschreiben? Ich weiß es gibt Dokumentation en masse, aber bei mir hat es nie wirklich geklickt.
Hab ganz vergessen, hier rauf zu antworten. Hatte noch einen Entwurf gespeichert: Hui so richtig eingegrooved bin ich noch nicht, aber es ist wesentlich angenehmer als die ganze Nerverei, wenn man Debuggen, unterschiedliche Targets möchte etc.
Ich habe mir zum Einarbeiten einfach dieses Video:
[youtube]b7DZo4jA3Jo[/youtube]
auf 1,25facher Geschwindigkeit rein gezogen. Danach hatte ich einen allgemeinen Eindruck, wie man mit Unity3D zumindest Quick and Dirty arbeitet. Ich hoffe das nächste Mal kann ich dann auch was Fertiges abgeben. Mal sehen was mit meinen üblichen elenden endlosen größenwahnsinnigen Langzeitprojekten wird...
Um mal einen Eindruck davon zu bekommen, was VR für interaktive Medien verändern kann, habe ich mir mal ein Gear VR für mein neues Smartphone besorgt. Ich bin überrascht was alleine so ein kleines Smartphone heutzutage leisten kann und was VR tatsächlich für einen Unterschied macht... Ich teile John Carmacks Einschätzung, dass Mobile VR mit die zukunftsträchtigste Plattform für VR-Spiele ist. Smartphones kaufen sich alle, wenn man dann 50-100EUR für VR drauflegen muss, dann ist das eine ganz andere Sache, als sich für das gleiche Geld (Smartphone+Brille) nur eine aktive Brille zu kaufen und dann noch einen dicken PC braucht...
Hmm … die Shuttle-Modelle könnten leider weniger detailliert kaum sein :(
Aber dafür sind das Dateien aus 20 Jahren 3D-Software-Geschichte. Lightwave, 3D Studio, Blender. Die STLs stammen aus Blender, Cura, OpenSCAD, Sketchup, SolidWorks, AutoCAD, Tinkercad, Netfabb, Rhino, und aus 20 Jahre alten Autodesk-Schnittstellen. Sehr sehr feiner Testsatz für meine Loader :)
Wenn der Rechner abratzt während Notepad++ läuft, stellt es beim nächsten Start sogar die Dateien wieder her, die noch nie gespeichert wurden. Da ich es als eine Art Notizblock nutze, ist das geiler Shit.
Ja. Aaaaber: Ich habe einige vertrauliche Dokumente in verschlüsselten Containern. Ich will von den Daten keine Kopien auf meiner eigentlich Festplatte haben, auch keine lokalen. Ich würde mir manchmal wünschen, mehr Programme würden dokumentieren, wo sie was speichern. Lyx z.B. schreibt ja die ganzen temporären LaTeX Dateien nicht in das selbe Verzeichnis, wie die lyx Datei, was erstmal sehr nett ist - ich fand es immer erz nervig, wenn LaTeX 5 verschiedene temporäre Dateien erzeugt und nicht löscht (weil es sonst beim nächsten mal wieder genau so lange rechnen müsste). Aber im Falle von vertraulichen Daten, wäre es mir lieber, das würde nicht passieren.
Man könnte jetzt sagen, es ist eh dämlich, vertrauliche Dokumente auf normalen Rechnern zu bearbeiten. Oder dass eh nie jemals jemand diese temporären Dateien finden wird. Aber ein ungutes Gefühl ist es irgendwie doch...
Hmmm, ich habe mich da nicht eindeutig ausgedrückt: Die neuen Dokumente, die du anlegst, aber nie speicherst, werden wiederhergetellt. Das ist per se nicht schlecht, denn zu diesem Zeitpunkt ist nichts in einem sensiblen Container oder so.
Ob die Dateien, denen bereits ein Speicherort (z.B. im verschlüsselten Container) zugewiesen wurde, ebenfalls wiederhergestellt werden, habe ich noch gar nicht in Erfahrung gebracht. Falls ja, hast du mit deinen Sicherheitsbedenken völlig recht.
