|
ENGLISH VERSION |
|
 |
| Links | | | Forum | | | Kommentare | | | News melden |
|
| Chat | | | Umfragen | | | Newsticker | | | Archiv |
|
| amiga-news.de Forum > Programmierung > Amos - lohnt es sich noch? | [ - Suche - Neue Beiträge - Registrieren - Login - ] |
| -1- 2 | [ - Beitrag schreiben - ] |
|
12.04.2004, 17:10 Uhr Lord_Helmchen Posts: 532 Nutzer |
Hallo! Da ja in den letzten Tagen die Nachfrage nach Amos rege zugenommen hat, wollte ich mal nachfragen: Lohnt es sich noch, in Amos was zu programmieren und ein paar Sachen dafür "herzustellen"? Ich habe hier das Original von 1992 vob EuroPress und würde gerne mal reinschnuppern... Grüße Lord Helmchen [ - Antworten - Zitieren - Direktlink - ] |
|
12.04.2004, 17:57 Uhr Jinx Posts: 2077 Nutzer |
lass es lieber.. amos ist a) amiga-only und du kannst b) afaik nur für die custom chips proggen. grafikkarte ist nicht. dazu kommt, dass unsicher ist, ob es je nen port für os 4 geben wird. ich denke eher nicht (siehe b). -- eMail: TheJinx@web.de Homepage: http://www.TheJinx.de [ - Antworten - Zitieren - Direktlink - ] |
|
12.04.2004, 22:18 Uhr Cj-Stroker Posts: 1343 Nutzer |
@Jinx Das Amiga-only ist ja nicht unbedingt schlecht. Das ist nicht nur bei Amos so, sondern bei den meisten Sprachen, wenn es nicht gerade C/C++ ist. Ansonsten macht Amos natürlich wenig Sinn. Wenn die damit erstellte Soft jedoch nur für alte Classics sein soll, dann kann er es ruhig versuchen. @Lord_Helmchen Ansonsten wären da noch diverse andere Basic-Derivate interessant, welche in Punkto Modernität mehr zu bieten haben. Wie wäre es mit Blitz Basic bzw. Amiblitz? Schon mal daran gedacht? Es soll zwar eine an Amos angelehnte neue Sprache namens Mattathias Basic geben, doch das kann wohl noch nicht so weit sein (vom Entwicklungsstand her) und ist ohnehin eh wieder eine neue Programmiersprache. In letzter Zeit ist es zudem auch sehr still geworden. MFG Cj-Stroker -- Webmaster at Amiforce and Abakus-Design http://www.Amiforce.de (Fight For Amiga) http://www.cj-stroker.de/Abakus/ (World of AMHuhn and more) Forum: http://amiforce-forum.cj-stroker.de [ - Antworten - Zitieren - Direktlink - ] |
|
13.04.2004, 11:53 Uhr Bjoern Posts: 1730 Nutzer |
Amos ist von der Bedienung her sehr einfach, und es ist möglich ohne viele Vorkenntnisse einige Erfahrungen im Programmieren zu machen. Wenn du es sowieso rumliegen hast wüsste ich nicht warum es schlecht wäre, mal reinzuschauen. Obwohl man arg eingeschränkt ist, hat mir Amos damals viel Spaß gemacht. Wenn du wirklich neue Sachen "herstellen" willst, solltest du allerdigs eine andere Sprache wählen, das stimmt schon. mfg Björn -- visit http://www.ac-de.de [ - Antworten - Zitieren - Direktlink - ] |
|
13.04.2004, 15:21 Uhr Jinx Posts: 2077 Nutzer |
ich denke, mit einer hochsprache wie c/c++ investiert man seine zeit besser. die chancen, dass der amiga nie mehr auf die beine kommt stehen leider viel zu hoch. amos-kenntnisse kannst du aber zb am pc nicht verwenden, während du bei c nicht wieder von vorn anfangen musst. -- eMail: TheJinx@web.de Homepage: http://www.TheJinx.de [ - Antworten - Zitieren - Direktlink - ] |
|
13.04.2004, 15:29 Uhr GMKai Posts: 155 Nutzer |
versucht euer glück ruhig mal mit hollywood, ist zwar nich pc-tauglich, aber nicht schwerer als basic und um einiges mächtiger. -- Ich bin nicht Kai9! [ - Antworten - Zitieren - Direktlink - ] |
|
13.04.2004, 16:28 Uhr Lord_Helmchen Posts: 532 Nutzer |
@alle Danke für eure Antworten! So wie ich dne Eindruck jetzt habe, läuft Amos wahrscheinlich nur auf meinem A500, nur bin ich zu faul, den wieder hervor zu kramen  Vor ein paar Wochen schwirrte hier doch ein Thread zum C-Anfängerkurs herum. Ich denke, das wäre auch eine Variante... @CJ-Stroker Von Deiner HP habe ich mal AmiBlitz herunter geladen und werde mir das mal näher anschauen. Grüße Lord Helmchen [ - Antworten - Zitieren - Direktlink - ] |
|
13.04.2004, 16:53 Uhr Mad_Dog Posts: 1944 Nutzer |
Zitat: Definitiv nicht. Ich habe damals auch mit Amos Pro angefangen - auf meinem A1200. Allerdings hat Amos keine eingebaute AGA oder gar Grafikkarten Unterstützung. Ohne geistige Verrenkungen bekommt man da nur OCS/ECS Screens. Aber für den Einstig generell sind Basic-Dialekte immer gut, da man damit schnell zu Erfolgserlebnissen kommt. Im Netz kursieren immernoch Sachen aus meiner Amos-Zeit, z.B.: http://us.aminet.net/game/misc/robosq.lha Aber Vorsicht: Das Teil öffnet einen Pal-Screen. P.S.: Hier ist noch ein Centipede-Clone von mir (samt AMOS-Sourcecode): http://us.aminet.net/dev/amos/centiped.lha . Das Teil habe ich nie fertiggestellt, da zu dem Zeitpunkt meine AMOS-Zeiten eigentlich schon vorbei waren. Das beste daran finde ich immernoch mein 3D-Optionsmenü (Eigenlob stinkt, ich weiß  ).-- http://www.norman-interactive.com [ Dieser Beitrag wurde von Mad_Dog am 13.04.2004 editiert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
13.04.2004, 17:27 Uhr Lord_Helmchen Posts: 532 Nutzer |
Zitat: Dachte ich mir schon, hat ja Jinx schon erwähnt. Ich habe es übrigens auch mit der OCS/ECS-Einstellung im Early-Startup-Menü versucht, aber damit wollte Amos auch nicht laufen... Nach einer Weile blieb der Bildschirm schwarz...  Naja, ist ja auch egal, hat sich eh erst mal erledigt, siehe meine letzten Post  Grüße Lord Helmchen [ - Antworten - Zitieren - Direktlink - ] |
|
13.04.2004, 19:07 Uhr Mad_Dog Posts: 1944 Nutzer |
Zitat: Ich beziehe mich hier auf Amos Pro. Das läuft definitiv auch auf AGA-Rechnern. Allerdings kommt das Signal am original Amiga Video-Port heraus (also nicht auf der Grafikkarte). Die Entwicklerumgebung von Amos öffnet einen Pal-Screen, also wieder nichts mit Grafikkarte. Wenn Du allerdings einen 15khz-tauglichen Monitor am Amiga-Video Port anschließt, sollt es keine Probleme geben (mit Amos Pro). Also laß Dich nicht entmutigen.  -- http://www.norman-interactive.com [ - Antworten - Zitieren - Direktlink - ] |
|
13.04.2004, 19:47 Uhr Lord_Helmchen Posts: 532 Nutzer |
@Mad_Dog Und ich bin von Amos 1.3 ausgegangen. Sorry, hätte ich früher sagen sollen... Grüße Lord Helmchen [ - Antworten - Zitieren - Direktlink - ] |
|
14.04.2004, 16:37 Uhr Mad_Dog Posts: 1944 Nutzer |
Aber meine alten AMOS-Games laufen doch auf Deiner Kiste, oder? Hier noch zwei gute, alte AMOS-Games von anderen Autoren: http://us.aminet.net/game/think/ColConqII_v11.lha http://us.aminet.net/game/shoot/Scorch185.lha Übrigens: Den C-Kurs für Einsteiger findest Du auf meiner Website. -- http://www.norman-interactive.com [ - Antworten - Zitieren - Direktlink - ] |
|
15.04.2004, 12:29 Uhr eye-BORG Posts: 1282 Nutzer |
Ich habe immer in AMOS 1.34 geproggt. Auf dem A1200 lief es einwandfrei. Am besten aber OCS/ECS im Early Startup einstellen. Sonst kommt es ab und an vor, daß man einen Pixelmatsch-Screen erhält. AMOS ist wirklich große Klasse, wenn man ein Classic-Only-Game erstellen möchte. Ich habe noch die TOME (Total Amos Map Editor) Erweiterung. Geniales Teil! Man kann damit 16x16 oder 32x32 Pixel große Tiles erzeugen und sich riiiieesige Maps bauen, über die man dann scrollen kann. Der Dual-Playfiel-Mode wird kinderleicht eingesetzt. So kann man echt professionell wirkende Games schreiben. Ruckelig wird es nur dann, wenn man zig Bobs einsetzt und zu viele Copies von Grafikelementen durchführt. Reinschnuppern in AMOS schadet nicht. Will man zukunftsorientiert proggen, dann ist C++ erste Wahl. -- eye-BORG SCHRANZ rulez! [ - Antworten - Zitieren - Direktlink - ] |
|
15.04.2004, 13:09 Uhr Sebel Posts: 62 Nutzer |
Hy Leute, ich fand Amos und AmosPro richtig genial, wir haben damals angefangen THE SECRET OF MOUNT MONKEY zu programmieren, ein Adventure im Stil von Monkey Island, in der alle Figuren aus bekannten Classic-Adventures (Monkey I+II, Simon The Sorcerer, Maniac Mansion, etc) drin vorkommen sollten und in eine Story verknüpft werden sollten. Mann, ich habe monatelang an der Amal-Grafik-Figur Steuerung gearbeitet, ein eigenes "Scumm"-Adventure-System entworfen und sogar einen "Level-Editor" geschrieben, um alles zu verknüpfen. Mein Kollege hat mit VistaPro die Inselanimation gerendert, die sich gedreht hat, wenn man einen bestimmten Ort aufgesucht hat, und was weiss ich nicht noch. *InErinnerungenSchwelg* Leider ist das Spiel auf dem Miggy nie fertig geworden, da die Routinen wahrscheinlich zum Schluss so komplex wurden, dass mir AmosPro immer abgepennt ist... Das war sehr demotivierend. Naja das war so 1998, inzwischen haben wir uns zusammengerafft und versuchen dem Spiel wieder neues Leben einzuhauchen, wenn auch nur vorerst auf dem PC. Eine alte Demo-Version (Intro-only) für den Amiga (nur auf OCS/ECS Screens, AGA sollte auch, wenn ihr das system ordentlich degradiert), gibt es auf der offiziellen MOUNT MONKEY-Projekt-Homepage: http://www.mountmonkey.de Schaut mal vorbei... -- Regards, Sebel http://www.sebelinteractive.de [ - Antworten - Zitieren - Direktlink - ] |
|
15.04.2004, 13:35 Uhr Eule Posts: 1607 Nutzer |
@Sebel tja und wenn du versuchst dein Adventure zu portieren wirst du auf das größte Problem von AMOS und und jeder modernen Programmiersprache stoßen: AMOS Problem: Mangelnde Verfügbarkeit auf anderen Systemen Problem von 'C' und 'C++': Mangelnde Verfügbarkeit von möglichst freien GUI Libraries für alles Systeme ( ich siuche immer noch ein System welches für Amiga/Linux und Windows verfügbar ist ) --- Komisch aber seit den Basic Zeiten von vor 20 Jahren hat sich an den eigentlichen Problemen der Software Portierbarkeit nicht viel geändert, ausser dass es jetzt ein OS gibt welches auf 90% alles PC installiert ist ... [ - Antworten - Zitieren - Direktlink - ] |
|
15.04.2004, 14:30 Uhr Mazze Posts: 263 Nutzer |
Wenn es um plattformübergreifende Entwicklung von Spielen geht, kann ich SDL empfehlen. Es gibt auch einige GUI-Libraries dafür. Ich weis aber nicht, ob die auf dem Amiga laufen. Übrigens: die Suche nach Amos und SDL auf Sourceforge liefert 2 Ergebnisse: sdlbasic Alvyn [ - Antworten - Zitieren - Direktlink - ] |
|
15.04.2004, 15:18 Uhr eye-BORG Posts: 1282 Nutzer |
Wenn ich noch die Zeit finden würde, dann würde ich weiter an meinem Ballerspiel "Survivor" proggen. Ich fing in 1994 mit der Entwicklung an. Der Clou an der Sache: Ich entwickelte ein neues Scrolling-System, genannt HaSo (Hardware-Software). Was das Besondere an dieser Scrollingvariante sein soll? Nun, nutzt man Hardwarescrolling alleine, dann kostet das eine Unmenge wertvollen Speichers, da man ja einen Layer größer als den sichtbaren Screen definieren muß. Z.B. Scrollfläche ist 320 x 1000, sichtbar ist jedoch immer nur der Ausschnitt von 320 x 200 (das wäre jetzt bei vertikalem Scrolling und würde nur läppische 5 Screens ergeben (1000 vertikale Pixel geteilt durch 200 sichtbare = 5)). Vorteil Hardwarescrolling: Teuflisch schnell u. ruckfrei, da es durch Customchips übernommen wird. Nachteil Hardwarescrolling: Große Screens fressen Speicher, so daß es z.B. für Ballerspiele, die sich oft über 100 Screens erstrecken nicht zu gebrauchen ist. Nutzt man NUR Softwarescrolling, kann man durch Verwendung von Maps, die ja in kleine, flexibel aneinanderfügbare Tiles untergliedert sind riesige Scroll-Flächen schaffen, die theoretisch mehrere 1000 Pixel in der vertikalen und horizontalen umfassen. Jedem Tile (in der Regel 16x16 Pixel groß) wird lediglich ein Byte zugeordnet. So ähnlich hat man es auch beim C64 gehandhabt, wenn man die ASCII-Zeichen neu belegt hat, um Scrolling-Landschaften zu erzeugen. Das spart eine Menge Speicher, weil man diverse Teils mehrfach verwenden kann. Man zeigt immer nur einen Bereich der Map an auf dem 320x200 Pixel-Screen. Dieser muß jedoch immer komplett neu kopiert werden, da die alten Grafikdaten überschrieben werden müssen. Das macht die Sache natürlich langsamer! Vorteil Softwarescrolling: Durch Verwendung von Tiles und Maps flexibel und speicherschonend (Baukastenprinzip) Nachteil Softwarescrolling: Bei großen Screens oder hohen Auflösung viel langsamer als Hardwarescrolling. Ruckeln ist schnell angesagt! Mein "HaSo" funktionierte wie folgt: Ich definierte einen Screen, der doppelt so groß war wie der angezeigte Ausschnitt. Also: Sichtbar waren immer nur 320 x 256 Pixel, der Layer war aber 320 x 512 Pixel. Das Scrolling sollte von unten nach oben verlaufen. Ich bastelte eine Map, die 20 Tiles (16 Pixel x 20 = 320) breit und mehrere 1000 Pixel hoch war. Es lief eine Schleife ab, die den Screen immer um 2 Pixel hardwaremäßig verschob in der Vertikalen. Es wurde bei 255 gestartet und auf 1 runtergezählt in 2er Steps. War die 1 erreicht, sprang die Schleife wieder auf 255 zurück. Soweit so gut, das war die Hardwareseite des Scrollings. Nun kommt die Map ins Spiel: Anstatt immer einen kompletten 320x256 Ausschnitt auf den Screen zu kopieren, was ja viel Rechenzeit kostet, ließ ich in einem versteckten Screen der Maße 320x16 immer nur EINE Reihe an Tiles von der Map anzeigen. Es wurde immer nur ein 2-Pixel-Streifen in den Hardwarescreen kopiert und zwar dorthin, wo der Screen noch nicht hingescrollt war. Zugleich wurde schon hinter der angezeigten Position auch schon ein gleicher Teil der Map aufgebaut (also auch ein 2-Pixel-Streifen), da der Screen ja wieder bei 1 auf die alte Position zurücksprang und dann der Bildschirm ja schon aufgebaut sein mußte. Ich weiß nicht, ob ich das Prinzip gut rübervermitteln konnte. Auf jeden Fall kann ich mir nicht vorstellen, daß man unter AMOS ein schnelleres und effizienteres Scrolling hinbekommen kann. Wenn jemand Interesse am Source-Code für HaSo hat - nur melden. Vielleicht proggt wer anders das Spiel fertig!? cu eye -- eye-BORG SCHRANZ rulez! [ - Antworten - Zitieren - Direktlink - ] |
|
15.04.2004, 15:31 Uhr Holger Posts: 8116 Nutzer |
Zitat:Und warum habe ich dann nie eins gesehen? Ich kenn nur Spiele, die man auf den ersten Blick als typisches AMOS-Spiel kategorisieren kann. Professionell wirkte keines davon. Zitat:Das was Du da beschreibst, ist die vollkommen normale Vorgehensweise bei auf tiled-Grafik basierenden Spielen, wenn man von den AMOS-spezifischen workarounds absieht. Jedes Spiel mit tiles funktioniert so. Ok, außer vielleicht den typischen AMOS-Spielen. Ich glaube kaum, daß es sich lohnt, diese Sourcen noch mal herauszuholen. In PAL-Auflösung programmieren zu müssen (ich rede von der Entwicklungsumgebung!), ist gesundheitsschädlich. mfg -- Good coders do not comment. What was hard to write should be hard to read too. [ Dieser Beitrag wurde von Holger am 15.04.2004 editiert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
15.04.2004, 15:48 Uhr Lord_Helmchen Posts: 532 Nutzer |
Zitat: Hallo Mad_Dog! Ja, Deine Spiele laufen bis auf ColConqII. RoboSquash ist ja witzig, aber 3 Paddles auf einmal sind ein bißchen viel für mich... Zum Anfängerkurs: Ah, Du bist das also! Werde ich mir dann mal zur Gemüte führen, muss allerdings noch die Developer-CD besorgen...  Grüße Lord Helmchen PS: Du studierst ja in Stuttgart! Kommst Du etwa aus der Ecke? [ - Antworten - Zitieren - Direktlink - ] |
|
15.04.2004, 15:52 Uhr Lord_Helmchen Posts: 532 Nutzer |
Wow, so viele Antworten! Da scheine ich ja was losgetreten zu haben. Vielen Dank noch mal für eure Hinweise, ich denke aber mal ich werde erst mal in AmiBlitz und dem Anfängerkurs von Mad_Daog reinschnuppern, werde damit auch ziemlich beschäftigt sein... Vielen Dank noch mal! Grüße Lord Helmchen [ - Antworten - Zitieren - Direktlink - ] |
|
15.04.2004, 16:28 Uhr Mad_Dog Posts: 1944 Nutzer |
Zitat: @Holger: Was Du wahrscheinlich meinst nennt sich "Double Buffered Scrolling". Die andere Sache ist das wesentlich schnellere, aber auf bestimmte Größen beschränkte Amiga-Hardware-Scrolling. Man kann auch beides kombinieren und hat dann ein unbegrenzt großens Spielfeld und gleichzeitig superschnelles Scolling. Mit sowas habe ich auch schon experimentiert, ist aber schon lange her... Funktioniert im Prinzip wie folgt: 1. Du führst Deine Grafikoperationen im unsichtbaren, logischen Screen aus. 2. Du machst einen Screen Swap. Dabei landet der neue Teil der Grafik in einem unsichtbaren Bereich des Bildschirms. Jetzt benutzt Du Hardware-Scolling um das Bild zu scorllen - und zwar so weit, wie die eingefügte Grafik breit ist. 3. Nun geht das ganze wieder von vorne los. Das ist schneller wie das reine, softwaremäßige Double-Buffered Scrolling und flexibler (aber langsamer) wie das reine Hardware-Scrolling. -- http://www.norman-interactive.com [ - Antworten - Zitieren - Direktlink - ] |
|
15.04.2004, 16:31 Uhr Mad_Dog Posts: 1944 Nutzer |
Zitat: Ja. Du auch? -- http://www.norman-interactive.com [ - Antworten - Zitieren - Direktlink - ] |
|
15.04.2004, 16:40 Uhr Mad_Dog Posts: 1944 Nutzer |
Zitat: Also für 2D/3D Grafik gibt's ja OpenGL, welches mit GLUT immerhin eine portable Fenster,Screen,Pulldownmenü,Tastatur und Joystick API mitbringt. Auf dem Amiga ist StormMesa das ausgereifteste OpenGL Derivat. Schau mal auf meiner Homepage nach, dort findest Du einige Beispielsources zum Thema OpenGL und GLUT. -- http://www.norman-interactive.com [ - Antworten - Zitieren - Direktlink - ] |
|
16.04.2004, 10:09 Uhr eye-BORG Posts: 1282 Nutzer |
@Holger: Nein, tile-basierende Games haben immer den Screen geswapt und komplett neu gezeichnet. Eine Kombi aus Hard/Software-Scrolling auf die von mir beschriebene und geproggte Art und Weise haben sicher auch schon Andere umgesetzt, aber mir ist kein Spiel bekannt, das diese Technik einsetzt. -- eye-BORG SCHRANZ rulez! [ - Antworten - Zitieren - Direktlink - ] |
|
18.06.2004, 23:47 Uhr CyberZorro Posts: 47 Nutzer |
Kann man mit AmiBlitz auch auf Grafikartenscreens arbeiten? Ich meine lässt sich der Editor auf einem CGX Screen öffnen und GUI-Applikationen damit erstellen die auf einem CGX Screen laufen? -- ..to boldy go where no-one has gone before! [ - Antworten - Zitieren - Direktlink - ] |
|
19.06.2004, 00:06 Uhr asregg Posts: 265 Nutzer |
Zitat: Sicher. Einfach in den Einstellungen einen RTG Screenmode auswählen. Bei mir funktioniert AmiBlitz unter P96 einwandfrei. Und selbstverständlich kannst du auch Programme schreiben, die dann auf Grafikkarten lauffähig sind. Ich denke "Foundation" ist das beste Beispiel dafür (ja, das wurde mit BlitzBasic gecodet  ).  [ - Antworten - Zitieren - Direktlink - ] |
|
19.06.2004, 12:05 Uhr dante Posts: 111 Nutzer |
Zitat: Na, wer machte denn Scrolling auf Amiga, in dem man mit riesigen Bitmaps das Chipmem blockierte, oder per Frame ne neue Bitmap aufbaute?! Wofür hat der Amiga einen Blitter?! Eine Tile-Engine auf Amiga: Screengrösse 320x256. Tilegrösse 32x32. Ergo: Screengrösse=10 Tiles x 8 Tiles. Im einfachsten Fall werden für Scrolling nun 2 Bitmaps obiger Grösse angelegt + oben, unten, links und rechts jeweils 1 Tilespalte / -zeile , also 12x10 Tiles. Nun wird hardwaremässig gescrollt in die zusätzliche Tilereihe/spalte hinein oder hinaus, gleichzeitig wird abhängig von der Richtung die andere Bitmap im VB-IRQ refreshed, Und bei einer Tilesize von 32x32 hat man ordentlich Zeit, da es ja bei 1-Frame-Scrolling 32 Frames dauert, bis eine neue Tile-Reihe/Spalte sichtbar ist, man kann sich also pro Frame damit begnügen, im VB-IRQ meinetwegen 4 Tiles zu blitten. Das bedeutet eine konstante aber geringe Belastung hauptsächlich für den Blitter. Für 4-Wege-Scrolling kann man mehr nehmen, um Richtungswechsel abzufangen ohne plötzlichen Anstieg der Rechenzeit, also 2 Tile-Reihen/Spalten extra pro Richtung, bei obigen Beispiel dann 14x12 Tiles. Tja, es hat Gründe, warum es bis Mitte der 90er dauerte, bis es auf PC's zum Amiga vergleichbare Ballergames und Jump 'n Runs gab....  [ - Antworten - Zitieren - Direktlink - ] |
|
19.06.2004, 14:31 Uhr whose Posts: 2156 Nutzer |
Zitat: Naja, ganz so trivial ist es nicht. Sobald Du bis in die zusätzlichen Tile-Zeilen/-Spalten hineingescrollt hast und an deren Ende angekommen bist, mußt Du das komplette Bild wieder neu aufbauen. Also bekommst Du am Ende jedes Scroll-Bereiches nochmal ordentlich Blitter-Last, weil Du das gesamte Bild verschieben mußt, um wieder die Anfangsposition für erneutes Scrollen zu erreichen (brauchst ja schließlich wieder Platz in der Scroll-Richtung für die zusätzliche Tile-Zeile/-Spalte). Das ist eine Technik, die ich in meiner Artikelserie in der AmigaInsider näher beschreibe, unter anderem mit Beispielsourcen in C. Darüber hinaus lohnt sich ein Blick ins AmiBlitz-Archiv, speziell in "ThilosIncludes". Dort wird sehr schön gezeigt, wie man Scrolling auf GraKa realisieren kann. Dort wird zwar nicht mit Tiles gearbeitet, abr die grundsätzliche Technik ist die Gleiche. Grüße [ - Antworten - Zitieren - Direktlink - ] |
|
19.06.2004, 15:02 Uhr dante Posts: 111 Nutzer |
whose, du hast mein Posting scheinbar nicht gelesen.  Oder nicht verstanden? Der Aufbau des nächsten Bildes erfolgt im VB-IRQ, mit diesen Blits von jeweils ein paar Tiles, wie oben beschrieben. Glaubs mir, das funktioniert, hab ich schon so programmiert... auch wenns lange her ist, ich kann mich erinnern.  Ich glaub, ich hack gleich mal nen Example in BB2 zurecht, wenn du es mir weiterhin nicht glaubst.  [ Dieser Beitrag wurde von dante am 19.06.2004 editiert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
19.06.2004, 17:12 Uhr whose Posts: 2156 Nutzer |
Zitat: Na, ich glaub Dir ja, daß das funktioniert. Ich werde aber das Gefühl nicht los, daß Du das im Singlebuffering machst. Scrollt dann zwar nett, aber animierte Sprites oder gar Tile-Animationen dürften dann etwas flackernd wiedergegeben werden.  Daß Du einen 2. Buffer im Hintergrund mit dem "im Voraus" gescrollten Bild füllst ist ja nun nicht gerade Doublebuffering im herkömmlichen Sinn, eher Caching Sollte ich das immer noch nicht richtig verstanden haben, hack uns doch bitte das Beispiel zusammen. Schließlich lernt man ja nie aus Bisher habe ich als beste Lösung das Scrollen bis zum Ende der zusätzlichen Tiles und dann Umkopieren des gesamten Bildes auf Position 0 angenommen. Ermöglichte sogar schon auf dem C64 Scrolling UND Doublebuffering. Grüße [ - Antworten - Zitieren - Direktlink - ] |
| -1- 2 | [ - Beitrag schreiben - ] |
| amiga-news.de Forum > Programmierung > Amos - lohnt es sich noch? | [ - Suche - Neue Beiträge - Registrieren - Login - ] |
|
|
Impressum |
Datenschutzerklärung |
Netiquette |
Werbung |
Kontakt
Copyright © 1998-2024 by amiga-news.de - alle Rechte vorbehalten. |
|