Wrote a custom C++ engine to render raw WAD geometry directly to the DAC.
-
-
-
Wrote a custom C++ engine to render raw WAD geometry directly to the DAC.
Pure vector output, 1D occlusion culling, no rasterization tricks.
Running on a MOTU M4.
@ut3usw is this just a two channel vectorscope?
i should try it with mine -
Wrote a custom C++ engine to render raw WAD geometry directly to the DAC.
Pure vector output, 1D occlusion culling, no rasterization tricks.
Running on a MOTU M4.
@ut3usw
I should repair channel 2 of the original Quake on oscilloscope Hitachi scope and wait for the release.
-
Wrote a custom C++ engine to render raw WAD geometry directly to the DAC.
Pure vector output, 1D occlusion culling, no rasterization tricks.
Running on a MOTU M4.
oscdoom!
-
Wrote a custom C++ engine to render raw WAD geometry directly to the DAC.
Pure vector output, 1D occlusion culling, no rasterization tricks.
Running on a MOTU M4.
@ut3usw mind = blown
-
Wrote a custom C++ engine to render raw WAD geometry directly to the DAC.
Pure vector output, 1D occlusion culling, no rasterization tricks.
Running on a MOTU M4.
-
Wrote a custom C++ engine to render raw WAD geometry directly to the DAC.
Pure vector output, 1D occlusion culling, no rasterization tricks.
Running on a MOTU M4.
@ut3usw dear god
-
Wrote a custom C++ engine to render raw WAD geometry directly to the DAC.
Pure vector output, 1D occlusion culling, no rasterization tricks.
Running on a MOTU M4.
@ut3usw This runs smoother than it did on my neighbour's 486
-
Wrote a custom C++ engine to render raw WAD geometry directly to the DAC.
Pure vector output, 1D occlusion culling, no rasterization tricks.
Running on a MOTU M4.
@ut3usw if you make this into a playable maze game one day, i would happily build a large size "IGOR" vector display for that
-
@ut3usw What a beautiful classic Siemens.
They were the only one who really went all in with sleek early 1980s design. Even for hard tech stuff like scopes.
@Computeum @ut3usw
Ich würde da mal nach Grundig suchen die diese Oszis als OEM für Siemens gebaut haben z.B. https://www.mikrocontroller.net/attachment/23365/DSC00288.JPGDir könnten vielleicht auch Geräte gefallen wie das Philips PM3215
-
@poleguy yes, ty! In real time wasd control.
On video below it’s how I see it on pc screen (with actual audio). -
Wrote a custom C++ engine to render raw WAD geometry directly to the DAC.
Pure vector output, 1D occlusion culling, no rasterization tricks.
Running on a MOTU M4.
@ut3usw Now do enemies!
-
Wrote a custom C++ engine to render raw WAD geometry directly to the DAC.
Pure vector output, 1D occlusion culling, no rasterization tricks.
Running on a MOTU M4.
@ut3usw But does it run crysis?
Nice project! Respect!
-
@poleguy yes, ty! In real time wasd control.
On video below it’s how I see it on pc screen (with actual audio). -
Wrote a custom C++ engine to render raw WAD geometry directly to the DAC.
Pure vector output, 1D occlusion culling, no rasterization tricks.
Running on a MOTU M4.
@ut3usw 🤯
-
@Computeum @ut3usw
Ich würde da mal nach Grundig suchen die diese Oszis als OEM für Siemens gebaut haben z.B. https://www.mikrocontroller.net/attachment/23365/DSC00288.JPGDir könnten vielleicht auch Geräte gefallen wie das Philips PM3215
Jain, das Grundig ist der gleiche Oskar, und von einer rein technischen Sicht hast Du sicher recht.
Design ist aber mehr als Innenschaltung und wo und in welcher Reihenfolge die Knöpfe platziert sind. Hier machen speziell die Farbe den feinen Unterschied. Sowohl in der Platzierung als auch der Gestaltung. Bei (fast) gleichen Strukturelementen ist das Siemens durch die andere Farbwahl besser strukturiert. Die am meisten gebrauchte Einstellung, die Kanäle, ist gegenüber allem anderen durch Farbflächen hervorgehoben. Während beim Grundig die Linien mur eindimensional Kästchen machen Strukturieren sie beim Siemens Bereiche. So ist alles was den Strahl betrifft in einem einzigen Kasten innerhalb dessen die Empfindlichkeit durch die Farbflächen (als Negativlinie) abgetrennt wird.
Dazu kommt die Verwendung runder 'Ecken' bei den Rahmen, die der Designsprache der frühen 80er entstammen. Sie machen es gefälliger und führen das Auge besser als reine Linien.
Das Siemens kannst Du so direkt auf eine Stereoanlage von Siemens aus dergleichen Zeit stellen und es passt sofort. Sogar neben einer 777, die komplett in Silber ist, beisst es sich nicht.
Diese Designarbeit ist was den Unterschied - und Mehrwert - zum Grundig ausmacht - aber auch zu vorherigen Modellen (z.B. D1005). Da steckt der extra Aufwand drinnen den man bei Siemens (damals noch) betrieben hat.
Und das war der Kernpunkt in meinem Kommentar. Das Siemens stellt einen Höhepunkt des Benutzerorientierten Designs dar.
---
Das Philips im Gegenzug steckt noch tief im Nicht-Design der 50er fest. Hier werden optisch die technisch nicht mehr vorhandenen Einzelbaugruppen nachgebildet. Sowohl in der Anordnung als auch in der Bedruckung. Wie bei einem 55x Tektronix von 1955.
Und Tektronix schauen auch heute noch grundsätzlich so aus. Hauptsache die Innenschaltung ist gut, der Bediener wirds schon irgendwie hinbekommen.
Bei Siemens/Grundig hingegen kann man über die Modelle eine Weiterentwicklung feststellen, nachdem mal der Zwang durch die Module entfallen war.
Und wie Tektronix schauen heute noch viele Gräte aus, von Technikern gemacht ohne an UI zu denken (bzw. halt an Tektronix orientiert). Nur halt in Plastik und einheitsbeigegrau. Bzw. dann von den Chinesen mit verschwurbelten Formen und grellbunten Tasten weiter verschlimmert.
-
Wrote a custom C++ engine to render raw WAD geometry directly to the DAC.
Pure vector output, 1D occlusion culling, no rasterization tricks.
Running on a MOTU M4.
Beautiful.
Did you do any optimization to minimize the way the ray has to run? Or does it just work well enough?
-
Wrote a custom C++ engine to render raw WAD geometry directly to the DAC.
Pure vector output, 1D occlusion culling, no rasterization tricks.
Running on a MOTU M4.
-
Beautiful.
Did you do any optimization to minimize the way the ray has to run? Or does it just work well enough?
@deusfigendi Absolutely. I use a greedy solver to minimize the 'air travel' of the beam between lines. Without it, the refresh rate would tank because the beam would waste too much time jumping around.
