[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von Der_Wanderer:
Auf dem Classic ist es ein Sprite.
Auf einem anderen System kann es alles mögliche sein.

---

Zitat:

---

Ich weiss ja nicht wie Ralf seine Sprites erzeugt, aber wenn er Probleme hat sie zu Positionieren ist das sicher nicht systemfreundlich.

---

Noch dazu kommt, daß das auf GraKa-Systemen in den meisten Fällen eh nicht funktioniert, weil selbige selten mehr als das Sprite für den Mauszeiger emulieren.

Da wäre es eventuell geschickter, mit maskiertem Blit einen Satz Zeiger zu zeichnen, die sich dann auch "normal" positionieren lassen.

Grüße

--
---

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

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von Der_Wanderer:
Auf dem Classic ist es ein Sprite.
Auf einem anderen System kann es alles mögliche sein.

Ich weiss ja nicht wie Ralf seine Sprites erzeugt, aber wenn er Probleme hat sie zu Positionieren ist das sicher nicht systemfreundlich.

---

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von whose:
Noch dazu kommt, daß das auf GraKa-Systemen in den meisten Fällen eh nicht funktioniert, weil selbige selten mehr als das Sprite für den Mauszeiger emulieren.

---

Hm, da hab ich mich wohl zu früh gefreut.

Zitat:

---

Da wäre es eventuell geschickter, mit maskiertem Blit einen Satz Zeiger zu zeichnen, die sich dann auch "normal" positionieren lassen.

---

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von Ralf27:

Zitat:

---

Original von whose:
Noch dazu kommt, daß das auf GraKa-Systemen in den meisten Fällen eh nicht funktioniert, weil selbige selten mehr als das Sprite für den Mauszeiger emulieren.

---

Hm, da hab ich mich wohl zu früh gefreut.

Zitat:

---

Da wäre es eventuell geschickter, mit maskiertem Blit einen Satz Zeiger zu zeichnen, die sich dann auch "normal" positionieren lassen.

---

Oh, gib es wirklich keinen anderen Weg? Denn das wäre wirklich dann etwas schwierig. Denn der Hintergrund kann sich auch ändern durch z.b. Animationen. Dann würde der Aufwand bestimmt recht hoch werden. (Z.b. müßte ich immer feststellen ob die 2.Maus in dem Bereich ist in dem was verändert wird und das dann auch berücksichtigen, etc.)

---

Naja, Sprites auf einem Rechner mit Grafikkarte ist halt schwierig... ich kenne keine Grafikkarte, die mehr als ein Sprite unterstützen würde. Gerüchteweise habe ich mal vernommen, daß eine der EGS-GraKas von GVP immerhin zwei (einfarbige) Sprites geboten hätte, gesehen habe ich es aber nie.

Die Berücksichtigung eines zu ändernden Bereich ist aber nicht allzu schwierig.

Wenn Dich ein kurzes Flackern nicht stört, einfach bei jedem Neuzeichnen eines Bildbereichs die Koordinaten und die Ausdehung beider Mauszeiger überprüfen. Ist der neu zu zeichnende Bereich wenigstens teilweise innerhalb des Zeiger-Rechtecks, den Zeiger neu zeichnen. Die Überprüfung ist mathematisch keine große Sache (insgesamt 8 Punkte überprüfen, ob deren gedachte Linien irgendwo Schnittpunkte haben) und die CPU wird da problemlos mit fertig. Auch mit MB Compiler-Programmen.

Die "simpel und einfach"-Methode müßte für Deine Zwecke aber auch reichen, da Du ja keine Linien clippen willst sondern nur schauen, ob ein Rechteck mit einem Teil seiner Fläche in einem anderen liegt. Dafür reichts, die Eckpunkte und die Ausdehnung der Rechtecke zu testen.

Eventuell hat ja jemand ein einfaches Beispiel dazu auf die Schnelle "parat", ich bräuchte etwas, um eines aufzubereiten.

Grüße

--
---

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

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von Ralf27:
Hm, ok, dann muß ich wohl die Spritestory wieder terminieren. Schade. Die Sache mit dem Blitten ist so eine Sache. Ich bekomme diese auch selbst ist, das ist nicht das Problem. Es ist nur recht umfangreich. Denn es werden nur immer Teile des ganzen Verändert und das auch nicht immer und das ganze auch immer von unterschiedlichen Teilen des Programmes (Hintergrundroutinen, Spielfeldroutinen, etc.).

Somit wird aus der anfangs einfachen Erweiterung ein größeres Unterfangen. Ich frag mich eben auch ob ich wirklich diese Netzwerkmaus einbauen soll. Mal sehn.

Kurz nachgefragt:
Wie schaut es eigentlich mit den Bobs aus? Bzw. wie werden denn die beweglichen Objekte auf Grafikkarten systemkonform aufgebaut?

---

Zu den BOBs kann ich wenig sagen, hab sie nie genutzt. Nach den Bruchstücken, die von den entsprechenden Stellen in den RKMs im Gedächtnis habe, sollten die sich ähnlich verhalten wie "Blitten von Hand", in Deinem Fall wäre Dir aber auch mit einem Retten des Hintergrundes nicht gedient, weil der noch gar nicht feststeht, wenn das BOB gezeichnet wird.

Tut mir leid, weiter kann ich Dir da wohl nicht helfen

Vielleicht hat ja noch jemand anders eine gute Idee dazu, noch solltest Du die Hoffnung nicht aufgeben

Grüße

--
---

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

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von Michael_Mann:
Hmm whose,

erledigt das Retten des Hintergunds bevor der Bob gezeichnet wird nicht das Attribut "SmartRefresh" von sich aus?

---

Gute Frage... basieren BOBs denn auf der layers.library? Wenn ja, wäre das evtl. schon die Lösung seines Problems (layer sind die Lösung, die mir spontan auf die Frage einfällt, wie sowas wie BOBs wohl intern funktioneren, wenn sie den Hintergrund nicht beschädigen würden). Oder wird das bei den BOBs anders gelöst?

Wie gesagt, mit BOBs habe ich mich nie auseinandergesetzt...

Grüße

--
---

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

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von Michael_Mann:
Hmm,

BOBs werden mittels der gfx-library erzeugt (auch Sprites und VSprites werden so generiert).
Bei BOBs mußte man aber Flags setzen, ich glaube da gab es ein SaveBack-Flag das den Hintergund immer restaurierte und dann gerne zum Flimmern größerer BOBs führte.

---

Hm, ja, das wäre das, was ich aus meiner Erinnerung noch hervorkramen konnte. Also prinzipiell das Gleiche, als wenn man das BOB (bzw. den Zeiger) "von Hand" blitten würde (und vorher den Hintergrund sichert). Hätte mich auch etwas gewundert, wenn die layers.library da eine Rolle gespielt hätte... sonst wäre es ja nicht so kompliziert, "durchsichtige" Fenster zu erzeugen.

Das Problem bei Ralf scheint aber zu sein, daß sich der Hintergrund auch nach dem Blit und unabhängig davon noch ändern kann und er dann recht aufwändig ermitteln müßte, wo genau diese Änderung stattfinden soll, damit er den "handgemachten" Zeiger erneut drüberblitten kann.

Vertrackte Angelegenheit, wenn die Struktur des Programms bzw. des Zeichenvorgangs nicht auf die gewünschten Extra-Mauszeiger eingerichtet ist...

Grüße

--
---

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

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Das Problem bei Ralf scheint aber zu sein, daß sich der Hintergrund auch nach dem Blit und unabhängig davon noch ändern kann

---

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von thomas:
Ich würde jetzt die ganzen Updates in einer Off-Screen-Bitmap machen und dann am Ende des Zyklus alles auf einmal in das Fenster blitten. D.h. ich entferne am Anfang des Zyklus den Mauszeiger, rufe alle meine Routinen auf und füge am Ende den Mauszeiger wieder hinzu und erst dann blitte ich das ganze ins Fenster.

---

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von thomas:

Zitat:

---

Das Problem bei Ralf scheint aber zu sein, daß sich der Hintergrund auch nach dem Blit und unabhängig davon noch ändern kann

---

Die Frage hierbei ist, was "unabhängig" in diesem Zusammenhang bedeutet.

---

So, wie ich Ralf verstanden habe, kommt es bei seinem Programm in mehreren Funktionen, die voneinander wenig bis gar nichts wissen, zu Zeichenvorgängen. Taskmäßig macht das zwar keinen Unterschied, man kann dabei aber von "unabhängig voneinander" sprechen, weil funktionsübergreifend keine Information vorhanden ist, wer was zu welchem Zeitpunkt wo hinzeichnet.

Wie dann also entscheiden, welcher Teil des Hintergrundes bereits feststeht, so daß das "Retten" sinnvoll ist?

Er scheut wohl (wie gesagt, so wie ich das verstanden habe) den Umbau seines Programms in der Hinsicht, daß der Zeichenprozess "überwachbarer" wird, als er bis jetzt abläuft. Sprites würden ihm da sicherlich helfen, nur schließt das GraKa-Betrieb nahezu aus.

Auch die Offscreen-Bitmap würde da nicht viel bringen, weil er eben nicht "vorhersagen" könnte, was in welcher Position seines Fensters wann gezeichnet wird.

Deswegen schrieb ich auch "vertrackte Sache". Er hat da halt ein wenig beim Design seines Programms ins Klo gegriffen (sofern meine Auslegung seiner Posts stimmt!). Entweder muß er das komplett umbauen oder eben halt "ferngesteuerte" Mauszeiger fallen lassen.

Genauer kann das aber wohl nur Ralf selbst klären. Mal schauen, was er zu unseren Mutmaßungen meint

Grüße

--
---

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

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Auch die Offscreen-Bitmap würde da nicht viel bringen, weil er eben nicht "vorhersagen" könnte, was in welcher Position seines Fensters wann gezeichnet wird.

---

code:

---

anfang:
	call karte_zeichnen
	call status_zeichnen
	call liste_zeichnen
	call uhr_zeichnen
	call dingsbums_zeichnen
	blit bitmap in fenster
	blit zeiger in fenster
goto anfang

---

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von thomas:

Zitat:

---

Auch die Offscreen-Bitmap würde da nicht viel bringen, weil er eben nicht "vorhersagen" könnte, was in welcher Position seines Fensters wann gezeichnet wird.

---

Er muß doch gar nichts vorhersagen. Wenn es einen Zyklus gibt, kann er das ganze Fenster im Hintergrund zeichnen und dann auf einmal aktualisieren.

---

Ja, wenn. Und wenn nicht? Wenn z.B. eine der Netzwerk-Funktionen Bereiche neuzeichnet, was, je nach Konstallation, durchaus auch mal nach dem Zeichnen des Zeigers geschehen kann (denk dran: Das ist Vermutung. Solange Ralf nichts konkreteres dazu sagt, kann man halt nur mutmaßen. Wenns so ist, wie ich derzeit vermute, ist es zwar schlechtes Design, aber wer ist schon perfekt?)

Dann macht er ein dummes Gesicht und das Programm "Zeichenfehler" (z.B. unsichtbare Zeiger oder teilweise nicht korrekt gezeichnete Bereiche im "Hintergrund").

Vielleicht erwähnt er ja in einem der nächsten Postings, wie sein Programm "verdrahtet" ist, dann wissen wir mehr und können ggf. auch konkretere Vorschläge machen bzw. den Kopf schütteln.

Ich halte ihn inzwischen für so gewieft, daß er erkennt, wo er simple Zeichenschleifen durchläuft oder wo er eben zu viele Programmzweige "nebeneinander" laufen läßt. Bisher klingt es für mich nach letzterem.

Grüße

--
---

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

[ - Antworten - Zitieren - Direktlink - ]

Hallo und erst mal Danke an alle die mir helfen möchten:

Wegen dem Programmdesign:
Am Anfang wollte ich einfach nur ein Programm schreiben mit dem man Sudoku spielen kann. Ganz einfach ohne alles. Erst nach und nach ist alles dazu gekommen und konnte mir ehrlichgetippt am Anfang nicht vorstellen wie viel ich in das Programm einbauen werden. Somit ist das ganze Programm also gewachsen mit allen Vor- und Nachteilen. Zuerst war alles statisch, dann sind kleine Hintergrundänderungen dazugekommen, Feldanimationen, Zähler, ... also Stück für Stück.

Ich könnte zwar die untereinander relativ unabhängigen Routinen zusammenfassen, aber dazu müßte ich dann doch einiges umbauen. Die Idee mit der weiteren Bitmap ist schon recht gut und gefällt mir auch gut, allerdings hat das ganze einen kleines Problem: Chiprammangel bei größeren Skins. Leider wird es jetzt schon langsam etwas knapp wenn auch noch Sound geladen werden. Bei Grafikkartenrechnern sieht das bestimmt etwas anderst aus, aber es soll auch noch unter AGA spielbar sein und eventuell auch unter OCS/ECS, sofern auf mindestens OS3.0 aufgerüstet.

Ich finde es aber dennoch sehr seltsam das Sprites nicht auf Grafikkarten emuliert werden (was mir das ganze natürlich sehr vereinfacht hätte ), ich vermute sogar das das Programm mit Sprite sogar auf WinUAE laufen würde (Vorsicht, Vermutung! ), aber ich möcht aber auch, das es auf möglichst vielen unterschiedlichen Rechnerkonfigurationen läuft.

Es gibt jetzt schon einige Möglichkeiten:
* Ich baue Sprites ein für Customchipsatzrechner und die Bufferstory für Grafikkartenrechner. Leider ist es halt so, das halt noch ein Buffer der dann auch noch bei Customchipsatzrechnern im Chipram liegen würde, etwas zuviel.
* Der Netzwerkmauszeiger kann nur benutzt werden wenn das komplette Spielfeld statisch bleibt, also nicht verändert wird. So kann man auch etwas erklären wenn man möchte.
* Ich lass es einfach mit dem Netzwerkmauszeiger
* ...

Kurz noch etwas am Rande:
Wenn man FBlit benutzt, dann könnten ja auch die Bitmaps im Fastram liegen, auch wenn die Customchips im Spiel sind (hab ich einfach mal vor einiger Zeit getestet). So eine Abfrage ob FBlit aktiv ist wäre wohl noch eine Möglichkeit, aber geht wohl schon mehr Richtung "schlechte Programmierung".

Hm, die Programmierung des Amigas ist teilweise wirklich nicht einfach, wenn es auf möglichst vielen Amigas laufen soll. Ich dachte bis jetzt immer das die Programme eigentlich immer laufen wenn man 100% Systemkonform programmiert. Aber die Sprites sprechen dann wohl eine andere Sprache.
--
http://www.alternativercomputerclub.de.vu

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von Ralf27:
Ich könnte zwar die untereinander relativ unabhängigen Routinen zusammenfassen, aber dazu müßte ich dann doch einiges umbauen. Die Idee mit der weiteren Bitmap ist schon recht gut und gefällt mir auch gut, allerdings hat das ganze einen kleines Problem: Chiprammangel bei größeren Skins. Leider wird es jetzt schon langsam etwas knapp wenn auch noch Sound geladen werden. Bei Grafikkartenrechnern sieht das bestimmt etwas anderst aus, aber es soll auch noch unter AGA spielbar sein und eventuell auch unter OCS/ECS, sofern auf mindestens OS3.0 aufgerüstet.

---

Speicher wäre das kleinste Problem... anhand der BitMap-Attribute kannst Du feststellen, auf welcher Art Screen das Programm läuft. BMF_STANDARD würde z.B. aussagen, daß es sich um eine Planar-Bitmap handelt, was die Wahrscheinlichkeit für einen ECS/AGA-Betrieb doch ziemlich erhöht

Zitat:

---

Ich finde es aber dennoch sehr seltsam das Sprites nicht auf Grafikkarten emuliert werden (was mir das ganze natürlich sehr vereinfacht hätte ), ich vermute sogar das das Programm mit Sprite sogar auf WinUAE laufen würde (Vorsicht, Vermutung! ), aber ich möcht aber auch, das es auf möglichst vielen unterschiedlichen Rechnerkonfigurationen läuft.

---

Ja, auf dem WinUAE würde es mit Sprites laufen. Sofern man keinen Screenmode wählt, der von P96 bereitgestellt wird, dann wäre es aus mit Sprites

Es ist auch gar nicht sooo seltsam: Die GraKas beherbergen meist ganz einfach keine Hardware für Sprites (oder Copper, der fehlt z.B. auch völlig), so daß diese in Software emuliert werden müßten. Den Aufwand, den man dafür treiben müßte, müßtest Du Dir nun eigentlich leise vorstellen können, nachem Du bemerkt hast, wie schwierig es sein kann, "einfach mal so etwas zu blitten".

Die RTG-Software müßte, genau wie Du aktuell, bei jedem einzelnen Zeichenvorgang vermerken, wo etwas verändert wurde auf einem Screen und dementsprechend die Sprite-Grafiken und/oder den Hintergrund erneuern. Auf 68K-System vermutlich sehr langsam.

Zitat:

---

Es gibt jetzt schon einige Möglichkeiten:
* Ich baue Sprites ein für Customchipsatzrechner und die Bufferstory für Grafikkartenrechner. Leider ist es halt so, das halt noch ein Buffer der dann auch noch bei Customchipsatzrechnern im Chipram liegen würde, etwas zuviel.

---

Zitat:

---

Hm, die Programmierung des Amigas ist teilweise wirklich nicht einfach, wenn es auf möglichst vielen Amigas laufen soll. Ich dachte bis jetzt immer das die Programme eigentlich immer laufen wenn man 100% Systemkonform programmiert. Aber die Sprites sprechen dann wohl eine andere Sprache.

---

Du sagst es: eigentlich. Bis auf gewisse Spezialitäten ist das auch so, das allermeiste (98% würde ich sagen) konform Programmierte läuft ja auch. Aber Sprites und Copper fehlen den PC-Grafikchips, Emulation dieser Features via RTG gabs eigentlich nie. Man muß mit dem klarkommen, was man hat

Grüße

--
---

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

[ - Antworten - Zitieren - Direktlink - ]

Ok, also lasse ich die Sprite-Story erst mal wieder drausen. Eventuell mach ich mich später mal wieder dran, aber das ganze ist ja nicht sooo wichtig. Wäre aber dennoch ein schönes Gimmik geworden
--
http://www.alternativercomputerclub.de.vu

[ - Antworten - Zitieren - Direktlink - ]

Hab es nach langem überlegen doch eingebaut und es läuft. Also keine Spritestory sondern blitten. Aber nicht mit einem Buffer sondern direkt und zwar mit Invertieren. Genauergetippt ist da der Netzwerkmauszeiger einfach ein Fadenkreuz das invertiert gezeichnet wird. Beim zweiten mal zeichnen verschwindet dann dieser Zeiger wieder. Ist zwar nicht besonderst schön, aber es geht und als Übergangslösung ein nettes Gimmik.
--
http://www.alternativercomputerclub.de.vu

[ - Antworten - Zitieren - Direktlink - ]