Turbulence Demo Sourcecode verfügbar
Turbulence Demo Sourcecode verfügbar
Hier ist er..
http://www.linusakesson.net/scene/turbulence/source.php
Müßte doch auch für den HIVE (Bellatrix) anpassbar sein (andere VGA Pins?)?
Peter
http://www.linusakesson.net/scene/turbulence/source.php
Müßte doch auch für den HIVE (Bellatrix) anpassbar sein (andere VGA Pins?)?
Peter
Re: Turbulence Demo Sourcecode verfügbar
Hm das ganze könnte sich als sehr kompliziert erweisen.
Zuerst einmal sind im Hive VGA- Ausgang und Sound Ausgabe auf 2 unterschiedlichen Propellern, die nicht direkt miteinander reden dürfen. Ok, dies ist kein KO kriterium, macht das ganz nur etwas aufwendiger zu verwalten.
Aber dann kommt das Problem. Der VGA- Treiber vom Turbulence Demo nutzt die Ports P0 bis P7 als schnellen Datenbus zwischen den COG's. Da liegen auf dem Turbulence Board keine IO- Leitungen drauf, so das das dort keine rolle spielt. Nur der Hive hat aber am Belatrix keine freien IO- Leitungen mehr, die sind alle belegt. Und da mal eben wild auf den IO's auszugeben, könnte dem ganzen Hive sehr abträglich sein. Hier müsste auf jeden fall eine andere Lösung gefunden werden, um die Video-Cog's und das VGA- Signal Synchronisieren zu können.
Wäre aber richtig cool, wenn einer von euch die Demo passend umschreiben könnte.
Grüße
Janaha
Zuerst einmal sind im Hive VGA- Ausgang und Sound Ausgabe auf 2 unterschiedlichen Propellern, die nicht direkt miteinander reden dürfen. Ok, dies ist kein KO kriterium, macht das ganz nur etwas aufwendiger zu verwalten.
Aber dann kommt das Problem. Der VGA- Treiber vom Turbulence Demo nutzt die Ports P0 bis P7 als schnellen Datenbus zwischen den COG's. Da liegen auf dem Turbulence Board keine IO- Leitungen drauf, so das das dort keine rolle spielt. Nur der Hive hat aber am Belatrix keine freien IO- Leitungen mehr, die sind alle belegt. Und da mal eben wild auf den IO's auszugeben, könnte dem ganzen Hive sehr abträglich sein. Hier müsste auf jeden fall eine andere Lösung gefunden werden, um die Video-Cog's und das VGA- Signal Synchronisieren zu können.
Wäre aber richtig cool, wenn einer von euch die Demo passend umschreiben könnte.
Grüße
Janaha
Re: Turbulence Demo Sourcecode verfügbar
Ah moment, nicht das ihr annehmt das wäre ganz unmöglich. Man könnte ja z.B. den Regnatix dazu zweckentfremden, das er den Datenbus nutzt um die Videosignale zu bauen und das Belatrix dann dort nur noch das "Endprodukt" der Pixel abholt und ausgibt. Und wärend der V/HSYNC Pausen kann Regnatix die Audiobefehle für Administra ausgeben. Also unmöglich wäre es nicht, nur etwas kompliziert in der Umsetzung. Aber man müsste wohl schon einen großteil des Codes neu schreiben, damit er Hive- tauglich wird.
Grüße
Janaha
Grüße
Janaha
Re: Turbulence Demo Sourcecode verfügbar
Noch dazu ist das Demo zwingend vom (geflashten) EEPROM abhängig. Das Demo dekomprimiert in Echtzeit Daten aus dem EEPROM.
Ich glaube nicht daß sich der Aufwand lohnt für ein 4 Minuten Demo.
Für den Hive bräuchte man ein Hive-Demo ... also eins, das zeigt was der Hive kann ... nicht was ein einzelner Propeller kann.
Ich bin (leider) kein Demo-Programmierer ... ich finde die Dinger zwar cool, aber verschwendetes Know-How und Arbeitszeit, die man auch in etwas Sinnvolles hätte stecken können ... ist nicht negativ gemeint .. ich habe Hochachtung vor diesen Freaks ... aber für mich ist es nichts (glaube ich ... aber noch nie probiert).
Das Einzige was ich daraus ziehen kann ist, das man vom Sourcecode unter Umständen viel lernen kann ... vor allen Dingen kompakt zu programmieren und was eigentlich möglich ist mit der jeweiligen Maschine ... was inspirieren kann.
Gruß.
Rainer
Ich glaube nicht daß sich der Aufwand lohnt für ein 4 Minuten Demo.
Für den Hive bräuchte man ein Hive-Demo ... also eins, das zeigt was der Hive kann ... nicht was ein einzelner Propeller kann.
Ich bin (leider) kein Demo-Programmierer ... ich finde die Dinger zwar cool, aber verschwendetes Know-How und Arbeitszeit, die man auch in etwas Sinnvolles hätte stecken können ... ist nicht negativ gemeint .. ich habe Hochachtung vor diesen Freaks ... aber für mich ist es nichts (glaube ich ... aber noch nie probiert).
Das Einzige was ich daraus ziehen kann ist, das man vom Sourcecode unter Umständen viel lernen kann ... vor allen Dingen kompakt zu programmieren und was eigentlich möglich ist mit der jeweiligen Maschine ... was inspirieren kann.
Gruß.
Rainer
"Wer andauernd begreift, was er tut, bleibt unter seinem Niveau."
Re: Turbulence Demo Sourcecode verfügbar
Verschoben ins Forum "Software", da es sich nicht um eine technische Dokumentation handelt.
- drohne235
- Administrator
- Beiträge: 2284
- Registriert: So 24. Mai 2009, 10:35
- Wohnort: Lutherstadt Wittenberg
- Kontaktdaten:
Re: Turbulence Demo Sourcecode verfügbar
Also ich persönlich fand die Demos auf den Retros immer cool und hab sie mir gern angeschaut. Programmiert hab ich auch noch keines, aber ich denke das kommt automatisch nebenbei wenn man z.B. eine Grafikengine auf dem Hive entwickelt - irgendwo muss man das ja auch testen ohne gleich ein Game zu entwickeln. Ähnlich ist ja letztlich auch die Demoszene entstanden - als "Trailer" vor den gecrackten Programmen.
Nun, Programme wird man auf dem Hive wohl nicht knacken brauchen, aber es genügt schon wenn man mal eine kleine Demonstration für ein Retrotreffen schreibt. Hat eigentlich schonmal jemand vecdem1 gestartet? Das war so eine kleine Endlos-"Demo" für das KC-Treffen, eine 2-Stunden-Spielerei mit einem Grafiktreiber wo ich dachte: Das kann man einfach mal endlos so rumlaufen lassen. Ich glaube bei Demos ist das Spielen ganz wichtig. Viele Sachen entstehen da ganz von selbst wenn man mal ein wenig wie bei Lego die Bausteine völlig sinnfrei zusammensteckt und sagt: Schau mal wie das aussieht! Und schon ist irgendein neuer cooler Effekt so ganz nebenbei entstanden, den man dann auch problemlos z.B. in einem Game verwenden kann.
Nun, Programme wird man auf dem Hive wohl nicht knacken brauchen, aber es genügt schon wenn man mal eine kleine Demonstration für ein Retrotreffen schreibt. Hat eigentlich schonmal jemand vecdem1 gestartet? Das war so eine kleine Endlos-"Demo" für das KC-Treffen, eine 2-Stunden-Spielerei mit einem Grafiktreiber wo ich dachte: Das kann man einfach mal endlos so rumlaufen lassen. Ich glaube bei Demos ist das Spielen ganz wichtig. Viele Sachen entstehen da ganz von selbst wenn man mal ein wenig wie bei Lego die Bausteine völlig sinnfrei zusammensteckt und sagt: Schau mal wie das aussieht! Und schon ist irgendein neuer cooler Effekt so ganz nebenbei entstanden, den man dann auch problemlos z.B. in einem Game verwenden kann.
"Ob Sie denken, dass Sie es können, oder ob Sie denken, dass Sie es nicht können - in beiden Fällen haben Sie recht." Henry Ford
- lohrermopper
- Beiträge: 91
- Registriert: Fr 5. Jun 2009, 18:39
- Wohnort: Tief im Spessartwald
Re: Turbulence Demo Sourcecode verfügbar
Hallo Drohne235,drohne235 hat geschrieben: ...
Hat eigentlich schonmal jemand vecdem1 gestartet?
...
ja, ich habe dieses Demo getartet. Es erscheint ein rotes, rotierendes Vector-Dreick und herrlicher Sound, dann schaltet sich jedoch mein Monitor ab.
![Weinend oder sehr traurig :cry:](./images/smilies/icon_cry.gif)
Viele Grüße
LohrerMopper.
"Etwas nicht tun zu können, ist kein Grund es nicht zu tun!" (ALF)
Re: Turbulence Demo Sourcecode verfügbar
Ich höre den Sound, mein Bildschirm schaltet sich zwar nicht ab, bleibt aber schwarz.
Habe aber noch nicht in den Sourcecode reingesehen .. sicher nur ne Kleinigkeit.
Gruß.
Rainer
Habe aber noch nicht in den Sourcecode reingesehen .. sicher nur ne Kleinigkeit.
Gruß.
Rainer
"Wer andauernd begreift, was er tut, bleibt unter seinem Niveau."
- drohne235
- Administrator
- Beiträge: 2284
- Registriert: So 24. Mai 2009, 10:35
- Wohnort: Lutherstadt Wittenberg
- Kontaktdaten:
Re: Turbulence Demo Sourcecode verfügbar
Versucht doch mal bitte die angehängte Version - interessiert mich mal wie die mit verschiedenen Monitoren läuft. Vecdem war das einzige Programm was auf dem Prototypen 3 (Sammelbestellung) gegenüber den Vorgängern nicht sofort lief. Nach folgender Änderung in "vectron-1-drv" geht es aber jetzt bei drei getesteten Monitoren bei mir - mehr Geräte hab ich nicht zum testen.
Mein Problem ist das ich mir die Sache nicht schlüssig erklären kann. Ich hab es mal darauf geschoben das der Treiber irgendwie an der Grenze arbeitet und es im Timing irgendwo Unterschiede zwischen den Bords gibt - aber so richtig zufrieden bin ich nicht mit der Erklärung.
Kann sein das die Darstellung flimmert, das ist normal so, denn ich hab mit diesem Code ein kleines Experiment gemacht: Normalerweise ist es ja so das man für eine flüssige Darstellung immer zwei Puffer verwendet, welche man im Bildwechsel umschaltet. Zwei Puffer bedeuten aber auch doppelter Speicher - ein Luxus den wir in Bellatrix bei einem Vollgrafikpuffer nicht haben. Der Treiber arbeitet mit 512x384 Pixeln. Außerdem muß man nach der Berechnung eines Screens den anderen löschen um dort den nächsten Frame neu aufzubauen. Als ich so durch den PASM-Code des Treibers getobt bin hatte ich nun folgende Idee: Was wäre wenn...
Halt stop, das kennen wir ja schon!
Also: Was wäre wenn der Treiber gleich bei der Darstellung den Puffer quasi "hinter sich" in der COG-Routine löscht? So hätte man wie bei der Vectrex (geiles Teil) ein dynamisches Display. Man kann also eine Linie zeichen, aber die ist nach dem ersten Bilddurchlauf aber wieder gelöscht, was aber ganz praktisch ist für dynamische Vektorgrafik. Der Ablauf bei einer bewegten Vektorgrafik sieht ja folgendermaßen aus:
1. Linie zeichnen
2. Neue Linie berechnen
3. Alte Linie auf dem Screen löschen
4. Neue Linie zeichen
5. Goto 1
Man hat also doppelten Zeichenaufwand, denn man muss zum Löschen der Linie ja diese in der Hintergrundfarbe nochmal zeichnen. Diesen doppelten Aufwand nimmt der experimentelle Treiber ab indem er bei der Darstellung schon den Bildschirmtreiber löscht. Wenn man das Demo genau betrachtet erkennt man auch das der zeichnende Code es oft schafft innerhalb eines Bilddurchlaufes mehrere Linien zu zeichnen - das ergibt dann eine Art Schweif. Verteilen sich die Zeichenvorgänge einer Animationsphase aber über zwei oder drei Bilddurchläufe flackert es etwas - so muß das wohl auch auf der Vectrex ausgesehen haben
ist also kein Bug sondern ein Retro-Feature! ![Zwinkern ;)](./images/smilies/icon_e_wink.gif)
Naja, vielleicht findet es ja jemand interessant um weiter zu experimentieren.
Code: Alles auswählen
' änderung wegen synchronisationsproblemen bei board r13
' hn = 1 'horizontal normal sync state (0|1)
' vn = 1 'vertical normal sync state (0|1)
hn = 0 'horizontal normal sync state (0|1)
vn = 0 'vertical normal sync state (0|1)
Mein Problem ist das ich mir die Sache nicht schlüssig erklären kann. Ich hab es mal darauf geschoben das der Treiber irgendwie an der Grenze arbeitet und es im Timing irgendwo Unterschiede zwischen den Bords gibt - aber so richtig zufrieden bin ich nicht mit der Erklärung.
Kann sein das die Darstellung flimmert, das ist normal so, denn ich hab mit diesem Code ein kleines Experiment gemacht: Normalerweise ist es ja so das man für eine flüssige Darstellung immer zwei Puffer verwendet, welche man im Bildwechsel umschaltet. Zwei Puffer bedeuten aber auch doppelter Speicher - ein Luxus den wir in Bellatrix bei einem Vollgrafikpuffer nicht haben. Der Treiber arbeitet mit 512x384 Pixeln. Außerdem muß man nach der Berechnung eines Screens den anderen löschen um dort den nächsten Frame neu aufzubauen. Als ich so durch den PASM-Code des Treibers getobt bin hatte ich nun folgende Idee: Was wäre wenn...
![Lächeln :)](./images/smilies/icon_e_smile.gif)
![Verrückter Teufel :twisted:](./images/smilies/icon_twisted.gif)
1. Linie zeichnen
2. Neue Linie berechnen
3. Alte Linie auf dem Screen löschen
4. Neue Linie zeichen
5. Goto 1
Man hat also doppelten Zeichenaufwand, denn man muss zum Löschen der Linie ja diese in der Hintergrundfarbe nochmal zeichnen. Diesen doppelten Aufwand nimmt der experimentelle Treiber ab indem er bei der Darstellung schon den Bildschirmtreiber löscht. Wenn man das Demo genau betrachtet erkennt man auch das der zeichnende Code es oft schafft innerhalb eines Bilddurchlaufes mehrere Linien zu zeichnen - das ergibt dann eine Art Schweif. Verteilen sich die Zeichenvorgänge einer Animationsphase aber über zwei oder drei Bilddurchläufe flackert es etwas - so muß das wohl auch auf der Vectrex ausgesehen haben
![Lächeln :)](./images/smilies/icon_e_smile.gif)
![Zwinkern ;)](./images/smilies/icon_e_wink.gif)
Naja, vielleicht findet es ja jemand interessant um weiter zu experimentieren.
- Dateianhänge
-
- vecdem1.rar
- (4.87 KiB) 898-mal heruntergeladen
"Ob Sie denken, dass Sie es können, oder ob Sie denken, dass Sie es nicht können - in beiden Fällen haben Sie recht." Henry Ford
Re: Turbulence Demo Sourcecode verfügbar
Jo. läuft jetzt super.
Wie Du "so nebenbei" supergeile Sachen hier rein wirfst ist schon erstaunlich.
Das Teil ist der Hammer !
Geschwindigkeit ist erstaunlich .. auch der Effekt ist fast genauso wie bei den alten Vektorspielen ... nur kenn ich da nur schwarz/weiß.
Nebenbei ... es flimmert bei mir kaum .. und wenn, dann sehe ich es eher als Imitation der echten Vektormaschinen an.
Wer programmiert das erste Asteroids oder Lunar lander ?
Gruß.
Rainer
Wie Du "so nebenbei" supergeile Sachen hier rein wirfst ist schon erstaunlich.
Das Teil ist der Hammer !
Geschwindigkeit ist erstaunlich .. auch der Effekt ist fast genauso wie bei den alten Vektorspielen ... nur kenn ich da nur schwarz/weiß.
Nebenbei ... es flimmert bei mir kaum .. und wenn, dann sehe ich es eher als Imitation der echten Vektormaschinen an.
Wer programmiert das erste Asteroids oder Lunar lander ?
![Zwinkern ;)](./images/smilies/icon_e_wink.gif)
Gruß.
Rainer
"Wer andauernd begreift, was er tut, bleibt unter seinem Niveau."