Suche - amiga-news.de Forum

amiga-news.de Forum > Suche

[ - Suche - Neue Beiträge - Registrieren - Login - ]

Erste << 30 31 32 33 34 -35- 36 37 38 39 40 >> Letzte

Ergebnisse der Suche: 8130 Treffer (30 pro Seite)

Holger Nutzer

06.05.2011, 12:31 Uhr

[ - Direktlink - ]

Thema: Neue Frage zu Überdeckungen
Brett: Programmierung

Zitat:
Original von Reth:
Aber wenn ich in diesem Fall die OriginalRegion nach EndRefresh wieder herstelle, wird dann nicht auch wieder das Damage-Flag gesetzt und die in dieser alten Region enthaltenen Bereiche ebenfalls wieder als beschädigt angesehen?

Moment mal.
Wie oft soll ich eigentlich noch sagen, dass alles, was Du tust, zwischen BeginRefresh und EndRefresh passieren soll?

Insofern möchte ich nie wieder etwas von nach EndRefresh hören.

Aber trotzdem möchte ich noch mal für die Akten festhalten, dass das Installieren einer Clipping-Region weder die Damage-Liste verändert, noch das Damage-Flag setzt.

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

Holger Nutzer

05.05.2011, 19:34 Uhr

[ - Direktlink - ]

Thema: Neue Frage zu Überdeckungen
Brett: Programmierung

Zitat:
Original von Reth:
Aber mit der unter "Letzteres" genannten Lösung manipuliere ich ja die ClippingRegion nicht, sondern installiere meine eigene, die ich aus allen zu aktualisierenden Bereichen ermittle.

Den Teil hatte ich wohl überlesen. Mir ging es nur darum, dass alles zwischen BeginRefresh und EndRefresh stattfindet.

Zitat:
Die Frage war nur, ob ich zu meiner eigenen ClippingRegion die Bereiche der Original-ClippingRegion hinzufügen muss oder nicht, bevor ich meine Objekte aktualisiere?

Ja, Du willst ja sowohl die Bereiche, die sich aus der Anwendungslogik her verändert haben, als auch die Bereiche, die "beschädigt" wurden, aktualisieren. Das heißt, Du nimmst eine Oder-Verknüpfung vor.

Die Alternative wäre zwei Zeichenvorgänge durchzuführen, einen mit der Clip-Region, die von BeginRefresh installiert wurde, und einen mit Deiner Clip-Region.

Der Vorteil des Verknüpfens liegt darin, dass Bereiche, die sowohl "beschädigt", als auch von veränderten Objekten betroffen sind, nur einmal gezeichnet werden.

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

Holger Nutzer

04.05.2011, 22:02 Uhr

[ - Direktlink - ]

Thema: Neue Frage zu Überdeckungen
Brett: Programmierung

Zitat:
Original von Reth:
Die erste Funktion benötige ich immer dann, wenn ich denke, dass die Gadgets refreshed werden müssen, oder wenn ich Gadgets verändert habe und deswegen aktualisieren will.
Passt das soweit?

Passt.

Zitat:
Nach diesem Verständnis würde ich dann RefreshGadgets auch immer zwischen BeginRefresh und EndRefresh rufen, sobald ich eine Refresh-Message bekommen habe. Korrekt?

Nein. Intuition zeichnet Gadgets und Fensterrahmen selbsttätig neu, wenn es Damage verursacht hat und nur in diesen Fällen bekommst Du Refresh-Messages. Nur wenn Du hinterm Rücken von Intuition Damage verursacht hast (siehe vergangene Diskussion zu Scroll-Funktionen), der auch Gadgets betreffen könnte, musst Du den Refresh der möglicherweise betroffenen Gadgets selbst anstoßen. Ansonsten dient RefreshGadgets() ausschließlich zum Updaten nach Änderungen.

Bei gadtools gibt es die Besonderheit, dass die Gadgets u.U. nicht alle Grafik-Informationen zum automatischen Neuzeichnen beinhalten. Das liegt daran, dass gadtools zumindest in älteren Versionen nicht auf BOOPSI aufsetzt (es war eine Parallelentwicklung). Genau deshalb gibt es die Funktionen GT_BeginRefresh und GT_EndRefresh, die die entsprechenden Intuition-Funktionen komplett ersetzen, wenn man gadtools benutzt. Diese Funktionen rufen nicht nur BeginRefresh und EndRefresh auf, sondern führen auch die für den kompletten Gadget-Refresh nötigen Zeichenbefehle aus.

Deshalb sieht die Trivial-Routine zum vollständigen Refresh eines Gadtools-Fenster (wenn man eine Refresh-Message bekommen hat, wohlgemerkt), das außer Gadgets nicht anderes enthält, genau so aus:

code:

GT_BeginRefresh();
GT_EndRefresh();

Weil aber mindestens diese zwei Routinen für einen Refresh aufgerufen werden müssen, arbeiten Gadtools-Oberflächen auch nicht mit NoCareRefresh zusammen.

Zitat:
Für das Herstellen des Originalzustandes: Ich hatte verstanden meine Bereiche mit der alten ClipRegion zu verknüpfen, muss diese Originalregion aber am Schluss wieder herstellen.
Ist dies denn überhaupt sinnvoll, oder merke ich mir nur die alte ClipRegion nach BeginRefresh, aktualisiere dann meine Bereiche mit einer eigenen, neuen ClipRegion und stelle die Original-ClipRegion vor EndRefresh wieder her?

Letzteres.
Vor BeginRefresh besitzt der Layer ja noch gar keine ClippingRegion. Erst der Aufruf von BeginRefresh macht ja aus der bisherigen Damage-Liste die zugehörige Clipping-Region. Dann kannst Du diese manipulieren, musst natürlich vor EndRefresh den alten Zustand wiederherstellen.

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

Holger Nutzer

04.05.2011, 14:10 Uhr

[ - Direktlink - ]

Thema: Ölgau und kein Ende
Brett: Get a Life

Zitat:
Original von DrNOP:
@Holger:
Wenn das tatsächlich als Wucher klassifiziert werden kann muß ich ja erst mal keinen Anwalt kennen.

Hab ich auch nirgendwo behauptet, dass Du einen Anwalt brauchst. Wenn diese Betroffenen aber nicht auf die Idee kommen, brauchen sie wohl jemanden, der sie berät. Und Du kannst es drehen und wenden, wie Du willst: Du kannst ihnen weder einen Beratung, noch ein juristische Maßnahme in ihrem Sinne aufzwingen.

Das ist deren Problem.

Ich hatte schon ähnliches erlebt, mit am Ende vierstelligen Telefonrechnungen. Hab aber noch nie erlebt, dass ich die am Ende wirklich zahlen musste.

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

Holger Nutzer

02.05.2011, 13:05 Uhr

[ - Direktlink - ]

Thema: Ölgau und kein Ende
Brett: Get a Life

Zitat:
Original von DrNOP:
Was ich nicht verstehe ist, daß man da jetzt auf Esso's Großzügigkeit angewiesen ist, damit die beiden Kunden ihr Geld wiederbekommen.

Wie die Kunden versuchen, ihr Geld wiederzubekommen, ist ihre eigene Sache. Selbst wenn Du den perfekten Anwalt für diese Problematik kennen würdest, kannst Du ihn diesen Kunden nicht aufzwingen.

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

Holger Nutzer

01.05.2011, 14:38 Uhr

[ - Direktlink - ]

Thema: Neue Frage zu Überdeckungen
Brett: Programmierung

Zitat:
Original von Reth:
Sollte ich in meinem Fall dann besser GT_BeginRefresh() und GT_EndRefresh() verwenden, auch wenn ich meine Gadgets gar nicht mehr aktualisieren muss? Oder spielt das hier keine Rolle und ich kann BeginRefresh() bzw. EndRefresh() verwenden?

Woher weißt Du denn bei einem normalen Refresh-Zyklus, dass die Gadgets keinen Refresh benötigen?

Zitat:
Habe auch gerade gesehen, dass ich WFLG_NOCAREREFRESH mit Gadtools gar nicht verwenden darf/soll. Hatte damit bisher aber keine Probleme!

Ich vermute mal, dass diese Beschränkung ab AOS3.0 keine Rolle mehr spielt, aber offiziell aufgehoben wurde sie nicht. Das hängt aber auch von den verwendeten Elementen ab, simple Objekte wie Buttons haben schon immer ohne expliziten Refresh funktioniert.

Die korrekte Verwendung gemäß Spezifikation schließt aber NoCareRefresh aus.

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

Holger Nutzer

29.04.2011, 11:23 Uhr

[ - Direktlink - ]

Thema: Ölgau und kein Ende
Brett: Get a Life

Zitat:
Original von Maja:
Ob wir uns deswegen selbst ausrotten sollten? Nun, das wäre doch auch wieder nur ein drastischer Eingriff in die Natur. ... Was wir auch tun, wir pfuschen der Natur dabei immer ins Handwerk.

Genau das meinte ich.

Zitat:
Original von Maja:

Zitat:
Original von DrNOP:
Immerhin ist der Mensch ein Teil der Natur.
Richtig. Allerdings der einzige, der sich seine eigene "Natur" schafft.

Ist er das?

Biber bauen Staudämmer, um aus fließenden Gewässern ruhende zu machen. Damit schaffen sie sich ihre eigene, zweckmäßige Natur.

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

Holger Nutzer

28.04.2011, 11:56 Uhr

[ - Direktlink - ]

Thema: Ölgau und kein Ende
Brett: Get a Life

Zitat:
Original von Maja:
Viel interessanter finde ich aber, dass sich hier nun quasi wie von selbst ein schlagartiges Aussterben der Gattung Mensch als These manifestiert.

Nein, der Ausgangspunkt war die Hypothese, dass das Beste, was der Mensch für die Natur tun könnte, seine eigene Abschaffung wäre. Damit er nicht mehr in die Natur eingreifen kann.

Zitat:
Nun brauchen unsere Haustiere uns in Wahrheit auch nicht unbedingt zum Überleben. Hund, Katze und Co. hätten es ohne Menschen nicht mehr so komfortabel, kämen aber trotzdem auch ohne uns klar.

Ja, aber in Hinblick auf die Ausgangsthese kann man eben darauf hinweisen, dass ein Freilassen all dieser Tiere ebenfalls einen (letzten) drastischen Eingriff in die Natur darstellt.

Zitat:
Original von DrNOP:
... war mein erster Gedanke, daß das so wohl auch nicht klappen wird, weil dieser Tsunami für diesen Zweck zu sehr örtlich begrenzt war und nicht schnell genug noch weitere woanders in der Welt hinterher kamen.

Und vor allem sind Erbeben und Tsunamis keine besonders neuartige Erscheinung, sondern treten, gerade in Japan, alle naselang auf und führen nicht zur Vernichtung der Menschheit. Falls diese angestrebt war, war es an sich schon ein guter Move, Atomkraftwerke genau in diese gefährdeten Gebiete zu bauen, aber auch das reicht nicht wirklich zur Ausrottung.

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

Holger Nutzer

27.04.2011, 12:41 Uhr

[ - Direktlink - ]

Thema: Ölgau und kein Ende
Brett: Get a Life

Zitat:
Original von DrNOP:
Wenn wir der Erde auf einen Schlag die Reste von Milliarden Menschen zu "verdauen" geben, ist das für das Ökosystem Erde IMHO leichter zu verkraften als noch weitere tausende Jahre menschlichen Wirkens.

Wie man's nimmt. Das Ökosystem verdaut alles, weil es im Gegensatz zum Menschen ganz einfach gar kein Interesse am Erhalt des Ist-Zustandes besitzt. Vor Millionen von Jahren waren Gifte in der Atmosphäre ganz normal, dann breiteten sich Einzeller immer weiter aus und begannen die Atmosphäre mit Sauerstoff zu verpesten. Vielleicht wäre die Atmosphäre in ein paar Jahrtausenden auch wieder giftig, wenn man die Natur sich selbst überlasse würde, wer weiß.

Es ist der Mensch, der den aktuellen Zustand, also den Zustand, der für sein eigenes Überleben komfortabel ist, als den "richtigen" Zustand der Umwelt ansieht. Und aus dieser egozentrischen Perspektive ist das auch sinnvoll. Wenn der Mensch sich anschickt, die "Umwelt zu schützen", dann schützt er vor allem sich selbst.

Wenn er allerdings sich selbst abschaffen würde, dann wäre die Grundlage für den Umweltschutz nicht mehr vorhanden. Es würden weiterhin Tierarten aussterben und es würde auch weiterhin immer wieder Klimaveränderungen geben, vielleicht auch irgendwann wieder ein Komet ungehindert einschlagen. Es wäre nur niemand mehr da, der das als schlecht einstufen könnte.

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

Holger Nutzer

26.04.2011, 20:57 Uhr

[ - Direktlink - ]

Thema: Ölgau und kein Ende
Brett: Get a Life

Zitat:
Original von Maja:
Sagt wer?

Die Physik und die Mathematik.

Holger Nutzer

26.04.2011, 16:29 Uhr

[ - Direktlink - ]

Thema: Ölgau und kein Ende
Brett: Get a Life

Zitat:
Original von DrNOP:
Der Weisheit letzter Schluß ist, uns selbst auszurotten. Nur dann ist sichergestellt, daß wir nicht in die Natur eingreifen...

Mal abgesehen davon, dass wir auch Teil der Natur sind und damit unsere eigene Ausrottung ebenfalls ein Eingriff in die Natur wäre: wer räumt dann die Leichen weg? Andernfalls besteht bei dieser Menge ja ebenfalls das Risiko, dass das Ökosystem der Erde kippt. Und was ist mit den Haus- und Nutztieren? Freilassen oder töten? Beides wäre ein Eingriff in die Natur.

Zitat:
Original von Maja:

Zitat:
Original von jochen22:
Ich glaube nicht, daß wir Menschen bezogen auf das Universum
relevant sind.
Absout sicher? Es gibt z. B. Pläne, die Flugbahn sehr großer Asteroiden auf Kollisionskurs mit der Erde per Raketenbeschuss zu ändern. Was ein so abgelenkter Himmelskörper an anderer Stelle im Universum anrichten würde, interessiert dabei offensichtlich nicht.

Richtig. Denn egal, was so ein Himmelskörper woanders anrichten würde, es wäre immer noch, bezogen auf das gesamte Universum, absolut irrelevant.

Zitat:
Original von Wolfman:
ich schätze mal, da das Licht schneller als der Schall ist, dass wir das "WUMM" zwar evtl. noch sehen, aber nicht mehr hören werden

Wenn ein Asteroid auf der entgegengesetzten Seite der Erde einschlägt, wirst Du eher ein Wumm hören, als etwas sehen.

Zitat:
Original von Maja:
Ich finde Spielfilme mit futuristischen Schussgeräuschen und feuergewaltigen Explosionen im Weltraum faszinierend.

Wenn man in seinem Raumschiff noch Analogfunk benutzt, könnte man tatsächlich vergleichbares hören.

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

[ Dieser Beitrag wurde von Holger am 26.04.2011 um 16:30 Uhr geändert. ]

Holger Nutzer

26.04.2011, 16:15 Uhr

[ - Direktlink - ]

Thema: Die Lügenbande, Teil zwo ! ;-)
Brett: Get a Life

Zitat:
Original von Begeisterter_Amiga_User:
bist du sicher das es der einzige ist der da mit augenscheinlich erschlichenem doktortitel sitzt/saß?

Natürlich sind alle, die da sitzen, Lügner und/oder Verbrecher. In diesem Fall ging es aber um die Offensichtlichkeit.

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

Holger Nutzer

26.04.2011, 14:26 Uhr

[ - Direktlink - ]

Thema: Ölgau und kein Ende
Brett: Get a Life

Zitat:
Original von Maja:
Jedes Ding braucht seine Zeit. Vor 50 Jahren waren in der Hinsicht Politik und Bürger in gleichem Maße blauäugig. Von daher wäre ein solches Bestreben der Politik damals zum einen als Verschwendung von Steuergeldern beschimpft und zum anderen postwendend vom Wähler geahndet worden.

Das möchte ich doch arg bezweifeln. Vor fünfzig Jahren hätte die Regierung jede Energiepolitik durchdrücken können, die sie wollte, solange sie nur genug gegen die Gefahr des Kommunismus unternimmt.

Zitat:
Indes scheiden sich besonders am Thema Windräder heute noch die Geister, wenn diese Windräder in der eigenen Nachbarschaft stehen (sollen).

Ja, und warum Ökostrom in Deutschland immer zu 99% mit Windrädern gleichgesetzt wird, ist mir schleierhaft. Wobei, eigentlich nicht, das wird wie so ziemlich alles andere auch, von der Lobbyarbeit abhängen.

Zitat:
In Bezug auf Wasserkraftwerken war man auch erst sehr spät, mancherorts zu spät darauf gekommen, dass Flüsse keine Kraftwerke zur willkürlichen Nutzung sind, sondern Lebensräume einer manigfaltigen Flora und Fauna.

Und heute gibt es Mini-Wasserkraftwerke, die nur einen Teil des Flussbettes belegen und somit auch Flora und Fauna Freiheit geben und vor allem auch keine hundert Meter Gefälle benötigen. Jetzt müssen sie nur noch in größerem Maßstab eingesetzt werden.

Siehe http://de.wikipedia.org/wiki/Wasserkraftschnecke
oder http://de.wikipedia.org/wiki/Strom-Boje

Zitat:
Ich bleibe skeptisch, ob das, was man uns als "Öko"-Strom teuer verkauft, für das Öko-System Erde tatsächlich der Weisheit letzter Schluss ist.

Skepsis ist auch angebracht, deshalb sollte man sich grundsätzlich immer informieren, denn zum einen ist Öko nicht gleich Öko. Zum anderen bedeutet es in der Tat nicht immer "besser", weshalb man einfach Prioritäten setzen muss. "Keine Kernkraft" ist beispielsweise eine solche, "Keine fossilen Brennstoffe" eine andere. Wenn man eine solche Priorität hat, kann man sie auch für sich persönlich durchsetzen.

Zitat:
Warum die Einspeisungsgebühr stattlich festgelegt werden muss, konnte mir auch noch niemand plausibel erklären.

Weil die Netzbetreiber weiterhin Monopolisten sind und auch weiterhin mit Energie"erzeugern" in einem Konzern verbunden sind, der keinerlei Interesse an fremden Einspeisern hat und dementsprechend ohne staatliche Regulierung auch wenig bis nichts bezahlen würden.
Dass dies mitunter der Physik spottet, wenn Einspeiser Windräder in die Pampa setzen, deren eingespeiste Energie auf dem Weg zum Verbraucher komplett in Verlustleistung umgesetzt wird, aber dennoch zum gesetzlichen Einheitstarif bezahlt werden muss, steht auf einem anderen Blatt.
Der Markt richtet es nicht, wenn kein echter Markt da ist, staatliche Regulierung aber ist und bleibt ein ineffizientes Mittel.

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

Holger Nutzer

21.04.2011, 11:23 Uhr

[ - Direktlink - ]

Thema: SAM 460ex
Brett: Get a Life

Ja und mit dem heutigen Wissen noch mal die Freizeit wie zu Schüler/Studentenzeit haben, mei, was ich da alles, quasi rückwirkend, noch für den Amiga programmieren würde...

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

Holger Nutzer

20.04.2011, 19:11 Uhr

[ - Direktlink - ]

Thema: Commodity zeitweilig ausschalten ??
Brett: AROS und Amiga-Emulatoren

Nun, ich kenne PKA-Zip nicht, aber wenn es so gut ist, dann hat es vielleicht auch eine Option, bei Beendigung ein Programm oder ARexx-Skript auszuführen?

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

Holger Nutzer

20.04.2011, 10:38 Uhr

[ - Direktlink - ]

Thema: SAM 460ex
Brett: Get a Life

Zitat:
Original von Maja:
das Leben ist zwar ein scheiß Spiel, aber die Grafik ist granatengeil.

Der Sound meistens auch.
Bzw. finde ich das Leben insgesamt durchaus gut gelungen, die Mischung aus Anspruch und Spaß stimmt schon, zumindest hat man es selbst in der Hand.

Negativ fällt nur auf, dass es keine Savepoints gibt und mitunter muss man ein bisschen zuviel "farmen" (wie man das heute nennt), um weiterzukommen.

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

Holger Nutzer

20.04.2011, 10:33 Uhr

[ - Direktlink - ]

Thema: Commodity zeitweilig ausschalten ??
Brett: AROS und Amiga-Emulatoren

@Thore:
Ja, Google hat es tatsächlich geschafft, dass man gelegentlich vergisst, dass es außer Google noch andere Möglichkeiten im Netz gibt.

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

Holger Nutzer

19.04.2011, 19:26 Uhr

[ - Direktlink - ]

Thema: Commodity zeitweilig ausschalten ??
Brett: AROS und Amiga-Emulatoren

@Mittag12:
Im Aminet buhlen gleich zwei Tools um Deine Gunst:

http://aminet.net/search?query=commodities+shell

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

Holger Nutzer

18.04.2011, 10:39 Uhr

[ - Direktlink - ]

Thema: Neue Frage zu Überdeckungen
Brett: Programmierung

Zitat:
Original von Reth:
Wann und warum kann ich denn dann überhaupt reine Layer ohne Fenster benutzen (sprich was wäre denn ein gutes Beispiel)?

Wenn Du beispielsweise einen Custom-Screen öffnest und auf diesem niemals Fenster benutzt. Keiner sagt, dass es überhaupt sinnvolle Anwendungsmöglichkeiten dafür geben muss. Layers sind einfach das von intuition verwendete Back-End. So wie auch das input.device, für das es auch in den seltensten Fällen Gründe für die direkte Benutzung gibt.

Zitat:
Kann ich denn Scrolloperationen im eigenen Fenster durchführen, ohne Schaden anzurichten (nur mit Clipping, oder)?

Ja klar, der RastPort Deines Fensters enthält auch einen Pointer auf den Layer Deines Fensters, weshalb Scroll-Operationen in diesem RastPort auch korrektes Clipping verwenden.

Zitat:
Und welcher ist es, wenn ich nichts angebe?

Musst Du einfach mal in die includes gucken, welches dieser Flags den Wert 0 hat. Ich glaube, es war simple-refresh.

Zitat:
Dann kann ich die Dimension der "bezeichenbaren Fläche" eines RastPorts nie ermitteln, ich muss immer die Dimension des Fensters und die Angabe GZZ ja/nein kennen, wenn ich die Dimension der "bezeichenbare Fläche" wissen will?

Sofern Du nicht durchgängig auf GZZ-Fenster setzt, ja.

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

Holger Nutzer

15.04.2011, 11:55 Uhr

[ - Direktlink - ]

Thema: Neue Frage zu Überdeckungen
Brett: Programmierung

Zitat:
Original von Reth:
Kommt das ungefähr so hin? Oder läuft das Ganze anders?

Ich denke schon. Ich habe allerdings gerade keine Dokumentation zur Hand, um das noch mal genau zu überprüfen.

Zitat:
ist mir immer nocht nicht ganz klar, wann ich denn nun direkt mit Layern hantiere (bzw. hantieren darf) und wann nicht? Verstanden habe ich bisher, wenn ich ein Fenster habe, Hände weg von Layern. Aber wieso? Und wann kann/sollte ich denn Layer benutzen?

Im Fenster-System verschickt intuition an alle Beteiligten Refresh-Nachrichten, wenn Refreshs nötig sind, bzw. zeichnet auch schon mal Fensterrahmen und Gadgets selbst neu. Voraussetzung ist, dass intuition auch weiß, dass eine Situation eingetreten ist, die Refreshs nötig machen könnte.

Deshalb sind sämtliche Layer-Operation tabu, die dazu führen könnten, dass irgendein Unbeteiligter einen Refresh durchführen müsste, von dem er dann nichts mitbekommt. Für alle diese Operationen gibt es aber Pendants, MoveWindow statt MoveLayer, WindowToFront statt LayerToFront, etc.

Da für reine Layer, die nicht zu einem Fenster gehören, keine solchen Alternativen zur Verfügung stehen, können diese eben nicht systemkonform mit Fenstern vermischt werden.

Etwas anderes sind Operationen, die ausschließlich den Layer Deines Fensters betreffen. Wenn Du also Scroll-Operationen innerhalb Deines Fensters durchführst, erhältst Du u.U. Damage in Deinem Layer, aber Du weißt ja, dass Du diese Operation durchgeführt hast, kannst also im direkten Anschluss das Damage Bit überprüfen und, wenn nötig, einen Refresh durchführen.

Zitat:
Zum Thema Refresh: Wenn das Fenster kein "NOCAREREFRESH" angegeben hat, ist es dann automatisch im SIMPLEREFRESH oder SMARTREFRESH Modus, wenn nichts angegeben wird?

Das sind zwei verschiedene Paar Schuhe. Der Refresh-Modus eines Fensters ist immer simple, smart oder super-bitmap. no-care ist ein zusätzliches Flag, das lediglich besagt, dass man keine Refresh-Nachrichten bekommen möchte.

Zitat:
Und noch eine Frage: Kann ich bei einem RastPort eines Fensters immer davon ausgehen, dass er eine gültige BitMap enthält?

Zitat:
Gibt mir diese die Dimension der Zeichenfläche im RastPort an (z.b. für Koordinaten + Abmessungen für EraseRect, so dass ich nicht an Stellen des RastPorts komme, die ggf. außerhalb der Zeichenfläche liegen)?

Nein.
Die BitMap ist mit Ausnahme von super-bitmap-refresh Fenstern die BitMap des Screens und hat dementsprechend deren Ausmaße, bzw. je nach Alignment ist sie sogar größer als der Screen.

Die Größe Deiner Zeichenfläche ist die Größe des Fensters abzüglich des Rahmens. Wenn Du GZZ-Fenster benutzt, ist die Zeichenfläche identisch mit der Größe Deines Layers, d.h. Du kannst einfach munter draus los löschen, ohne etwas zu überschreiben. Der Nachteil ist, dass das Fenster dann zwei Layer besitzt (Overhead), einen für den Rahmen und einen für die Zeichenfläche.

Normale Fenster haben nur einen Layer und Du musst selbst dafür sorgen, dass Du den Fensterrahmen nicht überschreibst.

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

Holger Nutzer

13.04.2011, 11:09 Uhr

[ - Direktlink - ]

Thema: Historyline 1914-1918
Brett: Amiga, AmigaOS 4

Zitat:
Original von tOrbiT:
Nachdem das Spiel gestartet wurde erscheint eine Meldung mit einer Grafik "Protection Codes" und es stehen dort einige Zahlen und Buchstaben.

Klingt für mich nach einem Kopierschutz. Da brauchst Du wohl das Handbuch.

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

Holger Nutzer

13.04.2011, 11:04 Uhr

[ - Direktlink - ]

Thema: Apollo 1240 schneller als Cyberstorm MK2 kann das sein ?
Brett: Amiga, AmigaOS 4

@Compuhard:
Kannst Du evtl. die beiden RAMs mal tauschen und dann testen?

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

Holger Nutzer

08.04.2011, 18:16 Uhr

[ - Direktlink - ]

Thema: Historyline 1914-1918
Brett: Amiga, AmigaOS 4

Zitat:
Original von DaxB:
Mein subjektives Empfinden ist, dass die "Entscheidungsfindung" des Computers dadurch nicht beschleunigt wird, sondern nur früher gestartet. Ich vermute da eine einfache Prioritäts Vergabe/Änderung.

Was anderes habe ich auch nicht vermutet. Es ist nur so ein sinnloses Verhalten. Wenn ich nichts tue und warte, bis der Computer seinen Zug durchgeführt hat, dauert das etliche Minuten, wenn ich dasselbe (also nichts) tue, aber vorher auf "Runde beenden" gehe, dauert es wenige Sekunden. (auf hinreichend schnellen Rechnern)

Zitat:
Am längsten dauern wohl die Zug-Animationen.

Nur, wenn man die Berechnung, wie oben beschrieben, vorher forciert hat. Und dann relativiert sich das, da man dann ja selber auch noch nicht gezogen hat. Bei großen Level dauert das ja auch seine Zeit, da HL keine Befehle ala "Gehe zu" über mehrere Runden kennt. Also viel Kleinarbeit und kurz nachdem man die Runde tatsächlich beendet hat, fällt einem ein, "ach die Einheit wolltest Du doch noch verschieben...und die da ist ja immer noch im Depot..."

Zitat:
HL ist leider ein Defensive Spiel und damit einfach. Man muss nur warten bis sich der Gegner aufgerieben hat.

Muss man nicht. Man kann ja auch ein Runden-Limit setzen, und dann muss man auch eine andere Strategie fahren, wenn man bis dahin die Oberhand gewonnen haben will.

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

Holger Nutzer

08.04.2011, 13:00 Uhr

[ - Direktlink - ]

Thema: Historyline 1914-1918
Brett: Amiga, AmigaOS 4

Nachtrag:

Zitat:
Original von Bluebird:
... da hat mich der erste Level schon mehr gefordert als das Finale bei HL ...

Das liegt aber bei HL in der Natur der Sache. Da der Computerspieler ausgesprochen dämlich war, und sich diese Dämlichkeit um so mehr zeigt, je mehr es falsch zu machen gibt, sank der Schwierigkeitsgrad von Level zu Level, je mehr die Komplexität stieg. Das Finale ist wirklich das leichteste Level. Einfach Abwarten, langsam Zurückziehen, sorgsam Reparieren...

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

Holger Nutzer

08.04.2011, 12:55 Uhr

[ - Direktlink - ]

Thema: Historyline 1914-1918
Brett: Amiga, AmigaOS 4

Zitat:
Original von Bluebird:
Naja man muss aber auch sagen die KI von HL ist unter aller Sau,...

HL hat eine KI?

Zitat:
...wenn man an Battle Ilse denkt

Hmm, Battle Isle (1) hatte ich nie gespielt, weil ich erwartet hatte, dass diese ältere Spiel vom gleichen Entwickler keine bessere KI haben könnte. Obwohl ich ja aus Erfahrung weiß, dass man nicht alles logisch betrachten sollte.

Bemerkenswert fand ich auch, dass man das "Denken" der KI, also die Entscheidungsfindung, was man jetzt wie sinnlos nach vorne schiebt, beschleunigen konnte, in dem man so tat, als ob man seine Runde beenden will, und erst mit dem Ziehen anfing, wenn der Computer ebenfalls damit anfing.

Je schneller die CPU (also insb. bei 060er und WinUAE), desto drastischer der Unterschied.

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

Holger Nutzer

07.04.2011, 11:12 Uhr

[ - Direktlink - ]

Thema: Dokumentation von Systemzusammenhängen
Brett: Programmierung

Zitat:
Original von Reth:
Eine weitere Überlegung von mir dazu ist z.B. eine BitMap-Klasse mit zwei Blit-Methoden auszustatten. Eine fürs Blitten des jew. BitMap-Objektes in einen RastPort und eine fürs Blitten in eine andere BitMap.

Wozu?
Soweit ich das erkennen kann, hast Du bislang den Ansatz verfolgt, dass Zielobjekt mit Methoden zu versehen, die das Quell-Objekt als Argument übergeben bekommen. Da ist es nicht sehr sinnvoll, jetzt das BitMap-Objekt (also die Quelle) mit einer Methode zu versehen, die in einen RastPort blittet. Und die zweite Methode gehört ja offensichtlich in die Kategorie, Methoden, die Du laut eigener Aussage nicht benutzt. Bringt also gar nichts.

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

Holger Nutzer

06.04.2011, 19:41 Uhr

[ - Direktlink - ]

Thema: Dokumentation von Systemzusammenhängen
Brett: Programmierung

Zitat:
Original von Reth:
Derzeit nicht, da ich nur im RastPort blitte.

Dann ist ja alles klar.

Zitat:
Der zweite Fall wäre ja auch nicht so sinnvoll, da diese Methode eine der BitMap-Klasse sein würde (zumindest nach meiner Ansicht).

Ja klar, aber Du hattest die Frage angesprochen, ob die RastPort-Klasse Methoden anbietet, die an die BitMap delegieren.

Zitat:
BltBitMapRastPort (auch mit Maske) für die RastPort-Klasse, BltBitMap (auch mit Maske) für die BitMap-Klasse (so mal die Idee).

Ich halte es nicht für sinnvoll, den Begriff RastPort noch mal extra im Methodennamen zu haben, wenn das Ziel des Aufrufes schon ein RastPort ist.
Und da es momentan eher so aussieht, als ob Du die Blit-Funktionen auf BitMap überhaupt nicht brauchst, lass sie doch einfach weg.

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

Holger Nutzer

06.04.2011, 11:13 Uhr

[ - Direktlink - ]

Thema: Historyline 1914-1918
Brett: Amiga, AmigaOS 4

Man muss übrigens nicht immer rebooten, um zu spielen. Historyline läuft auch, wenn man vorher einfach nur den Bildschirmmodus der Workbench auf einen ECS-kompatiblen umstellt.
Das kann man auch automatisieren.
Man legt sich zwei Screenmode-Konfigurationen mit dem gleichnamigen Voreinsteller mittels "Speichern unter" an, eine mit dem gewohnten Modus und eine mit einem ECS-Modus, z.B. 640x256 mit 4 Farben.
Dann macht man sich ein Start-Skript (bzw. meine ich mich zu erinnern, dass die Start-Datei von HistoryLine eh ein Skript ist, das man bearbeiten kann) mit entsprechendem Inhalt an:

code:

ScreenMode MeineECSEinstellung USE
Start (von HistoryLine)
ScreenMode MeineOriginalEinstellung USE

in dieser Art...

Ähnliches macht WHDLoad natürlich auch.

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

Holger Nutzer

06.04.2011, 10:53 Uhr

[ - Direktlink - ]

Thema: Dokumentation von Systemzusammenhängen
Brett: Programmierung

Zitat:
Original von Reth:
Das ist klar. Es gibt ja aber noch andere Konzepte, wie z.B. Interfaces oder Templates, die hier ne Rolle spielen könnten und bei denen ich nicht sicher bin, ob sie genutzt werden könnten.

Ja, man könnte natürlich eine Abstraktion der Art "Blit-Ziel" machen, um dann bestimmte Funktionen von der Frage, ob sie in einen RastPort oder direkt in eine BitMap blitten, zu entkoppeln.
Die Frage, die Du Dir dabei stellen solltest, ist: brauchst Du diese Möglichkeit?

Ich tendiere eher zu nein, denn Blitten ohne Clipping kann man auch mit einem RastPort, dazu muss nur der Layer-Pointer auf null stehen. D.h. es gibt bereit eine Möglichkeit, beides mit demselben Code ganz ohne Polymorphie zu erschlagen.

Zitat:
Bisher hatte ich mich gefragt, ob ich eine BitMap-BlitMethode für die BitMap eines RastPort-Objektes aufrufen muss, wenn die BlitMethode des RastPort-Objektes gerufen wurde (also delegieren). Nachdem, was Du (Holger) aber oben angeführt hast sind das wirklich zwei Paar getrennte Schuhe!

Delegation als "Komfortfunktion" ist an sich nicht schlecht. Würde ich hier aber von abraten, da der RastPort-Wrapper dann zwei verschiedene Arten von Blit-Funktionen anbieten würde, die man durcheinanderbringen könnte.

Und wenn man versucht, Eindeutigkeit beispielsweise über den Namen zu erzielen, sind die Funktionen auch nicht mehr komfortabler, als beispielsweise, rastport->bitMap->blit statt rastport->bitMapDirectBlit zu schreiben.

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

Holger Nutzer

05.04.2011, 16:50 Uhr

[ - Direktlink - ]

Thema: Parameter für Dateigröße unter V1.3
Brett: Amiga, AmigaOS 4

Zitat:
Original von Thore:
Vergiss die Dateiheader nicht, Nodes, Boot- und Rootblock, dann kommst auf mehr Daten als nur 1 Byte

Aus der Sicht sind es natürlich immer 880kB, weil auch unbenutzte Blöcke Daten enthalten.

Ansonsten ist der Verwaltungsoverhead (die Bitmap fehlt noch) gerade der Grund, warum noch weniger Nutzdaten (bzw. Dateien) auf eine Diskette passen.

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

Erste << 30 31 32 33 34 -35- 36 37 38 39 40 >> Letzte

Ergebnisse der Suche: 8130 Treffer (30 pro Seite)

Suchbegriffe
Schlüsselwörter			Benutzername
Suchoptionen
	Nur in diesen Foren suchen	nur ganze Wörter Nur Titel anzeigen alle Treffer anzeigen