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

amiga-news.de Forum > Programmierung > Netzwerkmauszeiger [ - Suche - Neue Beiträge - Registrieren - Login - ]

-1- [ - Beitrag schreiben - ]

18.12.2006, 21:19 Uhr

Ralf27
Posts: 2779
Nutzer
Ich hab vor via Netzwerk einen zweiten Mauszeiger anzuzeigen. Dieser soll einfach nur denn Zeiger anzeigen und mehr nicht. Allerdings soll dieser auch an denn korrekten Koordinaten angezeigt werden und da hab ich jetzt ein Problem:
Ich hab mich für die Sprites entschieden und da ist es nunmal so, das diese in 320*256 laufen, egal was für eine Auflösung eingestellt ist.

Und genau dieses Umrechnen (zja, wie schauts aus auf Grafikkarten, oder z.b. wenn der User ein Screen hat von z.b. 320*200, die Auflösung aber 640*512 ist...) und wenn ich jetzt das ganze auf der WB laufen lassen, der Netzwerkmauszeiger aber nur in einem Fenster laufen soll. ... ja, da gehts rund mit dem Umrechnen.
Der Punkt ist, gibt es nicht eine andere Möglichkeit? Das Problem ist halt, das der Inhalt des Fensters sich recht oft verändern kann und das dieser Anzeiger halt unabhängig davon sein soll.

Sinn und Zweck des ganzen:
Ich hätte gerne einen Mauszeiger für ein Netzwerkspiel, damit der gegenüber im Netzwerk was auf dem Bildschirm zeigen kann, wenn er möchte. Und dieser Bildschirm kann ein eigener Screen sein oder ein Fenster auf der WB.

Ich vermute mal das da ein Sprite am besten wäre, aber wie bekomme ich da die Umrechnung der Koordinaten am flexsibelsten hin das es überall läuft? Oder gibt es eine bessere Möglichkeit der Darstellung eines Netzwerkmauszeigers?
--
http://www.alternativercomputerclub.de.vu

[ - Antworten - Zitieren - Direktlink - ]

18.12.2006, 23:28 Uhr

NoImag
Posts: 1050
Nutzer
@Ralf27:

Verstehe ich das richtig? Du hast zwei Rechner, auf beiden läuft Dein Spiel. Es kann sowohl in einem Fenster auf der WB als auch auf einem eigenen Screen laufen. Dies kann bei den beiden Rechnern unterschiedlich eingestellt sein. Du möchtest, dass der Mauszeiger auf Rechner A im Fenster von Rechner B immer an der richtigen Position angezeigt wird.

Ich würde mir die Position des Mauszeigers auf Rechner A in Fenster-Koordinaten besorgen und an Rechner B schicken. Dies sollte kein Problem sein (Window-Struktur).
Auf Rechner B musst Du umrechnen nach den Einstellungen auf Rechner B. Ich fürchte, da kommst Du nicht drum herum. Ob ein Sprite dafür wirklich die beste Lösung ist, kann ich nicht sagen, weil ich mit Sprites noch nicht viel gemacht habe.

Tschüß


[ - Antworten - Zitieren - Direktlink - ]

18.12.2006, 23:50 Uhr

Ralf27
Posts: 2779
Nutzer
Die Besorgung der Koordinaten und die Umrechnung von Rechner A auf Rechner B ist nicht das Problem.

Das Problem ist, das die Sprite immer mit 320*256 arbeiten, egal was für eine Auflösung aktiv ist(jedenfalls habe ich das so verstanden).
Und da geht es halt schon rund: wie sieht es z.b. auf Grafikkarten aus, bzw. kann ich mir da ne Menge Probleme vorstellen...

Also ist viel mehr das Problem die Koordinaten im "Bitmapauflösungsraster" auf das "Spriteraster".

Oder gibt es eine bessere, elegantere Möglichkeit? Dieser Mauszeiger muß ja nur auf der Spielfläche des Spieles sichtbar sein. Allerdings kann sich der Hintergrund leider auch recht oft unter diesem Netzwerkmauszeiger ändern.
--
http://www.alternativercomputerclub.de.vu

[ - Antworten - Zitieren - Direktlink - ]

19.12.2006, 15:24 Uhr

Der_Wanderer
Posts: 1229
Nutzer
Nun, warum nimmst du nicht den echten Mauszeiger ?
Warum ein Sprite ? (btw, das wird auf Grakas sowieso nicht funktionieren)

Den Mauszeiger kann man recht einfach setzen, mit einem gefaktem Input Event für das input.device, dass den MP an einer absoluten Stelle positioniert, wie bei einem Grafik Tablet.

Wenn du nicht weisst wie das geht, poste ich dir gerne den Code dazu hier rein. (Amiblitz)

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


[ - Antworten - Zitieren - Direktlink - ]

19.12.2006, 15:49 Uhr

thomas
Posts: 7716
Nutzer
@Der_Wanderer:

Der echte Mauszeiger *ist* ein Sprite.

Außerdem möchte er zwei Zeiger haben, für jeden Spieler einen.

Gruß Thomas

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

[ - Antworten - Zitieren - Direktlink - ]

19.12.2006, 15:54 Uhr

Der_Wanderer
Posts: 1229
Nutzer
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.

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


[ - Antworten - Zitieren - Direktlink - ]

19.12.2006, 16:27 Uhr

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


Was thomas meint, ist, daß der Mauszeiger technisch betrachtet immer ein Sprite ist, selbst, wenn es von der RTG-Software emuliert werden muß.

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

--
---

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

[ - Antworten - Zitieren - Direktlink - ]

20.12.2006, 22:32 Uhr

Ralf27
Posts: 2779
Nutzer
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.

Ich hab die Systemroutinen benutzt. Also vermute ich mal, das das Systemfreundlich ist.

Es ist ja egal wie die Sprites auf anderen Systemen emuliert werden, Hauptsache sie werden es. Und es wäre doch sehr verwunderlich wenn die Hardwaresprites nicht emuliert werden würden, z.b. von CybergraphX oder sonst was. So wie eben auch der Mauszeiger auf denn anderen Systemen emuliert wird.


--
http://www.alternativercomputerclub.de.vu

[ - Antworten - Zitieren - Direktlink - ]

20.12.2006, 22:35 Uhr

Ralf27
Posts: 2779
Nutzer
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.)
--
http://www.alternativercomputerclub.de.vu

[ - Antworten - Zitieren - Direktlink - ]

20.12.2006, 23:45 Uhr

whose
Posts: 2156
Nutzer
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

--
---

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

[ - Antworten - Zitieren - Direktlink - ]

20.12.2006, 23:59 Uhr

Ralf27
Posts: 2779
Nutzer
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?
--
http://www.alternativercomputerclub.de.vu

[ - Antworten - Zitieren - Direktlink - ]

21.12.2006, 00:36 Uhr

whose
Posts: 2156
Nutzer
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

--
---

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

[ - Antworten - Zitieren - Direktlink - ]

21.12.2006, 23:34 Uhr

Michael_Mann
Posts: 1012
Nutzer
Hmm whose,

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


Michael

[ - Antworten - Zitieren - Direktlink - ]

21.12.2006, 23:56 Uhr

whose
Posts: 2156
Nutzer
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

--
---

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

[ - Antworten - Zitieren - Direktlink - ]

22.12.2006, 00:32 Uhr

Michael_Mann
Posts: 1012
Nutzer
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.


Michael

[ - Antworten - Zitieren - Direktlink - ]

22.12.2006, 00:39 Uhr

whose
Posts: 2156
Nutzer
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

--
---

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

[ - Antworten - Zitieren - Direktlink - ]

22.12.2006, 09:46 Uhr

thomas
Posts: 7716
Nutzer
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.

Wenn man nicht gerade mit mehreren Tasks arbeitet, und davon gehe ich mal aus, denn einen neuen Task in Basic aufzumachen, stelle ich mir schwierig vor, dann hat man einen Zyklus, den man immer wieder durchläuft. D.h. man ruft nacheinander mehrere Routinen auf, die jeweils ihren Bereich des Fensters aktualisieren und irgendwann ist man durch und fängt wieder von vorne an.

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.

Sinnvollerweise sollte man sich merken, ob sich überhaupt etwas geändert hat und vielleicht einen Spezialfall einrichten, wenn sich nur der Mauszeiger bewegt hat, sonst könnte die Geschwindigkeit etwas leiden.

Gruß Thomas

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

[ - Antworten - Zitieren - Direktlink - ]

22.12.2006, 14:14 Uhr

Holger
Posts: 8116
Nutzer
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.


Wozu den Mauszeiger überhaupt in die Off-Screen-Bitmap zeichnen? Da gehört er doch gar nicht hin. Wenn man ihn nicht in die Off-Screen-Bitmap zeichnet, muss man ihn auch nicht vorher entfernen.

D.h. man muss lediglich die Off-Screen-Bitmap auf den Screen blitten und dabei den Mauszeiger als Maske aussparen. Oder man spart sich die Maske und blittet Off-Screen-Bitmap, gefolgt vom Mauszeiger. Bei der kurzen Zeit zwischen den zwei Blits flimmert nichts.

Und dann ist das Bewegen des Mauszeigers auch einfach. Man blittet einfach das Rechteck in der Größe des Mauszeigers aus der Off-Screen-Bitmap, die ja vom letzten Zeichenvorgang gültige Daten enthält, an die alte Stelle und den Mauszeiger an die neue Stelle. Und bei zwei so kleinen Vorgängen sollte kein zusätzlicher Puffer nötig sein. Ein WaitBOV() vorher kann natürlich nicht schaden.

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

[ - Antworten - Zitieren - Direktlink - ]

22.12.2006, 16:51 Uhr

whose
Posts: 2156
Nutzer
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

--
---

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

[ - Antworten - Zitieren - Direktlink - ]

22.12.2006, 18:18 Uhr

thomas
Posts: 7716
Nutzer
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.

Ungefähr so:

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


Die einzelnen Zeichenfunktionen brauchen nichts voneinander zu wissen, außer der Zielbitmap bzw. dem Zielrastport. Und das müssen sie bereits jetzt auch schon wissen.

Gruß Thomas

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

[ Dieser Beitrag wurde von thomas am 22.12.2006 um 18:18 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

22.12.2006, 18:44 Uhr

whose
Posts: 2156
Nutzer
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

--
---

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

[ - Antworten - Zitieren - Direktlink - ]

22.12.2006, 22:52 Uhr

Ralf27
Posts: 2779
Nutzer
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 :D ), ich vermute sogar das das Programm mit Sprite sogar auf WinUAE laufen würde (Vorsicht, Vermutung! :D ), 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 - ]

22.12.2006, 23:28 Uhr

whose
Posts: 2156
Nutzer
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 :D ), ich vermute sogar das das Programm mit Sprite sogar auf WinUAE laufen würde (Vorsicht, Vermutung! :D ), 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.


In diesem Fall würde es sogar noch etwas einfacher: prüfe beim Start auf Vorhandensein der cybergraphics.library und dann, ob das BitMap-Attribut des betreffenden Screens nicht BMF_STANDARD ist, dann weißt Du, daß es auf einer GraKa betrieben wird. In diesem Fall kannst Du die Grafik mittels Offscreen-Buffer aufbauen.

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

--
---

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

[ - Antworten - Zitieren - Direktlink - ]

25.12.2006, 13:25 Uhr

Ralf27
Posts: 2779
Nutzer
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 - ]

30.12.2006, 01:06 Uhr

Ralf27
Posts: 2779
Nutzer
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 - ]


-1- [ - Beitrag schreiben - ]


amiga-news.de Forum > Programmierung > Netzwerkmauszeiger [ - Suche - Neue Beiträge - Registrieren - Login - ]


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