ENGLISH VERSION |
|
Links | | | Forum | | | Kommentare | | | News melden |
Chat | | | Umfragen | | | Newsticker | | | Archiv |
amiga-news.de Forum > Programmierung > Algo zum Kreiszeichnen | [ - Suche - Neue Beiträge - Registrieren - Login - ] |
1 -2- | [ - Beitrag schreiben - ] |
11.04.2010, 22:59 Uhr inq Posts: 445 Nutzer |
Zitat:da macht natürlich keinen Sinn, oder? allein der Meßfehler ist absurd hoch. setz doch mal den Loop auf mindestens das 100fache und beweg die Maus dabei (z.b.). inq [ - Antworten - Zitieren - Direktlink - ] |
11.04.2010, 23:00 Uhr Ralf27 Posts: 2779 Nutzer |
Ab3, ebenfalls ohne WritePixel, sonst alles gleich: 0.00356 Sekunden. Hinweis: Diesen Wert habe ich bei 100.000 loops ermittelt und dann die Zeit durch 1000 geteilt. -- http://www.alternativercomputerclub.de.vu [ - Antworten - Zitieren - Direktlink - ] |
11.04.2010, 23:04 Uhr Ralf27 Posts: 2779 Nutzer |
Ok, das gleiche auch mit MB. Also 100.000 loops, dann Wert durch 1000 geteilt = 0.0069218 -- http://www.alternativercomputerclub.de.vu [ - Antworten - Zitieren - Direktlink - ] |
11.04.2010, 23:04 Uhr akl Posts: 265 Nutzer |
@Ralf27: WritePixel_ rp,x+xh,y+yh WritePixel_ rp,x+yh,y+xh WritePixel_ rp,x+yh,y-xh WritePixel_ rp,x+xh,y-yh WritePixel_ rp,x-xh,y-yh WritePixel_ rp,x-yh,y-xh WritePixel_ rp,x-yh,y+xh WritePixel_ rp,x-xh,y+yh ^ Ich würde mal mit WriteLine() vergleichen, auch wenn die Linie nur einen (oder ggf. optimiert: wenige) Pixel lang ist... [ - Antworten - Zitieren - Direktlink - ] |
11.04.2010, 23:07 Uhr Ralf27 Posts: 2779 Nutzer |
Zitat: Der Kreis wird an 8 unterschiedlichen Stellen begonnen. Der Algo berechnet also nur ein 8tel vom Kreis, der Rest wird durch Spiegeln gezeichnet. Also, eine Gerade wäre da so nicht möglich. [ Dieser Beitrag wurde von Ralf27 am 11.04.2010 um 23:08 Uhr geändert. ] [ - Antworten - Zitieren - Direktlink - ] |
11.04.2010, 23:08 Uhr Der_Wanderer Posts: 1229 Nutzer |
AB3 (3.5 vom SVN) hat eigentlich nur noch einen einzigen wirklich bekannten Bug, und auch nur unter OS4. Wenn du solche Probleme schon beim Laden eines Sources hast, dann hast du entweder nicht die aktuelle Version oder mit deinem System stimmt was nicht, wage ich mal zu behaupten. Oder zu wenig RAM? 16 oder 32MB sollten schon drin sein. Oder poste den Fehler auf http://www.amiforce.de, wenn du Segtracker hast bitte am besten mit dem Hunk Offset, dann kann man die Codezeile aus der begleitenden *.dbg Datei auslesen. Danke. An alten Versionen festzuhalten macht keinen Sinn. AB3 ist abwärtskompatibel und hat massig Bugfixes erfahren. Und man kommt natürlich nicht in den genuss der "modernen" API, sondern muss sich auf veraltete, HW banging closed-source Libs verlassen. -- HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, AB3 Includes und viele mehr... Homepage: http://www.hd-rec.de [ - Antworten - Zitieren - Direktlink - ] |
11.04.2010, 23:13 Uhr inq Posts: 445 Nutzer |
Zitat:Das ist zu kurz gedacht: da für eine durchgehende Kreis"linie" benachbarte Punkte nötig sind, liegen benachbarte Punkte maximal 1,1 auseindander - auf Linie also... gruß inq [ - Antworten - Zitieren - Direktlink - ] |
11.04.2010, 23:15 Uhr Ralf27 Posts: 2779 Nutzer |
Zitat:Habe zur Zeit 192MB Fastram drin. Dies eigentlich nur zu Testzwecken. Daran sollte es nicht liegen. Es ist auch die aktuelle Version 3.5. Zitat:Ich helfe da euch gerne weiter. Ich bin auch froh das die Grafikkartenabhängigkeit von AB3 mal beseitigt worden ist. Da sind ja bei mir als reihenweise Fehlermeldungen aufgetaucht, da ich hier keine Grafikarte habe und somit als die 32Bit-Buffer nicht angelegt werden konnten... Zitat:Ist mir schon klar. Ich hab heute wieder seit langsam das erst mal was mit AB3 gemacht. Mit MB habe ich weniger Probleme. Das läuft einfach und die Macken sind mir da bekannt. Aber MB hat genauso eine Zukunft wie AB (AmigaBasic), also keine. Das ist mir auch klar. Ich werde wohl in Zukunft erst mal MuForce mit AB3 mitlaufen lassen und dann mal sehn wie SegTracker geht. Hatte damit noch nichts zu tun. -- http://www.alternativercomputerclub.de.vu [ - Antworten - Zitieren - Direktlink - ] |
11.04.2010, 23:24 Uhr Ralf27 Posts: 2779 Nutzer |
Die Frage die sich jetzt für mich stellt: Wie könnte man den WritePixel() Befehl jetzt "dreckig" umgehn? Also, wie am besten "Handmade" machen? Und MB versuch ich das erst nicht, da ich da vermutlich eh langsamer wäre. Mit AB3-Hardcoremitteln dürfte das aber wohl machbar sein, aber dafür fehlt mir jetzt wirklich die Erfahrung mit AB3. -- http://www.alternativercomputerclub.de.vu [ - Antworten - Zitieren - Direktlink - ] |
11.04.2010, 23:25 Uhr Ralf27 Posts: 2779 Nutzer |
Zitat:Ok, ich glaub ich weiß jetzt worauf du hinaus willst. Quasi immer eine zwei Punkte Linie. -- http://www.alternativercomputerclub.de.vu [ - Antworten - Zitieren - Direktlink - ] |
13.04.2010, 19:41 Uhr Holger Posts: 8116 Nutzer |
Zitat:Doch, das kann. Du schreibst selbst nur wenige Zeilen darüber: Zitat:Also wenn das kein Indiz dafür ist, dass unterschiedliche Algorithmen verwendet werden... Zitat:Gewagte Theorie, die sich aber leicht überprüfen ließe. Einfach mal ein Fenster so über das MB-Fenster legen, dass es den Kreis teilweise verdeckt. Wenn die Zeichenroutine direkt in die BitMap schreibt, müsste sie das Fenster überschreiben. Zitat: Was genau willst Du locken, bei einer nicht-RTG-BitMap? Zitat: Versteh ich nicht. Wenn Du jetzt schon mit WritePixel und Bresenham schneller als die originale Routine bist, warum sollte es dann ohne plötzlich zu langsam sein? Von welcher OS-Version gehst Du eigentlich aus? Ältere Version sind, was WritePixel angeht, sogar noch schlimmer als AOS3.1: die verwendeten den Blitter, dessen Initialisierung schon mehr Zeit kostet, als einfach via CPU in die BitMap zu schreiben. Es gibt, um auf Deine Frage zurück zu kommen, auch eine saubere Lösung, um WritePixel zu umgehen: Erzeuge eine BitMap der Tiefe eins und setze in dieser die Pixel direkt von Hand. Das ist für eine OCS/ECS/AGA BitMap vollkommen legal, da es sich um Deine private BitMap handelt und keinerlei Layer o.ä. zu berücksichtigen sind. Danach blitte diese BitMap in einer einzigen Operation in die Ziel-BitMap, unter Verwendung derselben BitMap als Maske. Verwende BltBitMapRastPort, damit die Layer korrekt berücksichtigt werden. -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
13.04.2010, 20:09 Uhr Ralf27 Posts: 2779 Nutzer |
Zitat:Ja, aber das das dann soviel langsamer ist. Zitat:Das funktioniert auch so wie es soll und soviel ich weiß läuft der Befehl auch auf Grafikkarten.Zitat:Gewagte Theorie, die sich aber leicht überprüfen ließe. Einfach mal ein Fenster so über das MB-Fenster legen, dass es den Kreis teilweise verdeckt. Zitat:Nur aus reinem Interesse.Zitat:Versteh ich nicht. Wenn Du jetzt schon mit WritePixel und Bresenham schneller als die originale Routine bist, warum sollte es dann ohne plötzlich zu langsam sein? Zitat:Von OS3.9. Aber interesant zur wissen das ältere OS-Versionen noch schlimmer sind. Zitat:Hm, interesant. Müßte man mal testen um zu sehn ob das eventuell schneller wäre. -- http://www.alternativercomputerclub.de.vu [ Dieser Beitrag wurde von Ralf27 am 13.04.2010 um 20:09 Uhr geändert. ] [ - Antworten - Zitieren - Direktlink - ] |
16.04.2010, 17:50 Uhr Holger Posts: 8116 Nutzer |
Zitat:Die Frage war nicht, warum Du Dich damit beschäftigst, sondern warum Du MB von vornherein ausschließt. Zitat:Davon gehe ich aus. Die Frage ist nur, ob der Gewinn den Aufwand rechtfertigt. -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
22.04.2010, 21:31 Uhr Ralf27 Posts: 2779 Nutzer |
Zitat:MB ist extrem langsam. In diesem Beispiel scheint es recht schnell zu sein, bzw. nur halb so schnell wie AB, aber eigentlich ist es viel langsamer. Es war nur aus reinem Interesse und ich bin eigentlich immer davon ausgegangen das die Betriebesssstemroutinen schneller sind als die MB-Befehle, bzw. das ich "Handmade" erst gar nicht in die Nähe kommen würde. Zitat:Eigentlich nicht. Aber hier scheint es mir wirklich so, das man denn Amiga auch noch Softwaretechnisch beschleunigen könnte. Hier und da etwas geschraubt und es geht noch schneller. "Neue", schnellere Hardware für 68k-Amigas sind ja nicht in Sicht, bzw. unwahrscheinlich.Zitat:Davon gehe ich aus. Die Frage ist nur, ob der Gewinn den Aufwand rechtfertigt. -- http://www.alternativercomputerclub.de.vu [ - Antworten - Zitieren - Direktlink - ] |
23.04.2010, 09:48 Uhr Thore Posts: 2266 Nutzer |
> "Neue", schnellere Hardware für 68k-Amigas sind ja nicht in Sicht, bzw. unwahrscheinlich. Für alte nicht, aber sowas... http://www.natami.net/index.htm [ - Antworten - Zitieren - Direktlink - ] |
23.04.2010, 12:00 Uhr Holger Posts: 8116 Nutzer |
Zitat:Eben. Und nur um dieses eine Beispiel ging es ja. Und da sich ja auch noch herausgestellt hatte, dass WritePixel() das Nadelöhr ist, und nicht der Basic-Code... Zitat:Das wird nicht die einzige Routine sein, die weit von der Perfektion entfernt ist. Die allgegenwärtigen doppelt-verketteten Listen z.B. sind auch nicht für jede Operation die optimale Datenstruktur. Das System hatte damals den anderen ein paar grundsätzliche Dinge voraus, man sollte es aber nicht als heilige Kuh der IT betrachten. -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
1 -2- | [ - Beitrag schreiben - ] |
amiga-news.de Forum > Programmierung > Algo zum Kreiszeichnen | [ - Suche - Neue Beiträge - Registrieren - Login - ] |
Impressum |
Datenschutzerklärung |
Netiquette |
Werbung |
Kontakt
Copyright © 1998-2024 by amiga-news.de - alle Rechte vorbehalten. |