|
DEUTSCHE VERSION |
|
 |
| Links | | | Forums | | | Comments | | | Report news |
|
| Chat | | | Polls | | | Newsticker | | | Archive |
|
| amiga-news.de Forum > Programmierung > Will lernen Amiga Games zu proggen | [ - Search - New posts - Register - Login - ] |
| 1 -2- 3 | [ - Post reply - ] |
|
2006-01-23, 13:30 h Vigo Posts: 1254 [Former member] |
Zitat: Ahem, was für einen Unsinn denn? Dass man durch Assembler durchaus sinnvolle Erfahrungen machen kann, wie ein Rechnersystem aufgebaut ist? Zitat: 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: 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: 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. ] [ - Answer - Quote - Direct link - ] |
|
2006-01-23, 13:47 h bruZard Posts: 307 User |
Zitat: Weil die Fragestellung explizit auf einen Amiga500 abziehlt und mit keiner Silbe nach Deinen persönlichen Vorlieben für Wintel PCs gefragt wird. [ - Answer - Quote - Direct link - ] |
|
2006-01-23, 13:54 h Vigo Posts: 1254 [Former member] |
Zitat: 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. ] [ - Answer - Quote - Direct link - ] |
|
2006-01-23, 14:12 h Mad_Dog Posts: 1944 User |
@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 [ - Answer - Quote - Direct link - ] |
|
2006-01-23, 14:13 h thomas Posts: 7721 User |
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/ [ - Answer - Quote - Direct link - ] |
|
2006-01-23, 14:16 h Mad_Dog Posts: 1944 User |
Zitat: 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 [ - Answer - Quote - Direct link - ] |
|
2006-01-23, 14:25 h Vigo Posts: 1254 [Former member] |
Zitat: 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: 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: 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: 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. [ - Answer - Quote - Direct link - ] |
|
2006-01-23, 14:30 h thomas Posts: 7721 User |
Zitat: 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/ [ - Answer - Quote - Direct link - ] |
|
2006-01-23, 14:32 h Vigo Posts: 1254 [Former member] |
Wie gesagt: WHDLOAD benutzen! Das geht sehr einfach. -- Jeder User verdient seinen Computer. [ - Answer - Quote - Direct link - ] |
|
2006-01-23, 14:45 h Holger Posts: 8116 User |
Zitat: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: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:Oder dem Demomaker... Zitat: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. [ - Answer - Quote - Direct link - ] |
|
2006-01-23, 15:21 h Holger Posts: 8116 User |
Zitat: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: 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. [ - Answer - Quote - Direct link - ] |
|
2006-01-23, 15:38 h thomas Posts: 7721 User |
@Holger:Zitat: 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/ [ - Answer - Quote - Direct link - ] |
|
2006-01-23, 16:09 h Schaumstofflumpi Posts: 1292 User |
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. ] [ - Answer - Quote - Direct link - ] |
|
2006-01-23, 16:34 h Mad_Dog Posts: 1944 User |
Zitat: 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 [ - Answer - Quote - Direct link - ] |
|
2006-01-23, 17:00 h bubblebobble Posts: 707 User |
@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 [ - Answer - Quote - Direct link - ] |
|
2006-01-23, 17:06 h bubblebobble Posts: 707 User |
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 [ - Answer - Quote - Direct link - ] |
|
2006-01-23, 18:22 h Vigo Posts: 1254 [Former member] |
Zitat: 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: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: Genau, und Erfahrungen kann man nur Sammeln, wenn man unvoreingenommen die Möglichkeiten abwägt. Schneller Erfolg, oder interessante Erfahrungen machen... Zitat:Zitat:Oder dem Demomaker... Klaro, hat natürlich dieselben Möglichkeiten.... Zitat:Zitat: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. ] [ - Answer - Quote - Direct link - ] |
|
2006-01-23, 18:44 h Vigo Posts: 1254 [Former member] |
Zitat: Nein, schon eher Jim Power! Hab erst vor kurzem rausgefunden, wie der Coder die 3. Parallax Ebene hinbekommen hat. Zitat: 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: 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: Mit WHDLOAD und ASM-Pro kommt man recht schnell zu brauchbaren Ergebnissen. Zitat: Klaro, und? Muss man immer den Weg des geringsten WIderstandes gehen? Zitat: [ironie] Was bei C Programmen natürlich überhaupt nicht der Fall ist... [/ironie] Selbst BB2 bekommt man mit den richtigen Griffen zum Absturz. Zitat: Hola, DAS nenne ich jetzt mal eine nette Ermutigung von Dir! "Versuch es nicht, DU wirst eh scheitern" Zitat: Du mutest unserem Lehrling auch noch zu, BASIC UND Assembler zu lernen? Zitat: Genau, und in den 5% will man nicht auch noch den restlichen Speed durch einen Basic Compiler vergeuden. Zitat: 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: 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. ] [ - Answer - Quote - Direct link - ] |
|
2006-01-23, 18:54 h bubblebobble Posts: 707 User |
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: 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 [ - Answer - Quote - Direct link - ] |
|
2006-01-23, 19:03 h Holger Posts: 8116 User |
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. [ - Answer - Quote - Direct link - ] |
|
2006-01-23, 19:08 h bruZard Posts: 307 User |
Zitat:Zitat: 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 [ - Answer - Quote - Direct link - ] |
|
2006-01-23, 19:24 h Vigo Posts: 1254 [Former member] |
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. Zitat: Was ist denn an einem Spiel, wo sich ständig Objekte bewegen und der Bildschirm scrollt nicht zeitkritisch? Zitat: 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: Darum geht es ja, den Jungen vom bösen Assembler wegzujagen... Geht leicht mit undokumentierten Code. Zitat: 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. ] [ - Answer - Quote - Direct link - ] |
|
2006-01-23, 19:26 h Vigo Posts: 1254 [Former member] |
Zitat: 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. ] [ - Answer - Quote - Direct link - ] |
|
2006-01-23, 20:11 h bubblebobble Posts: 707 User |
Zitat: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: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:ASM Coden macht die sache aber nicht unbedingt leichter... Zitat:Ich will nur zeigen, was ihn erwartet.Zitat: Das Sterne verschieben ist ziemlich simpel, x = x + xs. Aber in ASM artet das immer in eine Move, Add etc. Orgie aus. Zitat: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: Zitat: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: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 [ - Answer - Quote - Direct link - ] |
|
2006-01-23, 20:45 h Vigo Posts: 1254 [Former member] |
Zitat: 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: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: Ja, aber ich finde, man bekommt dafür jedoch mehr Freiheiten. Zitat:Zitat:Ich will nur zeigen, was ihn erwartet.Zitat: Das ist der Basic Code ja auch, bloss halt in einer Schleife gewickelt. Zitat:Zitat: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: Wohl nicht, aber er hat zumindestens die Möglichkeit, es zu tun. Man kommt, wenn man Hardwraenah programmiert, jedoch schneller auf solche Tricks. Zitat: Nur weil der Code länger geschrieben ist, heißt es nicht unbedingt, dass er größer oder schwerer zu verstehen ist. Zitat: Warum Äpfel-Birnen Vergleiche, wenn das Resultat genau so aussieht, nur viel weniger Rechenzeit erfordert? Zitat:Zitat: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: 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: 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. [ - Answer - Quote - Direct link - ] |
|
2006-01-23, 22:35 h bubblebobble Posts: 707 User |
>>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 [ - Answer - Quote - Direct link - ] |
|
2006-01-23, 22:35 h Palgucker Posts: 1342 User |
@ 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 [ - Answer - Quote - Direct link - ] |
|
2006-01-24, 16:44 h bruZard Posts: 307 User |
Zitat: 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 [ - Answer - Quote - Direct link - ] |
|
2006-01-24, 17:25 h Vigo Posts: 1254 [Former member] |
Zitat: 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. ] [ - Answer - Quote - Direct link - ] |
|
2006-01-24, 17:26 h Vigo Posts: 1254 [Former member] |
doppelpost [ Dieser Beitrag wurde von Vigo am 24.01.2006 um 17:27 Uhr geändert. ] [ - Answer - Quote - Direct link - ] |
| 1 -2- 3 | [ - Post reply - ] |
| amiga-news.de Forum > Programmierung > Will lernen Amiga Games zu proggen | [ - Search - New posts - Register - Login - ] |
|
|
Masthead |
Privacy policy |
Netiquette |
Advertising |
Contact
Copyright © 1998-2025 by amiga-news.de - all rights reserved. |
|