Überblick
Torus Trooper, hardwarebeschleunigtes Video, OpenCL-Compute und eine V-Entwicklungsumgebung für Kakoune – mit nachvollziehbaren APIs, Speicherbausteinen und dokumentierten Builds.
Jetzt quelloffen
Ein freier Tunnel-Racing-Arcade-Shooter in V mit Vulkan-Grafik für Windows und Linux, inspiriert von Kenta Chos Original. Eigene Raumschiffe und Strecken, drei Schwierigkeitsgrade, anpassbare Steuerung und eine Replay-Bibliothek mit Import und Export.
Fertige Pakete für Windows 10/11 x64 und Linux x64 sind verfügbar. Ein Vulkan-fähiger Grafiktreiber ist erforderlich; Linux benötigt glibc 2.38 oder neuer, etwa Ubuntu 24.04. macOS wird nicht offiziell unterstützt.
Hinter dem Arcade-Shooter steht eine klar getrennte Architektur. Der Design-Guide führt von Eingabe und Simulation bis zum fertigen Bild und erklärt auch, wann andere Ansätze sinnvoller wären.
Die Simulation läuft in festen 60-Hz-Schritten. Fenster, Vulkan-Darstellung und Audio sind davon getrennt; die Spielregeln lassen sich auch ohne Fenster testen.
Replays speichern Startwert, Spielmodus und logische Eingaben statt eines Videos. Die Wiedergabe braucht kompatible Simulationsregeln – das Dateiformat allein garantiert das nicht.
Render-Snapshots verbinden die Simulation mit prozeduralen Strecken, Raumschiffen und Vulkan-Rendering. Interpolation glättet die Darstellung zwischen zwei Spielschritten.
Der neunteilige Guide behandelt Speicherlayouts, Ressourcenbesitz, optionales Compute, Konfiguration und Tests. Er zeigt die Grenzen der Messungen und vergleicht alternative Designs.
Entwicklerwerkzeuge / vlang.kak
Ein tastaturorientierter V-Arbeitsablauf: Code verstehen, Tests ausführen und ein laufendes Programm untersuchen, ohne Kakoune zu verlassen.
VLS und kak-lsp liefern Sprachfunktionen. Projektexplorer, Suche, Definitionen, Dokumentation und kontextabhängige Menüs halten die Navigation nah am Quellcode.
Projektaufgaben und Tests laufen mit navigierbaren Fehlermeldungen. Lokales GDB-Debugging ergänzt Breakpoints, Einzelschritte, Stack, Variablen und Watches.
Ein isolierter Launcher hält das V-Setup von der persönlichen Kakoune-Konfiguration getrennt. Verwaltete Updates erhalten eigene Einstellungen; dokumentierte Wiederherstellung hilft bei Sitzungswechseln.
Das verwaltete Setup und der geprüfte lokale GDB-Pfad zielen auf Linux. Unter Windows ist WSL vorgesehen; Sprachfunktionen hängen von der installierten VLS-Version ab.
Kleine Repositories trennen API-Erzeugung, Datenformate, Speicher, Oberfläche und Anwendung. Der Vulkan-Video-Pfad spielt H.264 ab; der OpenCL-Pfad berechnet und visualisiert Partikel gemeinsam mit Vulkan.
v_vulkan_video
Ein H.264/AVC-MP4-Player in V mit Vulkan-Video-Dekodierung, B-Frame-Ausgabereihenfolge, Metadatenrotation, Timing, Resize und Looping. Der aktuelle Linux-Prerelease verbessert H.264-Verarbeitung und Paketprüfung; Windows-Hardwarewiedergabe ist noch nicht validiert.
minimp4 liest den MP4-Container. h264 interpretiert den Videostream und liefert Metadaten und Bildreihenfolge.
Die Vulkan-Bindings stellen die native API in V bereit. Der Player prüft das Videoprofil und wählt eine kompatible GPU.
GLFW erzeugt Fenster und Eingabe, Dear ImGui liefert die Oberfläche und vkmemalloc unterstützt den GPU-Speicher.
v_vulkan_video verbindet Parsing, GPU-Auswahl, Dekodierung, Timing, Resize, Präsentation und Looping.
opencl
Generierte OpenCL-1.0–3.0-Bindings für V, typsichere Hilfen für Buffer, Bilder und SVM sowie ein Partikelsystem, in dem OpenCL und Vulkan Speicher und Synchronisation teilen.
v_opencl_bindings liest die kanonische Khronos-Registry und erzeugt nachvollziehbare V-Bindings für OpenCL 1.0 bis 3.0.
opencl ergänzt die vollständige Low-Level-API um optionale, typsichere Hilfen für Discovery, Buffer, Bilder, SVM, Events und Lebenszyklen.
CI prüft Laufzeitpfade unter Linux sowie ABI-Builds für macOS und Windows; GCC, Clang, MSVC und TinyCC werden abgedeckt.
Das Partikelbeispiel kombiniert OpenCL-Compute mit Vulkan-Darstellung, nutzt nach Möglichkeit gemeinsamen Speicher und Semaphore und fällt sonst auf Host-Staging zurück.
Ein Videoplayer wirkt wie eine einzelne Anwendung. Tatsächlich löst er mehrere sehr unterschiedliche Probleme, die hier bewusst in verständliche, wiederverwendbare Projekte getrennt sind.
minimp4
Eine MP4-Datei ist ein Behälter. minimp4 findet darin Bilder, Zeitangaben und technische Metadaten – vergleichbar mit einem Inhaltsverzeichnis.
h264
H.264 speichert meist nur Veränderungen zu anderen Bildern. Dieses Projekt liest die Regeln, Abhängigkeiten und Reihenfolge, die zum Rekonstruieren nötig sind.
v_vulkan_bindings + vulkan
Vulkan spricht die Sprache der GPU. Der Generator hält tausende Definitionen aktuell; die Bindings machen sie aus V heraus sicher und reproduzierbar erreichbar.
vulkan_memory_allocator
Der V-native Allokator vkmemalloc nutzt memory für Block-Suballokation und ergänzt Speicherbudgets, Upload-Ringe und Diagnostik. Er ist kein Binding für AMDs Vulkan Memory Allocator.
glfw + imgui
GLFW verbindet Fenster, Bildschirm und Eingabe. ImGui liefert Kontrollen und Diagnoseoberflächen, damit aus der Pipeline ein benutzbares Programm wird.
v_vulkan_video
Der Player koordiniert Dateizugriff, Zeittakt, Referenzbilder, GPU-Warteschlangen, Darstellung und Fensteränderungen zu einem sichtbaren Video.
opencl
Die vollständigen Bindings bleiben zugänglich; eine optionale Eigentums- und Typschicht vereinfacht Buffer, Bilder, SVM, Events und Kernel-Aufrufe.
v_opencl_bindings
Der Generator bindet die Ausgabe an feste Khronos-Eingaben und validiert die generierte Oberfläche über mehrere Plattformen und Compiler.
v_imgui_examples
Ein getestetes Beispiel verbindet V, Vulkan, GLFW und Dear ImGui als kurzen Einstieg in die Grafik-Toolchain.
memory
Geprüfte Objekt- und Slot-Pools sowie Bereichs-, Linear-, Ring- und Buddy-Allokatoren für V; der Kern funktioniert unabhängig von Vulkan.
Für technisch Interessierte: Ein einzelnes H.264-Bild wird nicht mit einem Funktionsaufruf „angezeigt“. Metadaten, Referenzbilder, GPU-Ressourcen und Synchronisation werden als miteinander verknüpfte Vulkan-Strukturen beschrieben.
StdVideoDecodeH264PictureInfoBildnummer, SPS/PPS-IDs, Picture Order Count und Flags beschreiben das H.264-Bild unabhängig von Vulkan-Ressourcen.
VideoDecodeH264PictureInfoKHR → pNextErgänzt Slice-Anzahl und Slice-Offsets und hängt die codec-spezifischen Angaben über pNext an die allgemeine Dekodierstruktur.
StdVideoDecodeH264ReferenceInfoBeschreibt jedes ältere Referenzbild, von dem P- oder B-Bilder abhängen. Ohne diese Historie kann die GPU das aktuelle Bild nicht rekonstruieren.
VideoDecodeH264DpbSlotInfoKHR → VideoReferenceSlotInfoKHRVerbindet H.264-Referenzdaten mit einem Slot im Decoded Picture Buffer und dessen konkreter Bildressource.
VideoPictureResourceInfoKHRZeigt über imageViewBinding auf das GPU-Bild und nennt kodierte Größe und Array-Layer. Dies ist der physische Ziel- oder Referenzspeicher.
VideoBeginCodingInfoKHRÖffnet den Videokodierbereich mit Session, Session-Parametern und aktiven Referenzslots. Optional folgt ein Session-Reset.
VideoDecodeInfoKHR → vkCmdDecodeVideoKHRBündelt Bitstream-Puffer, Bytebereich, Zielbild, aktuellen DPB-Slot und alle Referenzslots. Erst jetzt wird der Dekodierbefehl aufgezeichnet.
ImageMemoryBarrier2 + SemaphoreBarrieren wechseln Bildlayout und Besitz zwischen Video- und Grafikwarteschlange; ein Semaphor verhindert, dass die Grafik ein unfertiges Bild liest.
SubmitInfo → Draw → PresentInfoKHRDie Dekodierwarteschlange erzeugt das Bild, die Grafikwarteschlange zeichnet es in ein Swapchain-Bild, und vkQueuePresentKHR übergibt dieses an den Bildschirm.