Category: Notes

Donki Hills ist jetzt seit über einem Jahr auf Steam!

Vor genau einem Jahr erschien das Projekt auf der Steam-Seite und seitdem hat das Spiel einen langen Weg zurückgelegt. In dieser Zeit gab es viele Experimente, Veränderungen und die Suche nach der genauen Richtung, in die sich Donki Hills entwickeln sollte.

Die Arbeit am Gameplay geht weiter und nun erhält das Projekt nach und nach sein wahres Gesicht. Donki Hills beginnt sich in das zu verwandeln, was es sein sollte: Comedy First Person Roguelike Parody Survival Horror.

Ein seltsames Abenteuer, in dem Horror auf Humor, Entdeckungen und unerwartete Situationen trifft. Sie müssen in die Stadt gehen, nach Gegenständen suchen, Rätsel lösen und nach und nach das Geheimnis lüften, das Sie zu Maria führt.

Nachfolgend finden Sie aktuelle Screenshots vom nächsten Spieltest des Prototyps. Dies ist noch nicht das endgültige Erscheinungsbild des Spiels, aber man kann bereits die Atmosphäre der Stadt und die Richtung spüren, in die sich das Projekt bewegt.

Sehr gespannt auf Ihre Reaktion! 👀
Wie gefällt Ihnen die neue Ausrichtung? Wie sind eure Eindrücke von der Atmosphäre und den Ideen des Spiels?

Vielen Dank an alle, die Donki Hills zu ihrer Wunschliste hinzugefügt haben, die Entwicklung verfolgen und das Projekt unterstützen ❤️

Es liegen noch viele Experimente, neue Mechaniken und seltsame Abenteuer vor uns.

https://store.steampowered.com/app/3476390/Donki_Hills/

Hersteller moderner Gaming-Laptops konfigurieren Systeme häufig so, dass sich der Prozessor unter Last auf bis zu 90 Grad erwärmt und sogar 100 Grad Celsius erreicht. Dieses Problem ist im Sommer besonders akut, wenn anspruchsvolle Spiele oder schwere Arbeitsaufgaben ausgeführt werden.

Aufgrund der extremen Erwärmung wird Throttling aktiviert (Zurücksetzen der Prozessorfrequenzen, um physische Schäden zu verhindern), was zu einem starken Leistungsverlust, Einfrieren und einem Rückgang der FPS führt. Es gibt viele Möglichkeiten, Überhitzung zu bekämpfen (von der Verwendung von Kühlpads bis hin zu Undervolting), aber in diesem Artikel werde ich die einfachste und schnellste Methode beschreiben, die für Windows 11 und frühere Versionen des Betriebssystems relevant ist.

Die Methode besteht darin, den maximalen Prozessorstatus durch die Stromversorgungseinstellungen zu begrenzen:

1. Öffnen Sie die Energieoptionen über die Windows-Suche oder die Systemsteuerung.
2. Gehen Sie im aktiven Energieplan zum Abschnitt zum Ändern zusätzlicher Parameter.
3. Suchen Sie den Zweig Prozessor-Energieverwaltung.
4. Erweitern Sie die Option Maximaler Prozessorstatus.
5. Ändern Sie für Plugged In den Wert von 100 % auf 80 % oder weniger.

Nach Anwendung dieser Einstellungen übertaktet der Prozessor nicht mehr automatisch auf extreme Frequenzen, die übermäßige Wärme erzeugen. Obwohl die maximale Spitzenleistung um etwa 20 % sinkt, kommt es nicht mehr zu einer Überhitzung des Prozessors. Ein stabiler Betrieb mit reduzierter Frequenz ohne Drosselung ist VIEL besser und komfortabler für das System als ständige starke Leistungssprünge durch Überhitzung bei Temperaturen unter 100 Grad.

Jeder Laptop ist einzigartig, daher empfehle ich Benutzern, zu experimentieren und die optimale Balance (Prozentsatz) zu finden, die die gewünschte Leistung ohne Überhitzung bietet.

In diesem Beitrag beschreibe ich, wie ich die Surreal Engine-Spiel-Engine auf WebAssembly portiert habe.
https://demensdeum.com/demos/SurrealEngine/”
Surreal Engine – eine Spiel-Engine, die die meisten Funktionen der Unreal Engine 1 implementiert, berühmte Spiele auf dieser Engine – Unreal Tournament 99, Unreal, Deus Ex, Undying. Es bezieht sich auf klassische Engines, die hauptsächlich in einer Single-Threaded-Ausführungsumgebung arbeiteten.
Ich hatte ursprünglich die Idee, ein Projekt zu übernehmen, das ich nicht in einem angemessenen Zeitrahmen abschließen konnte, und so meinen Twitch-Followern zu zeigen, dass es Projekte gibt, die selbst ich nicht schaffen kann. Während meines ersten Streams wurde mir plötzlich klar, dass die Aufgabe, Surreal Engine C++ mithilfe von Emscripten auf WebAssembly zu portieren, machbar war.

Einen Monat später kann ich meine Gabel- und Motorbaugruppe auf WebAssembly demonstrieren:
https://demensdeum.com/demos/SurrealEngine/
Die Steuerung erfolgt wie im Original über die Tastaturpfeile. Als nächstes plane ich, es für die mobile Steuerung (Tachi) anzupassen und dabei die richtige Beleuchtung und andere grafische Funktionen des Unreal Tournament 99-Renderings hinzuzufügen.

Wo soll ich anfangen?

Als erstes möchte ich sagen, dass jedes Projekt mit Emscripten von C++ nach WebAssembly portiert werden kann. Die Frage ist nur, wie vollständig die Funktionalität sein wird. Wählen Sie ein Projekt, dessen Bibliotheksports bereits für Emscripten verfügbar sind; Im Fall der Surreal Engine haben Sie großes Glück, denn die Engine verwendet SDL 2, OpenAL – Bibliotheken. Sie sind beide auf Emscripten portiert. Als Grafik-API kommt allerdings Vulkan zum Einsatz, das derzeit für HTML5 nicht verfügbar ist, an der Implementierung von WebGPU wird gearbeitet, befindet sich aber ebenfalls im Entwurfsstadium und es ist auch nicht bekannt, wie einfach die weitere Portierung von Vulkan auf WebGPU nach der vollständigen Standardisierung sein wird. Daher musste ich meinen eigenen grundlegenden OpenGL-ES/WebGL-Renderer für Surreal Engine schreiben.

Das Projekt erstellen

Build-System in Surreal Engine – CMake, was auch die Portierung vereinfacht, da Emscripten seine nativen Builder – emcmake, emmake.
Der Surreal Engine-Port basierte auf dem Code meines neuesten Spiels in WebGL/OpenGL ES und C++ namens Death-Mask. Dadurch war die Entwicklung viel einfacher, ich hatte alle notwendigen Build-Flags und Codebeispiele dabei.
Einer der wichtigsten Punkte in CMakeLists.txt sind die Build-Flags für Emscripten, unten ist ein Beispiel aus der Projektdatei:

set(CMAKE_CXX_FLAGS "-s MIN_WEBGL_VERSION=2 
-s MAX_WEBGL_VERSION=2 
-s EXCEPTION_DEBUG 
-fexceptions 
--preload-file UnrealTournament/ 
--preload-file SurrealEngine.pk3 
--bind 
--use-preload-plugins 
-Wall 
-Wextra 
-Werror=return-type 
-s USE_SDL=2 
-s ASSERTIONS=1 
-w 
-g4 
-s DISABLE_EXCEPTION_CATCHING=0 
-O3 
--no-heap-copy 
-s ALLOW_MEMORY_GROWTH=1 
-s EXIT_RUNTIME=1")

Das Build-Skript selbst:

clear
emmake make -j 16
cp SurrealEngine.data /srv/http/SurrealEngine/SurrealEngine.data
cp SurrealEngine.js /srv/http/SurrealEngine/SurrealEngine.js
cp SurrealEngine.wasm /srv/http/SurrealEngine/SurrealEngine.wasm
cp ../buildScripts/Emscripten/index.html /srv/http/SurrealEngine/index.html

Als Nächstes bereiten wir index.html vor, das den Projektdateisystem-Preloader enthält. Zum Hochladen ins Web habe ich die Unreal Tournament Demo-Version 338 verwendet. Wie Sie der CMake-Datei entnehmen können, wurde der entpackte Spielordner zum Build-Verzeichnis hinzugefügt und als Preload-Datei für Emscripten verknüpft.

Hauptcodeänderungen

Dann mussten wir die Spielschleife des Spiels ändern, man kann keine Endlosschleife ausführen, das führt zum Einfrieren des Browsers, stattdessen muss man emscripten_set_main_loop verwenden, über diese Funktion habe ich in meiner Notiz von 2017 geschrieben „Portierung von SDL C++-Spielen nach HTML5 (Emscripten)“
Wir ändern den Code zum Beenden der while-Schleife in if, zeigen dann die Hauptklasse der Spiel-Engine, die die Spielschleife enthält, im globalen Bereich an und schreiben eine globale Funktion, die den Spielschleifenschritt vom globalen Objekt aus aufruft:

#if __EMSCRIPTEN__
#include <emscripten.h>
Engine *EMSCRIPTEN_GLOBAL_GAME_ENGINE = nullptr;
void emscripten_game_loop_step() {
	EMSCRIPTEN_GLOBAL_GAME_ENGINE->Run();
}
#endif

Danach müssen Sie sicherstellen, dass in der Anwendung keine Hintergrundthreads vorhanden sind. Wenn ja, dann machen Sie sich bereit, sie für die Single-Thread-Ausführung neu zu schreiben, oder verwenden Sie die phtread-Bibliothek in Emscripten.
Der Hintergrund-Thread in Surreal Engine wird zum Abspielen von Musik verwendet. Vom Haupt-Engine-Thread kommen Daten über den aktuellen Titel, die Notwendigkeit, Musik abzuspielen, oder deren Fehlen. Anschließend erhält der Hintergrund-Thread über einen Mutex einen neuen Status und beginnt mit der Wiedergabe neuer Musik oder pausiert. Der Hintergrundthread wird auch zum Puffern von Musik während der Wiedergabe verwendet.
Meine Versuche, die Surreal Engine für Emscripten mit pthread zu erstellen, waren erfolglos, da die SDL2- und OpenAL-Ports ohne pthread-Unterstützung erstellt wurden und ich sie nicht aus Gründen der Musik neu erstellen wollte. Daher habe ich die Funktionalität des Hintergrundmusik-Streams mithilfe einer Schleife auf die Single-Threaded-Ausführung übertragen. Durch das Entfernen von pthread-Aufrufen aus dem C++-Code habe ich die Pufferung und Musikwiedergabe in den Hauptthread verschoben, damit es keine Verzögerungen gibt, und den Puffer um einige Sekunden erhöht.
Als nächstes werde ich spezifische Implementierungen von Grafik und Sound beschreiben.

Vulkan wird nicht unterstützt!

Ja, Vulkan wird in HTML5 nicht unterstützt, obwohl alle Marketingbroschüren die plattformübergreifende und breite Plattformunterstützung als Hauptvorteil von Vulkan darstellen. Aus diesem Grund musste ich meinen eigenen grundlegenden Grafikrenderer für einen vereinfachten OpenGL-Typ schreiben – ES, es wird auf mobilen Geräten verwendet, enthält manchmal nicht die modischen Funktionen des modernen OpenGL, lässt sich aber sehr gut auf WebGL portieren, was genau das ist, was Emscripten implementiert. Das Schreiben des grundlegenden Kachel-Renderings, des BSP-Renderings für die einfachste GUI-Anzeige und des Renderns von Modellen und Karten wurde in zwei Wochen abgeschlossen. Dies war vielleicht der schwierigste Teil des Projekts. Es liegt noch viel Arbeit vor uns, die volle Funktionalität des Surreal Engine-Renderings zu implementieren, daher ist jede Hilfe von Lesern in Form von Code und Pull-Requests willkommen.

OpenAL unterstützt!

Das große Glück ist, dass Surreal Engine OpenAL für die Audioausgabe verwendet. Nachdem ich eine einfache Hallo-Welt in OpenAL geschrieben und sie mit Emscripten in WebAssembly zusammengestellt hatte, wurde mir klar, wie einfach alles war, und ich machte mich an die Portierung des Sounds.
Nach mehreren Stunden des Debuggens stellte sich heraus, dass die OpenAL-Implementierung von Emscripten mehrere Fehler aufweist. Beispielsweise gab die Methode beim Initialisieren des Lesens der Anzahl der Monokanäle eine unendliche Zahl zurück, und nach dem Versuch, einen Vektor unendlicher Größe zu initialisieren, stürzte C++ mit der Ausnahme vector::length_error ab.
Wir haben es geschafft, dies zu umgehen, indem wir die Anzahl der Monokanäle auf 2048 fest codiert haben:

		alcGetIntegerv(alDevice, ALC_MONO_SOURCES, 1, &monoSources);
		alcGetIntegerv(alDevice, ALC_STEREO_SOURCES, 1, &stereoSources);

#if __EMSCRIPTEN__
		monoSources = 2048; // for some reason Emscripten's OpenAL gives infinite monoSources count, bug?
#endif

Gibt es ein Netzwerk?

Surreal Engine unterstützt derzeit kein Online-Spielen, das Spielen mit Bots wird unterstützt, aber wir brauchen jemanden, der KI für diese Bots schreibt. Theoretisch können Sie mithilfe von Websockets ein Netzwerkspiel auf WebAssembly/Emscripten implementieren.

Schlussfolgerung

Abschließend möchte ich sagen, dass die Portierung der Surreal Engine aufgrund der Verwendung von Bibliotheken, für die es Emscripten-Portierungen gibt, sowie meiner bisherigen Erfahrung bei der Implementierung eines Spiels in C++ für WebAssembly auf Emscripten recht reibungslos verlief. Nachfolgend finden Sie Links zu Wissensquellen und Repositorien zum Thema.
M-M-M-MONSTER TÖTEN!
Wenn Sie dem Projekt außerdem helfen möchten, vorzugsweise mit WebGL/OpenGL ES-Rendering-Code, dann schreiben Sie mir per Telegram:
https://t.me/demenscave

Links

https://demensdeum.com/demos/SurrealEngine/

https://github.com/demensdeum/SurrealEngine-Emscripten

https://github.com/dpjudas/SurrealEngine

Wenn sich zwei Geräte hinter NAT oder strengen Firewalls befinden und sich nicht direkt „sehen“ können, scheint ein VPN die Standardlösung zu sein. Ein vollwertiger L3-Tunnel (wie WireGuard oder OpenVPN) ist jedoch häufig überflüssig: Er erfordert Root-Rechte, die Einrichtung virtueller Schnittstellen und kann zu Konflikten mit vorhandenen Routen führen.

In solchen Fällen ist es praktisch, Chisel zu verwenden – einen TCP/UDP-Tunnel, der auf HTTP läuft und WebSockets für die Datenübertragung verwendet. In diesem Hinweis werde ich zeigen, wie man einen Port über einen Zwischenserver von einem Client an einen anderen „weiterleitet“.

Wie funktioniert es?

Stellen Sie sich die Situation vor: Sie haben Client A (z. B. Ihren Heimserver), Client B (Ihren Arbeitslaptop) und einen VPS mit einer öffentlichen IP-Adresse. Clients A und B können auf den VPS zugreifen, jedoch nicht aufeinander.

Das Weiterleitungsschema sieht folgendermaßen aus:
1. Client A stellt eine Verbindung zum VPS her und öffnet einen „Reverse“-Port auf dem Server. Jetzt geht alles, was an Port X des Servers ankommt, an Port Y von Client A.
2. Client B stellt eine Verbindung zum VPS her und leitet Port Z von seinem lokalen Computer an Port X des Servers weiter.
3. Infolgedessen greift Client B auf localhost:Z zu und landet auf Client A:Y.

Dieser Ansatz ist eine der Lösungen in Fällen, in denen die Kommunikation mit einem VPS keine L3-Schicht implementiert oder keine Möglichkeit besteht, Routing zwischen Clients zu konfigurieren. Wir arbeiten ausschließlich auf Anwendungs- und Portebene.

Schritt 1: Starten Sie den Server

Führen Sie Chisel auf Ihrem VPS einfach im Servermodus aus. Das Flag --reverse ist erforderlich, damit Clients Ports auf der Serverseite öffnen können.

chisel server --port 8080 --reverse

Schritt 2: Client A (Quelle) verbinden

Nehmen wir an, Kunde A möchte den Zugriff auf seinen lokalen Webserver auf Port 3000 öffnen. Er verbindet sich mit dem VPS und sagt: „Reservieren Sie Port 2000 auf dem Server und leiten Sie ihn an 3000 an mich weiter.“

chisel client vps-ip:8080 R:2000:127.0.0.1:3000

Jetzt führt Port 2000 am VPS (an der Loopback-Schnittstelle) zu Client A.

Schritt 3: Client B (Verbraucher) verbinden

Jetzt möchte Client B auf diese Ressource zugreifen. Es verbindet sich mit demselben VPS und leitet seinen lokalen Port 8080 an Port 2000 des Servers weiter.

chisel client vps-ip:8080 8080:127.0.0.1:2000

Bereit! Wenn Sie nun http://localhost:8080 auf Client B öffnen, sehen Sie, dass der Dienst auf Client A ausgeführt wird.

Sicherheit und Nuancen

Chisel unterstützt die Authentifizierung über das Flag --auth, was bei der Arbeit über öffentliche Server dringend empfohlen wird. Sie können TLS-Zertifikate auch zum Verschlüsseln des Datenverkehrs verwenden.

Der Hauptvorteil dieses Ansatzes besteht darin, dass keine TUN/TAP-Geräte und komplexen Routing-Tabellen erforderlich sind. Dabei handelt es sich um einen abgespeckten Tunnel, der genau eines tut: Ports über eine WebSocket-Verbindung bindet. Dies funktioniert sogar über Unternehmens-Proxys, wenn Sie Chisel so konfigurieren, dass es über Port 443 funktioniert.

Ausgabe

Chisel ist ein Dienstprogramm für bestimmte Netzwerkaufgaben. Wenn Sie Ports zwischen isolierten Knoten weiterleiten müssen, ohne ein vollwertiges VPN einzurichten, erweist sich eine Kombination aus Vorwärts- und Rückwärtstunneln über einen Relay-Server als eine durchaus praktikable Lösung.

Links

https://github.com/jpillora/chisel

Sie verbringen Stunden damit, am Code zu arbeiten, Hypothesen durchzugehen und die Bedingungen anzupassen, aber der Fehler wird trotzdem reproduziert. Kommt Ihnen das bekannt vor? Dieser Zustand der Frustration wird oft als „Geisterjagd“ bezeichnet. Das Programm scheint sein eigenes Leben zu führen und ignoriert Ihre Korrekturen.

Einer der häufigsten – und ärgerlichsten – Gründe für diese Situation ist die Suche nach einem Fehler an der völlig falschen Stelle in der Anwendung.

Die Falle der „falschen Symptome“

Wenn wir einen Fehler sehen, wird unsere Aufmerksamkeit auf die Stelle gelenkt, an der er „geschossen“ hat. Aber in komplexen Systemen ist das Auftreten eines Fehlers (Absturz oder falscher Wert) nur das Ende einer langen Kette von Ereignissen. Wenn Sie versuchen, das Ende zu beheben, bekämpfen Sie die Symptome, nicht die Krankheit.

Hier kommt das Flussdiagramm-Konzept ins Spiel.

Wie es in der Realität funktioniert

Natürlich ist es nicht notwendig, jedes Mal direkt ein Flussdiagramm auf Papier zu zeichnen, aber es ist wichtig, es im Kopf zu haben oder als architektonischen Leitfaden zur Hand zu haben. Mit einem Flussdiagramm können Sie den Betrieb einer Anwendung als Ergebnisbaum visualisieren.

Ohne diese Struktur zu verstehen, tappt der Entwickler oft im Dunkeln. Stellen Sie sich die Situation vor: Sie bearbeiten die Logik in einem Bedingungszweig, während die Anwendung (aufgrund eines bestimmten Parametersatzes) zu einem völlig anderen Zweig wechselt, an den Sie noch nicht einmal gedacht haben.

Ergebnis: Sie verbringen Stunden mit der „perfekten“ Codekorrektur in einem Teil des Algorithmus, was natürlich nicht dazu beiträgt, das Problem in einem anderen Teil des Algorithmus zu beheben, wo es tatsächlich fehlschlägt.

Algorithmus zur Beseitigung eines Fehlers

Um nicht mehr an einer verschlossenen Tür herumzurütteln, müssen Sie Ihre Herangehensweise an die Diagnose ändern:

• Finden Sie den Status im Ergebnisbaum:Bevor Sie Code schreiben, müssen Sie den Pfad genau bestimmen, den die Anwendung genommen hat. An welchem ​​Punkt hat die Logik eine falsche Wendung genommen? Welcher konkrete Staat (Staat) hat zu dem Problem geführt?
• Reproduktion ist 80 % des Erfolgs: Dies wird normalerweise durch Tester und automatisierte Tests durchgeführt. Wenn der Fehler „schwebt“, wird die Entwicklung in den Prozess einbezogen, um gemeinsam nach Bedingungen zu suchen.
• Verwenden Sie so viele Informationen wie möglich: Protokolle, Betriebssystemversion, Geräteparameter, Verbindungstyp (WLAN/5G) und sogar ein bestimmter Telekommunikationsbetreiber sind für die Lokalisierung wichtig.

„Foto“ vom Moment des Fehlers

Um das Problem zu beheben, müssen Sie im Idealfall über den vollständigen Status der Anwendung zum Zeitpunkt der Reproduktion des Fehlers verfügen. Auch Interaktionsprotokolle sind von entscheidender Bedeutung: Sie zeigen nicht nur den Endpunkt, sondern auch den gesamten Benutzerpfad (welche Aktionen dem Fehler vorausgingen). Dies hilft zu verstehen, wie ein ähnlicher Zustand wieder hergestellt werden kann.

Zukunftstipp: Wenn Sie auf einen komplexen Fall stoßen, fügen Sie diesem Codeabschnitt erweiterte Debug-Protokollierungsinformationen hinzu, für den Fall, dass die Situation erneut auftritt.

Das Problem „schwer fassbarer“ Zustände im Zeitalter der KI

In modernen Systemen, die LLM (Large Language Models) verwenden, wird der klassische Determinismus („ein Eingang, ein Ausgang“) häufig verletzt. Sie können genau die gleichen Eingabedaten übergeben, erhalten aber ein anderes Ergebnis.

Dies geschieht aufgrund des Nichtdeterminismus moderner Produktionssysteme:

• GPU-Parallelität: GPU-Gleitkommaoperationen sind nicht immer assoziativ. Aufgrund der parallelen Ausführung von Threads kann sich die Reihenfolge, in der Zahlen hinzugefügt werden, geringfügig ändern, was sich auf das Ergebnis auswirken kann.
• GPU-Temperatur und -Drosselung: Ausführungsgeschwindigkeit und Lastverteilung können vom physischen Zustand der Hardware abhängen. In großen Modellen häufen sich diese mikroskopischen Unterschiede und können dazu führen, dass am Ausgang ein anderer Token ausgewählt wird.
• Dynamisches Batching: In der Cloud wird Ihre Anfrage mit anderen kombiniert. Unterschiedliche Batch-Größen verändern die Mathematik der Berechnungen in den Kerneln.

Unter solchen Bedingungen wird es nahezu unmöglich, „denselben Zustand“ zu reproduzieren. Nur ein statistischer Testansatz kann Sie hier retten.

Wenn die Logik versagt: Speicherprobleme

Wenn Sie mit „unsicheren“ Sprachen (C oder C++) arbeiten, kann der Fehler aufgrund einer Speicherbeschädigung auftreten.

Dies sind die schwerwiegendsten Fälle: Ein Fehler in einem Modul kann Daten in einem anderen „überschreiben“. Dies führt zu völlig unerklärlichen und isolierten Fehlern, die mit der normalen Anwendungslogik nicht nachvollzogen werden können.

Wie schützt man sich auf architektonischer Ebene?

Um solche „mystischen“ Fehler zu vermeiden, sollten Sie moderne Ansätze verwenden:

• Multithread-Programmiermuster:Eine klare Synchronisierung eliminiert Race Conditions.
• Thread-sichere Sprachen: Tools, die Speichersicherheit zur Kompilierungszeit garantieren:
  • Rust: Das Eigentümersystem eliminiert Speicherfehler.
  • Swift 6-Parallelität:Starke Datenisolationsprüfungen.
  • Erlang: Vollständige Prozessisolation durch das Akteurmodell.

Zusammenfassung

Bei der Behebung eines Fehlers geht es nicht darum, neuen Code zu schreiben, sondern darum, zu verstehen, wie der alte funktioniert. Denken Sie daran: Sie könnten Zeit damit verschwenden, einen Zweig zu bearbeiten, den das Management nicht einmal berührt. Erfassen Sie den Zustand des Systems, berücksichtigen Sie den Faktor des KI-Nichtdeterminismus und wählen Sie sichere Tools aus.

(und wie man Lösungen erstellt, die auch nach Updates weiterhin funktionieren)

„Apps dürfen nur öffentliche APIs verwenden und müssen auf dem aktuell ausgelieferten Betriebssystem ausgeführt werden.“ Richtlinien zur Überprüfung von Apple-Apps

Wenn Sie jemals angefangen haben, mit einem neuen Framework zu arbeiten, und sich dabei ertappt haben, dass Sie denken: „Jetzt verstehe ich alles selbst, das Lesen der Dokumentation ist zu lang“, dann sind Sie definitiv nicht allein. Viele von uns haben einen natürlichen Forscherinstinkt: Erst ausprobieren und erst dann die Anleitung anschauen. Und das ist völlig normal.

In diesem Stadium kann es jedoch leicht passieren, dass man sich übertreibt und in eine Situation gerät, in der der Code zwar gut funktioniert, sich aber möglicherweise auf nicht offensichtliche Funktionen des Systems verlässt.

Warum reicht es manchmal nicht aus, es einfach „selbst herauszufinden“?

Frameworks, insbesondere geschlossene, sind komplexe und vielschichtige Systeme. Sie verbergen oft interne Logik und Optimierungen, die:

* sind nicht in der öffentlichen Dokumentation beschrieben;
* garantieren nicht, dass das Verhalten auch in Zukunft beibehalten wird;
* kann sich mit der Veröffentlichung neuer Versionen ändern;
* kann den Entwicklern bekannte Funktionen enthalten, die noch nicht behoben wurden.

Wenn wir intuitiv handeln, besteht die Gefahr, dass Architektur auf zufälligen Beobachtungen und nicht auf dokumentierten Regeln basiert. Dadurch kann der Code empfindlicher auf Aktualisierungen reagieren.

Dokumentation ist keine Einschränkung, sondern eine verlässliche Unterstützung

Framework-Entwickler erstellen Handbücher, um uns zu helfen. Wenn wir innerhalb der Dokumentation handeln, erhalten wir:

* Stabilität;
* Unterstützung;
* vorhersehbares Systemverhalten.

Wenn wir über diese Grenzen hinausgehen, gehen wir zusätzliche Risiken ein und die Pflege dieses Codes wird schwieriger.

Experimente? Sicherlich. Aber mit einem Verständnis für Grenzen.
Neugier ist eine großartige Eigenschaft eines Entwicklers. Das Erkunden und Ausprobieren neuer Dinge ist absolut unerlässlich. Aber hier ist ein kleiner Wunsch:

Die bequemste Art zu experimentieren besteht darin, sich auf Best Practices zu verlassen.

Bei der Dokumentation handelt es sich um eine Karte, die zeigt, welche Pfade am sichersten sind und von den Erstellern unterstützt werden.

Eine Außenperspektive: Expertenrat

Wir lernen oft von erfahrenen Kollegen:

* sie führen nützliche Kurse durch,
* auf Konferenzen sprechen,
* wunderbare Bücher und Blogs schreiben,
* ihre einzigartige Vision teilen.

Viele von ihnen teilen wirklich wertvolle Erfahrungen. Aber es sei daran erinnert: Wenn die Ansätze des Autors im Widerspruch zur offiziellen Dokumentation stehen, können sie sich als fragil erweisen.

Solche „empirischen Muster“ manchmal:

* nur mit einer bestimmten Version des Frameworks arbeiten;
* empfindlich gegenüber Updates;
* kann sich in ungewöhnlichen Situationen unvorhersehbar verhalten.

Von der Community zu lernen ist großartig und lohnend. Aber jeder Rat, selbst der maßgeblichste, sollte immer sorgfältig anhand offizieller Handbücher überprüft werden.

Ein wenig über SOLID

Drei Ideen aus den SOLID-Prinzipien ergänzen diesen Ansatz perfekt:

* Offenes/geschlossenes Prinzip: Versuchen Sie, das Verhalten über öffentliche APIs zu erweitern und verlassen Sie sich nach Möglichkeit nicht auf eine versteckte Implementierung.
* Liskov-Substitutionsprinzip: Verlassen Sie sich auf den Vertrag, nicht auf die konkrete Umsetzung. Andernfalls können Änderungen unter der Haube zu unerwarteten Schwierigkeiten führen.
* Abhängigkeitsumkehr: Erstellen Sie Abhängigkeiten auf Abstraktionen, nicht auf Details.

In der Praxis bedeutet dies, dass die Bindung an interne, nicht dokumentierte Details des Frameworks das System spröde macht.
Basierend auf öffentlichen Schnittstellen und Verträgen erhalten wir:

* bessere Isolierung des Codes von Änderungen im Framework;
* einfache Prüfung;
* Vorhersehbarkeit und Zuverlässigkeit der Architektur.

Was passiert, wenn ein Fehler vorliegt?

Es kommt auch vor, dass alles nach den Regeln gemacht wird, das Ergebnis aber nicht den Erwartungen entspricht. Rahmenbedingungen entwickeln sich weiter und sind nicht immer perfekt. In solchen Fällen:

* Erstellen Sie ein Minimalbeispiel, das das Problem reproduziert.
* Stellen Sie sicher, dass nur dokumentierte APIs verwendet werden.
* Senden Sie einen Fehlerbericht – das Entwicklungsteam wird Ihre Arbeit sicherlich zu schätzen wissen und versuchen zu helfen.

Wenn das Beispiel auf Workarounds setzt, wird es für Entwickler deutlich schwieriger, Support zu leisten.

So holen Sie das Beste aus dem Framework heraus

*Siehe Dokumentation.
* Befolgen Sie die Anleitungen und Empfehlungen der Autoren.
* Experimentieren Sie innerhalb der beschriebenen Funktionalität.
* Überprüfen Sie die Ratschläge im Internet mit offiziellen Quellen.
* Lokalisieren Sie Fehler unter Einhaltung der Rahmenverträge.

Schlussfolgerung

Frameworks sind mächtige Werkzeuge mit eigenen Spielregeln. Wenn wir sie vergessen, besteht die Gefahr, dass unser Code übermäßig anfällig wird. Aber wir alle möchten, dass die erstellten Produkte lange leben und nicht nach jedem kleinen Update dringende Korrekturen erfordern.

Handbücher und Dokumentationen sind eine hervorragende Unterstützung, die dabei hilft, wirklich zuverlässige Lösungen zu schaffen.

Quellen

https://developer.apple.com/app-store/review/guidelines/
https://en.wikipedia.org/wiki/SOLID
https://en.wikipedia.org/wiki/API
https://en.wikipedia.org/wiki/RTFM

In dieser Notiz beschreibe ich das Verfahren zum Erstellen einer C++-SDL-Anwendung für iOS unter Linux, zum Signieren eines IPA-Archivs ohne kostenpflichtiges Apple Developer-Abonnement und zum Installieren auf einem sauberen Gerät (iPad) mit macOS ohne Jailbreak.

Zuerst installieren wir die Build-Toolchain für Linux:
https://github.com/tpoechtrager/cctools-port

Die Toolchain muss aus dem Repository heruntergeladen werden. Befolgen Sie dann die Anweisungen auf der Godot Engine-Website, um die Installation abzuschließen:
https://docs.godotengine.org/ru/latest/development/compiling/cross-compiling_for_ios_on_linux.html

Im Moment müssen Sie Xcode dmg herunterladen und das SDK von dort kopieren, um den cctools-Port zu erstellen. Dieser Schritt ist unter macOS einfacher durchzuführen; Kopieren Sie einfach die erforderlichen SDK-Dateien aus dem installierten Xcode. Nach erfolgreicher Assemblierung enthält das Terminal den Pfad zur Cross-Compiler-Toolchain.
Als Nächstes können Sie mit der Erstellung der SDL-Anwendung für iOS beginnen. Öffnen wir cmake und fügen die notwendigen Änderungen hinzu, um den C++-Code zu erstellen:

SET(CMAKE_SYSTEM_NAME Darwin)
SET(CMAKE_C_COMPILER arm-apple-darwin11-clang)
SET(CMAKE_CXX_COMPILER arm-apple-darwin11-clang++)
SET(CMAKE_LINKER arm-apple-darwin11-ld)

Jetzt können Sie mit cmake und make kompilieren, aber vergessen Sie nicht, $PATH zur Cross-Compiler-Toolchain hinzuzufügen:

PATH=$PATH:~/Sources/cctools-port/usage_examples/ios_toolchain/target/bin

Zur korrekten Verknüpfung mit Frameworks und SDL schreiben wir diese in cmake, Abhängigkeiten des Spiels Space Jaguar zum Beispiel:

target_link_libraries(
${FSEGT_PROJECT_NAME}
${FLAME_STEEL_PROJECT_ROOT_DIRECTORY}/scripts/buildScripts/ios/resources/libs/libclang_rt.ios.a
${FLAME_STEEL_PROJECT_ROOT_DIRECTORY}/scripts/buildScripts/ios/resources/libs/libSDL2.a
${FLAME_STEEL_PROJECT_ROOT_DIRECTORY}/scripts/buildScripts/ios/resources/libs/libSDL2_mixer.a
${FLAME_STEEL_PROJECT_ROOT_DIRECTORY}/scripts/buildScripts/ios/resources/libs/libSDL2_image.a
"${FLAME_STEEL_PROJECT_ROOT_DIRECTORY}/scripts/buildScripts/ios/resources/libs/CoreServices.framework"
"${FLAME_STEEL_PROJECT_ROOT_DIRECTORY}/scripts/buildScripts/ios/resources/libs/ImageIO.framework"
"${FLAME_STEEL_PROJECT_ROOT_DIRECTORY}/scripts/buildScripts/ios/resources/libs/Metal.framework"
"${FLAME_STEEL_PROJECT_ROOT_DIRECTORY}/scripts/buildScripts/ios/resources/libs/AVFoundation.framework"
"${FLAME_STEEL_PROJECT_ROOT_DIRECTORY}/scripts/buildScripts/ios/resources/libs/GameController.framework"
"${FLAME_STEEL_PROJECT_ROOT_DIRECTORY}/scripts/buildScripts/ios/resources/libs/CoreMotion.framework"
"${FLAME_STEEL_PROJECT_ROOT_DIRECTORY}/scripts/buildScripts/ios/resources/libs/CoreGraphics.framework"
"${FLAME_STEEL_PROJECT_ROOT_DIRECTORY}/scripts/buildScripts/ios/resources/libs/AudioToolbox.framework"
"${FLAME_STEEL_PROJECT_ROOT_DIRECTORY}/scripts/buildScripts/ios/resources/libs/CoreAudio.framework"
"${FLAME_STEEL_PROJECT_ROOT_DIRECTORY}/scripts/buildScripts/ios/resources/libs/QuartzCore.framework"
"${FLAME_STEEL_PROJECT_ROOT_DIRECTORY}/scripts/buildScripts/ios/resources/libs/OpenGLES.framework"
"${FLAME_STEEL_PROJECT_ROOT_DIRECTORY}/scripts/buildScripts/ios/resources/libs/UIKit.framework"
"${FLAME_STEEL_PROJECT_ROOT_DIRECTORY}/scripts/buildScripts/ios/resources/libs/Foundation.framework"
)

In meinem Fall werden die Bibliotheken SDL, SDL_Image und SDL_mixer vorab in Xcode unter macOS für die statische Verknüpfung kompiliert; Von Xcode kopierte Frameworks. Außerdem wurde die Bibliothek libclang_rt.ios.a hinzugefügt, die iOS-spezifische Laufzeitaufrufe enthält, beispielsweise isOSVersionAtLeast. Enthalten ist ein Makro für die Arbeit mit OpenGL ES, das nicht unterstützte Funktionen in der mobilen Version deaktiviert, ähnlich wie bei Android.
Nachdem Sie alle Build-Probleme gelöst haben, sollten Sie die zusammengestellte Binärdatei für arm erhalten. Betrachten wir als Nächstes die Ausführung der zusammengestellten Binärdatei auf einem Gerät ohne Jailbreak.
Installieren Sie unter macOS Xcode, registrieren Sie sich im Apple-Portal, ohne für das Entwicklerprogramm zu bezahlen. Fügen Sie ein Konto in Xcode hinzu -> Einstellungen -> Konten, erstellen Sie eine leere Anwendung und bauen Sie auf einem echten Gerät auf. Während der Montage wird das Gerät Ihrem kostenlosen Entwicklerkonto hinzugefügt. Nach der Zusammenstellung und dem Start müssen Sie das Archiv erstellen; Wählen Sie dazu Generisches iOS-Gerät und Produkt -> Archiv. Sobald das Archiv erstellt ist, extrahieren Sie die Dateien „embedded.mobileprovision“ und „PkgInfo“ daraus. Suchen Sie im Build-Protokoll auf dem Gerät die Codesign-Zeile mit dem richtigen Signaturschlüssel und den Pfad zur Berechtigungsdatei mit der Erweiterung app.xcent und kopieren Sie sie.
Kopieren Sie den .app-Ordner aus dem Archiv, ersetzen Sie die Binärdatei im Archiv durch eine Binärdatei, die von einem Cross-Compiler unter Linux kompiliert wurde (z. B. SpaceJaguar.app/SpaceJaguar), fügen Sie dann die erforderlichen Ressourcen zur .app hinzu, überprüfen Sie die Integrität der PkgInfo- und eingebetteten.mobileprovision-Dateien in der .app-Datei aus dem Archiv und kopieren Sie sie bei Bedarf erneut. Wir signieren die .app erneut mit dem Codesign-Befehl – Codesign erfordert einen Eingabeschlüssel für sign, den Pfad zur Berechtigungsdatei (kann mit der Erweiterung .plist umbenannt werden).
Erstellen Sie nach dem erneuten Signieren einen Payload-Ordner, verschieben Sie den Ordner mit der Erweiterung .app dorthin, erstellen Sie ein Zip-Archiv mit Payload im Stammverzeichnis und benennen Sie das Archiv mit der Erweiterung .ipa um. Öffnen Sie anschließend in Xcode die Geräteliste und ziehen Sie das neue ipa per Drag & Drop in die Anwendungsliste des Geräts. Die Installation über Apple Configurator 2 funktioniert bei dieser Methode nicht. Wenn die Neusignierung korrekt durchgeführt wurde, wird die Anwendung mit der neuen Binärdatei auf einem iOS-Gerät (z. B. iPad) mit einem 7-Tage-Zertifikat installiert, dies reicht für den Testzeitraum.

Quellen

https://github.com/tpoechtrager/cctools-port

https://docs.godotengine.org/ru/latest/development/compiling/cross-compiling_for_ios_on_linux.html

https://jonnyzzz.com/blog/2018/06/13/link-error-3/

https://stackoverflow.com/questions/6896029/re-sign-ipa-iphone

https://developer.apple.com/library/archive/documentation/Security/Conceptual/CodeSigningGuide/Procedures/Procedures.html

In diesem Beitrag beschreibe ich den Prozess der Erstellung von Bibliotheken und Anwendungen für Windows mithilfe der MinGW32-Toolchain unter Ubuntu.
Wine installieren, mingw:

sudo apt-get install wine mingw-w64

Danach können Sie bereits C/C++-Anwendungen für Windows erstellen:

# C
i686-w64-mingw32-gcc helloWorld.c -o helloWorld32.exe      # 32-bit
x86_64-w64-mingw32-gcc helloWorld.c -o helloWorld64.exe    # 64-bit
 
# C++
i686-w64-mingw32-g++ helloWorld.cc -o helloWorld32.exe     # 32-bit
x86_64-w64-mingw32-g++ helloWorld.cc -o helloWorld64.exe   # 64-bit

Die gesammelte Exe kann mit Wine überprüft werden.
Schauen wir uns als Nächstes die Änderungen am CMake-Build, der Datei CMakeLists.txt, an und fügen der Build-Datei MinGW-spezifische Dinge hinzu:

if (MINGW32)
set(CMAKE_SYSTEM_NAME Windows)
SET(CMAKE_C_COMPILER i686-w64-mingw32-gcc)
SET(CMAKE_CXX_COMPILER i686-w64-mingw32-g++)
SET(CMAKE_RC_COMPILER i686-w64-mingw32-windres)
set(CMAKE_RANLIB i686-w64-mingw32-ranlib)
endif()

// для сборки shared dll
elseif (MINGW32)
add_library(FlameSteelEngineGameToolkit.dll SHARED ${SOURCE_FILES})
else()

// обязательно линкуем со всеми зависимостями
if (MINGW32)
target_link_libraries(
                        FlameSteelEngineGameToolkit.dll 
                        -static-libgcc
                        -static-libstdc++
                        SDL2 
                        SDL2_mixer 
                        /home/demensdeum/Sources/cube-art-project-bootstrap/FlameSteelFramework/FlameSteelCore/FlameSteelCore.dll
                        /home/demensdeum/Sources/cube-art-project-bootstrap/FlameSteelFramework/FlameSteelBattleHorn/FlameSteelBattleHorn.dll
                        /home/demensdeum/Sources/cube-art-project-bootstrap/FlameSteelFramework/FlameSteelCommonTraits/FlameSteelCommonTraits.dll)

set_target_properties(FlameSteelEngineGameToolkit.dll PROPERTIES
        PREFIX ""
        SUFFIX ""
        LINK_FLAGS "-Wl,--add-stdcall-alias"
        POSITION_INDEPENDENT_CODE 0 # this is to avoid MinGW warning; 
        # MinGW generates position-independent-code for DLL by default
)
else()

Wir sammeln:

cmake -DMINGW32=1 .
make

Die Ausgabe ist eine DLL oder Exe, je nachdem, was Sie sammeln. Ein funktionierendes Beispiel finden Sie im Repository des neuen Cube-Art-Projekts und seiner Bibliotheken:
https://gitlab.com/demensdeum/cube-art-project

https://gitlab.com/demensdeum/FlameSteelEngineGameToolkitFSGL

https://gitlab.com/demensdeum/cube-art-project-bootstrap

Quellen
https://arrayfire.com/cross-compile-to-windows-from-linux/

In diesem Beitrag beschreibe ich die Erstellung plattformübergreifender C++-Anwendungen für macOS auf einer Ubuntu-Build-Maschine mit CMake und osxcross.
Installieren Sie zunächst die osxcross-Toolchain:
https://github.com/tpoechtrager/osxcross
Die Installation erfolgt in drei Phasen, wobei Abhängigkeiten heruntergeladen werden:

cd tools
./get_dependencies.sh

Laden Sie XCode.xip von der offiziellen Apple-Website herunter und laden Sie dann das SDK von XCode herunter:

./gen_sdk_package_pbzx.sh /media/demensdeum/2CE62A79E62A4404/LinuxSupportStorage/xcode111.xip

Ich hoffe, Sie haben im letzten Schritt die XCode-Lizenzvereinbarung gelesen? Als nächstes erstellen Sie die Toolchain mit dem erforderlichen Präfix:

INSTALLPREFIX=/home/demensdeum/Apps/osxcross ./build.sh 

Jetzt können Sie osxcross aus dem Präfixverzeichnis des vorherigen Schritts verwenden. Fügen wir ein neues Build-Makro für CMake hinzu und schreiben alles Notwendige:

if (OSXCROSS)
SET(CMAKE_SYSTEM_NAME Darwin)
SET(CMAKE_C_COMPILER o64-clang)
SET(CMAKE_CXX_COMPILER o64-clang++)
SET(CMAKE_C_COMPILER_AR x86_64-apple-darwin19-ar)
SET(CMAKE_CXX_COMPILER_AR x86_64-apple-darwin19-ar)
SET(CMAKE_LINKER x86_64-apple-darwin19-ld)
SET(ENV{OSXCROSS_MP_INC} 1)
endif()

Die dynamische Verknüpfung war bei mir nicht erfolgreich, daher exportieren wir die Bibliotheken statisch:

if (OSXCROSS)
add_library(FlameSteelCore STATIC ${SOURCE_FILES})
else()

Als nächstes werden Sie möglicherweise mit der Tatsache konfrontiert, dass Sie nicht über die erforderlichen Bibliotheken für osxcross verfügen. Dies ist mir bei der Verwendung von SDL2 aufgefallen. osxcross unterstützt vorgefertigte Bibliothekspakete – Macports. Beispiel: Installation des SDL2-Mixers:

osxcross-macports -v install libsdl2_mixer

Danach können Sie wie gewohnt mit dem Erstellen von Bibliotheken/Anwendungen im cmake-make-Link beginnen. Vergessen Sie nicht, bei Bedarf eine statische Verknüpfung von Bibliotheken anzugeben.

Manuelle Zusammenstellung von Bibliotheken

Derzeit bin ich auf das Problem der fehlerhaften Archivierung von Bibliotheken beim statischen Linken gestoßen; Beim Erstellen der endgültigen Anwendung erhalte ich die Fehlermeldung:

file was built for archive which is not the architecture being linked (x86_64)

Ganz ähnlich wie bei diesem Ticket ist es uns gelungen, eine Problemumgehung zu implementieren, die dazu führte, dass der Build korrekt abgeschlossen wurde. Entpacken wir die statische Bibliothek und erstellen sie mit dem osxcross-Archiver neu:

ar x ../libFlameSteelCore.a
rm ../libFlameSteelCore.a
x86_64-apple-darwin19-ar rcs ../libFlameSteelCore.a *.o

Eines der Probleme, die ich persönlich sehe, ist außerdem die fehlende Möglichkeit, macOS-Anwendungen direkt auf Ubuntu auszuführen (zumindest mit einem Teil der Funktionalität). Natürlich gibt es ein Projekt Darling, aber die Unterstützung lässt noch zu wünschen übrig.

Quellen

https://github.com/tpoechtrager/osxcross

Heutzutage sind Sie nicht mehr auf Cloud-Dienste angewiesen: Sie können hochwertige Bilder vollständig auf Ihrer eigenen Hardware erstellen. In diesem Beitrag beschreibe ich, wie Sie das moderne FLUX-Modell mit ComfyUI lokal auf Ihrem Computer ausführen.

ComfyUI verwendet eine knotenbasierte Architektur. Dies ermöglicht Ihnen:
– Volle Kontrolle über jede Generationsstufe.
– Einfaches Teilen vorgefertigter „Workflows“

FLUX ist ein großes Modell, daher sind die Hardwareanforderungen höher als bei SD 1.5 oder SDXL:
– Grafikkarte (GPU): Nvidia RTX mit 12 GB VRAM oder höher (für komfortables Arbeiten). Wenn Sie über 8 GB oder weniger verfügen, müssen Sie die quantisierten Versionen (GGUF oder NF4) verwenden.
– Arbeitsspeicher (RAM): mindestens 16 GB (vorzugsweise 32 GB und mehr).
– Festplattenspeicher: Ungefähr 20–50 GB für Modelle und Komponenten.

Der einfachste Weg, FLUX zu starten, ist die Verwendung einer vorgefertigten Vorlage. Suchen Sie einfach im Workflow-Fenster nach „flux text to image“ und installieren Sie es.

Schreiben Sie im Knoten „Text to Image (Flux.1 Dev)“ eine Eingabeaufforderung auf Englisch, wählen Sie die Auflösung aus (FLUX funktioniert gut mit 1024 x 1024 und sogar höher) und drücken Sie RUN.

Die erste Generation kann einige Zeit dauern, da die Modelle in den Grafikkartenspeicher geladen werden.

https://github.com/comfyanonymous/ComfyUI

Wenn Sie den Wunsch hatten, neuronale Netze zum Schreiben von Code zu verwenden (sog. Vibe-Codierung), und über einen recht leistungsstarken Computer verfügen, beispielsweise mit einer Nvidia RTX-Grafikkarte, können Sie die gesamte Umgebung völlig kostenlos auf Ihrem Computer bereitstellen. Dadurch werden Probleme mit kostenpflichtigen Abonnements gelöst und Sie können sicher mit Projekten unter NDA arbeiten, da Ihr Code nirgendwohin gesendet wird. In diesem Beitrag beschreibe ich, wie man ein lokales Bundle aus LM Studio, VS Code und der Continue-Erweiterung zusammenstellt.

Tools für die lokale Vibe-Codierung

Für komfortables Arbeiten benötigen wir drei Hauptkomponenten:
– LM Studio: eine praktische Anwendung zum Herunterladen und Ausführen lokaler LLMs. Es übernimmt die gesamte Komplexität der Arbeit mit GGUF-Modellen und stellt einen lokalen Server bereit, der mit der OpenAI-API kompatibel ist.
– VS Code: ein beliebter und bekannter Code-Editor.
– Continue: Erweiterung für VS Code, die neuronale Netze direkt in die Arbeitsumgebung integriert. Ermöglicht Ihnen das Chatten, das Hervorheben von Code für die Umgestaltung und unterstützt die automatische Vervollständigung.

Hardwareanforderungen

Lokale Sprachmodelle sind speicherintensiv:
– Grafikkarte (GPU): Nvidia mit 8 GB VRAM oder höher (für komfortables Arbeiten mit Modellen mit 7–8 Milliarden Parametern). Schwerere Modelle benötigen 16 GB VRAM.
– Speicherplatz: ca. 500 GB zum Speichern verschiedener heruntergeladener Modelle.

Link konfigurieren

Der Einrichtungsprozess ist recht einfach und erfordert keine komplexen Manipulationen im Terminal:
1. Laden Sie LM Studio herunter und installieren Sie es. Verwenden Sie die integrierte Suche, um ein leichtes Modell wie Qwen Coder oder gemma3:12b zu finden.
2. Gehen Sie in LM Studio zur Registerkarte Lokaler Server und klicken Sie auf Server starten. Standardmäßig startet es unter „http://localhost:1234/v1“.
3. Öffnen Sie VS Code und installieren Sie die Erweiterung Continue aus dem Plugin-Store.
4. Öffnen Sie die Continue-Konfigurationsdatei und fügen Sie ein neues Modell hinzu. Geben Sie dabei den „openai“-Anbieter und die Adresse Ihres lokalen Servers aus LM Studio an.

Anschließend können Sie direkt in der Seitenleiste „Weiter“ mit Ihrem lokalen LLM kommunizieren, Fragen zu Ihrem Code stellen und neue Komponenten generieren.

Warum funktioniert das?

Wie ich bereits geschrieben habe, schneiden LLMs mit flacher Struktur und WET-Code (Write Everything Twice) besser ab. Lokale Parametermodelle sind möglicherweise Giganten wie GPT-4 unterlegen, wenn es um den Entwurf komplexer Architekturen geht, aber sie sind mehr als in der Lage, Boilerplate-Code zu generieren, einfache Funktionen umzugestalten und schnelle Prototypen zu erstellen.

Darüber hinaus verlässt Ihr Code bei der lokalen Vibe-Codierung nie die Maschine. Damit ist diese Kombination ideal für die Unternehmensentwicklung und die Arbeit mit sensiblen Daten.

Ausgabe

Lokale neuronale Netze sind nicht in der Lage, einen Programmierer vollständig zu ersetzen oder ein komplexes System zu entwerfen. Die Kombination aus LM Studio + VS Code + Continue bietet jedoch Unabhängigkeit von Cloud-Diensten und wahrt die Privatsphäre. Dies ist ein voll funktionsfähiges Hilfsmittel für Routineaufgaben, wenn Sie bereit sind, die Einschränkungen kleiner Modelle in Kauf zu nehmen und die Projektarchitektur selbstständig zu steuern.

Links

https://code.visualstudio.com/
https://lmstudio.ai/
https://continue.dev/

Quellen

https://youtu.be/IqqCwhG46jY
https://www.youtube.com/watch?v=7AImkA96mE8

Bisher war die Erstellung von Videos mithilfe neuronaler Netze das Vorrecht von Cloud-Diensten wie Runway oder Luma. Wenn Sie heute über eine moderne Nvidia-Grafikkarte verfügen, können Sie hochwertige Videos direkt auf Ihrem Computer erstellen. In diesem Beitrag erkläre ich Ihnen, wie Sie die lokale Videogenerierung mit ComfyUI und dem effektiven LTX-2.3-Modell einrichten.

Tools zur Videogenerierung

Für die Arbeit benötigen wir:
– ComfyUI: eine leistungsstarke Schnittstelle mit einer knotenbasierten Architektur, die es Ihnen ermöglicht, den Generierungsprozess flexibel anzupassen.
– LTX-2.3: Ein modernes Modell von Lightricks, optimiert für die Erstellung flüssiger und detaillierter Videos mit relativ moderatem Videospeicherbedarf.

Hardwareanforderungen

Das Generieren von Videos ist ein viel ressourcenintensiverer Prozess als das Arbeiten mit Bildern:
– Grafikkarte (GPU): Nvidia RTX mit 8 GB VRAM ist das Minimum, das für eine Auflösung von 768 x 512 erforderlich ist. Für eine komfortable Bedienung und höhere Auflösungen sind 16–24 GB VRAM äußerst wünschenswert.
– Arbeitsspeicher (RAM): mindestens 32 GB. Videomodelle und VAEs beanspruchen beim Herunterladen viel Platz.
– Speicherplatz: ca. 500 GB für das Modell selbst und zugehörige Komponenten.

Einrichten und starten

Der Prozess zum Starten von LTX-2.3 in ComfyUI ist wie folgt:
1. ComfyUI aktualisieren: Das Modell ist relativ neu. Stellen Sie daher sicher, dass Sie die neueste Version der Schnittstelle installiert haben.
2. Workflow installieren: Der einfachste Weg besteht darin, eine vorgefertigte JSON-Vorlage für LTX Video zu finden. Das Modell erfordert bestimmte Knoten, um mit dem latenten Videoraum zu arbeiten.
3. Eingabeaufforderung und Parameter: Geben Sie eine Beschreibung der Szene auf Englisch ein. Beachten Sie, dass der LTX-2.3 Bewegungen gut versteht (z. B. „Kamera umkreist“, „schnelle Bewegung“).

Warum LTX-2.3 wählen?

LTX-2.3 zeichnet sich dadurch aus, dass es Ergebnisse liefert, die mit proprietären Cloud-Diensten vergleichbar sind, aber lokal ausgeführt wird. Das gibt Ihnen:
– Vollständiger Datenschutz: Ihre Eingabeaufforderungen und generierten Videos werden nicht auf die Server anderer Personen übertragen.
– Kontrolle: Sie können mit der Bildrate (FPS), der Auflösung und der Eingabeaufforderungsstärke experimentieren, ohne für jeden Versuch bezahlen zu müssen.

Die lokale Videoerzeugung befindet sich noch in der aktiven Entwicklung und LTX-2.3 ist ein großartiger Einstieg in die Welt des „Heimat-Hollywoods“.

Links

https://github.com/comfyanonymous/ComfyUI
https://huggingface.co/Lightricks/LTX-Video

Heutzutage ist man für die Erstellung von Inhalten nicht mehr auf Cloud-Dienste angewiesen: Sie können hochwertige Musik vollständig auf Ihrer eigenen Hardware generieren. In diesem Beitrag beschreibe ich, wie Sie das moderne ACE-Step-1.5-Modell mithilfe von ComfyUI lokal auf Ihrem Computer ausführen.

ComfyUI verwendet eine knotenbasierte Architektur. Dies ermöglicht Ihnen:
– Volle Kontrolle über jede Phase der Audioerzeugung.
– Teilen Sie ganz einfach vorgefertigte „Workflows“.

ACE-Step-1.5 ist ein fortschrittliches Modell zur Musikgenerierung, das erhebliche Rechenressourcen erfordert. Die Hardwareanforderungen sind höher als bei vielen einfachen Synthesizern:
– Grafikkarte (GPU): Nvidia RTX mit 8 GB VRAM oder höher (12 GB+ empfohlen) für komfortables Arbeiten in hoher Qualität.
– Arbeitsspeicher (RAM): mindestens 16 GB (vorzugsweise 32 GB und mehr).
– Prozessor (CPU): Moderner Multi-Core-Prozessor mit guter Unterstützung für AVX/CUDA-Computing.
– Festplattenspeicher: Ungefähr 20–50 GB für Modelle und Komponenten.

Der einfachste Weg, ACE-Step-1.5 auszuführen, besteht darin, eine vorgefertigte Vorlage zur Audiogenerierung zu verwenden. Suchen Sie einfach im Workflow-Fenster nach „Musiktext zu Audio“ und installieren Sie es.

Schreiben Sie im Knoten „Eingabeaufforderung“ eine Eingabeaufforderung, die das Genre und die Stimmung beschreibt (z. B. „aufmunternder Synthwave-Track mit starkem Bass“). Geben Sie die gewünschte Dauer an und drücken Sie RUN.
Die erste Generation kann einige Zeit in Anspruch nehmen, da die Modelle in den Speicher der Grafikkarte geladen werden und komplexe akustische Muster verarbeiten.

https://github.com/comfyanonymous/ComfyUI
https://www.youtube.com/watch?v=UAlLD5fS7-c

Wenn Sie den Wunsch hatten, so etwas wie ChatGPT zu starten, und über einen ziemlich leistungsstarken Computer verfügen, beispielsweise mit einer Nvidia RTX-Grafikkarte, können Sie das Ollama-Projekt ausführen, mit dem Sie eines der vorgefertigten LLM-Modelle völlig kostenlos auf Ihrem lokalen Computer verwenden können. Ollama bietet die Möglichkeit, mit LLM-Modellen in der Art von ChatGPT zu kommunizieren; Außerdem wurde in der neuesten Version die Möglichkeit angekündigt, Bilder zu lesen und die Ausgabedaten im JSON-Format zu formatieren.

Ich habe das Projekt selbst auch auf einem MacBook mit einem Apple M2-Prozessor ausgeführt und weiß, dass die neuesten Grafikkartenmodelle von AMD unterstützt werden.

Um es unter macOS zu installieren, gehen Sie zur Ollama-Website:
https://ollama.com/download/mac

Klicken Sie auf „Für macOS herunterladen“. Sie laden ein Archiv der Form ollama-darwin.zip herunter. Im Archiv befindet sich Ollama.app, das nach „Anwendungen“ kopiert werden muss. Starten Sie anschließend Ollama.app. Der Installationsvorgang wird höchstwahrscheinlich beim ersten Start stattfinden. Danach haben Sie in der Taskleiste das Ollama-Symbol gesehen, die Taskleiste befindet sich oben rechts neben der Uhr.

Starten Sie anschließend ein normales macOS-Terminal und geben Sie den Befehl ein, um ein beliebiges Ollama-Modell herunterzuladen, zu installieren und auszuführen. Eine Liste der verfügbaren Modelle, Beschreibungen und ihre Eigenschaften finden Sie auf der Ollama-Website:
https://ollama.com/search

Wählen Sie das Modell mit den wenigsten Parametern, wenn es beim Start nicht in Ihre Grafikkarte passt.

Zum Beispiel der Befehl zum Starten des Modells llama3.1:latest:

ollama run llama3.1:latest

Die Installation für Windows und Linux ist im Allgemeinen ähnlich, in einem Fall gibt es einen Ollama-Installer und die weitere Arbeit damit über Powershell.
Bei Linux erfolgt die Installation über ein Skript, ich empfehle jedoch die Verwendung der Version Ihres spezifischen Paketmanagers. Unter Linux kann Ollama auch über ein normales Bash-Terminal gestartet werden.

Quellen
https://www.youtube.com/watch?v=Wjrdr0NU4Sk
https://ollama.com

Wenn Sie Videos stabilisieren und Kameraverwacklungen entfernen möchten, bietet das Tool „ffmpeg“ eine leistungsstarke Lösung. Dank der integrierten Filter „vidstabdetect“ und „vidstabtransform“ können Sie professionelle Ergebnisse erzielen, ohne komplexe Videoeditoren zu verwenden.

Vorbereitung auf die Arbeit

Bevor Sie beginnen, stellen Sie sicher, dass Ihr „ffmpeg“ die „vidstab“-Bibliothek unterstützt. Unter Linux können Sie dies mit dem Befehl überprüfen:

bash  
ffmpeg -filters | grep vidstab  

Wenn die Bibliothek nicht installiert ist, können Sie sie hinzufügen:

sudo apt install ffmpeg libvidstab-dev  

Installation für macOS über brew:

brew install libvidstab
brew install ffmpeg

Kommen wir nun zum Prozess.

Schritt 1: Bewegungsanalyse

Zuerst müssen Sie die Bewegung des Videos analysieren und eine Datei mit Stabilisierungsparametern erstellen.

ffmpeg -i input.mp4 -vf vidstabdetect=shakiness=10:accuracy=15 transfile=transforms.trf -f null -  

Parameter:

Wackeligkeit: Video-Verwackelungsstufe (Standard 5, kann für komplexere Fälle auf 10 erhöht werden).
Genauigkeit: Analysegenauigkeit (Standard 15).
transfile: Dateiname zum Speichern der Bewegungsparameter.

Schritt 2: Stabilisierung anwenden

Jetzt können Sie die Stabilisierung mithilfe der Transformationsdatei anwenden:

ffmpeg -i input.mp4 -vf vidstabtransform=input=transforms.trf:zoom=5 output.mp4

Parameter:

Eingabe: Zeigt auf die Datei mit Transformationsparametern (im ersten Schritt erstellt).
Zoom: Zoomfaktor zum Entfernen schwarzer Ränder (z. B. 5 – automatischer Zoom, bis Artefakte entfernt sind).

Ich präsentiere Ihnen eine Übersetzung der ersten Seiten von Alan Turings Artikel „ON COMPUTABLE NUMBERS WITH AN APPLICATION TO THE PROBLEM OF RESOLUTION“ aus dem Jahr 1936. Die ersten Kapitel enthalten eine Beschreibung von Computern, die später zur Grundlage der modernen Informatik wurden.

Die vollständige Übersetzung des Artikels und der Erklärung kann im Buch des amerikanischen Popularisierers Charles Petzold mit dem Titel „Reading Turing: A Journey through Turing’s Historical Article on Computability and Turing Machines“ (ISBN 978-5-97060-231-7, 978-0-470-22905-7) nachgelesen werden.

Originalartikel:
https://www.astro.puc.cl/~rparra/tools/PAPERS/turing_1936.pdf

ÜBER BERECHNBARE ZAHLEN MIT ANWENDUNG AUF DAS AUFLÖSUNGSPROBLEM

A. M. TURING

[Eingegangen am 28. Mai 1936 – gelesen am 12. November 1936]

„Berechenbare“ Zahlen können kurz als reelle Zahlen beschrieben werden, deren Ausdrücke als Dezimalbrüche auf endlich viele Arten berechnet werden können. Obwohl dieser Artikel Zahlen auf den ersten Blick als berechenbar behandelt, ist es fast genauso einfach, berechenbare Funktionen einer ganzzahligen Variablen, einer reellen Variablen, einer berechenbaren Variablen, berechenbarer Prädikate und dergleichen zu definieren und zu untersuchen. Die grundlegenden Probleme, die mit diesen berechenbaren Objekten verbunden sind, sind jedoch jeweils dieselben. Für eine detaillierte Betrachtung habe ich berechenbare Zahlen als berechenbares Objekt gewählt, da die Methode, sie zu berücksichtigen, am wenigsten umständlich ist. Ich hoffe, bald die Beziehung zwischen berechenbaren Zahlen und berechenbaren Funktionen usw. beschreiben zu können. Gleichzeitig wird auf dem Gebiet der Theorie der Funktionen einer reellen Variablen, ausgedrückt in berechenbaren Zahlen, geforscht. Nach meiner Definition ist eine reelle Zahl berechenbar, wenn ihre Dezimaldarstellung von einer Maschine geschrieben werden kann.

In den Absätzen 9 und 10 gebe ich einige Argumente an, um zu zeigen, dass berechenbare Zahlen alle Zahlen umfassen, von denen man natürlich annimmt, dass sie berechenbar sind. Insbesondere zeige ich, dass einige große Zahlenklassen berechenbar sind. Dazu gehören beispielsweise die Realteile aller algebraischen Zahlen, die Realteile der Nullstellen von Bessel-Funktionen, die Zahlen π, e und andere. Allerdings umfassen berechenbare Zahlen nicht alle definierbaren Zahlen, wie das folgende Beispiel einer definierbaren Zahl zeigt, die nicht berechenbar ist.

Obwohl die Klasse der berechenbaren Zahlen sehr groß ist und in vielerlei Hinsicht der Klasse der reellen Zahlen ähnelt, ist sie dennoch aufzählbar. In §8 betrachte ich bestimmte Argumente, die gegenteilig zu sein scheinen. Bei richtiger Anwendung eines dieser Argumente ergeben sich Schlussfolgerungen, die auf den ersten Blick denen von Gödel* ähneln. Diese Ergebnisse haben äußerst wichtige Anwendungsmöglichkeiten. Insbesondere kann das Auflösungsproblem, wie unten (§11) gezeigt wird, keine Lösung haben.

In einem kürzlich erschienenen Artikel stellte Alonzo Church die Idee der „effektiven Berechenbarkeit“ vor, die meiner Vorstellung von „Berechenbarkeit“ entspricht, aber eine völlig andere Definition hat. Zu ähnlichen Schlussfolgerungen kommt auch Church hinsichtlich des Lösungsproblems. Der Beweis der Äquivalenz von „Berechenbarkeit“ und „effektiv berechenbar“ wird im Anhang dieses Artikels vorgelegt.

1. Computer

Wir haben bereits gesagt, dass berechenbare Zahlen diejenigen Zahlen sind, deren Dezimalstellen mit endlichen Mitteln abzählbar sind. Hier ist eine klarere Definition erforderlich. Dieser Artikel wird keinen wirklichen Versuch unternehmen, die hier gegebenen Definitionen zu rechtfertigen, bis wir zu §9 kommen. Vorerst möchte ich nur anmerken, dass der (logische) Grund (dafür) darin besteht, dass das menschliche Gedächtnis zwangsläufig begrenzt ist.

Vergleichen wir einen Menschen, der eine reelle Zahl berechnet, mit einer Maschine, die nur eine endliche Anzahl von Bedingungen q1, q2, …, qR erfüllen kann; Nennen wir diese Bedingungen „M-Konfigurationen“. Diese (also so definierte) Maschine ist mit einem „Band“ (analog zu Papier) ausgestattet. Dieses durch die Maschine laufende Band ist in Abschnitte unterteilt. Nennen wir sie „Quadrate“. Jedes dieser Quadrate kann eine Art „Symbol“ enthalten. Zu jedem Zeitpunkt gibt es nur ein solches Quadrat, sagen wir das r-te, das das Symbol „in dieser Maschine“ enthält. Nennen wir ein solches Quadrat ein „gescanntes Symbol“. Ein „gescanntes Zeichen“ ist das einzige Zeichen, das der Maschine sozusagen „direkt bekannt“ ist. Durch Ändern seiner M-Konfiguration kann sich die Maschine jedoch effektiv an einige der Zeichen erinnern, die sie zuvor „gesehen“ (gescannt) hat. Das mögliche Verhalten der Maschine zu jedem Zeitpunkt wird durch die m-Konfiguration qn und das gescannte Symbol*** bestimmt. Nennen wir dieses Symbolpaar qn, „Konfiguration“. Die so bezeichnete Konfiguration bestimmt das mögliche Verhalten einer bestimmten Maschine. In einigen dieser Konfigurationen, in denen das gescannte Quadrat leer ist (dh kein Zeichen enthält), schreibt das Gerät ein neues Zeichen auf das gescannte Quadrat und in anderen dieser Konfigurationen löscht es das gescannte Zeichen. Diese Maschine ist auch in der Lage, sich zu bewegen, um ein anderes Quadrat zu scannen, auf diese Weise kann sie sich jedoch nur zu dem benachbarten Quadrat rechts oder links bewegen. Zusätzlich zu diesen Vorgängen kann die M-Konfiguration der Maschine geändert werden. In diesem Fall bilden einige der geschriebenen Zeichen eine Ziffernfolge, die den Dezimalteil der zu berechnenden reellen Zahl darstellt. Der Rest wird nichts weiter als ungenaue Markierungen sein, um „dem Gedächtnis zu helfen“. In diesem Fall können nur die oben genannten ungenauen Markierungen gelöscht werden.

Ich behaupte, dass die hier betrachteten Operationen alle Operationen umfassen, die in der Berechnung verwendet werden. Die Begründung dieser Aussage ist für den Leser, der sich mit der Maschinentheorie auskennt, leichter zu verstehen. Daher werde ich im nächsten Abschnitt die betreffende Theorie weiter entwickeln, basierend auf einem Verständnis der Bedeutung der Begriffe „Maschine“, „Band“, „gescannt“ usw.

*Gödel „Über die formal unentscheidbaren Sätze der Principia Mathematics (veröffentlicht von Whitehead und Russell 1910, 1912 und 1913) und verwandte Systeme, Teil I“, Journal of Mathematics. Physik, Monatsheft Nr. 38 (für 1931, S. 173–198).
** Alonzo Church, „An Undecidable Problem in Elementary Number Theory“, American J. of Math., Nr. 58 (1936), S. 345-363.
*** Alonzo Church, „A Note on the Resolution Problem“, J. of Symbolic Logic, Nr. 1 (1936), S. 40-41