|
ENGLISH VERSION |
|
 |
| Links | | | Forum | | | Kommentare | | | News melden |
|
| Chat | | | Umfragen | | | Newsticker | | | Archiv |
|
| amiga-news.de Forum > Programmierung > Neue Frage zu Überdeckungen | [ - Suche - Neue Beiträge - Registrieren - Login - ] |
| Erste 1 2 3 4 5 -6- | [ - Beitrag schreiben - ] |
|
15.08.2011, 18:58 Uhr Holger Posts: 8116 Nutzer |
Zitat:Das hängt wirklich von der Menge der Objekte und deren Verteilung in der Fläche ab. Leider auch in gewissem Maße vom System. Wenn Deines durch Clipping ohnehin nicht schneller wird, lohnt sich Clipping natürlich nicht. Aber es ist ja nicht schwer, ein Programm so zu schreiben, dass man Clipping an und abschalten kann und dann nach einem passenden Schwellwert zu suchen. -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
06.01.2012, 21:14 Uhr Reth Posts: 1858 Nutzer |
So nach langer Zeit mal wieder ein Update zu dem Thema, nachdem ich mich mal wieder drangesetzt habe. Also was funktioniert ist das Clipping, EraseRect und Reblitting aller Objekte. Allerdings n u r solange es über dem Spielfeld passiert. Über dem grauen Bildschirmhintergrund, aber auch über den Images für die Statusanzeige, sowie über meinen Buttons bleiben die geblitteten Objekte stehen. EraseRect sorgt hier nicht für ein "Löschen" und Darstellen der Hintergrundfarbe! Es ist wie verhext! Woran liegt das denn nun wieder? Jetzt nochmal die verzweifelte Frage an alle Amiga-(Spiele-)-Programmierer: Wie löst ihr denn solche Dinge bei euch? Doublebuffering? Und wenn ja, dann auch für solche Dinge wie Buttons (struct Gadget) und Images? Bin langsam echt ratlos und hab momentan keine Motivation auf Doublebuffering umzurüsten! Zusätzlich habe ich wohl so einen massiven Fehler eingebaut, dass beim Beenden des Programms das ganze System einfriert. Den muss ich auch noch aufstöbern! [ Dieser Beitrag wurde von Reth am 10.01.2012 um 13:00 Uhr geändert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
11.01.2012, 14:56 Uhr Holger Posts: 8116 Nutzer |
Zitat:a) Du hast immer noch ein Clipping gesetzt, das das Zeichnen außerhalb des Spielfeldes verbietet b) Du hast einen No-Op Backfill-Hook installiet Zitat:Kennst Du ein solches Spiel, das aufwendige Grafiken und Systemroutinen, vor allem Standard-Gadgets verwendet? -- Good coders do not comment. What was hard to write should be hard to read too. [ Dieser Beitrag wurde von Holger am 11.01.2012 um 14:57 Uhr geändert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
11.01.2012, 23:45 Uhr Reth Posts: 1858 Nutzer |
Zitat:b) Hab ich nicht installiert. a) Muss ich nochmal prüfen (sitz gerade leider nicht vorm AOS). Zitat:Naja, Flare für AOS4. Wenn ich den Source richtig verstehe werden dort alle Tiles und darüber befindlichen Objekte jedesmal komplett neu geblittet. Leider weiss ich nicht genau wie die SDL intern arbeitet, aber es wird darin auch BltBitMapRastPort() (allerdings wohl kein BltMaskBitMapRastPort() wie ich es nutze) verwendet. Allerdings hab ich noch nicht rausgefunden, ob mit DoubleBuffer oder nicht. Bei Flare wird alles mittels SDL_BlitSurface() dargestellt. Und das geht trotz SDL ziemlich flüssig, obwohl Flare neben der Map auch z.T. noch mehrere animierte Gegner und Geschosse darstellt (war bei mir nicht der Fall, als ich alles mit Maske geblittet hatte, kann aber auch an meinen massiven Debugausgaben in eine Datei liegen). Auch hab ich noch nicht rausbekommen, wie die Statusanzeigen (die festen und die eingeblendeten) bei Flare dargestellt werden. Vermute aber auch, dass diese immer geblittet werden. [ - Antworten - Zitieren - Direktlink - ] |
|
12.01.2012, 10:43 Uhr Holger Posts: 8116 Nutzer |
@Reth: Ja, aber Flare hat bestimmt keine Gadgets, bzw. keine Gadgets, über die sich animierte Objekte bewegen und die deshalb wiederhergestellt werden müssten, oder? In einem Loop immer wieder alles neu blitten, ist nicht schwer. Das wurde hier auch schon geäußert. Dein Problem rührt ja aus der Verwendung von Gadgets und dem systemkonformen Refresh. -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
12.01.2012, 11:07 Uhr Reth Posts: 1858 Nutzer |
@Holger: Aber bei mir hat selbst das alles neu blitten zu lange gedauert, was aber wie gesagt auch an meinen Debug-Ausgaben liegen kann (bin gerade auf der Suche nach einer einfachen Lösung für Logging in C++, hab auch mal probiert log4c++ zu compilieren, noch ohne Erfolg weil pthreads.library nicht gefunden wurde). Ich habe eh als nächstes vor, die ganze Blitterei mittels Clipping auf das Spielfeld zu beschränken, da animierte Pointer über den Gadgets doch etwas komisch wirken. Dann sollte ein "stupides" blitte immer alles neu, beginnend mit der untersten Ebene, wie es in Flare gemacht wird ebenfalls funktionieren, oder? Wenn ichs richtig verstanden habe nutzt Flare wahrscheinlich auch keinerlei Gadgets o.ä., sondern macht das alles selbst über eigene Grafiken. Hab mir aber noch nicht angesehen, wie dann das entsprechende GUI-Handling dazu aussieht. Hab noch festgestellt, dass Flare mit SDL_Flip arbeitet, welches hardwareseitiges Doublebuffering unterstützt. Da ich nicht davon ausgehe, dass die in den heutigen "Amigas" jeglicher Coleur so etwas nicht benutzt wird denke ich mal es wird bei mir unter AOS4 ohne Doublebuffering abgebildet. Es sei denn SDL_Flip ist unter AOS4 mit Doublebuffering implementiert. [ Dieser Beitrag wurde von Reth am 12.01.2012 um 22:02 Uhr geändert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
26.10.2012, 20:16 Uhr Reth Posts: 1858 Nutzer |
So, hab nun endlich mal so viele Fehler ausgemerzt, dass meine "Engine" erst einmal halbwegs stabil zu funktionieren scheint. Unwohl wird mir aber immer noch, wenn ich denke, welche Fehler ich wohl noch nicht gefunden habe (C++ ist in dieser Hinsicht für mich noch um vieles schlimmer als C und verzeiht noch weniger!)! Aber mal abgesehen davon, dass ichs nicht kann (also C++ und AOS-API) und ich die Amiga-API immer noch als hoch programmiererunfreundlich empfinden empfinde ich den produzierten Code nach Abzug dieser Dinge immer noch als hoch-komplex und "undurchsichtig". Also wer da mal durchgucken will und mir hilfreiche Tips geben kann, wie ich das schlanker, effizienter und verständlicher hinbekommen kann ... Freiwillige vor. Ich schüttle immer noch mit dem Kopf, was ich benötige, um "nur" animierte Objekte dar zu stellen, die nicht die ganze GUI "kaputt machen"! Ein Wahnsinn! Das Ergebnis ist leider auch in der dabei entstandenen Aussenschnittstelle nicht besser geworden (für ne gut durchdachte API-Kapselung, v.a., was animierte Darstellung mittels OS-Funktionen unter C++ anbelangt) hat mir dann doch der Nerv gefehlt! Jetzt muss ich "nur noch" den Spielablauf in meine selbst gebastelte "C++-API" reinbringen (sprich Interaktion, Zustände und Übergänge und damit verbundene Auswirkungen, sichtbar und unsichtbar). Zusätzlich muss ich die "Engine" leider auch noch verbessern, da man ein Flimmern beim EraseRect sieht, wenn sich die Animation schnell über den Bildschirm bewegt! D.h., irgendwann muss ich da noch Double-Buffering o.ä. reinbringen. Auf alle Fälle allen Mithelfern hier vielen, vielen Dank (auch denen aus den anderen Threads). Ohne euch wäre ich gar nicht erst soweit gekommen! Bis zum nächsten Posting mal! Ciao [ - Antworten - Zitieren - Direktlink - ] |
|
26.10.2012, 22:01 Uhr Thore Posts: 2266 Nutzer |
C++ ist eine Programmiersprache und AmigaOS API ist eine API. Die Programmiersprache darf die API benutzen, dadurch wird sie nicht schwieriger oder einfacher. Sie bleibt immer noch C++. Was der Programmierer für Strukturen einbaut, das macht dann die Sache erst komplex. Mit C++ kann man die API genauso easy benutzen wie mit C, Pascal oder gar BASIC. Es sind nur LibCalls... [ - Antworten - Zitieren - Direktlink - ] |
|
27.10.2012, 12:12 Uhr Reth Posts: 1858 Nutzer |
@Thore: Was willst Du genau damit herausstellen? Sehe gerade den Bezug zu meinem Post nicht. Habe beides getrennt betrachtet (bzw. so gemeint). Dass ich das AOS-API nicht gerade programmierfreundlich finde ist glaube ich schon länger bekannt. Mein aktuelles Bsp.: Das Erstellen einer "Animations-Engine". Wie gesagt, gehe ich aber davon aus, dass ich mich dabei mehr als nur "ungelenk" und umständlich angestellt habe! Zweites Thema: Ich finde C++ um einigs komplexer, schwieriger und "gefährlicher" als C (unabhängig davon, was man damit machen will). Da ichs aber lernen will, beiß ich mich da rein. Leider habe ich die vielen tollen Zusatz-Libraries/-features noch nicht ausprobiert (z.B. Boost, smartPointer etc.). Einige davon können das Leben glaub ich erleichtern (bin mir aber nicht sicher, welche z.B. der AOS-SDK-GCC schon mitbringt und welche nicht - zumindest die STL-Container sind schon mal dabei). [ - Antworten - Zitieren - Direktlink - ] |
|
27.10.2012, 12:20 Uhr Thore Posts: 2266 Nutzer |
Ich wollte nichts herausstellen oder Deinen Code irgendwie schlechtmachen, sondern lediglich sagen, daß man die Themen API und Programmiersprache schon etwas trennen sollte. Das war rein allgemein geschrieben  Ich z.B. finde die AmigaOS API extrem gut und Benutzerfreundlich. Das liegt sicher daran, daß ich schon länger damit programmier. Wenn man sich mal richtig eingelesen hat, z.B. in die Developer CD (z.B. die RKM) und sich die Beispiele anschaut, dann merkt man daß es eigentlich recht einfach ist, oder anders gesagt, die APIs der anderen Systeme sind nicht einfacher [ - Antworten - Zitieren - Direktlink - ] |
|
27.10.2012, 20:12 Uhr Reth Posts: 1858 Nutzer |
@Thore: Ah ok, danke. Hatte nur nicht verstanden, worauf Du im Bezug auf meinen Post hinaus wolltest. Die Trennung von Programmiersprache und API ist für mich eigentlich selbstverständlich, daher konnte ich den Bezug nicht gleich herstellen. Und das mit dem Code schlecht machen: Keine Bange, das wär nur berechtigt. Schätze meine Designfähigkeiten als unterirdisch ein, daher hänge ich an manchen Stellen ewig rum, bis ich mich entschieden habe, wie ichs angehe (auch bei den Vorüberlegungen), nur um dann festzustellen, dass es doch nicht trägt. Von demher sehe ich meinen Code selbst als ziemlich schlecht an (merkt man auch an den Problemen, die ich allerorten bei der AOS-API-Nutzung habe)! Daher bin ich für jedes Review/jeden Vorschlag bzw. Tipp dankbar. [ - Antworten - Zitieren - Direktlink - ] |
|
29.10.2012, 10:13 Uhr Holger Posts: 8116 Nutzer |
Zitat:Das stimmt nicht. Für Pascal oder Basic muss man erst einmal passende Anbindungen erzeugen, die dann aber den Vorteil haben, auf die Sprache angepasst zu sein, während für C++ einfach die C-Anbindung genutzt wird, die den Vorteil hat, am ehesten verfügbar zu sein, dafür aber nicht im Geringsten an die Sprache angepasst ist. Z.B. wird der Vorteil von C++, Namespaces und andere lexikalische Scopes zu haben, durch die vielen #define’s der AOS-includes komplett zunichte gemacht. Zitat:dass man offenbar zu der seltenen Gattung derjenigen Programmierer gehört, zu deren Problemen immer ein passendes Beispiel existiert. Dabei zeigen doch die meisten Beispiele, wie kompliziert oftmals einfache Dinge sein können und dass man bei Commodore anscheinend nicht in der Lage war, selbst bei simplen Code-Beispielen ohne nicht-empfohlene Programmiertechniken auszukommen (oder gar noch Fehler einzubauen). -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
29.10.2012, 10:14 Uhr Holger Posts: 8116 Nutzer |
Zitat:Ja, immer schick den Code. Ich weiß zwar nicht, wann ich Zeit habe, aber das schlimmste, was passieren kann, ist, dass er ne Weile in meinem Postfach rumliegt. -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
29.10.2012, 10:22 Uhr Thore Posts: 2266 Nutzer |
@Holger Es ging mir nicht um den technischen Aufwand, wie man LibCalls in BASIC und Pascal erzeugt, sondern um deren Aufrufe innerhalb des Programmcodes. Daß man erst bmap Files erzeugen muss ist klar. Ebenso mit den Beispielen, hier gehts um die Verwendung der API an sich, und nicht um fertiggekochte Prgrammcodes. Es geht ums Verständnis der API und deren Aufrufe. Mehr wollte ich damit nicht ansprechen. [ - Antworten - Zitieren - Direktlink - ] |
|
29.10.2012, 12:35 Uhr Reth Posts: 1858 Nutzer |
Zitat:Super! Vielen Dank schon mal. Geht demnächst irgendwann raus. @Thore: Bei mir gehts meistens noch, wenn ich mir einzelne API-Aufrufe isoliert anschaue (z.B. für das Öffnen eines Fensters oder das AND-Verknüpfen einer Region mit einem Rechteck). Wenn es aber um das Zusammenspiel und die richtigen Reihenfolgen bei der Verwendung (wie z.B. bei mir im Rahmen von Refreshs) geht wird die Sache aus meiner Sicht schon schwieriger. Und das Ganze trotz der Bsps. und anderen Hilfen auf der Developer CD. Da bin ich dann eher bei Holger. Mit C++ hab ich gerade die größten Probleme, im Auge zu behalten, wo ich welche Sachen wie verwende und wie sich dadurch deren Scope-Verhalten darstellt. Dabei kommt dann noch die zusätzliche Schwierigkeit (für mich zumindest) ins Spiel, im Auge zu behalten, bei welchen Aufrufen/Zuweisungen Objekte kopiert werden. Mit diesen Dingen tue ich mich gerade absolut schwer! [ - Antworten - Zitieren - Direktlink - ] |
|
30.10.2012, 10:19 Uhr Holger Posts: 8116 Nutzer |
Zitat:Das ist aber eine ziemlich willkürlich gezogene Grenze. Wenn bei Funktion Foo() ein Beispielcode beiliegt, der ohne jeglichen Zusammenhang die Funktion Foo() benutzt, bedeutet das noch lange nicht, dass Funktion Foo() verständlich wäre. Noch nicht einmal, dass der Nutzen von Foo() daraus klar ersichtlich wird. Mal ein praktisches Beispiel. In den RKRMs findet sich bei der Dokumentation der Funktion CloseWindow() ein Beispielprogramm, das zeigt, wie man ein Fenster schließt, wenn man ein Shared IDCMP benutzt. Das hilft dem Verständnis überhaupt nicht weiter, zum einen, weil es ein überhaupt nicht an dieser Stelle behandeltes Thema anspricht, zum anderen, weil auch dieses spezielle Thema auch gar nicht ausreichend erklärt wird. Das heißt, viele Programmierer haben diesen Beispielcode übernommen, ohne zu wissen, wozu er überhaupt dient, weil sie angenommen haben, so müsse man generell Fenster schließen (finden sich auch Beispiele hier im Forum). Andererseits fehlt für die höhere Aufgabe „Shared IDCMP verwenden“ in diesem Beispiel natürlich, wie man solche Fenster überhaupt öffnet und der Rest der üblichen Fensterbenutzung. Wenn Du brauchbare Beispiele, die eine bestimmte Aufgabe auch vollständig bearbeiten als „fertiggekochte Programmcodes“ ansiehst, dann fehlen der Dokumentation eben „fertiggekochte Programmcodes“, um wirklich brauchbar zu sein. -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
07.11.2012, 21:34 Uhr Reth Posts: 1858 Nutzer |
@Holger: Source ging vor ein paar Tagen raus. [ - Antworten - Zitieren - Direktlink - ] |
|
07.11.2012, 22:22 Uhr Thore Posts: 2266 Nutzer |
Bevor man API Funktionen anwendet, muss man erstmal wissen was sie tun und wie sie funktionieren. Da ist das RKM eine gute Anlaufstelle, auch wenn Du wieder voll dagegen bist. Das RKM war die Bibel der Internetlosen Zeit und da haben viele Programmierer sich wertvolle Hinweise herausgelesen. Aber laut den "neuen Erkenntnissen" funktionieren ja API Funktionen je nach Programm anders... aha aha aha. Macht ihr nur weiter, wenn nichtmal das RKM noch helfen kann dann mach Du es alleine, Allwissender. Ich kling mich aus dem Thread aus. Infos zu CloseWindow und IDCMP_CLOSEWINDOW befinden sich übrigens ebenfalls deutlich beschrieben... im RKM!! [ - Antworten - Zitieren - Direktlink - ] |
|
07.11.2012, 22:56 Uhr Reth Posts: 1858 Nutzer |
@Thore: Also ich nutze das RKRM auch, mehr aber noch die abgedruckte Version auf z.B. Innoidea oder die Teile von der Developer CD. Allerdings haben mir bisher am meisten Bsp.-Programme, Bsp.-Sourceausschnitte und die Erläuterungen in allen Threads geholfen! @Thread: Ich finde es schade, dass sich hier (wieder mal) OT gezofft wird und Streit entbrennt. Damit ist niemandem geholfen und auch weiteren Problemeröterungen ist damit schon geschadet. [ - Antworten - Zitieren - Direktlink - ] |
|
08.11.2012, 09:17 Uhr Holger Posts: 8116 Nutzer |
Zitat:Ach was. Zitat:Wie kommst Du auf diesen Unsinn? Die RKRMs sind natürlich eine gute Anlaufstelle, schon deshalb, weil es überhaupt keine Alternative gibt. Zitat:Das hat niemand behauptet. Zitat:Allein dieser Satz zeigt, dass Du offensichtlich nicht das geringste verstanden hast. Nirgendwo hat jemand behauptet, dass die Funktion nicht beschrieben wird. Und von IDCMP_CLOSEWINDOW war schon überhaupt nirgendwo die Rede. -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
| Erste 1 2 3 4 5 -6- | [ - Beitrag schreiben - ] |
| amiga-news.de Forum > Programmierung > Neue Frage zu Überdeckungen | [ - Suche - Neue Beiträge - Registrieren - Login - ] |
|
|
Impressum |
Datenschutzerklärung |
Netiquette |
Werbung |
Kontakt
Copyright © 1998-2024 by amiga-news.de - alle Rechte vorbehalten. |
|