Beiträge von mad^bkn

    Hallo, vielleicht kann jemand anderes besser helfen.. Aber in sogut wie allen Spiele Programmen auf allen Systemen gibt es einen "Game Loop". Das ist eine Schleife, die unendlich läuft also im Prinzip ein "Goto 10". Die Zustände der einzelnen Elemente werden in Arrays gespeichert. So kann man jedes "Frame" als jeden Loop Schritt alles nochmal neu zeichnen, was sich bewegt hat.

    Wie gesagt, hab perönlich nichts mit Basic zu tun, aber dieses "Game Loop" Konzept gibt es sogut wie überall.

    Cheers und Frohes Fest!

    Danke Kinzi für die Hinweise!! :) Ich glaub das wäre echt auch ne Idee für nen Zoomscroller.. Einfach 4 Pixel breite Pixel in der untersten Zoomstufe! Vielleicht könnte man Interlace verwenden um die wieder zu "verkleinern", vielleicht wäre das Flackern sogar ok..

    Das Ding ist sehr wahrscheinlich, dass man nur 8 Sprites hat, die ungezoomt in multicolor nicht mal 320 Pixel (sondern nur 8*24) füllen können.

    Kann sein, dass sie oben und unten nur mindestens Faktor zwei gezoomt haben müssen und die Sprites dafür in X Stretchen (*2 mit "Stretch Register"), wenn sie im oberen oder unteren Border sind.

    Ist schon krass, was die machen und klar gehen nur Sprites im Border, du hast natürlich vollkommen Recht. Gibt von Graham nen riesen Zoom Picture was auch im Border zoomt und dazu noch in x und y bewegt, er meinte mal "Border geht immer.", was ich aufgrund der Sprite Geschichte ziemlich krass finde, als Aussage.. Das Sprites nicht den ganzen Bildschirm covern ist halt wirklich schade..

    Bitte melde dich an, um dieses Medienelement zu sehen. das Demo mit dem etwas grösseren Bild.. Kann sein, dass Graham da wirklich nur 8 Sprites verwendet, wie Du das vorschlägst.. Wäre eine Erklärung für seine Aussage damals :D ..

    Btw.. Wird wohl nen Grund haben dass Boozes Scroller so klein sind und Grahams Bilder ebenfalls eher nicht den ganzen Screen covern. Eventuell ist da irgendwie nicht genug Speicher, oder irgend nen anderes Problem.. Bei Booze ist es sicherlich auch der Border und die dafuer benoetigten Sprites..

    Keine Ahnung, hab sowas nie probiert..

    Übrigens, ohne Badlines auf dem Screen braucht man sogar nur 40 Bytes updaten pro Frame + das Anfügen an der rechten Seite vom neuen dazugekommenen Scrolltext.. Also eigentlich sollten irgendwie wirklich große Scroller möglich sein, soweit es der Speicher hergibt..

    Na das Scrollen kannst du einfach über ein +1 im Charindex machen, für 10 Pixel dann zum Beispiel +10.. Damit scrollt der ganze Kram einen (oder 10) multicolor Pixel nach links. Es gibt noch andere Zoomtechniken.. Aber im Prinzip muss man bei dem Booze Design Scroller oben nur 16 Zeilen X Zoomen (das sind 2*40 Chars, also zwei Zeilen pro Frame neu setzen, 2 weil 16 Zeilen = 2 * 8 Pixel), so wie das aussieht, und den Y Zoom macht man dann mit gängigen "Rasterstrahl Techniken" und zieht die 16 Zeilen damit in die Länge Y mäßig..

    float charIndex = 10, stepSize = 1;

    for (i = 0; i < 40; ++i) {

    screen[i] = (int)charIndex;

    charIndex += stepSize;

    }


    Das charIndex = 10 sorgt dafür, dass das Bild um 10 Pixel nach links gescrollt ist..

    Auf dem C64 ist es übrigens wichtig Festkomma (oder eventuell Tabellen) in Assembler zu benutzen "floats" gehen da eh nicht! Und natürlich mehrere Charsets zu benutzen, 256 Chars sind oft zu wenig, gerade bei größeren Bildern.. :)

    Kann mich auch irren, wie die das gemacht haben.. Aber erstmal nen Guess von hier... Das sollte aber eigentlich sogar mit 64 Pixel hohen Buchstaben gehen, das wären 8*40 Chars neu setzen pro Frame also (320 byte) oder so, natürlich nur nen Guess aber nen Versuch wäre es wert, vielleicht täusche ich mich da auch..

    Alles Gute und viel Erfolg! :)

    Natürlich kenne ich die Zoomscroller von Booze Design, ich hatte mir bloß den Code nie angeschaut meinte ich (z.B mit Vice), Zoomscroller interessierten mich persönlich nie zu coden. Irgendwie denke ich, dass man den Scroller in dem Link noch toppen kann, dann aber ohne den Border zu öffnen (auch wenn das aus Deiner Sicht vielleicht vermessen klingt)... Der Border ist bei denen dort scheinbar das eigentliche Thema! Trotzdem natürlich danke für den Link Booze Design sind schon die Kings auf dem C64.. Wahrscheinlich toppen die das eh später nochmal selbst. :D

    Ich warte ja immer noch darauf, dass andere Leute hier was beisteuern, wahrscheinlich bin ich eh Offtopic für Dich.. Wollte irgendwie bloß helfen, auch wenn Du eigentlich eine präzise Antwort nach Booze Design Zoomscrollern gesucht hattest.. Bitte melde dich an, um diesen Link zu sehen.


    Wie gesagt sorry für den Offtopic Exkurs zu X Zoomern :). Soll heißen es gibt nicht wirklich Hardware Tricks auf dem C64 die einem dabei helfen, auch wenn man das bei Booze Designs Demos manchmal denken könnte, dass ist meist wie so vieles in Demos "Character Magic" oder zumindest werden meist 4 Pixel auf einmal "gezoomt" auch wenn es mit Sprites gelöst ist.. Auf dem Amiga ist es jedoch meist nen Hardware Trick mit dem Finescroll Register soweit ich das gehört hab..

    Vielleicht konntest Du ja trotzdem mit dem ganzen Kram hier was anfangen.. Viel Erfolg bei dem PC Projekt!

    Achso und tut mir leid, ich hab mir den Booze Zoomscroller nie angeschaut, mal schauen, ob hier noch fundierteres kommt.. Mein Kram war eventuell ein bisschen OffTopic, ich persönlich würde wahrscheinlich für nen 1ten Versuch den X Zoomer damit machen.. Zweiter Versuch wäre mehrere Scroller zu haben an die am rechten Rand etwas angefügt wird, sozusagen für jede ZoomStufe eine schmale Bitmap. Gibt sehr wahrscheinlich noch bessere Möglichkeiten. Mal schauen, ob hier jemand noch mehr Plan hat! :)

    Also noch schnell:

    Also sagen wir wir haben eine Bitmap aus 32x8 multicolor Pixeln.

    Jetzt erzeugen "wir" 32*4 Chars daraus.


    Der erste Char ist einfach die Pixel (0,0) bis (4,8).. Der zweite Char ist von Pixel(1,0) bis (5,8).. Der dritte Char ist von Pixel(2,0) bis (6,8). Der vierte von von Pixel(3,0) bis Pixel(7,8). Der fünfte von von Pixel(4,0) bis Pixel(8,0).. Etc.... bis zum Character 128..

    Für das Zoomen zeichnen wir eine Linie auf den Bildschirm also 40 Zeichen.

    wir haben eine float Schrittgröße, also zum Beispiel 1, 4, 8 oder 2..


    float charIndex, stepSize = 1;

    for (i = 0; i < 40; ++i) {

    screen[i] = (int)charIndex;

    charIndex += stepSize;

    }

    Wenn die Stepsize 4 ist "sehen wir" das original Bild.. Da ja jeder Character 4 mal da ist (nur nen bissl verschoben)..

    Wenn die StepSize 2 ist sehen wir das Bild um Faktor 2 vergrößert.. Wenn die StepSize 8 ist ist das Bild um die Hälfte geschrumpft..


    Das ist jedenfalls ein Zoom Ansatz mit dem man sehr weit kommt. Extrem viele Oldchool zooms basieren auf diesem Ansatz..

    Hier bei ungefähr 5:05 Graham Oxyron Parts

    Kann aber gut sein, dass man für einen Zoomscroller eher doch noch anders ans Ziel kommt.. Wie gesagt ich glaube der X Zoom ist die wichtigste Komponente dabei. Was mit Y ist, weiß ich leider da auch nicht.. Simple Zoomscroller duplizieren da oft Zeilen z.B. mit Rastertricks..

    Also der Chaos von Sanity hat auf dem Amiga eine Zoomtechnik erfunden (soweit ich weiß), die darauf basiert das man alle horizontalen 16 pixel das x Finescrollregister neu setzt. Komischerweise werden dadurch Zooms um in der Nähe von Faktor 2 in beide (größer/kleiner) Richtungen möglich. Wenn man das Bild jetzt noch mehrmals im Speicher ablegt, also im Prinzip als "Mipmaps" die jeweils um Faktor zwei gezoomt sind kann man im Prinzip beliebig weite Zooms damit machen. Soweit ich weiß hat Chaos das Graham von Oxyron erklärt und Graham hat ein sehr beindruckendes Demo damit auf dem C64 gemacht in dem er (wahrscheinlich) das Bild in Character aufgeteilt hat und jedes Zeichen davon 4 mal um x Pixel verschoben abgelegt hat. Dadurch kann man im Prinzip alle 4 horizontalen Pixel ( in Hires 8 ) Pixel im Prinzip ein neues "finescroll" Offset setzen.

    Es gibt von Krill in dem Demo +H2K ein sehr schönen wabbelnden Zoomscroller auf der Basis, soweit ich mich erinnere.. Bei ungefähr 0:25 Bitte melde dich an, um dieses Medienelement zu sehen.

    Die ganzen XRotator auf dem Amiga und C64 (z.B auch im C64 Desert Dreams der "drehende" braune Cube mit dem Desert Dreams Schriftzug) basieren oft auch auf dieser Zoom Technik um jede Rasterline in X zu zoomen.

    Es gibt noch andere Zoomtechniken vielleicht irre ich mich auch bei den Demozuweisungen hier, aber dieser alle 8 horizontale pixel das "finescroll register" ändern ist glaub ich der gängiste Trick um in X zu zoomen..

    In Y sind das dann aber meist eher nur "irgendwelche Rastertricks"...

    Ich schreibe wahrscheinlich später mehr hab bloß gerade jetzt ne Telko.. :)

    Hoffe es ist nichts falsch an der Description! :) Und klar es gibt noch andere Zoomtechniken für horizontale Zooms und sei es eben nur jeden Pixel neu zu berechnen..

    Für nen Zoomscroller könnte man vielleicht auch beim Anfügen der Buchstaben rechts am Border gleich alle Zoomstufen mit berechnen.. oder so.. :)

    Cool!! Großartig, Doug ist eine Legende auf dem Plus/4. Selten, dass jemand aus den 80ern wieder erscheint und seine damaligen Idee verwirklicht und das besser macht, was ihm nach all den Jahren noch auffiel. Auf Plus4World hatte er geschrieben in welchen Umfeldern er sich Job mäßig danach bewegt hatte. Dürfte ein interessantes Interview werden! Danke Goethe!

    Hallo Leute,

    gestern hatte mich Shine auf die Idee gebracht einen Loader den ich gerade soweit zum Laufen brachte, dass er eigentlich mit dem SD2IEC und unseren Spielen funktioniert in Pets Rescue und Alpharay einzubauen.

    Andy hat das auch schon auf real Iron getestet und anscheinend laufen beide Spiele jetzt als d81 auf dem SD2IEC..

    Natürlich einige Flaws wie:

    - langsameres laden (aber dank SD2IEC vielleicht ok)

    - Kein Saven

    - Pets Rescue hat den Level End und Rennen Jingle verloren. Der Speicher war dafür nicht mehr ausreichend.

    - Das ganze ist sogut wie völlig ungetestet.

    Hier mal die Links:

    Bitte melde dich an, um diesen Link zu sehen.

    Bitte melde dich an, um diesen Link zu sehen.

    Habt Spass! :)

    Parallax Scrolling ist im Prinzip relativ simpel. Das sind fast immer Zeichensatz Animationen.

    Die Dinger von Flimbos Quest und Hawkeye sind mit 90% Wahrscheinlichkeit auch Zeichensätze.

    In eine der krassesten Ausbaustufen sind das dann 8 Zeichensätze, für jede Y Feinscroll Position einer um die jeweilige Anzahl verschobene Zeile (also 0-7 Zeilen Verschiebung (direkt in 8 Zeichensätze gebacken)).

    Sozusagen liegt der Hintergrund der parallaxen soll 8 Mal im Speicher um jeweils x (0..7) Zeilen verschoben (in Charsets gebacken). Vertikal gibt es glaub ich noch nicht viele Spiele mit sowas (ah doch Turrican 2?), aber das ist eher trivial.

    Es wird ein Hintergrund der 8 ausgewählt je nachdem wie der Parallaxscroll gerade positioniert (Y) ist und das Feinscrollregister (Y) aussieht.

    Hoffe das ist nicht zu unverständlich beschrieben.

    Die ganzen Sarah Demos, die ich bis jetzt vertikal gesehen haben animieren sehr sehr wahrscheinlich einzelne Chars. Sie hat aber an einer Stelle Abgerundete Wolken also nicht nur 8x8 Block Parallax, was dann doch wieder cool ist! Bin gespannt wie sich das entwickelt! :)

    Hallo Forum64!

    Wir (Frenetic und ich) haben letzte Woche zwei 264 (Also Plus/4 / C16) "crt" Versionen gebastelt, eine von "Pets Rescue" und eine von "Alpharay". Beide Versionen laufen mit einem Plus/4 und dem Sidekick rangestöpselt. Nur das Saven von Spielständen funzt noch nicht.. Frenetic hat echt ganze Arbeit geleistet mit dem Sidekick und es ist recht einfach ansprechbar von Plus/4 Seite aus. Danke dafür..

    Bloß ne Plus/4 Randnotiz in dem Thread hier! :)

    Sieht schon ziemlich gut aus! Nur so als Stimme aus dem Off.. Muss nicht ernstgenommen werden. Die Glitches der Fahrbahnmakierungen bekommt man weg, falls ihr das wollt, in dem die Linien über längere Distanzen interpoliert werden. Wir hatten die Interpolation an jeder Markierungsänderung festgemacht, glaub ich.. Das sah glaub ich bei uns recht ähnlich aus am Start und war zum verzweifeln. Der Code für die Interpolation könnte spezialisiert werden, z.b. jeweils eigene Routine für 1,2,3,4,5,7,n Distanzen..

    Ansonsten viel Erfolg mit dem großen Projekt!

    Ich hab nicht alles gelesen vielleicht verstehe ich das Thema deswegen nicht wirklich (vielleicht auch Thema verfehlt oder das war schon hier so vorgekommen), aber:

    Übrigens der Kram ist beliebig optimierbar.. Vor allem das Entrollen der Schleifen bring Performance wenn Speicher nicht so wichtig ist.. Ich würde das wahrscheinlich nie als Schleife schreiben..

    Have Fun!

    ( Hoffe das hilft vielleicht eventuell weiter! :) )