amiga-news ENGLISH VERSION
.
Links| Forum| Kommentare| News melden
.
Chat| Umfragen| Newsticker| Archiv
.

amiga-news.de Forum > Programmierung > Will lernen Amiga Games zu proggen [ - Suche - Neue Beiträge - Registrieren - Login - ]

1 -2- 3 [ - Beitrag schreiben - ]

23.01.2006, 13:30 Uhr

Vigo
Posts: 1254
[Ex-Mitglied]
Zitat:
Original von bruZard:
Ooch vigo ... tut das Not dass Du einem offensichtlichen absoluten Anfänger so einen Unsinn erzählst?


Ahem, was für einen Unsinn denn? Dass man durch Assembler durchaus sinnvolle Erfahrungen machen kann, wie ein Rechnersystem aufgebaut ist?

Zitat:
Mag ja sein dass Games, welche die A500 Hardware bis zum letzten Register ausreizen, besser in Assm programmiert werden. Aber auch in Blitzbasic2 (nein, nicht AmiBlitz2) kann man äußerst hochperfomante Games programmieren. Die UltimateBlitz CD kann man sich bei http://www.back2roots.org saugen.

Warum dann nicht gleich aufm PC in Blitz Basic Programmieren? Sorry, macht für mich keinen Sinn, einen A500 damit abzuquälen. Und so performant ist BB2 auch wieder nicht (hab selber früher darin programmiert).

Zitat:
Eine schlechte Performance hängt meistens vor dem Monitor ... ich kann dir auch in Assembler schlecht laufende Games programmieren deren Blitz2 Derivat wesentlich perfomanter läuft

Sicher, und? Blitz 2 schränkt Dich aber in Deiner Freiheit ein, die vorhandene Hardware auszunutzen. Und es ist, selbst bei optimaler Ausnutzung, immer noch langsamer als ASM. Wie gesagt, warum nicht gleich aufm PC Programmieren, wenn man von der A500 Hardware nix wissen will?

Zitat:
, ganz einfach aus dem Grund weil ich seit 15 jahren kein Assm mehr programmiert habe und deshalb kaum noch in der Lage bin da was zu optimieren.

Du tust gerade so, als würde man mit ASM nur einen minimalen Performanceunterschied im Gegensatz zu Blitz2 herauskitzeln können. Ich behaupte, dass man selbst mit nicht-optimalen ASM code immer noch viel schneller als Blitz2 sein kann. Ganz zu schweigen von den Möglichkeiten, die sich einem eröffnen, wenn man Blitter und Copper direkt programmiert.

Wie gesagt, warum dann nicht gleich aufm PC Programmieren? Da lernt man genau so viel über dem Amiga, als aufm Amiga in Blitz 2 zu coden.

Ich geb mal einen kleinen Tipp für Amiga ASM coder: benutzt WHDLOAD als Entwicklungsplattform! Man kann mit WHDLOAD prima sachen coden, die sich sauber aus dem System entfernen lassen.
--
Jeder User verdient seinen Computer.

[ Dieser Beitrag wurde von Vigo am 23.01.2006 um 13:33 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

23.01.2006, 13:47 Uhr

bruZard
Posts: 307
Nutzer
Zitat:
Wie gesagt, warum dann nicht gleich aufm PC Programmieren?

Weil die Fragestellung explizit auf einen Amiga500 abziehlt und mit keiner Silbe nach Deinen persönlichen Vorlieben für Wintel PCs gefragt wird.

[ - Antworten - Zitieren - Direktlink - ]

23.01.2006, 13:54 Uhr

Vigo
Posts: 1254
[Ex-Mitglied]
Zitat:
Original von bruZard:
Zitat:
Wie gesagt, warum dann nicht gleich aufm PC Programmieren?

Weil die Fragestellung explizit auf einen Amiga500 abziehlt und mit keiner Silbe nach Deinen persönlichen Vorlieben für Wintel PCs gefragt wird.


Und umgekehrt könnte ich jetzt auch sagen, dass die Fragestellung ebenfalls nicht explizit auf Deine Vorliebe für BB2 oder sonstige Basic Dialekte abzielt. Wo Du aus meinen Aussagen meine Vorliebe für Wintel PC's herauslesen willst ist mir schleierhaft, da ich mehrmals betont habe, dass der Amiga eine sehr flexible und interessante Hardware unter der Haube hat, und es einfach nur schade ist, wenn man durch einen 0815 Basic Dialekt nix davon mitbekommt. Da kann ich, wie gesagt, gleich aufm PC Programmieren.

Udn außerdem: wer hat das Gerücht in die Welt gesetzt, ASM sei nix für Anfänger? Das kotzt mich nämlich immer an, dass sich immer sofort eine ängstliche Anti-ASM Fraktion bildet, sobald man jemandem nahelegt, dieses (verbotene?) Wissen zu erlernen. Gerade der 68K ist ne ziemlich gute ASM Plattform (im Gegensatz zum Intel, den ich ebenfalls schon häufig in ASM programmiert habe).
--
Jeder User verdient seinen Computer.

[ Dieser Beitrag wurde von Vigo am 23.01.2006 um 13:56 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

23.01.2006, 14:12 Uhr

Mad_Dog
Posts: 1944
Nutzer
@Vigo:

Die Frage wurde von einem ANFÄNGER gestellt!

Du magst ja recht haben, daß man nur mit absoluter Low-Level Programmierung einen Computer optimal ausreizen kann, aber glaubst Du im Ernst daß ein ANFÄNGER das sofort kann?

Und die spezial-Hardware kann man auch in Hochsprachen (ja auch in Basic oder C/C++) programmieren - entweder über Betriebssystemfunktionen (was einem sauberen Programmierstiel entspricht), oder aber direkt per Low-Level Programmierung (auch das können Hochsprachen) auf die Register klopfen (was aber oft zu Kompatiblitätsproblemen führt).

Meine Meinung dazu: Der Fragesteller soll sich erstmal darüber klar werden, was er will, was er kann und wieviel Zeit er bereit ist, ins Lernen zu investieren...

Wenn er bereit ist, viel Zeit zu investieren und sich tief in die Amiga Hardware reinzuarbeiten, kann er ruhig Assembler lernen.
Wenn er schnelle Erfolgserlebnisse haben will, sollte er es für den Anfang mal mit einem BASIC Dialekt probieren.
Wenn er portablen Code haben will, sollte er C oder C++ lernen.

Bei amazon bekommt man diverse Bücher über Amiga-Programmierung in diversen Sprachen... davon kann er sich ja dann was raussuchen.

Aber wie gesagt: Assembler für einen ANFÄNGER halte ich für ein wenig zu hart - schon alleine deshalb, weil man sich da sehr gut mit der Hardware (CPU und diverse Coprozessoren) auskennen muß...

--

http://www.norman-interactive.com

[ - Antworten - Zitieren - Direktlink - ]

23.01.2006, 14:13 Uhr

thomas
Posts: 7716
Nutzer

68k-Asm ist wirklich sehr einfach. Vor allem, wenn man vom C64 kommt, ist es das reinste Paradies. Allerdings ist es in Asm zu einfach, nur auf die Hardware zuzugreifen, anstatt das OS zu benutzen, was in Asm ziemlich umständlich ist.

Als Literatur empfehle ich das "Amiga Intern" von Data Becker. Das beschreibt wirklich jedes kleinste Bit der Hardware.

Ich würde heutzutage auch auf dem A500 C als Programmiersprache empfehlen. Zum einen kommt da genauso guter Code heraus wie bei Asm und zum anderen kann man es besser lesen/warten. Und zum Dritten gibt es noch Literatur zum Lernen von C zu kaufen, das dürfte bei 68k-Asm schwieriger werden.

Natürlich braucht man für C eine Festplatte, denn es gibt kaum einen Compiler, der auf eine Diskette paßt.

Gruß Thomas

--
Email: thomas-rapp@web.de
Home: thomas-rapp.homepage.t-online.de/

[ - Antworten - Zitieren - Direktlink - ]

23.01.2006, 14:16 Uhr

Mad_Dog
Posts: 1944
Nutzer
Zitat:
Original von thomas:

Natürlich braucht man für C eine Festplatte, denn es gibt kaum einen Compiler, der auf eine Diskette paßt.


Er hat doch gesagt, daß er auf seinem PC Amiga Programme schreiben will - das Ergebnis kann er dann auch auf nem 500er ohne Festplatte ausführen... (dazu muß er dann eben die Programme irgendwie übertragen, was aber wieder ein Thema für sich ist ;) ).


--

http://www.norman-interactive.com

[ - Antworten - Zitieren - Direktlink - ]

23.01.2006, 14:25 Uhr

Vigo
Posts: 1254
[Ex-Mitglied]
Zitat:
Original von Mad_Dog:
@Vigo:

Die Frage wurde von einem ANFÄNGER gestellt!

Du magst ja recht haben, daß man nur mit absoluter Low-Level Programmierung einen Computer optimal ausreizen kann, aber glaubst Du im Ernst daß ein ANFÄNGER das sofort kann?


Im Gegensatz zu Dir gehe ich an unserem Lehrling ziemlich unvoreingenommen bezüglich seiner Talente/Fähigkeiten heran. Kann ein Anfänger sofort in C coden?

Zitat:
Und die spezial-Hardware kann man auch in Hochsprachen (ja auch in Basic oder C/C++) programmieren - entweder über Betriebssystemfunktionen (was einem sauberen Programmierstiel entspricht), oder aber direkt per Low-Level Programmierung (auch das können Hochsprachen) auf die Register klopfen (was aber oft zu Kompatiblitätsproblemen führt).

1. Einen 7Mhz A500, den programmiert man nicht Systemkonform, dafür ist die Kiste zu langsam.

2. Sicher kann man das in C auch versuchen, Hardwarenahe Spiele zu schreiben. Bilde Dir aber nicht ein, dass die direkten Harwdarezugriffe dadurch leichter werden.

Zitat:
Meine Meinung dazu: Der Fragesteller soll sich erstmal darüber klar werden, was er will, was er kann und wieviel Zeit er bereit ist, ins Lernen zu investieren...

Sicher, aber es gibt einige hier, die sofort ein Kruzifix aufstellen, wenn man den begriff Assembler erwähnt. Wovor habt ihr eigentlich schiss? Es kann durchaus in vielen Fällen sogar leichter als C oder Basic sein!

Zitat:
Aber wie gesagt: Assembler für einen ANFÄNGER halte ich für ein wenig zu hart - schon alleine deshalb, weil man sich da sehr gut mit der Hardware (CPU und diverse Coprozessoren) auskennen muß...

Es gibt da eine sehr uberlebenswichtige Funktion des menschlichen Gehirns, ich glaube, die heisst lernen. Außerdem ist es Blödsinn, Assembler als schwer abzustempeln. Man kann sogar in Assembler ohne viel Aufwand Betriebssystemkonform programmieren. Gerade der 68K hat viele Befehle, mit denen sich die wichtigsten Hochsprachenkonstrukte einfach nachbilden kann. Dazu kommen noch sehr viele 32bit breite Register, und 24bit linearen Adressierungsraum. Ein Traum!
--
Jeder User verdient seinen Computer.

[ - Antworten - Zitieren - Direktlink - ]

23.01.2006, 14:30 Uhr

thomas
Posts: 7716
Nutzer
Zitat:
Assembler für einen ANFÄNGER halte ich für ein wenig zu hart - schon alleine deshalb, weil man sich da sehr gut mit der Hardware (CPU und diverse Coprozessoren) auskennen muß...

Das sehe ich nicht so. Gerade für einen Anfänger ist Assembler leichter. Einfach zu lernen, leicht zu verstehen. Ein Bild mit einer Copperlist auf den Bildschirm zu zaubern, dann auf den Mausknopf zu warten und anschließend das Amiga-Bild wiederherzustellen ist in Assembler und mit direkten Hardwarezugriffen deutlich einfacher als mit C und den entsprechenden OS-Calls.

Natürlich braucht man jemanden, der einem das Grundgerüst zur Verfügung stellt. Wenn man alles allein lernen möchte, dann muß man sich schon die RKRMs zu Gemüte führen und kommt dann von einer ganz anderen (weniger spielerischen) Seite an die Sache heran.

Gruß Thomas

--
Email: thomas-rapp@web.de
Home: thomas-rapp.homepage.t-online.de/

[ - Antworten - Zitieren - Direktlink - ]

23.01.2006, 14:32 Uhr

Vigo
Posts: 1254
[Ex-Mitglied]
Wie gesagt: WHDLOAD benutzen! Das geht sehr einfach.
--
Jeder User verdient seinen Computer.

[ - Antworten - Zitieren - Direktlink - ]

23.01.2006, 14:45 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von Vigo:
Neee, der 68K hat keine Befehlspipeline, die beginnt erst mit dem 68010. D.h. man kann immer noch Zyklen zählen.

Der 68000 hat eine zweistufige Pipeline. Das heißt in der Praxis ja letztendlich nur, daß er den nächsten Befehl schon lesen kann, während er den aktuellen ausführt.
Das hindert Dich auch überhaupt nicht daran, Zyklen zu zählen, wenn's Dir Spaß macht, insb. weil Dir beim 68000 keine Parallelverarbeitung oder Cache-Misses in die Suppe spucken können.
Zitat:
C eignet sich dann am besten, je komplexer die Probleme werden.
Ich halte ein ernstzunehmendes Spiel durchaus für komplex genug, um auch C einzusetzen (evtl. mit Assembler-Ergänzung).

Aber für einen Anfänger spielt das keine so große Rolle. Der muß sowieso erst mal seine Erfahrungen sammeln und sehen wie weit man mit dem "ich will jetzt mal Spiele programmieren" Ansatz kommt.

Zitat:
Aber die Sachen, für die ein A500 halt prädestiniert ist (bunte, flüssig scrollende 2D SPiele), da kommt man mit ASM viel weiter.
Oder dem Demomaker...
Zitat:
Der A500 hat jedoch sehr viele nette Hardwarefeatures, die in einer Hochsprache entweder gar nicht oder nur rudimentär unterstützt werden. Du weisst ja gar nicht, was man z.B. mit dem Copper alles hinbekommen kann.
Das kannst Du in C auch alles machen. C iss ja auch nur geringfügig mehr als Assembler...

mfg
--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

23.01.2006, 15:21 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von thomas:
Das sehe ich nicht so. Gerade für einen Anfänger ist Assembler leichter. Einfach zu lernen, leicht zu verstehen.

Mmm, ich habe damals auch zuerst 68k-Assembler gelernt. C war im Vergleich dazu eine wirre Anhäufung von diversen Klammern und Sonderzeichen.
Ok, das isses heute eigentlich auch immer noch.
Zitat:
Ein Bild mit einer Copperlist auf den Bildschirm zu zaubern, dann auf den Mausknopf zu warten und anschließend das Amiga-Bild wiederherzustellen ist in Assembler und mit direkten Hardwarezugriffen deutlich einfacher als mit C und den entsprechenden OS-Calls.

Es ist nicht so, daß Assembler gleich Hardwarezugriffe und C gleich OS-Calls ist.

mfg
--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

23.01.2006, 15:38 Uhr

thomas
Posts: 7716
Nutzer
@Holger:
Zitat:
Es ist nicht so, daß Assembler gleich Hardwarezugriffe und C gleich OS-Calls ist.

Das habe ich nicht gesagt. Ich habe ja weiter oben schon geschrieben, daß es in Assembler zu einfach ist, nur auf die Hardware zuzugreifen. Ein einfach Move dieses nach dort macht den Bildschirm grün. Dagegen muß man für einen OS-Zugriff viele Zeilen Code schreiben.

In C ist es umgekehrt. Ein OS-Zugriff ist einfach ein Funktionsaufruf, meistens eine Zeile und dank umfangreicher Includes braucht man sich nicht um genaue Werte zu kümmern, da man mit Namen arbeiten kann. Ein Hardware-Zugriff ist zwar ähnlich simpel wie in Assembler, jedoch muß man erst mal die Hardware-Referenz herausholen und die entsprechenden Hardwareregister nachschlagen (was man in Assembler auch macht, aber man ist das da halt gewohnt und hat die meisten im Kopf).

Gruß Thomas
--
Email: thomas-rapp@web.de
Home: thomas-rapp.homepage.t-online.de/

[ - Antworten - Zitieren - Direktlink - ]

23.01.2006, 16:09 Uhr

Schaumstofflumpi
Posts: 1292
Nutzer
Hallo Leutzzz,

was erzählt ihr da eigentlich!? Das darf doch alle snciht wahr sein!

Ich würde mir wünschen, dass heutige (moderne) Spiele auf PCs auch heute noch Assembler programmiert würden. Wennich mir ein Spiel wie UT2004 anschaue oder GTR/GTLegends dann würden die in Assembler programmiert sogar auf nem Pentium 1 ihre Runden locker drehen. Es ist doch die Spieleindustrie, die die restliche Computerindustrie miliarden an Umsatz beschert. Welcher Hahn würde denn nach nem Turborechner schreien wenns keine Spiele geben würde?! Selbst die moderne Videobearbeitung bracuht nicht mal solch Powerkisten wie die Spiele. Und die ganzen Dumpfbäckelschiss, die sich SpieleProggis nennen können ein bisserl C++ proggen und mehr nicht. Die verschwenden mit jeder Zeile Code, die sie produzieren, reine REchnerpower...aber vom allerfeinsten. Die wahren Proggerkünstler waren damals die Assembler-Ästel, die selbst aus den Spargelkisten wie den A500 Power rausgesaugt haben, die die Kisten über ihre Grenzen hinaus zu Powerrechner wurden liesen.

Also Jung...lass dir eins gesagt sein...lern Assembler und werd der Progmeister. Progge so, wie Mark Knopfler seine Gitarre mit der Zunge Spielt!!! Nur so kommst du weiter und wirst der Meister!!!

Gruß,
SChaumstoffprogger
--
<<<~~~| Schaumstofflumpi |~~~>>>


[ Dieser Beitrag wurde von Schaumstofflumpi am 23.01.2006 um 16:09 Uhr geändert. ]

[ Dieser Beitrag wurde von Schaumstofflumpi am 23.01.2006 um 16:12 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

23.01.2006, 16:34 Uhr

Mad_Dog
Posts: 1944
Nutzer
Zitat:
Original von Schaumstofflumpi:
Ich würde mir wünschen, dass heutige (moderne) Spiele auf PCs auch heute noch Assembler programmiert würden. Wennich mir ein Spiel wie UT2004 anschaue oder GTR/GTLegends dann würden die in Assembler programmiert sogar auf nem Pentium 1 ihre Runden locker drehen. Es ist doch die Spieleindustrie, die die restliche Computerindustrie miliarden an Umsatz beschert. Welcher Hahn würde denn nach nem Turborechner schreien wenns keine Spiele geben würde?!


Nunja... also bei aller Begeisterung für Assembler: Code, der in einer Hochsprache geschrieben ist, ist zum einen leserlicher, zum anderen aber auch leichter portierbar, was ja gerade in der Spieleindustrie eine Rolle spielt (PCs <-> diverse Konsolen).

Angesichts dessen, daß heutzutage jeder eine individuelle Hardware hat und man nicht von einer konstanten Hardware (wie z.B. bei Konsolen) ausgehen kann, kannst Du's glatt vergessen, in irgendwelche Hardwareregister reinzuschreiben - das geht schon beim Amiga (ECS <-> AGA) schief.


--

http://www.norman-interactive.com

[ - Antworten - Zitieren - Direktlink - ]

23.01.2006, 17:00 Uhr

bubblebobble
Posts: 707
Nutzer
@Schaumstofflumpi

Du hast <ironic> .. </ironic> vergessen.

Wenn man das letzte Quäntchen Speed auf einem A500 rauskitzeln will, braucht man natürlich Assembler, das wird hier keiner bestreiten. Aber keiner erwartet, dass das erste Spiel von ANewBie ein "Shadow of the Beast" Nachfolger wird.
Hallo!!! Er nennt sich ANewbie und hat den Thread "Will lernen Amiga Games zu proggen" genannt.
Ein Spiel wie Packman etc. lässt sich in AB2 viel einfacher schreiben, auch einfacher als in C. Ich weiss das, weil ich C, AB2 und 68K Assembler fliessend progge, und sowohl die Register eines A500 gekitzelt habe und auch High Level mit allen möglichen APIs geproggt habe.

ANewbie:
Du musst dir überlegen, ob du hardcore ASM proggen willst, aber dann brauchst du erstmal eine ganze Weile bis du überhaupt ein paar Pixel auf den Bildschirm gebracht hast. Bis du ein richtiges Spiel zusammen hast (mit Copperlisten, Scrolling, Sounds, Musik, Joysticksteuerung, Highscore usw. usw.) wird da bestimmt ein Jahr und ca. 1.000.000 Reboots ins Land gehen. (ein klitze kleiner Fehler in einem ASM Programm crashed normalerweise das System komplett).
Mit AB2 schaffst du das ca. in 2 Monaten und 1.000 Reboots. Bei C wirst du vermutlich bei der Installation des GCC scheitern.

Wenn du tatsächlich zeitkritische Dinge programmierst, dann kannst du in AB2 auch immer noch inline-ASM benutzen, also du schreibst nach einem Basic Befehl einfach in Assembler weiter, kein Problem. Und die Grundprinzipien (Double Buffering, Bitmaps etc.) bekommst du auch da mit. Aber ein komplettes Programm in ASM zu schrieben dauert viel zu lange, und die Speed braucht man auch auf einem A500 nicht, 95% der Zeit wird der A500 sowieso mit Blitten verbringen, die unabhängig von der Sprache ist. Wenn man nicht wirklich gut in Assembler ist, proggt man möglicherweise sogar langsamer als ein Compiler das kann.

Ich würde sogar so weit gehen, und dir erstmal empfehlen meine Includes anzusehen und die "dbl" API zu benutzen. Da sind bereits kleine Demo proggs dabei wo du siehst, wie man ein paar Bälle durch die Lust fliegen lässt, Collision macht etc. Das läuft zwar nicht auch einem A500, aber du lernst in etwa wie man ein Spiel proggt ohne dich mit krypitschen Register bezeichnugnen auseinandersetzen zu müssen.


--
Thilo Köhler, Author von:
HD-Rec, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, TKUnpacker
Homepage: http://www.hd-rec.de


[ - Antworten - Zitieren - Direktlink - ]

23.01.2006, 17:06 Uhr

bubblebobble
Posts: 707
Nutzer
Ach ja, zu Schaumstofflumpi:

Schon ein Spiel wie Doom oder Quake wäre in ASM undenkbar. Dafür ist ein Mensch einfach zu dumm. Man braucht für sowas gut lesbaren Code, der der Denkweise eines Menschen mehr entspricht und Tools, die einem bei der korrektheit des Codes helfen (z.B. Typencheck).
Das heisst nicht, dass man nicht einzelne Routinen in ASM proggen kann, aber doch nicht den ganzen logischen Ablauf! Das wäre so, wie eine Turnhalle mit einer Zahnbürste zu putzen. Würde man in endlicher Zeit damit tatsächlich fertig, wäre die Turnhalle zwar blitzblank, aber ein grosser Besen tuts halt auch.

Ausserdem finden in modernen Spielen die zeitkritischen Dinge sowieso in Hardware gegossen auf der Graka statt. Die CPU, die ein bisschen Mausabfrage und Koordinaten Berechnung macht, ist mehr oder weniger Nebensache.


--
Thilo Köhler, Author von:
HD-Rec, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, TKUnpacker
Homepage: http://www.hd-rec.de


[ - Antworten - Zitieren - Direktlink - ]

23.01.2006, 18:22 Uhr

Vigo
Posts: 1254
[Ex-Mitglied]
Zitat:
Original von Holger:
Zitat:
Original von Vigo:
Neee, der 68K hat keine Befehlspipeline, die beginnt erst mit dem 68010. D.h. man kann immer noch Zyklen zählen.

Der 68000 hat eine zweistufige Pipeline. Das heißt in der Praxis ja letztendlich nur, daß er den nächsten Befehl schon lesen kann, während er den aktuellen ausführt.
Das hindert Dich auch überhaupt nicht daran, Zyklen zu zählen, wenn's Dir Spaß macht, insb. weil Dir beim 68000 keine Parallelverarbeitung oder Cache-Misses in die Suppe spucken können.


Ok, so gesehen hat bereits der 6502 eine einstufige Pipeline. Worauf Ralf aber hinauswollte ist, dass diese Pipeline es schwieriger machen würde, den code zu Otimieren, was beim 68000 ja wegen den von Dir aufgeführten Gründen nicht zutrifft. Der 68010 hingegen hat eine 6 Byte grosse Pipeline, die z.B. gerade noch den folgenden code komplett beinhalten kann:

.branchloop
move.l (a0)+,(a1)+
dbra d0,.branchloop

Zitat:
Zitat:
C eignet sich dann am besten, je komplexer die Probleme werden.
Ich halte ein ernstzunehmendes Spiel durchaus für komplex genug, um auch C einzusetzen (evtl. mit Assembler-Ergänzung).

Kommt drauf an. Turrican ist mit Sicherheit nicht in C geschrieben, Monkey Island hingegen schon.

Zitat:
Aber für einen Anfänger spielt das keine so große Rolle. Der muß sowieso erst mal seine Erfahrungen sammeln und sehen wie weit man mit dem "ich will jetzt mal Spiele programmieren" Ansatz kommt.

Genau, und Erfahrungen kann man nur Sammeln, wenn man unvoreingenommen die Möglichkeiten abwägt. Schneller Erfolg, oder interessante Erfahrungen machen...

Zitat:
Zitat:
Aber die Sachen, für die ein A500 halt prädestiniert ist (bunte, flüssig scrollende 2D SPiele), da kommt man mit ASM viel weiter.
Oder dem Demomaker...

Klaro, hat natürlich dieselben Möglichkeiten....

Zitat:
Zitat:
Der A500 hat jedoch sehr viele nette Hardwarefeatures, die in einer Hochsprache entweder gar nicht oder nur rudimentär unterstützt werden. Du weisst ja gar nicht, was man z.B. mit dem Copper alles hinbekommen kann.
Das kannst Du in C auch alles machen. C iss ja auch nur geringfügig mehr als Assembler...

Sicher geht das auch in C, habe ich auch nie anders behauptet. Aber ich halte C für die Klassischen Amiga Spiele (Jump'n runs, etc) für Overkill.

Also, ANewbie, Du hast die MAcht!
--
Jeder User verdient seinen Computer.

[ Dieser Beitrag wurde von Vigo am 23.01.2006 um 18:24 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

23.01.2006, 18:44 Uhr

Vigo
Posts: 1254
[Ex-Mitglied]
Zitat:
Original von bubblebobble:
Wenn man das letzte Quäntchen Speed auf einem A500 rauskitzeln will, braucht man natürlich Assembler, das wird hier keiner bestreiten. Aber keiner erwartet, dass das erste Spiel von ANewBie ein "Shadow of the Beast" Nachfolger wird.


Nein, schon eher Jim Power! Hab erst vor kurzem rausgefunden, wie der Coder die 3. Parallax Ebene hinbekommen hat. ;)

Zitat:
Hallo!!! Er nennt sich ANewbie und hat den Thread "Will lernen Amiga Games zu proggen" genannt.

Ja, er soll lernen, wie man Games auf dem Amiga proggt, nicht, wie man so tut als würde man Games auf dem Amiga proggen. ;)

Zitat:
Ein Spiel wie Packman etc. lässt sich in AB2 viel einfacher schreiben, auch einfacher als in C. Ich weiss das, weil ich C, AB2 und 68K Assembler fliessend progge, und sowohl die Register eines A500 gekitzelt habe und auch High Level mit allen möglichen APIs geproggt habe.

Für mehr als solche Spiele kann man die ganzen BAsic Dialekte auch nicht gebrauchen. Alles andere ruckelt Gnadenlos. Gerade deshalb war ich Amos/Blitz Basic ziemlich schnell leid.

Zitat:
ANewbie:
Du musst dir überlegen, ob du hardcore ASM proggen willst, aber dann brauchst du erstmal eine ganze Weile bis du überhaupt ein paar Pixel auf den Bildschirm gebracht hast.


Mit WHDLOAD und ASM-Pro kommt man recht schnell zu brauchbaren Ergebnissen.

Zitat:
Bis du ein richtiges Spiel zusammen hast (mit Copperlisten, Scrolling, Sounds, Musik, Joysticksteuerung, Highscore usw. usw.) wird da bestimmt ein Jahr und ca. 1.000.000 Reboots ins Land gehen.

Klaro, und? Muss man immer den Weg des geringsten WIderstandes gehen?

Zitat:
(ein klitze kleiner Fehler in einem ASM Programm crashed normalerweise das System komplett).

[ironie] Was bei C Programmen natürlich überhaupt nicht der Fall ist... [/ironie]

Selbst BB2 bekommt man mit den richtigen Griffen zum Absturz.

Zitat:
Mit AB2 schaffst du das ca. in 2 Monaten und 1.000 Reboots. Bei C wirst du vermutlich bei der Installation des GCC scheitern.

Hola, DAS nenne ich jetzt mal eine nette Ermutigung von Dir! "Versuch es nicht, DU wirst eh scheitern" ;)

Zitat:
Wenn du tatsächlich zeitkritische Dinge programmierst, dann kannst du in AB2 auch immer noch inline-ASM benutzen, also du schreibst nach einem Basic Befehl einfach in Assembler weiter, kein Problem.

Du mutest unserem Lehrling auch noch zu, BASIC UND Assembler zu lernen? ;)

Zitat:
Und die Grundprinzipien (Double Buffering, Bitmaps etc.) bekommst du auch da mit. Aber ein komplettes Programm in ASM zu schrieben dauert viel zu lange, und die Speed braucht man auch auf einem A500 nicht, 95% der Zeit wird der A500 sowieso mit Blitten verbringen, die unabhängig von der Sprache ist.

Genau, und in den 5% will man nicht auch noch den restlichen Speed durch einen Basic Compiler vergeuden.

Zitat:
Wenn man nicht wirklich gut in Assembler ist, proggt man möglicherweise sogar langsamer als ein Compiler das kann.

Wieder dieses hirnrissige Argument, welches man hauptsächlich nur auf CPU's mit grossen Caches anwenden kann, aber mit Sicherheit nicht auf dem 68000er. Man muss nicht wirklich gut in Assembler sein, um bereits schnellen Code zu erzeugen. Scheisse kann man in beiden Disziplinen sein, das ist nicht wirklich ein Argument.

Zitat:
Ich würde sogar so weit gehen, und dir erstmal empfehlen meine Includes anzusehen und die "dbl" API zu benutzen. Da sind bereits kleine Demo proggs dabei wo du siehst, wie man ein paar Bälle durch die Lust fliegen lässt, Collision macht etc. Das läuft zwar nicht auch einem A500, aber du lernst in etwa wie man ein Spiel proggt ohne dich mit krypitschen Register bezeichnugnen auseinandersetzen zu müssen.

Yeah, go my way, or the HIGHWAY! ;)

Wie gesagt ANewbie, lass Dich nicht einschüchtern. Die meisten Leute, die so eifrig dagegenwettern, denken, Assembler wäre eine hohe Geiteskunst. Ich z.B. habe bereits damit angefangen, da war ich 5 Jahre jünger als Du jetzt. Was ein Jugendlicher kann, das kannst Du auch.
--
Jeder User verdient seinen Computer.

[ Dieser Beitrag wurde von Vigo am 23.01.2006 um 18:46 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

23.01.2006, 18:54 Uhr

bubblebobble
Posts: 707
Nutzer
Jetzt mal ehrlich:
Ein Titelscreen, Highscore oder Options Menu in ASM ist doch völlig übertrieben. Da braucht man nicht das letzte % an Speed. Ist ja auch nicht so dass C oder AB2 langsam wäre. Nur bei zeitkritischen kleinen Loops kann man durch ASM was rausholen, wenn man z.B. einen 3D Sternen Himmel proggt oder soetwas.

Toadies z.B. ist in AB2 geschrieben, und käme so in etwa dem Nahe was
NewBie vermutlich machen will. Ein bisschen Smooth Scrolling, Explosionen, ein paar Objekte.

Mit ASM ist die Wahrscheinlichkeit auch sehr hoch, dass das Spiel einfach nie fertig wird. Sobald es etwas komplexer wird ist man mit ASM einfach sehr langsam im Implementieren, und jede Änderung verursacht Kopfschmerzen. Genau deshalb gibt es ja Hochsprachen, um das in den Griff zu bekommen.

Ein kleines Beispiel zur Abschreckung:

Zuerst der Basic Code, und dann genau das Gleiche in ASM,
aber von Hand optimiert. Der ASM Code ist etwa 2x schneller,
aber hat etwa 100mal so lange gedauert zu coden. Und ich muss
dazu sagen, dass der Basic code ziemlich unübersichtlich ist,
das war eines meiner ersten Spiele.

Sternenhimmel in Basic
code:
For n=0 To staranz-1
    If starVisible(n) Then Plot starX(n),starY(n),0:starVisible(n)=False
    starX(n) = yo+starYS(n)
    If starY(n)>yoffset
      starX(n) = ((starXS(n)-xo) MOD ScreenWidth) + xoffset
      If Point (starX(n),starY(n)) = 0 Then Plot starX(n),starY(n),starColor(n):starVisible(n)=True
    End If
Next


Genau das Gleiche in handoptimiertem ASM
code:
GetReg d2,staranz-1
GetReg d0,z
GetReg d1,bz
GetReg d3,xoffset
GetReg d4,yoffset

MOVEM.l a0-a6/d5-d7,-(a7)
MOVE.l  d1,a6
ADDA.l  #8,a6
MOVE.l  (a6)+,a0
MOVE.l  (a6)+,a1
MOVE.l  (a6)+,a2
MOVE.l  (a6)+,a3
MOVE.l  d0,a5
MOVE.l  16(a5),a6
MOVE.l  8(a5),a4
MOVE.l  12(a5),a5
MOVE.w  d2,xbb0
MOVEQ   #0,d7
xbb1:
TST.b   (a6)+
BEQ     xbb2
MOVE.w  0(a4,d7.w),d5
MOVE.w  0(a5,d7.w),d6
BCLR    d6,0(a0,d5.w)
BCLR    d6,0(a1,d5.w)
BCLR    d6,0(a2,d5.w)
BCLR    d6,0(a3,d5.w)
xbb2:
ADD.w   #2,d7
DBF     d2,xbb1
MOVE.l  d1,a6
MOVE.l  d0,a5
MOVE.l  0(a5),a0
MOVE.l  4(a5),a1
MOVE.l  8(a5),a2
MOVE.l  12(a5),a3
MOVE.l  16(a5),a4
MOVE.w  xbb0,d2
MOVE.w  d3,d5
MOVE.w  d4,d6
LSR.w   #1,d5
LSR.w   #1,d6
xbb17:
MOVE.w  (a0)+,d0
MOVE.w  (a1)+,d1
xbb4:
CMP.w   d5,d0
BGE     xbb16
ADD.w   #320,d0
BRA     xbb4
xbb16:
SUB.w   d5,d0
ADD.w   d6,d1
DIVU    #320,d0
SWAP    d0
AND.l   #$FFFF,d0
ADD.w   d3,d0
MOVE.b  #1,(a4)+
MOVE.w  d0,d7
NOT.w   d7
AND.w   #7,d7
MOVE.w  d7,(a3)+
LSR.w   #3,d0
MULU    0(a6),d1
ADD.w   d0,d1
MOVE.w  d1,(a2)+
DBF     d2,xbb17
MOVE.l  a6,d1
ADDA.l  #8,a6
MOVE.l  (a6)+,a0
MOVE.l  (a6)+,a1
MOVE.l  (a6)+,a2
MOVE.l  (a6)+,a3
MOVE.l  (a6)+,a4
MOVE.l  a5,d0
MOVE.l  12(a5),-(a7)
MOVE.l  8(a5),-(a7)
MOVE.l  16(a5),a5
MOVE.w  xbb0,d2
MOVEQ   #0,d7
xbb3:
TST.b   (a5)+
BEQ     xbb5
MOVE.l  (a7),a6
MOVE.w  0(a6,d7.w),d5
MOVE.l  4(a7),a6
MOVE.w  0(a6,d7.w),d6
BTST    d6,0(a4,d5.w)
BNE     xbb14
BTST    d6,0(a3,d5.w)
BNE     xbb14
BTST    d6,0(a2,d5.w)
BNE     xbb14
BTST    d6,0(a1,d5.w)
BNE     xbb14
BTST    d6,0(a0,d5.w)
BNE     xbb14
BRA     xbb5
xbb14:
CLR.b   -1(a5)
xbb5:
ADD.w   #2,d7
DBF     d2,xbb3
ADDA.l  #8,a7
MOVE.l  d1,a6
ADDA.l  #8,a6
MOVE.l  (a6)+,a0
MOVE.l  (a6)+,a1
MOVE.l  (a6)+,a2
MOVE.l  (a6)+,a3
MOVE.l  d0,a5
MOVE.l  16(a5),a6
MOVE.l  12(a5),-(a7)
MOVE.l  8(a5),-(a7)
MOVE.l  20(a5),a5
MOVE.w  xbb0,d2
MOVEQ   #0,d7
xbb15:
TST.b   (a6)+
BEQ     xbb21
MOVE.l  (a7),a4
MOVE.w  0(a4,d7.w),d5
MOVE.l  4(a7),a4
MOVE.w  0(a4,d7.w),d6
TST.b   (a5)+
BNE     xbb13
BCLR    d6,0(a3,d5.w)
BRA     xbb6
xbb13:
BSET    d6,0(a3,d5.w)
xbb6:
TST.b   (a5)+
BNE     xbb11
BCLR    d6,0(a2,d5.w)
BRA     xbb8
xbb11:
BSET    d6,0(a2,d5.w)
xbb8:
TST.b   (a5)+
BNE     xbb12
BCLR    d6,0(a1,d5.w)
BRA     xbb7
xbb12:
BSET    d6,0(a1,d5.w)
xbb7:
TST.b   (a5)+
BNE     xbb10
BCLR    d6,0(a0,d5.w)
BRA     xbb9
xbb10:
BSET    d6,0(a0,d5.w)
xbb9:
BRA     xbb20
xbb21:
ADDA.l  #4,a5
xbb20:
ADD.w   #2,d7
DBF     d2,xbb15
ADDA.l  #8,a7
MOVEM.l (a7)+,a0-a6/d5-d7


--
Thilo Köhler, Author von:
HD-Rec, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, TKUnpacker
Homepage: http://www.hd-rec.de


[ - Antworten - Zitieren - Direktlink - ]

23.01.2006, 19:03 Uhr

Holger
Posts: 8116
Nutzer
Nu laßt ANewbie doch auch mal die Chance zu sagen, was er ihm denn nun wirklich vorschwebt. Dann läßt sich auch sinnvolles zu der empfohlenen Programmiersprache sagen.

mfg
--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

23.01.2006, 19:08 Uhr

bruZard
Posts: 307
Nutzer
Zitat:
Zitat:
Ein Spiel wie Packman etc. lässt sich in AB2 viel einfacher schreiben, auch einfacher als in C. Ich weiss das, weil ich C, AB2 und 68K Assembler fliessend progge, und sowohl die Register eines A500 gekitzelt habe und auch High Level mit allen möglichen APIs geproggt habe.


Für mehr als solche Spiele kann man die ganzen BAsic Dialekte auch nicht gebrauchen. Alles andere ruckelt Gnadenlos. Gerade deshalb war ich Amos/Blitz Basic ziemlich schnell leid.


Womit mir klar ist dass Du ein zeimlich mieser Coder sein musst. Selbst ein Speedball oder ChaosEngine lässt sich flüssig mit BB2 auf einem A500 realisieren.

--
Wer glaubt dass Volksvertreter das Volk vertreten, der glaubt auch dass Zitronenfalter Zitronen falten

[ - Antworten - Zitieren - Direktlink - ]

23.01.2006, 19:24 Uhr

Vigo
Posts: 1254
[Ex-Mitglied]
Zitat:
Original von bubblebobble:
Jetzt mal ehrlich:
Ein Titelscreen, Highscore oder Options Menu in ASM ist doch völlig übertrieben.


Die meisten Amiga Games sind so geschrieben, haben wohl ein Grossteil der professionellen Spieleentwickler wohl einen an der Klatsche für Dich. Was daran völlig übertrieben sein soll, will mir nicht in den Kopf, da es mal wieder suggeriert, dass Assembler schwerer ist, was ich definitiv nicht unterschreibe.

Zitat:
Da braucht man nicht das letzte % an Speed. Ist ja auch nicht so dass C oder AB2 langsam wäre. Nur bei zeitkritischen kleinen Loops kann man durch ASM was rausholen, wenn man z.B. einen 3D Sternen Himmel proggt oder soetwas.

Was ist denn an einem Spiel, wo sich ständig Objekte bewegen und der Bildschirm scrollt nicht zeitkritisch?

Zitat:
Mit ASM ist die Wahrscheinlichkeit auch sehr hoch, dass das Spiel einfach nie fertig wird. Sobald es etwas komplexer wird ist man mit ASM einfach sehr langsam im Implementieren, und jede Änderung verursacht Kopfschmerzen. Genau deshalb gibt es ja Hochsprachen, um das in den Griff zu bekommen.

Ob ein Spiel fertig wird oder nicht hängt in erster Linie von der Motivation und dem Willen des Programmierers ab. Manchmal ist aber einfach nur der Weg das Ziel.

Zitat:
Ein kleines Beispiel zur Abschreckung:

Darum geht es ja, den Jungen vom bösen Assembler wegzujagen... Geht leicht mit undokumentierten Code. ;)

Zitat:
Zuerst der Basic Code, und dann genau das Gleiche in ASM,
aber von Hand optimiert. Der ASM Code ist etwa 2x schneller,
aber hat etwa 100mal so lange gedauert zu coden. Und ich muss
dazu sagen, dass der Basic code ziemlich unübersichtlich ist,
das war eines meiner ersten Spiele.


Du hast die Möglichkeiten der Amiga Hardware nicht genutzt. Der ASM Code wäre um ->einiges<- schneller, wenn Du anstatt einer Kopie des Basic Codes lieber die Möglichkeiten des Amigas genutzt hättest. Z.B. hättest Du ein 1 Pixel breites Sprite mit dem Copper gleichmäßig über den ganzen Bildschirm verteilen können. Dafür musst Du noch nicht einmal die Sprite DMA einschalten, schreib einfach Deine Grafikdaten in SPR0DATA und SPR0DATB rein. Nimm ein 16 Pixel 16 Farben Sprite, dann sieht es erstens schick aus und zweitens kommt dann Deine Basic Routine nicht mehr ansatzweise mit dem ASM code mit, da Du jetzt 16 Farben plotten musst (ihhhhhh ;) ).

Du siehst, man kann sehr schnell ein Beispiel so modifizieren, das Assembler haushoch gewinnen wird.
--
Jeder User verdient seinen Computer.

[ Dieser Beitrag wurde von Vigo am 23.01.2006 um 19:32 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

23.01.2006, 19:26 Uhr

Vigo
Posts: 1254
[Ex-Mitglied]
Zitat:
Original von bruZard:
Zitat:
Zitat:
Ein Spiel wie Packman etc. lässt sich in AB2 viel einfacher schreiben, auch einfacher als in C. Ich weiss das, weil ich C, AB2 und 68K Assembler fliessend progge, und sowohl die Register eines A500 gekitzelt habe und auch High Level mit allen möglichen APIs geproggt habe.


Für mehr als solche Spiele kann man die ganzen BAsic Dialekte auch nicht gebrauchen. Alles andere ruckelt Gnadenlos. Gerade deshalb war ich Amos/Blitz Basic ziemlich schnell leid.


Womit mir klar ist dass Du ein zeimlich mieser Coder sein musst. Selbst ein Speedball oder ChaosEngine lässt sich flüssig mit BB2 auf einem A500 realisieren.


Fragt sich, was Du als Flüssig ansiehst. Selbst die oben zitierten originale Laufen nicht flüssig (25fps). Die meisten Bitmap Brothers Spiele sind nämlich Atari ST Code Konvertierungen (und selbst Dir sollte sagen, was das bedeutet). Du weißt, aus welchem Lager AMOS kommt... ;)

Angesichts der Tatsache kann ich es GERADE NOCH verkraften, wenn DU mich als miesen Coder bezeichnest... ;)
--
Jeder User verdient seinen Computer.

[ Dieser Beitrag wurde von Vigo am 23.01.2006 um 19:34 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

23.01.2006, 20:11 Uhr

bubblebobble
Posts: 707
Nutzer
Zitat:
Die meisten Amiga Games sind so geschrieben, haben wohl ein Grossteil der professionellen Spieleentwickler wohl einen an der Klatsche für Dich. Was daran völlig übertrieben sein soll, will mir nicht in den Kopf, da es mal wieder suggeriert, dass Assembler schwerer ist, was ich definitiv nicht unterschreibe.
Am Anfang gabs ja nicht viel besseres. Später hat man schon andere Sprachen benutzt, z.B. Gloom, Worms und Skidmark sind in Blitzbasic geschrieben. Weiss nicht ob solche Spiele in ASM einfacher gewesen wären...

Zitat:
Was ist denn an einem Spiel, wo sich ständig Objekte bewegen und der Bildschirm scrollt nicht zeitkritisch?
Scrollen ist ja nur Pointer verbiegen auf dem Chipset, die Koordinaten berechnung von Objekten geht auch flink. Wie gesagt, die meiste Zeit wird beim Blitten verbraten, und das ist unabhängig von der Sprache. Mag sein, dass die Spiel-Logik in Basic 2x langsamer ist, dann ist der Overhead eben 10% statt 5%. Wenn man dafür aber deutlich schneller ans Ziel kommt ist das legitim. Dafür kann man dann dem Spiel mehr Features verpassen.

Zitat:
Mit ASM ist die Wahrscheinlichkeit auch sehr hoch, dass das Spiel einfach nie fertig wird. Sobald es etwas komplexer wird ist man mit ASM einfach sehr langsam im Implementieren, und jede Änderung verursacht Kopfschmerzen. Genau deshalb gibt es ja Hochsprachen, um das in den Griff zu bekommen.

Ob ein Spiel fertig wird oder nicht hängt in erster Linie von der Motivation und dem Willen des Programmierers ab. Manchmal ist aber einfach nur der Weg das Ziel.

ASM Coden macht die sache aber nicht unbedingt leichter...

Zitat:
Zitat:
Ein kleines Beispiel zur Abschreckung:

Darum geht es ja, den Jungen vom bösen Assembler wegzujagen... Geht leicht mit undokumentierten Code. ;)

Ich will nur zeigen, was ihn erwartet.
Das Sterne verschieben ist ziemlich simpel, x = x + xs. Aber in ASM artet das immer in eine Move, Add etc. Orgie aus.

Zitat:
Zitat:
Zuerst der Basic Code, und dann genau das Gleiche in ASM,
aber von Hand optimiert. Der ASM Code ist etwa 2x schneller,
aber hat etwa 100mal so lange gedauert zu coden. Und ich muss
dazu sagen, dass der Basic code ziemlich unübersichtlich ist,
das war eines meiner ersten Spiele.


Du hast die Möglichkeiten der Amiga Hardware nicht genutzt. Der ASM

Ein bisschen schon, dadruch dass ich nicht alle Bitplanes tatsächlich setze. Mit sprites wäre das schwierig geworden, weil ich die schon für den Mauspfeil und eine zwei-ziffern Anzeige genutzt habe, ausserdem müssen die Sterne HINTER der Landschaft fliegen, und sie tun das auch in mehreren Ebenen/Geschwindigkeiten.

Zitat:
Code wäre um ->einiges<- schneller, wenn Du anstatt einer Kopie des Basic Codes lieber die Möglichkeiten des Amigas genutzt hättest. Z.B. hättest Du ein 1 Pixel breites Sprite mit dem Copper gleichmäßig über den ganzen Bildschirm verteilen können.
Ok, aber ein Anfänger wird sowas erstmal kaum ausnutzen. Ausserdem kann man das auch von AB2 aus bequem tun. Ich wollte mit meinem Beispiel nur zeigen, wie ASM ausartet, wenn man das gleiche tut, nur
eben etwas optimierter. Eine Copperlist erzeugen ist in AB2 nur ein Befehl (InitCopperList), aber das ist eine völlig andere Idee den Sternenhimmel zu realisieren, und man will ja nicht Äpfel mit Birnen vergleichen.
Wie auch immer, wenn es schnell sein muss hat man ja auch unter AB2 die Möglichkeit, in ASM zu coden. Aber man muss es nicht, gerade bei so Dingen wie IFF Bilder laden, Highscore saven etc. erspart man sich da jede Menge Kopfschmerzen. Wie man einen Amiga proggt, lernt man bei AB2 auch, da es doch noch recht system nah ist. Falls man den Drang verspürt, ASM zu proggen kann man das ja "weich" anfangen mit inline ASM.

Zitat:
Du siehst, man kann sehr schnell ein Beispiel so modifizieren, das Assembler haushoch gewinnen wird.
Nur, dass der Sternenhimmel auch in Basic nicht viel Zeit braucht, vielleicht 2-4%. Das weiter zu optimieren bringt also in der Realität so gut wie nix. Die Speed wird vom Blitter gefressen bei solchen Spielen, und da kann man nix machen. Spielchen mit Copper und Sprites kann man auch in AB2 machen. AB2 ist in diesem Punkt deutlich anders als andere Basic Dialekte.



--
Thilo Köhler, Author von:
HD-Rec, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, TKUnpacker
Homepage: http://www.hd-rec.de


[ - Antworten - Zitieren - Direktlink - ]

23.01.2006, 20:45 Uhr

Vigo
Posts: 1254
[Ex-Mitglied]
Zitat:
Original von bubblebobble:
Zitat:
Die meisten Amiga Games sind so geschrieben, haben wohl ein Grossteil der professionellen Spieleentwickler wohl einen an der Klatsche für Dich. Was daran völlig übertrieben sein soll, will mir nicht in den Kopf, da es mal wieder suggeriert, dass Assembler schwerer ist, was ich definitiv nicht unterschreibe.
Am Anfang gabs ja nicht viel besseres. Später hat man schon andere Sprachen benutzt, z.B. Gloom, Worms und Skidmark sind in Blitzbasic geschrieben. Weiss nicht ob solche Spiele in ASM einfacher gewesen wären...

Woher weisst Du, dass diese Spiele nicht aus Tonnen von inline Asm Routinen stammen? Solche Spiele wie Gloom schaffst Du nicht in Basic alleine, den Basic Compiler hat man als solides Grundgerüst für den ASM code verwendet.

Zitat:
Was ist denn an einem Spiel, wo sich ständig Objekte bewegen und der Bildschirm scrollt nicht zeitkritisch?
Scrollen ist ja nur Pointer verbiegen auf dem Chipset, die Koordinaten berechnung von Objekten geht auch flink. Wie gesagt, die meiste Zeit wird beim Blitten verbraten, und das ist unabhängig von der Sprache. Mag sein, dass die Spiel-Logik in Basic 2x langsamer ist, dann ist der Overhead eben 10% statt 5%. Wenn man dafür aber deutlich schneller ans Ziel kommt ist das legitim. Dafür kann man dann dem Spiel mehr Features verpassen.
[/quote]

Wieso soll man dem Spiel mehr Features in Basic verpassen können, als in ASM? Ich bin der Meinung, dass die Schwierigkeit von 68K ASM sehr überbewertet wird.

Zitat:
ASM Coden macht die sache aber nicht unbedingt leichter...

Ja, aber ich finde, man bekommt dafür jedoch mehr Freiheiten.

Zitat:
Zitat:
Zitat:
Ein kleines Beispiel zur Abschreckung:

Darum geht es ja, den Jungen vom bösen Assembler wegzujagen... Geht leicht mit undokumentierten Code. ;)

Ich will nur zeigen, was ihn erwartet.
Das Sterne verschieben ist ziemlich simpel, x = x + xs. Aber in ASM artet das immer in eine Move, Add etc. Orgie aus.


Das ist der Basic Code ja auch, bloss halt in einer Schleife gewickelt.

Zitat:
Zitat:
Du hast die Möglichkeiten der Amiga Hardware nicht genutzt. Der ASM
Ein bisschen schon, dadruch dass ich nicht alle Bitplanes tatsächlich setze. Mit sprites wäre das schwierig geworden, weil ich die schon für den Mauspfeil und eine zwei-ziffern Anzeige genutzt habe, ausserdem müssen die Sterne HINTER der Landschaft fliegen, und sie tun das auch in mehreren Ebenen/Geschwindigkeiten.

Hinter der Landschaft: Sprite Priorität richtig setzen.
Mehrere Ebenen: X-Koordinaten in der Copperliste mit versch. Geschwindigkeiten manipulieren.

Brauchst Du wirklich alle 8 Sprites für die Mouse / 2 Ziffern Anzeige? Ansonsten verwende die Sprites einfach ab der Rasterline, wo die Ziffern Anzeige aufhört.

Zitat:
Ok, aber ein Anfänger wird sowas erstmal kaum ausnutzen.

Wohl nicht, aber er hat zumindestens die Möglichkeit, es zu tun. Man kommt, wenn man Hardwraenah programmiert, jedoch schneller auf solche Tricks.

Zitat:
Ausserdem kann man das auch von AB2 aus bequem tun. Ich wollte mit meinem Beispiel nur zeigen, wie ASM ausartet, wenn man das gleiche tut, nur eben etwas optimierter.

Nur weil der Code länger geschrieben ist, heißt es nicht unbedingt, dass er größer oder schwerer zu verstehen ist.

Zitat:
Eine Copperlist erzeugen ist in AB2 nur ein Befehl (InitCopperList), aber das ist eine völlig andere Idee den Sternenhimmel zu realisieren, und man will ja nicht Äpfel mit Birnen vergleichen.

Warum Äpfel-Birnen Vergleiche, wenn das Resultat genau so aussieht, nur viel weniger Rechenzeit erfordert?

Zitat:
Zitat:
Du siehst, man kann sehr schnell ein Beispiel so modifizieren, das Assembler haushoch gewinnen wird.
Nur, dass der Sternenhimmel auch in Basic nicht viel Zeit braucht, vielleicht 2-4%. Das weiter zu optimieren bringt also in der Realität so gut wie nix.

Dann erweitere mal Deine Sterne auf 16 Farben, und versuche sie, hinter der Vordergrundgrafik zu Blitten. Das steiert die Rechenzeit bei Deinem Beispiel enorm, währen man bei Sprites immer noch soviel Rechenzeit wie vorher benötigt. Das meinte ich damit, das man mit geschickter Hardwareprogrammierung viel mehr rausholen kann. Manchmal muss man halt die Möglichkeiten sehen, die sich einem offerieren. Das Super Beispiel in dem Zusammenhang ist immer noch Jim Power...

Zitat:
Die Speed wird vom Blitter gefressen bei solchen Spielen, und da kann man nix machen.

Es hängt bereits viel davon ab, WIE man den Blitter benutzt. Brauche ich immer alle 4 Kanäle? Muss ich alle Bitplanes blitten? Wie kann man die Sourcen am besten verknüpfen?

Zitat:
Spielchen mit Copper und Sprites kann man auch in AB2 machen. AB2 ist in diesem Punkt deutlich anders als andere Basic Dialekte.

Gut, sehe ich ein. Trotzdem bin ich der Meinung, dass Assembler nicht unbedingt schwieriger ist.

Einigen wir uns auf AB2 mit ner genzen Menge inline ASM?

--
Jeder User verdient seinen Computer.

[ - Antworten - Zitieren - Direktlink - ]

23.01.2006, 22:35 Uhr

bubblebobble
Posts: 707
Nutzer
>>Einigen wir uns auf AB2 mit ner genzen Menge inline ASM?
Haha, na gut.

--
Thilo Köhler, Author von:
HD-Rec, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, TKUnpacker
Homepage: http://www.hd-rec.de


[ - Antworten - Zitieren - Direktlink - ]

23.01.2006, 22:35 Uhr

Palgucker
Posts: 1342
Nutzer
@ ANewbie

Vielleich hilft diese Einführung
in Assembler dir erstmal, um überhaupt zu überblicken, auf was du dich da einlässt.
Die Beispiele lassen sich gut mit ASMPro assemblieren, auch wenn dieser oft an Labels herumnörgelt, da dieser auf Gross und Kleinschreibung unterscheidet. Ach ja, ein paar Bitmaps fehlen auch - aber für einen Einsteiger durchaus interessant.

mfg Palgucker

[ - Antworten - Zitieren - Direktlink - ]

24.01.2006, 16:44 Uhr

bruZard
Posts: 307
Nutzer
Zitat:
Fragt sich, was Du als Flüssig ansiehst. Selbst die oben zitierten originale Laufen nicht flüssig (25fps).

Den Wert hast Du woher? Ich empfand die genannten Games immer als absolut flüssig, erst CE2-AGA hat auf einem Standard 1200er geruckelt wie die wilde Wurst.

--
Wer glaubt dass Volksvertreter das Volk vertreten, der glaubt auch dass Zitronenfalter Zitronen falten

[ - Antworten - Zitieren - Direktlink - ]

24.01.2006, 17:25 Uhr

Vigo
Posts: 1254
[Ex-Mitglied]
Zitat:
Original von bruZard:
Zitat:
Fragt sich, was Du als Flüssig ansiehst. Selbst die oben zitierten originale Laufen nicht flüssig (25fps).

Den Wert hast Du woher? Ich empfand die genannten Games immer als absolut flüssig, erst CE2-AGA hat auf einem Standard 1200er geruckelt wie die wilde Wurst.


Ich weiss ja nicht, wie schwierig das für Andere ist, aber ich kann 25fps Scrolling problemlos mit bloßem Auge von 50fps Scrolling unterscheiden. Wenn Du mir nicht glaubst: mach mit WinUAE einen Film (50fps), und Du wirst sehen, dass sich nur jedes 2. Bild unterscheidet. Und so verhält sich das mit JEDEM Bitmap Brothers Spiel (Xenon, Speedball, Xenon II, Speedball 2, Gods, Magic Pockets, Chaos Engine). Die Spiele sind zwar schön designed, aber technisch sind sie Atari ST Konvertierungen (laufen sogar nur in 16 Farben). Erst ab GODS (woohooo, eine Copperliste im Hintergrund!), hat man so langsam damit begonnen, den Amiga etwas zu nutzen, das Ruckelscrolling blieb jedoch immer.

Unter dem ST Syndrom leiden übrigens sehr viele Spiele, die vor 1989/90 geschrieben wurden.
--
Jeder User verdient seinen Computer.

[ Dieser Beitrag wurde von Vigo am 24.01.2006 um 17:28 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

24.01.2006, 17:26 Uhr

Vigo
Posts: 1254
[Ex-Mitglied]
doppelpost

[ Dieser Beitrag wurde von Vigo am 24.01.2006 um 17:27 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]


1 -2- 3 [ - Beitrag schreiben - ]


amiga-news.de Forum > Programmierung > Will lernen Amiga Games zu proggen [ - Suche - Neue Beiträge - Registrieren - Login - ]


.
Impressum | Datenschutzerklärung | Netiquette | Werbung | Kontakt
Copyright © 1998-2024 by amiga-news.de - alle Rechte vorbehalten.
.