Zitat:

---

Original von Vigo:
Hätte man diesen Thread nicht lieber "Wer hat den längsten..." nennen sollen?

Iss ja schon gut....

---

Besser is das

Wenn, dann hätte sowieso ich...

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

Zitat:

---

Original von NoImag:
@whose:

Und ich dachte schon, die ersten A1000-Benutzer haben uns inzwischen alle verlassen. Es gibt also doch noch welche.

---

Hm, den Wahnsinns-"Phoenix"-Thread schon vergessen?

Ich gehöre da aber nicht zu, ich hab die Kiste original gelassen. Nach 20 Jahren sollte man der Gutsten den Altenteil gönnen und sie ab und an mal etwas "ausführen". Fürs Alltagsgeschäft sind die neuen ja doch bißchen besser geeignet

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

Zitat:

---

Original von Vigo:
Irgendwie ist das Realsatire pur hier. Kai9 im Kampf gegen den Rest der Welt, whose im Kampf gegen den bösen Kai9, mk ist der Verräter, Darius wurde gezwungen, sich hier wieder zu registrieren, bernd_roesch labert unbeeindruckt weiter offtopic, und ich, ja ich hab hier eigentlich auch nix verloren...

*duckt sich und rennt weg*

---

Treffend, keine Frage

Wenigstens ist der Humor hier noch nicht völlig flöten, ein echter Lichtblick

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

Zitat:

---

Original von bernd_roesch:
Ne persönlich antworte ich auf den unrealistuschen Quatsch den du mir geschreiben hast nicht
wahrscheinlich weil du keine Mitleser befürchten musst schreibst du noch weltfremder als sonst.

---

Zitat:

---

entweder du postest es hier oder gibst mir das ok es zu posten(aber lies es besser nochmal durch
einige deiner Zeilen sind schon realistisch
passen allerdings nicht in das OS4 ist toll Weltbild)

---

Zitat:

---

Das ich dir persönlich geschrieben habe kam daher,weil mir anews verbot deine Lüge
ich würde mich weigern was für PPC zu machen richtig zustellen.ausserdem habe ich dir vor einem Jahr mal den source
des grafischen powerup asm debuggers geschickt weil du in dem anews Post Intresse daran hattest
.Da wollte ich auch nachfragen ob du evtl in deiner Freizeit irgend
was OS4 debugger mässig gemacht hast.Es hätte ja für AB2 helfen können.Aber nix.
Hätte ich das gewusst,dann hätte ich mir die PM erspart.

---

Zitat:

---

AUf OS4 ist toll in PM habe ich keine Lust weil nicht jeder die Arguemente lesen kann.Wenn ich dich
überzeuge,dass OS4 derzeit nicht toll ist um ne Zukunft mit Neuusern zu bekommen und man es verbessern muss
nutzt mir das ja auch nix.

---

Zitat:

---

Und nun zum Thema Hilfe.Du hast zwar schon öfter geschrieben zu helfen .

Und hast du den debugger mal getestet und ne Reaper Ausgabe geschickt und wann es abstürzt ?.
es reicht fürs erste ein kleines Beispielprog.

for i=1 to 20
stop
next
nprint i

am besten stellst du den JIT für erste tests mal ganz ab

---

Zitat:

---

Hast du getestet ob stormmesa auf pre 4 läuft ?.

---

Zitat:

---

Ein OS das als Zukunft gelten soll,sollte schon ordentlichen 3d support haben der mehr als nur quake 2 Qualität
erlaubt.Damit man auch in AB2 3d games schreiben kann.

---

Nur gut, daß Du nicht weißt, was alles bereits läuft, sonst gingen Dir noch die Argumente aus. Schlimme Vorstellung...

Das ist mein letzter Post zu dem Thema, alles weitere per Mail. Wenn Dir das zu viel ist (oder zu wenig öffentlichkeitswirksam), dann schreib das lieber gleich, damit ich mir die Mails an Dich sparen kann. Am besten suchst Du Dir dann auch gleich einen anderen Dummen, der Dir helfen will. Langsam ist es echt genug mit Dir.

Grüße

Nachtrag: Der AB2-Debugger schmiert zwar ab, läßt sich aber (dank GrimReaper) fortsetzen und zeigt danach eine Privilegverletzung an. Test war MIT JIT. Mail an Dich mit GR-Ausgabe und einem Screenshot ist schon raus.

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233




[ Dieser Beitrag wurde von whose am 07.03.2006 um 10:30 Uhr geändert. ]

Zitat:

---

Original von Kai9:

Zitat:

---

Original von Kai9:

Wenn du es tatsächlich so sehr begrüßt, dass Hr. Gutjahr Beiträge wegen "off-topic" löscht, wieso hast du ihn dann bis heute noch nicht darum gebeten, auch deinen und all die anderen "off-topic"-Beiträge schnellstmöglich zu löschen? Oder geht's dir dabei gar nicht ernsthaft ums off-topic-Löschen, sondern um etwas ganz anderes?

Zitat:

---

Original von whose:

Schöne Unterstellung

---

---

Keine Unterstellung, sondern nur einfache 2 Fragen.

---

Zitat:

---

Zitat:

---

Mir ist es aber völlig egal, ob er mein Posting mit der selben Begründung löscht wie Deins oder eben nicht.

---

Ja wie jetzt? Entscheide dich doch bitte mal.

---

Kannst Du lesen? Mir ist es egal, ich muß mich nicht entscheiden

Zitat:

---

Begrüßt du es nun, wenn Christoph die Bremse zieht und deswegen off-topic-Beiträge löscht (dann solltest du aber auch konsequent genug sein und ihn auffordern, dass er auch die anderen off-topic-Kandidaten, einschließlich deines Beitrags ebenfalls löscht)

---

So? Muß ich das? Sagt wer? Kai9? Ist mir auch egal

Ernsthaft: Ich muß da in keinster Weise irgendetwas äußern und auch nicht in Deiner Lesart konsequent sein. Mein Kommentar steht vor Christophs Warnung, wurde also nicht gelöscht. Bernds erste Anti-OS4-Tirade aber auch nicht, falls Dir das entgangen sein sollte. Alles in bester Butter. Der einzige, der ein Problem damit hat, bist Du.

Zitat:

---

, oder ist dir die Begründung, warum gelöscht wird, im Gegensatz zu deiner ersten Behauptung, letztendlich doch völlig egal?
Dann würde das aber bedeuten, dass du andere Gründe haben musst, um die Löschaktion von cgutjahr zu begrüßen. Ist doch logisch, nicht wahr?.

---

Zitat:

---

Zitat:

---

Von seiner Warte aus ist alles völlig korrekt, so wie es ist.

---

Ach so, und weil cgutjahr es völlig korrekt findet (ich frage mich, woher du das so genau weist), bist du jetzt ebenfalls dieser Ansicht, oder wie darf man deine Äußerung hierzu verstehen?

---

Zitat:

---

Zitat:

---

Hättest Du seine Warnung gelesen, hättest Du Dir dein (hinterher gelöschtes) Posting sparen können, so wie ich mir darauf hin weitere Postings geknickt habe.

---

Um mein gelöschtes Posting brauchst du dir hier schon mal gar keine Gedanken zu machen, darum geht es nämlich überhaupt nicht. Das war sowieso nur an cgutjahr gerichtet und beinhaltete lediglich die Frage, warum er Bernds Beitrag (38) gelöscht hatte, mehr war nicht. Gegen seine tatsächliche Warnung (Diskussion um OS4 vs. MOS sowie Aminet-/os4depot-Uploads) habe ich in keiner Weise verstoßen.

---

Zitat:

---

Zitat:

---

Im Gegensatz zu Dir sehe ich nämlich ein, daß da was passieren mußte...

---

"Im Gegensatz zu Mir" ...schon klar! Was ist denn bitte genau mit dieser Löschaktion erreicht worden? Nichts, wovon man ernsthaft behaupten könnte, dass es eine positive Auswirkung auf den Kommentarbereich gehabt hätte! Nur reicht deine Einsicht offenbar nicht so weit, um auch zu erkennen, dass das, was letztendlich wirklich passiert ist, nicht das war, was tatsächlich hätte getan werden müssen, um mit dem Löschen entsprechender Beiträge wirklich etwas in positiver Richtung bewirken zu können.

---

Zitat:

---

Zitat:

---

Und Deine (wenn auch subtil vorgetragene) Unterstellung von oben ist dann also korrekt... weswegen? Weil sie von Dir kommt?

---

Nochmals: Da ist keine Unterstellung.

---

Zitat:

---

Zitat:

---

Außerdem, wenn dich gewisse Diskussionen nerven, wieso beteiligst du dich dann trotzdem immer wieder daran, oder entfachst diese gelegentlich sogar selbst?

Zitat:

---

Soso... ich entfache die also gelegentlich selbst... um dich mal bei Deiner Sachlichkeit zu packen: Zitate, die diese Behauptung belegen?

---

---

Ja, wer hat denn hier angefangen, mich persönlich anzugehen und mit mir auf unsinnige Weise über mich, statt über den wirklichen Inhalt meiner Aussagen zum Thema diskutieren zu wollen, wenn nicht du? Du merkst es wohl schon selbst nicht mehr, wie?

---

Zitat:

---

Zitat:

---

Und meinst du vielleicht, nur weil dich Diskussionen zu bestimmten Themen nerven, müssen diese deswegen gleich eingestellt werden?

Zitat:

---

Wieder eine Unterstellung...

---

---

Hm, sag mal ehrlich: In was für einer Schule warst du, dass du eine Frage nicht von einer Unterstellung zu unterscheiden vermagst?

---

Kennst Du "implizite Unterstellung"? Das ist so eine, Deine ach so harmlose Frage

Zitat:

---

Zitat:

---

steht irgendwo, daß diese Diskussion auf meine Veranlassung hin eingestellt wurde?

---

Nein, aber wenn du hier schon das Bedürfnis hast, mir öffentlich mitzuteilen, dass dich angeblich sinnlose Diskussionen nerven, dann gehe ich doch mal davon aus, dass du damit etwas erreichen willst. Ansonsten wüsste ich nicht, wieso (mit welchem Ziel) du mir das hier erzählst.

---

Zitat:

---

Weil, es interessiert mich nämlich überhaupt nicht, ob dir Diskussionen (egal welche) auf den Nerv gehen, oder ob nicht. :o) Ich erzähle dir doch auch nicht, was mich vielleicht nervt. Wozu auch?! :o))

---

Zitat:

---

Zitat:

---

Sag mal, gehts noch?

---

Was fragst du mich? - Naja, wenn ich mir deine Postings ansehe, habe ich ehrlichgesagt schon so meine Zweifel. ;o)

---

Zitat:

---

Zitat:

---

und vom Thema wegführen

Zitat:

---

Das sagt ja genau der Richtige!

Zitat:

---

Pack Dich an die eigene Nase

---

---

---

Wieso? Ich habe doch kein Problem mit off-topic-Beiträgen anderer (nie gehabt!), ganz im Gegensatz zu dir.

---

Zitat:

---

Zitat:

---

Echte Argumente, die man nachvollziehen kann und die Spekulationen ausschließen, bringst Du ja nicht.

---

Du merkst wohl langsam wirklich nicht mehr, was du für einen Schwachsinn hier zusammenbringst. Gründe, warum ich mich hier beschwert habe, stehen oben klar und deutlich aufgeführt.

---

Zitat:

---

Aber falls du beim Lesen oder Verstehen wirklich derart ernsthafte Schwierigkeiten haben solltest, dann wende dich doch einfach mal an deinen zuständigen Bildungsträger. Vielleicht kann der dir ja mit entsprechenden Kurs-Angeboten erst mal weiterhelfen.

---

Diese Sätze sind Kindergarten-Niveau, Kai... aber schön, daß Du mich für so einen harten Gegner hältst, daß Du jetzt schon unterhalb der Gürtellinie zuschlagen mußt, um überhaupt eine Chance zu haben, mich zu treffen.

Das baut auf, danke Dir!

Ich klinke mich hier dann aber mal aus und warte auf Bernds Antwort, um, wenn möglich, sachlich mit ihm über sein Problem mit OS4 zu diskutieren.

Andernfalls würden wir zwei hier noch zu sehr Off-Topic, das wollen wir ja nicht, oder?

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233


[ Dieser Beitrag wurde von whose am 07.03.2006 um 02:22 Uhr geändert. ]

Zitat:

---

Original von Kai9:

Zitat:

---

Original von whose:
Insofern kann ich das vollkommen nachvollziehen, daß Christoph hier die Bremse gezogen hat und ich begrüße es sogar, obwohl ich einer der Beteiligten bin.

---

Wenn du es tatsächlich so sehr begrüßt, dass Hr. Gutjahr Beiträge wegen "off-topic" löscht, wieso hast du ihn dann bis heute noch nicht darum gebeten, auch deinen und all die anderen "off-topic"-Beiträge schnellstmöglich zu löschen? Oder geht's dir dabei gar nicht ernsthaft ums off-topic-Löschen, sondern um etwas ganz anderes?

---

Schöne Unterstellung

Mir ist es aber völlig egal, ob er mein Posting mit der selben Begründung löscht wie Deins oder eben nicht. Von seiner Warte aus ist alles völlig korrekt, so wie es ist. Hättest Du seine Warnung gelesen, hättest Du Dir dein (hinterher gelöschtes) Posting sparen können, so wie ich mir darauf hin weitere Postings geknickt habe.

Es ist doch wohl nicht meine Schuld, daß Du nicht lesen WILLST, was ein Moderator schreibt

Abgesehen davon, ich wäre in keinster Weise böse, wenn er mein Posting dort jetzt löschen würde. Im Gegensatz zu Dir sehe ich nämlich ein, daß da was passieren mußte...

Zitat:

---

Zitat:

---

Diese ewigen (und sinnlosen) Diskussionen nerven nur noch.

---

Die Diskussionen werden nur sinnlos u. nervig, wenn nicht wirklich diskutiert wird, sondern stattdessen versucht wird, ständig falsche Unterstellungen oder unhaltbare u. persönliche Schuldzuweisungen einzubringen, so wie du das hier gerade wieder mal vortrefflich demonstrierst, anstatt sachlich auf tatsächlich geäußerte Argumentation oder auf Fragen zum Thema einzugehen.

---

Aha? Und Deine (wenn auch subtil vorgetragene) Unterstellung von oben ist dann also korrekt... weswegen? Weil sie von Dir kommt?

Zitat:

---

Außerdem, wenn dich gewisse Diskussionen nerven, wieso beteiligst du dich dann trotzdem immer wieder daran, oder entfachst diese gelegentlich sogar selbst?

---

Zitat:

---

Und meinst du vielleicht, nur weil dich Diskussionen zu bestimmten Themen nerven, müssen diese deswegen gleich eingestellt werden?

---

Wieder eine Unterstellung... steht irgendwo, daß diese Diskussion auf meine Veranlassung hin eingestellt wurde? Das wäre mir etwas völlig Neues. Ich habe ausschließlich auf Deine (unsachlich vorgetragenen) Anschuldigungen in dieser Sache reagiert, mehr nicht. Es steht Dir auch weiterhin mehr als frei, Dich zu meinen Kommentaren und allen anderen Themen hier auf AN im Rahmen der Nettiquette zu äußern.

Nein, quatsch, ich verlange natürlich, daß Du auf der Stelle aus diesem Forum und aus den Kommentaren verbannt wirst mit Hinweis darauf, daß Du ein unsachlich und persönlich angreifender Troll bist. Also so ähnlich wie zur Zeiten der Inquisition

Sag mal, gehts noch?

Zitat:

---

Zitat:

---

Du wiederum bist einer von denen, die genau diese Diskussionen ständig anheizen

---

Du nennst es "anheizen" (wahrscheinlich weil dir die inhaltliche Aussage meist nicht passt). Ich nenne es aufmerksam machen, verschiedene Punkte ansprechen, diskutieren und die Meinung zum Thema frei äußern.

---

Notfalls "mit Gewalt" und an Stellen, wo es einfach nicht zum Thema paßt, nicht wahr?

Find Dich damit ab, daß Off-Topic-Kommentare halt gelöscht werden nach Warnung. Ich tus auch

Zitat:

---

Zitat:

---

und vom Thema wegführen

---

Das sagt ja genau der Richtige!

---

Pack Dich an die eigene Nase

Zitat:

---

Zitat:

---

das ist dann wohl auch der Grund, weshalb Du Dich so massiv beschwerst.

---

Zu den Gründen habe ich in den Beiträgen oben bereits hinreichend geschrieben. Du brauchst diesbezüglich also nur zu lesen, anstatt hier zu spekulieren.

---

Ich habe nur gesagt, daß ich Deine Argumentation in keinem Punkt nachvollziehen kann. Sogar Dein Argument, daß Bernd mal den Namen Achim ins Gespräch gebracht hat, zieht da nicht. Ein Name allein macht noch nicht, daß der Rest des Postings auch zum eigentlichen Thema gehört. So gesehen war Bernds Post zu 99,999% Off-Topic und meiner zu 99,9995%. Deiner sogar zu 100%.

Irgendwie ist man da quasi dazu gezwungen, über Deine Beschwerdegründe zu spekulieren. Echte Argumente, die man nachvollziehen kann und die Spekulationen ausschließen, bringst Du ja nicht.

Gefällt Dir nicht, ich weiß. Tatsachen, die nicht in Deine Argumentation passen, haben Dir noch nie gefallen. 9 Jahre Diskussion mit Dir und nie ändert sich was

Zitat:

---

Zitat:

---

Bei anderen Themen wirklich mal "sachlich" (also nicht auf emotional geführtem Kleinkrieg zwischen OS4/MOS ausgelegt) mitzureden liegt anscheinend nicht im Bereich Deiner Möglichkeiten, oder?

---

Auf eine derart billige Provokation deinerseits soll ich doch jetzt hoffentlich nicht auch noch ernsthaft eingehen, oder?

---

Hast Du doch schon längst getan und es mir mit gleicher Münze heimgezahlt. Aber in Deinem Fall ist das ja etwas völlig anderes, ich weiß

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233


[ Dieser Beitrag wurde von whose am 06.03.2006 um 20:23 Uhr geändert. ]

Zitat:

---

Hm, dachte, Du hast das so gemeint. Man bestimmt das neu zu zeichnende Tile inkl. des Cliprechtecks. Das muss man aber doch bei bewegten Objekten vor und nach der Bewegung machen, denn sie können ja vorher und nachher unterschiedliche Tiles bedecken bzw. während der Bewegung 2 Tiles bedecken. Wenn sich ein Objekt bewegt wird seine alte Position und Größe sowie seine neue Position und seine Größe zur Bestimmung der "beschädigten" Regionen hergenommen, oder nicht?

---

Ganz genau. Wenn Du das Ganze jetzt noch aus dem Blickwinkel einer State Machine siehst, hast Du es ganz erfaßt. Du hast einen State und eine State Trasition zum einem neuen State. Die "Beschädigungen" des vorherigen State durch bewegte Objekte dienen zur Herstellung des neuen State genauso wie die Informationen der eigentlichen State Transition (z.B. neue unbewegte Objekte im Bild, neuer Frame einer Objektanimation).

Alles, was sich nicht verändert, bleibt einfach so stehen, wie es vorher auch war. Alles, was sich auf irgendeine Weise verändert (also ganz oder teilweise zu einer Damage Region gehört!), wird zur Herstellung des neuen State neu gezeichnet, und zwar nach vorher definierten Regeln (z.B. von oben nach unten/rechts nach links, die am Mauszeiger klebende Turmgrafik immer als letztes Element usw.).

Grüße


--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

Zitat:

---

Original von bernd_roesch:
achso erst schreibst du oben
...

---

Bernd, das gehört echt nicht mehr zum Thema... ich habe Dir das Ganze mal per Mail geschickt, das diskutieren wir besser dort weiter. Tu mir nur einen Gefallen und versuch mal, Dich aus Deiner festgefahrenen Haltung zu befreien. Geistig bist Du manchmal unflexibel wie ein 100jähriger. Hilfsangebote bekommst Du von anderen, die Nutzung derselben ist Deine Sache.

Rest bitte nur noch per PM.

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

Zitat:

---

Original von bernd_roesch:
>Das liegt daran, daß Du in den Kommentarforen meistens völlig am Thema vorbei diskutierst.

Das war der komplette Kommentar von Wolfgang

"
Ich finde es schon seltsam, daß ausgerechnet Du Dich darüber mokierst, das kaum was nativ auf den beiden Nachfolgesystemen entwickelt wird.
Wer weigert sich denn beharrlich, die eine oder andere Anpassung von AB2 an die PPC-Systeme durchzuführen?
Ist Dir zu viel Arbeit, ich weiß. Aber dann beschwer Dich nicht, wenn andere Leute auch so denken...
"

also was soll ich dann auf den Kommentar antworten.Kann ich doch garnicht anders als wieder runterzuleiern
was das Problem ist.vieleicht ändert sich ja was dadurch.oder es packt die der Ehrgeiz zu zeigen dass
OS4 auch zu mehr gut ist als nur Linux miniprog Basis und ich unrecht habe

---

Zitat:

---

Oder bist du so zufrieden wie es ist ?.

Das es irgendwann keine Hardware zu kaufen gibt habe ich schon vor Jahren gesagt wenn es zu geringe Nachfrage
gibt weil das Produkt zu schlecht ist.Und wenn die Nachfrage nicht steigt wird sich daran vermutlich auch nix ändern

---

Zitat:

---

Es ist schon verwunderlich warum keiner Geld verdienen will wenn doch alles
bestens ist

---

Zitat:

---

Also ran an die Tasten beweist doch das OS4 gut ist,portiert und releast Arteffect Candyfactory Real3d DA3
diropus magellan usw schreibt Apps dass User berzeugt den Mehrpreis des aone in Kauf zu nehmen um die Soft zu nutzen

---

Zitat:

---

Dann wollen vieleicht mehr den aone(wenn es nicht schon zu spät ist) und es wird vieleicht wieder welche geben.

Gönnt nicht den Triumph sagen zu können.Ich hatte von Anfang an recht,es war nie geplant ne ordentliche Zukunft
für AOS anzubieten,sondern nur darum mit wenig arbeit ein paar Euro verdienen zu können.

---

Zitat:

---

>Insofern kann ich das vollkommen nachvollziehen, daß Christoph hier die Bremse gezogen hat und ich begrüße es sogar,
>obwohl ich einer der Beteiligten bin

Erst unterstellst du mir ich weigere mich beharlich AB2 an PPC Systeme anzupassen was nicht stimmt,und dann willst
du nichtmal die Gründe wissen.

---

Zitat:

---

Auch mal was zum Thema:

wieso lässt sich eigentlich da3 so einfach auf MOS portieren und auf OS4 nicht ?.Was fehlt denn nun an OS4
wenn meine Kritik nicht stimmt

wenn die Antworten jemand liest,evtl verbessert dann jemand OS4

---

War es einfach? Oder war es eher einfach, DA3 in der ABox zum Laufen zu kriegen? Das ist immer noch ein klein wenig was anderes, als ein natives System ohne aufwändigen Kompatibilitätslayer und mit etlichen Neuerungen im Gedärm.

Eine Frage habe ich aber noch: Warum bist Du eigentlich immer der Meinung, daß an OS4 etwas fehlen würde, weil ein älteres Programm darauf nicht läuft? Evtl. ist es nämlich auch so, daß OS4 einiges zu viel hat, womit das ältere Programm nicht klarkommt, weil an eine solche Möglichkeit schlicht nicht gedacht wurde... kommt Dir das bekannt vor?

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

Zitat:

---

Original von Blackbird:

das OS4/MOS gut wird, und er entlich Hoffnung sehen kann das es mit dem AmigaOS weitergeht, so einfach ist das..

---

Das geht jetzt schon wieder am eigentlichen Thema vorbei, aber was solls...

Eine Frage: Wann ist für Euch beide OS4 gut? So, wie sich mir das darstellt doch nur, wenn AB2 darauf ohne Änderung läuft. Dann stellt sich gleich die nächste Frage: Wozu dann OS4/MOS? AB2 läuft schlecht auf OS4, weil Bernd keine Lust hat, irgendwas zu ändern. Auf MOS kann es die dortigen Vorteile ohne Änderungen nicht nutzen...

Ist das denn so schwer? OS4 hat gegenüber OS3 ein paar Änderungen erfahren, die vor allem schlecht designte Software untergehen lassen. Es kann schlicht nicht funktionieren, wenn man eine Debugger einem System auf den Leib schreibt, daß dieser auf einem System weiterhin läuft, welches interne Veränderungen erfahren hat oder gar einen heftigen CPU-Wechsel hinter sich hat. So einfach ist das! Kommt jetzt nicht mit der besseren Emu unter MOS... schaut Euch an, wie diese ins System eingebunden ist. Da sind Grenzen gesetzt, die Ihr jetzt noch nicht seht.

Und wenn ich diesen Unfug lese, daß unter OS3 geschriebene Software ohne jegliche Einschränkung auf OS4/MOS laufen muß, rollen sich mir die Zehennägel auf. Wer sich nicht an die Konventionen der RKMs hält oder an Programmierer-Weisheiten, die schon seit über 10 Jahren geläufig sein sollten, braucht sich nicht wundern, daß er mehr Arbeit investieren muß. Andere Leute für das eigene Unvermögen schuldig zu sprechen, finde ich, mit Verlaub, recht gewagt.

Demnächst kommt ihr noch damit, daß OS4/MOS-Software auf 68K-Systemen laufen muß oder wie?

Zum Thema Debugger: Mich nervts auch, daß ich gezwungen werde, den Bedienungs-Spielverderber gdb benutzen zu müssen, aber das ist derzeit der einzige Debugger, der für PPC zur Verfügung steht. Wann etwas anderes kommt, steht in den Sternen... wer nun unbedingt einen Debugger für 68K-Programme auf OS4 einsetzen will, findet mit dem GrimReaper zumindest schon mal eine wertvolle Hilfe. Mit dessen Ausgabe ist es durchaus machbar, ein 68K-Programm auf einer 68K-Maschine zu debuggen und die Wanze auch zu finden (oder, ums mit Bernds Lieblings-Argument zu sagen: Festzustellen, daß der Emulation etwas fehlt und man nun da hängt und evtl. doch die empfohlene Methode verwendet hätte).

Ich versuche mal, das Thema auf einen Punkt zu bringen: Solange dieses Gezerre um CPU-Vorlieben (und OS-Vorlieben) samt unglaublicher Borniertheit mancher Beteiligter anhält, kommen wir kein Stück weiter. Da hilft auch AROS nicht...

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

Zitat:

---

Original von bubblebobble:

Würde ein Baum weiter unten in das Rechteck hineinragen, hätten wir allerdings ein problem. Deshalb kann man die For schleife einfach noch eine Tile Zeile (oder mehr, wenn es höhere Objekte gibt) weiterlaufen lassen. Blitts, die nicht in der ClipRegion liegen, verbrauchen so gut wie keine Rechenzeit.Und das bisschen For Schleife ist auch kein Problem.

---

Jap, das meinte ich mit "kleiner Rekursion". Um da möglichen Bockmist zu vermeiden, müssen wir uns bei Reths Hextiles noch jeweils einmal das Tile darüber und das rechts daneben ansehen, ob ggf. eigentlich unbeteiligte Türme darauf von unserer aktuellen Damage Region erfaßt werden und somit "dazuaddiert" werden müssen, selbst wenn diese Türme sich eigentlich nicht verändern.

Das praktische dabei ist, daß das eben pro Tile, welches unter der aktuellen Damage Region liegt, nur auf die beiden Nachbartiles darüber/rechts davon zutreffen kann, sofern er keine Überdeckungen nach links/unten zuläßt.

Sobald er das doch macht, sind alle Tiles im Umkreis um die Damage Region potentielle Kandidaten für eine Untersuchung, da man nicht voraussagen kann, welche Objekte links/unterhalb betroffen sein könnten, auch wenn sie selbst sich eigentlich nicht verändern.

Die Vorgehensweise von oben nach unten/von rechts nach links bleibt dabei voll erhalten, es ist "nur" jeweils eine Überprüfung nach Oben/Rechts im Nachlauf sowie eine nach Unten/Links im Vorlauf fällig. Dabei kanns aber wieder passieren, daß fast das gesamte Bild neu aufgebaut werden muß, nur weil sich einige wenige Objekte verändern...

Ich würde sagen, Reth sollte die Grafik ein wenig einschränken, was die Überdeckungsmöglichkeiten betrifft. Überdeckung nach links/unten könnte sich da tödlich auswirken, Überdeckung nach rechts/oben ist eigentlich ausreichend, auch für animierte Tiles. Da müßte er dann die Grafik entsprechend anpassen, so daß z.B. sich im lauen Lüftchen wiegende Weizenfelder nicht auf die Tiles links auswirken. Das sollte eigentlich kein Problem sein.

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

Zitat:

---

Original von bubblebobble:
@whose

Nein, da verstehen wir uns etwas falsch.

Eine DamageRegion wird bei mir in Pixeln gemessen (Bildschirm oder Playfield Koordinaten), nicht in Tiles.
Ich markiere keine Tiles sondern direkt die Bildschirmkoordinaten, die neu gezeichnet werden müssen, daher meine Funktion drawTiles().

---

Zitat:

---

Wenn ein Turm in ein oberes Tile hineinragt, und sich neu zeichnen muss, dann wird selbstversändlich auch das obere Tile neu geblittet, aber dank ClipRegion eben nur der Teil, der innerhalb des Turm-Bildes ist. Ich blitte nicht das ganze Tile, sondern möglicherweise nur ein paar Pixel davon. Dadurch muss ich auch nicht gucken, was durch dieses Tile wiederum beeinflusst wird, keine Rekursion mölglich. Alles was sich verändert liegt ja in meinem x1,y2,x2,y2 Pixel-Bereich.

---

Zitat:

---

Ich denke diese Arbeitsweise hat nichts mit der Programmiersprache zu tun. Das lässt sich genauso auch in C++ machen.
(wobei angemerkt sei, dass ich C++ in diesem Fall für einen Kropf halte).

---

Das isn anderes Thema

Grüße



--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

Zitat:

---

Original von Reth:
Nur darin bestand glaub ich mein Performanceproblem, die Überdeckungen für jedes Objekt zu finden (rekursiv, wenn andere Objekte betroffen waren).
Ein Objekt kann ja ein darunterliegendes überdecken. Wenn es sich aber bewegt, muss ich auch die darüberliegenden berücksichtigen.
Darum hab ich die Layer eingeführt.
Nun brauch ich "nur" noch ne performante Methode, wie ich überdeckte Objekte in unterschiedlichen Layern finde.
Eine Suche über die Objektkoordinaten in einem Tilearray scheidet aus, da ja nicht nur die Hintergründe betroffen sind.

Zur Vereinfachung kann ich ja bei meinen 6-Ecken von ner festen Größe ausgehen, auch wenn sie mal mehrere Animationen und Frames haben. Da es keinen Sinn macht, die Tile-Größe während der Spielzeit zu ändern (zumindest seh ich keinen).

---

Hm, evtl. solltest Du darüber nachdenken, den Tiles einen "Sonderstatus" in Deiner Klassenhierarchie zu verpassen. Im Grunde steht und fällt Dein Konzept über die Tiles. Wie ich das meine?

Ich hatte in einem der vorherigen Beiträge geschrieben, daß in Deinem Grafikaufbau die Veränderungen "weitergereicht" werden und sich dadurch der Domino-Effekt ergibt. Das geschieht durch die Tiles!

Im Grunde ists egal, ob ein Objekt ein anderes verdeckt oder nicht, denn die Objekte befinden sich alle zusammen auf einem Tile. Das bedeutet im Endeffekt, daß, wenn ein Tile betroffen ist, bis zu einem gewissen Grad auch alle Objekte auf diesem Tile von der Änderung betroffen sind.

Das "bis zu einem gewissen Grad" ist der Knackpunkt. Wenn ein Objekt auf einem Tile, welches eine Veränderung erfährt, sich nicht im Bereich der Veränderung befindet (also in der Damage Region), und sich selbst auch nicht verändert, braucht es auch nicht neu gezeichnet werden. Das Tile selbst wird ja mittels Clipping gezeichnet, also teilweise, nämlich nur in dem Bereich, wo eine Veränderung stattfindet.

Bei animierten Tiles kommst Du allerdings nicht darum herum, das gesamte Tile samt den darauf befindlichen Objekten neu zu zeichnen. Macht auch nix, denn dadurch erübrigt sich für die darauf befindlichen Objekte die Abfrage, ob die sich in der Damage befinden oder nicht (sie sind es auf jeden Fall). Ggf. sind angrenzende Tiles betroffen, diese werden dann aber, falls sie nicht auch animiert sind, per Clipping gezeichnet.

Eine weitere Vereinfachung wäre es, wenn Du im Tile-Objekt festhältst, ob sich andere Objekte darauf befinden. Wenn der Test nämlich kein weiteres Objekt ergibt, erübrigt sich auch die Abfrage, ob irgendwas im Bereich des Damage ist und neu gezeichnet werden muß.

Du brauchst also "nur", sobald ein Objekt eine Veränderung erfährt, den Bereich der Änderung ermitteln (Damage), schauen, welches Tile in diesem Bereich liegt (Koordinaten aufs Array abbilden) und davon ausgehend weitere Objekte ermitteln, die von der Damage betroffen sind. Dementsprechend vergrößert sich der Damage-Bereich.

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

Zitat:

---

Original von Reth:
So langsam entwickelt sich das zum Brainstorming meinerseits.

Ich hab das Gefühl, ich steh auf sämtlichen Schläuchen und wenn ich von einem runtergeh, tret ich auf 2 neue!

Also mal für die statischen Objekte gesprochen, die da Hintergrund oder Gebäude sein können in unterschiedlichen Layern.
Die Gebäude überdecken bis zu 3 Hintergrundobjekte. Ändert ein Gebäude seine Grafik, sind bis zu 3 Hintergrundobjekte betroffen. Diese gilt es zu finden und neu zu zeichnen. Davor wird eine ClipRegion in der Größe des Gebäudes angelegt, damit nicht andere Gebäude betroffen werden, wenn die Hintergründe neu gezeichnet werden. Da Hintergrund und Gebäude unterschiedliche Größen haben, wird es schwierig die Überdeckungen zu ermitteln. Mir fällt da nur ein die 4 Ecken des Gebäudes zu nehmen und überdeckte Hintergründe zu finden.

---

Genau, Du hasts im Grunde erfaßt. Und dabei spielt es keine Rolle, welche Größe z.B. das Gebäude aktuell hat, da Du diese Größe in die Berechnung der Überdeckung aktuell mit hinein nehmen kannst. Die Größen ändern sich ja nicht mitten im Zeichenvorgang sondern schon davor. Also kannst Du auch auf die Größen zurückgreifen bei der Berechnung, selbst für die Ermittlung des betroffenen Tiles. Statt fester Werte nimmst Du einfach die tatsächlichen Werte des Objekts.

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

Zitat:

---

Original von Reth:

Dieser Aufbau gilt für alle Elemente, auch die Hintergrundtiles, die animiert sein können. Damit geht das ganze Konzept mit Tilearray usw. flöten!

Das ist das ganze Prinzip. Warum einfach, wenns auch kompliziert geht!?

Naja, bin ja selbst schuld!

---

Hm, machs Dir in Gedanken nicht komplizierter, als es eh schon ist

Die Größe der Tiles ist gar nicht so entscheidend. Du kannst jederzeit die Berechnungen an neue Größen der Tiles anpassen. Abgesehen davon macht es aber auch nicht viel Sinn, die Tilegröße mitten im Spiel zu verändern, oder?

Die Animationen sind auch kein großes Problem. Das Spiel durchläuft ja verschiedene States, einer davon ist halt der "Zeichne den Kram"-State. Erst da kommen die jeweiligen Animationsframes eines Tiles zum Tragen. Wenn sich bei einem animierten Tile das Bild verändert, wird da halt ein Damage für eingetragen und gut. Je nach dem, ob Objekte auf diesem Tile stehen, wird u.U. ein Refresh der benachbarten Tiles benötigt, aber halt nur im Rahmen des ClipRects, welches die betroffenen Objekte samt animiertem Tile umschließt.

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

Zitat:

---

Original von Reth:
Hm, jetzt hab ich mein Hauptproblem (?) wieder entdeckt.
Ich habe meine Animationsklassen so entworfen, dass sie mit flexiblen Framegrößen umgehen können und ihre aktuelle Höhe und Breite kennen.
Es gibt dazu noch eine maximale Höhe und Breite.
Eine Animation kann aus beliebig vielen Frames mit unterschiedlichen Größen bestehen.

Das macht das Ganze nicht unbedingt leichter (im Hinblick auf Umsetzung von Pixelkoordinaten auf Arraykoordinaten).

Hm, muss ich mir nochmal reinziehen.

---

Nein, im Grunde ists auch dann genau das Gleiche. Du nimmst als Berechnungsgrundlage halt die dann aktuellen Größen (Position X/Y, Höhe und Breite des Animationsframes) und weißt, was so alles überdeckt wird davon. Unter anderem erfährst Du dann auch, ob dieses Objekt bereits in einem Damage-Bereich (ClipRect später!) liegt und ob es da noch ganz reinpaßt. Paßts nicht mehr ganz rein, ists an der Zeit, den Damage-Bereich zu vergößern

Nimm Dir dazu auch mal Michas, Thilos und meinen Rat zu Herzen, informier Dich über Sinn und Zweck von ClipRects. Wenn Du diese ClipRects in ihrer Größe so berechnest, daß alle Objekte auf ihren jeweiligen Positionen und in ihren aktuellen Größen da reinpassen, kannst Du für die Ermittlung der betroffenen Tiles (also die unterste Ebene!) sogar ganz simpel die ClipRect-Koordinaten nehmen.

Die Tiles müssen im Refresh dann ja als erstes gezeichnet werden und eben auch durch Clipping beim Zeichnen begrenzt werden, damit nicht am Refresh beteiligte Objekte unbehelligt bleiben.

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

Zitat:

---

Original von bubblebobble:
Also ich habe mir mal die Tuts reingelesen, kann ich nicht uneingeschränkt empfehlen, es sei denn du hast vor, dass sich die Figuren nur Blockweise bewegen. Wenn du eine wirklich "freie" ISO Grafik haben willst, mit vorder und Hintergrund, muss man das ein wenig anders machen.

Die vorgehensweise vom ersten Tut entspricht auch nicht wie man es mit der Amiga API machen würde.

Vergiss auch die Listen! Heute hat man genug Speicher, das ist nur umständlich und schwer zu implementieren.

---

Zitat:

---

Beschreibe doch nochmal genau, was die Anforderungen sind.

Zum Doublebuffering:
Du allocierst den Screen und einen unsichtbaren Rastport, der genauso gross ist wie der Screen.
Wenn du eine Fläche refreshen willst, dann zeichne sie einfach auf den unsichtbaren Rastport, und wenn du fertig bist swappe es auf den Screen.

---

Zitat:

---

Mach dir keinen so grossen Kopf wegen dem Rereshen. Schreibe einfach wie ich oben beschrieben habe eine Funktion, die einen beliebigen Ausschnitt komplett zeichnet, und benutze eine DamageList und InstallClipRegion() zum clippen.
Bewegliche Figuren kannst du in einem eigenen Array/Liste halten, und alle abfragen für jedesmal zeichnen, das braucht kaum Rechenzeit,
denn wenn viel los ist musst du soweiso fast alle neu zeichnen, und wenn wenig los ist dann spielt der overhead keine Rolle.

@whose
Nein, nicht y * x + x !!!!
y * Breite +x !!!!

---

Wie ich oben schon schrieb, Hektik und Übermüdung... genauer heißts: (y * Anzahl Spalten pro Zeile + x). Ich hoffe, das konnten wir jetzt so weit klären, das keine Aufregung mehr nötig ist

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

Zitat:

---

Original von Reth:

Zitat:

---

Original von whose:

8 ist Binär 00000111.

---

Halt! 8 ist binär 00001000 !
D.h. Du verknüpfst mit 11110111.

---

Zitat:

---

Zitat:

---

Und was passiert bei, sagen wir, 12/8? Das ist 1.5. Wie wird das gerundet?

Das ist implementierungsabhängig Je nach Compiler/Typ der Operanden geht das in die Hose und Du bekommst 2 statt 1. Richtig kritisch wirds ab 13...

---

Halt, halt! Von Runden hab ich nichts gesagt. Es ist eine reine Ganzzahldivision von Integerwerten ohne Rest.
D.h. alles geteilt durch 8, was einen Rest ergibt ergibt die Zahl vorm Komma, also:

...
9/8 = 1
10/8 = 1
11/8 = 1
12/8 = 1
...
15/8 = 1
16/8 = 2
...

---

Zitat:

---

Zitat:

---

Das bedeutet, es wird immer automatisch zum richtigen Index umgeschalten, wenn Deine Tiles 8 Pixel breit sind.

Mit dem Verfahren oben bekommst Du immer die (fast) korrekt für unsere Zwecke gerundete Ganzzahl. Bei x=9 käme dabei 2 raus, was dem richtigen Index+1 (!) entspricht. Bei x=17 gäbe das 3, was ja auch richtig ist, da die Koordinate 17 das dritte Tile berührt (immer davon ausgegangen, daß ein Tile 8 Pixel groß ist). Einziger Fallstrick hierbei ist die in C/C++ verwendete Indexierung, die nun einmal bei 0 beginnt und nicht bei 1. Daher mußt Du das Ergebnis um 1 verringern, um den korrekten Index im Array zu erhalten.

---

Und eben hier hast Du keine Probleme mit dem von mir beschriebenen Verfahren, denn alles < 8 (also 0 bis 7) geteilt durch 8 gibt damit immer 0.

---

Nicht immer. Spätestens, wenn eine Float-Zahl als Teiler ins Spiel kommt, wird implementierungsabhängig gerundet. Bei einfachen Algorithmen mag das so noch funktionieren, spätestens bei komplizierteren Sachen kommst Du da ins Rudern. Aber mach ruhig einstweilen so, solange Du einfache Rechnungen laufen hast. Solange nur Ganzzahlen verwendet werden, funktioniert das so...

@bubblebobble:

Hektik und Übermüdung, man möge mir verzeihen. In meinen Programmen stehts korrekt

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233


[ Dieser Beitrag wurde von whose am 02.03.2006 um 16:35 Uhr geändert. ]

Zitat:

---

Original von Reth:

Zitat:

---

Original von whose:
Zu dem Thema ist auf gamedev.net der Artikel, von dem ich sprach. Ich weiß jetzt nicht mehr genau, welcher das war, aber da gings auch um Hextiles und deren Anordnung in einem 2D-Array. Wenn ich mich recht erinnere, war das so gelöst, daß die Tiles einer Reihe auch in die entsprechende Reihe des 2D-Arrays eingetragen wurden und bei Berechnungen/Zeichenoperationen der Zeichen-Offset berücksichtigt wurde.

---

Den hab ich gelesen, aber nicht sosehr auf mich gemünzt, da deren Tiles immer am linken und oberen Rand beginnen, ich aber ja die weißen Bereiche habe, aber die kann ich ja ignorieren und die entspr. Felder leer lassen.

---

Genau. Ich denke mal, dann läßt sich die ganze Geschichte deutlich leichter rechnen (und vor allem überschauen ).

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

Zitat:

---

Original von Reth:

Zitat:

---

Original von whose:

Zitat:

---

Original von Reth:
Die Damagelist wird dann Layer für Layer komplett neu gezeichnet (in dem einen Artikel auf gamedev.net steht glaub, dass erst alle Layer eines Bereiches gezeichnet werden, bevor die des anderen Bereiches drankommen, um Abschneiden von Objekten zu verhindern. Also entweder hab ich in dem Artikel was missverstanden oder passiert dadurch doch genau das: Objekte können abgeschnitten werden.

---

Es kann Dir passieren, daß Objekte "aus Versehen" von Objekten einer unteren Ebene übermalt werden, wenn Du die Reihenfolge nicht korrekt einhältst. Das kann so weit gehen, daß ein neu zu zeichnendes Tile ein gerade neu gezeichnetes Objekt eines Nachbartiles übermalt. Das wäre dann abgeschnitten.

---

Darum meinte ich ja, dass man alle Bereiche Ebene für Ebene zeichnen muss und zwar auf einmal. Nicht Bereich1 alle Ebenen, dann Bereich2 alle Ebenen, etc. Dann sollte es klappen, denke ich.

---

Zitat:

---

Zitat:

---

(char angenommen) Es wird mit 11111000 UND-verknüpft.

---

Aber wie kommt da das NICHT (~) zum tragen?

---

Zitat:

---

Zitat:

---

Der Gag dabei ist die vorherige Addition von 7. Mit der Mimik erreichst Du, daß Du nur ganze Zahlen erhältst, die durch 8 teilbar sind. Wenn Du z.B. ein Objekt auf der Koordinate x = 9 liegen hast, muß diese Koordinate für die Umrechnung in einen Array-Index irgendwie auf "ganze" Indizes erweitert werden. Mit dem Krempel von oben käme dann (9 + 7) = 16 heraus, das &~8 hätte darauf keinen Einfluß. 16 läßt sich gut durch 8 teilen...

---

Ich nehm dafür immer Ganzzahl-Division ohne Rest (/).
Ist das von Dir beschriebene Verfahren schneller?
Also wenn ich den Index im Array zu einer Koordinate ermitteln will nehm ich die Koordinatenwerte dividiert durch 8 ohne Rest.
Z.B. (x,y) = (10,10) => Arrayindex = (10/8=1,10/8=1)
also an Position (1,1) im Array (dieses beginnt bei (0,0)).

---

Und was passiert bei, sagen wir, 12/8? Das ist 1.5. Wie wird das gerundet?

Das ist implementierungsabhängig Je nach Compiler/Typ der Operanden geht das in die Hose und Du bekommst 2 statt 1. Richtig kritisch wirds ab 13...

Mit dem Verfahren oben bekommst Du immer die (fast) korrekt für unsere Zwecke gerundete Ganzzahl. Bei x=9 käme dabei 2 raus, was dem richtigen Index+1 (!) entspricht. Bei x=17 gäbe das 3, was ja auch richtig ist, da die Koordinate 17 das dritte Tile berührt (immer davon ausgegangen, daß ein Tile 8 Pixel groß ist). Einziger Fallstrick hierbei ist die in C/C++ verwendete Indexierung, die nun einmal bei 0 beginnt und nicht bei 1. Daher mußt Du das Ergebnis um 1 verringern, um den korrekten Index im Array zu erhalten.

Aber das eigentlich wichtige: Du bist dadurch unabhängig vom Rundungsverhalten des Compilers im Zusammenhang mit Ganzzahlen.

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

Zitat:

---

Original von Reth:
@bubblebobble:

Danke. Aber wie siehts mit dem Ablegen einer solchen Karte
http://people.freenet.de/WizardGrounds/images/Beginn.png
in ein Array aus? Mit der Formel y*Breite + x bekomme ich ne eindeutige lineare Zuordnung.
Allerdings würde ich bei einer Map wie im Bild die weißen Bereiche mit ins Array legen müssen, obwohl die nie verwendet werden.
Du arbeitest mit DoubleBuffering, oder. Aber ist das auch noch ratsam (bezogen auf den ganzen Bildschirm), wenn man mit nem 1024x768x8 Screen arbeitet?

@Micha1701:

Auch danke. Werde mir die diesbezüglichen Dokumente mal reinziehen.

---

Zu dem Thema ist auf gamedev.net der Artikel, von dem ich sprach. Ich weiß jetzt nicht mehr genau, welcher das war, aber da gings auch um Hextiles und deren Anordnung in einem 2D-Array. Wenn ich mich recht erinnere, war das so gelöst, daß die Tiles einer Reihe auch in die entsprechende Reihe des 2D-Arrays eingetragen wurden und bei Berechnungen/Zeichenoperationen der Zeichen-Offset berücksichtigt wurde.

Du hast da ja immer eine Verschiebung um einen festen Betrag drin, wenn Du Dir die Hextiles als Rechtecke denkst. In Deinem Fall findet diese Verschiebung seitlich statt, das Nachbartile rechts oder links ist immer um einen bestimmten Betrag (untere/obere Kantenlänge eines Tiles) versetzt gezeichnet. Wenn Du diesen Offset bei Berechnungen berücksichtigst, kannst Du Hextiles genau wie rechteckige Tiles behandeln und auch so in einem Array ablegen. Die "leeren" Bereiche sind dabei völlig uninteressant.

Alles, was dabei "leer" bleibt, sind die nicht durch ein Tile besetzten Indizes in dem Map-Array. Die kannst Du aber recht einfach "überlesen", da die Anzahl der Tiles pro Zeile jeweils bekannt ist. Wahlweise kannst Du auch das Array um einen Eintrag in X-Richtung größer machen und in Array[0, y] die Anzahl der enthaltenen Tiles vorhalten. So riesig fällt das Array bei Dir ja nicht aus und selbst bei größeren Arrays fällt ein Eintrag mehr oder weniger nicht so sehr ins Gewicht. Die ungenutzten Einträge tun da auch nicht so sehr weh, finde ich.

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

Zitat:

---

Original von Reth:

Zitat:

---

Original von whose:
@Reth:

Bekannt sein muß dafür die Anzahl der X-Koordinaten pro Zeile.

Dann ist Eintrag(x, y): Array[y * x]

Simpel, oder?

---

Aber dann haben die Objekte mit gleichen vertauschten Koordinatenwerten ja denselben Eintrag!
Also x=3 und y=4 bilden auf dieselbe Arrayposition ab wie x=4 und y=3!? Oder meintest Du Array[x, y]?

---

Zitat:

---

Zitat:

---

Worauf Du unbedingt achten mußt ist, so wenig Zeichenvorgänge wie möglich pro Frame zu erreichen und nicht zu lange durch die Koordinatenberechnungen zu laufen.

---

Das will ich ja mit den Layerlisten erreichen. Allerdings bei den Koordinatenberechnungen weiss ich noch nicht, wie ich das optimal gestalten kann. Habe mir im Moment diesen Ansatz überlegt:

Wenn ein Objekt seine Position ändert => finden seiner Liste in der Map. Aufnehmen der Layerliste an dieser Position in die Damagelist. Durchgehen aller Objekte in der Liste, prüfen der 4 Eckpunkte jedes dieser Objekte (also jeden Layer an dieser Position), ob diese andere Objekte überlappen (hier wärs halt sehr von Vorteil, wenn ich eindimensional arbeiten könnte, da ich dann direkt in der HashMap die überlappenden Objekte finde). Für jede so gefundene andere Layerliste diese in die Damagelist aufnehmen und den Vorgang wiederholen.
Denke aber nicht, dass das performant ist (Dominoeffekt).

---

Zitat:

---

Die Damagelist wird dann Layer für Layer komplett neu gezeichnet (in dem einen Artikel auf gamedev.net steht glaub, dass erst alle Layer eines Bereiches gezeichnet werden, bevor die des anderen Bereiches drankommen, um Abschneiden von Objekten zu verhindern. Also entweder hab ich in dem Artikel was missverstanden oder passiert dadurch doch genau das: Objekte können abgeschnitten werden.

---

Zitat:

---

Zitat:

---

Einziger Nachteil bei dieser Engine ist bisher nur, daß die noch nicht mit überlappenden Sprites klarkommt, da wird der Hintergrund noch doppelt gezeichnet unnötigerweise.

---

Genau das Problem hab ich momentan. Wenns nur ein Objekt überm Hintergrund wäre, wärs einfacher. So aber hab ich Objekte in versch. Ebenen, die sich gegenseitig überdecken können.

---

Zitat:

---

Zitat:

---

(Edit) Vielleicht fällts Dir leichter, wenn Du Dir die Grafik vorstellst wie übereinandergelegte Overhead-Folien. Für jedes Objekt eine eigene Folie, die Hintergrund-Tiles bilden eine einzige Folie. Je nachdem, wie Du die "Folien" der Objekte verschiebst, sind ein oder mehrere Tiles auf der Hintergrund-"Folie" überdeckt.

---

Genauso ist meine Grafik aufgebaut. Jedes Objekt hat einen Layer zugeordnet. Objekte innerhalb des selben Layers können sich nicht überdecken.

---

Diese Beschränkung ist weise

Damit machst Du Dir das Leben leichter, weil die Überdeckungen dann nicht auf allen Ebenen weitergereicht werden können, sondern höchstens von Ebene zu Ebene in einem beschränkten Bereich. Da helfen ClipRects dann mit Sicherheit weiter (s.O.).

Zitat:

---

Zitat:

---

Dieser Bereich ermittelt sich wie folgt, wenn die Tiles 8*8 Pixel groß sind:

Startposition des Bereiches in X: (ObjectPosX + 7) &~ 8
Startposition des Bereiches in Y: (ObjectPosY + 7) &~ 8

Anzahl "ganze" Tiles in X, die das Objekt überdeckt: (((ObjectPosX + ObjectSizeX) + 7) &~ 8 ) - Startposition in X

Anzahl "ganze" Tiles in Y, die das Objekt überdeckt: (((ObjectPosY + ObjectSizeY) + 7) &~ 8 ) - Startposition in Y

Die ermittelten Werte sind Indizes innerhalb des Tile-Arrays, also "ganze" Tiles (!). Damit weißt Du, welche Tiles innerhalb des Arrays neu gezeichnet werden müssen. Das funktioniert genauso bei hexagonalen Tiles, vorausgesetzt, Du bekommst die Koordinaten in ein 2D-Array transformiert.

---

Das ist ungefähr das Gleiche wie ich es machen will mit den 4 Eckpunkten pro Objekt, denke ich. Was ist da schneller? Was macht (ObjektPosX +7) &~ 8 nochmal genau? Wird hier mit Nicht-8 UND-verknüpft (also mit 0111)?

---

Zitat:

---

Zitat:

---

In Deinem Fall ist das Ganze sogar noch ein wenig simpler, fällt mir gerade auf. Bei Deiner Grafik kann ein Objekt maximal 3 Tiles überdecken, da läßt sich das bestimmt noch stark vereinfachen (also nur mit den Objektkoordinaten arbeiten, die Größe des Objekts spielt dann wohl nur eine sehr untergeordnete Rolle).

---

Das ist richtig. Dazu kommen aber noch Überdeckungen von Objekten untereinander (Cursor über Turm usw.). Dafür hab ich die Layer eingeführt. In meiner ersten Version war auch nicht die Überdeckung das Problem, aber wenn mal mehrere animierte Objekte auf dem Schirm waren, wurde das Ganze sehr langsam. Hab noch nicht rausgefunden wieso, denke aber, dass die ganzen Iterationen, die im Animations- und Überdeckungsalgorithmus stattfinden Schuld waren.

---

Ich denke eher, daß da der Domino-Effekt ins Spiel kam, weil dann wohl jedesmal, wenns etwas ungünstig lief, das gesamte Bild neu gezeichnet wurde (s.O.). Da helfen die ClipRects.

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

Zitat:

---

Original von Reth:

Zitat:

---

Original von whose:

Zitat:

---

Original von Reth:
2. Was mache ich mit Objekten, die mehr als ein Tile überdecken? Denke mir dass so, dass deren linke untere Ecke (wenn man immer von oben links nach unten rechts blittet) ausschlaggebend ist. Über welchem Tile diese liegt, in dessen Layerliste wird das Objekt eingetragen.

---

Prinzipiell eine gute Idee... so kannst Du auch mehrere überlagernde Objekte relativ simpel verwalten, in diesem Fall über die Liste des Tiles. Achte nur drauf, daß Du dadurch nicht zu viele Blits fabrizierst (also nicht platt alles neu zeichnen, auch wenns nicht nötig ist), sonst wirds mächtig langsam bei vielen Überdeckungen.

Grüße

---

Hi whose,

ja das hab ich auch schon gedacht. In dem 2. Artikel steht auch was dazu.
Allerdings komme ich wohl um den Dominoeffekt nicht herum. Sobald ich ein Objekt aktualisiere muss ich alle anderen (oder benachbarten) überprüfen, ob sie überdeckt sind und ggf. neu zeichnen dann prüfen, ob sie andere überdecken etc.
Da ich Objekte an den Ecken meiner 6-Ecke hab, überdecken diese automatisch die benachbarten 6-Ecke, wenn an deren Ecken auch wieder Objekte sind, geht das Ganze weiter.

Hab noch keine Ahnung, wie ich darum herumkommen soll immer alle anderen Objekte auf Überdeckung zu prüfen?

---

Schau noch mal auf gamedev.net, da ist auch irgendwo ein Artikel versteckt, der sich mit hexagonal zeichnenden Engines beschäftigt. Da wird u.A. ein Weg gezeigt, wie sich die hexagonalen Tiles in ein simpels 2D-Array "pressen" lassen. Dann kannst Du auch relativ einfach eine Art "Damage Region"-Verwaltung aufbauen.

Übersetze Objekt-Koordinaten in Dein hexagonales System und Du weißt, wo sich etwas verändert hat, sobald Du irgend etwas mit einem Objekt veranstaltest (Koordinatenänderung z.B. zieht immer ein Neuzeichnen nach sich). In dem Fall wird das Objekt in die Liste des entsprechenden Tiles eingehängt und im Zeichen-State halt mitsamt allen evtl. vorhandenen Objekten neu gezeichnet, stur nach Liste. Die Tiles, die nicht von Veränderungen betroffen sind, tauchen nicht in der "Damage"-Liste auf und werden dann auch nicht neu gezeichnet.

Das Problem der Überdeckung läßt sich damit auch verhältnismäßig einfach lösen, die Höhe und Breite Deiner Objekte ist ja bekannt. Wenn Du für die Hex-Tiles ein 2D-Array hast, läßt sich mit relativ wenig Aufwand berechnen, welche weiteren Tiles von einer Veränderung durch ein Objekt betroffen sind. Das funktioniert dann ähnlich wie bei rechteckigen Tiles (wenn Du meine älteren Mails noch hast, die Geschichte mit der Erweiterung von Koordinaten auf eine z.B. glatt durch 8 teilbare Zahl gehört zu dem Themenkomplex).

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

Zitat:

---

Original von Reth:
@psd

Gerne!

@whose
Hab mal ein paar Artikel dort gelesen. Z.B. gehen http://www.gamedev.net/reference/articles/article748.asp und http://www.gamedev.net/reference/articles/article727.asp im Prinzip diesen Weg, den ich oben beschrieben habe.

Bleiben mir aber noch 2 Fragen:
1. Kann ich eine Matrix/ein Array vermeiden und meine 2-Dimensionale Landschaft aus Tiles in eine eindimensionales Array abbilden?

---

Zitat:

---

2. Was mache ich mit Objekten, die mehr als ein Tile überdecken? Denke mir dass so, dass deren linke untere Ecke (wenn man immer von oben links nach unten rechts blittet) ausschlaggebend ist. Über welchem Tile diese liegt, in dessen Layerliste wird das Objekt eingetragen.

---

Prinzipiell eine gute Idee... so kannst Du auch mehrere überlagernde Objekte relativ simpel verwalten, in diesem Fall über die Liste des Tiles. Achte nur drauf, daß Du dadurch nicht zu viele Blits fabrizierst (also nicht platt alles neu zeichnen, auch wenns nicht nötig ist), sonst wirds mächtig langsam bei vielen Überdeckungen.

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233