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

amiga-news.de Forum > Programmierung > AGA<->CyberGraphX: Buffer [ - Suche - Neue Beiträge - Registrieren - Login - ]

-1- 2 [ - Beitrag schreiben - ]

18.02.2007, 13:34 Uhr

Ralf27
Posts: 2779
Nutzer 		Ich hab ein kleines Programm geschrieben das mittels Doubelbuffer eine Grafik im Hintergrund zeichnet und dann einfach mit BltBitMapRastport auf die vordere Bitmap kopiert.

Genauer:
* Fenster geöffnet
Eine Bitmap mit AllocBitmap() in den gleichen Dimensionen geöffnet, mit Friendbitmap auf die Bitmap des Fensters
* Rastport für diese Bitmap angelegt und initialisiert

So, nach jedem zeichnen(in die eigene, versteckte Bitmap) blitte ich mit BltBitMapRastPort von der versteckten Bitmap ins Fenster.
Soweit, sogut. Allerdings ist dieses Konstrukt unter AGA schneller als auf einem Grafikkartensystem!
Ist es irgendwie möglich, das der Buffer im Grafikkartenspeicher aufgebaut wird und da dann Move() und Draw() dort angewendet wird? Ich vermute mal, das sonst laufend auf Grafikkartenrechnern von Fastram ins Grafikkartenspeicher kopiert wird.

Es wird nur Move() und Draw() benutzt, die Bitmaptiefe beträgt noch 1Bit, wird aber vermutlich später tiefer.
--
http://www.alternativercomputerclub.de.vu

[ - Antworten - Zitieren - Direktlink - ]
18.02.2007, 13:46 Uhr

thomas
Posts: 7718
Nutzer
Zitat:
Allerdings ist dieses Konstrukt unter AGA schneller als auf einem Grafikkartensystem!

Kannst du etwas genauer werden ? Was für "ein Grafikkartensystem" hast du denn zum Testen benutzt ? WinUAE ist für sowas kein Maßstab.

Gruß Thomas

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

[ - Antworten - Zitieren - Direktlink - ]
18.02.2007, 13:47 Uhr

malte2
Posts: 148
Nutzer 		Alles mit weniger als 8bit wird wahrscheinlich nur als planare BitMap angelegt. Bei CGX ist es zudem notwendig BMF_MINPLANES bei AllocBitMap() zuverwenden.

[ - Antworten - Zitieren - Direktlink - ]
18.02.2007, 17:48 Uhr

Der_Wanderer
Posts: 1229
Nutzer 		Also meine DBL.include funktioniert so, und macht mehr als 200FPS unter WinUAE auf meinem Laptop bei 24bit.
Auch eine Cybervision 64 3D mit einem 60er bringt es auf mehr als 50FPS bei 640x480x16.

Wichtig ist, dass die Friendbitmap natürlich genau der Screenbitmap entspricht, also auch von der Tiefe her. Ich vermute mal, dass deine WB nicht auf 2 Farben läuft.

Für Fullscreen gibt es noch einen Trick, nähmlich einen Screen zu allocieren, der Doppelt so hoch ist wie sichtbar. So ist auf jeden Fall garantiert, dass die versteckte Bitmap im Graka RAM liegt, ohne das Cybergfx oder Picasso die Bitmap swappen kann. Ist allerdings etwas unsauber.

Für Fullscreen sollte man aber ChangeScreenBuffer oder ChangeVPBitmap benutzen, oder ScrollVP. Die sind noch schneller als ein BltBitmapRasport, aber geht nur Full screen.

--
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 - ]
18.02.2007, 19:25 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von Der_Wanderer:
Für Fullscreen gibt es noch einen Trick, nähmlich einen Screen zu allocieren, der Doppelt so hoch ist wie sichtbar. So ist auf jeden Fall garantiert, dass die versteckte Bitmap im Graka RAM liegt, ohne das Cybergfx oder Picasso die Bitmap swappen kann. Ist allerdings etwas unsauber.
Eine solche Garantie gibt es nicht. Da auch weiterhin der Direktzugriff auf BitMaps verboten ist, könnte durchaus auch die zweite Hälfte der BitMap außerhalb der Grafikkarte liegen.
Nur weil Dein System so etwas nicht macht, sollte man nicht gleich von einer Garantie reden. Hohe Wahrscheinlichkeit, bestenfalls.

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

[ - Antworten - Zitieren - Direktlink - ]
18.02.2007, 19:34 Uhr

Der_Wanderer
Posts: 1229
Nutzer 		@Holgher

Stimmt, es ist nicht garantiert. Ich meine sogar beobachtet zu haben, dass Picasso unter Low-Memory Bedingungen tatsächlich den nicht-sichtbaren Teil swapped. Aber es passiert sehr sehr viel seltener als wenn es eigenständige Bitmaps sind.

Bei eigenen Bitmaps kommt das swappnen sehr häufig vor, auch oft wenn es gar nicht notwendig scheint, bzw. wenn man viele kleine Objekte blittet. Dann werden die Objekte ins Graka RAM verschoben, und die "fette" Hintergrundbitmap herausgenommen. Es wäre aber wesentlich performanter, die Hintergurndbitmaps drin zu lassen und jedesmal die kleinen Bitmaps zu schieben. Das kann Picasso aber ja nicht wissen.

Einmal ins Swappen gekommen, wird soz. immer im Kreis geswapped und die FPS brechen auf 25% ein oder noch mehr.
Deshalb drehen sich in AsteroidsTR die Asteroiden nicht in der Light Version. Dadruch werden weniger Graka RAM gebraucht und swappen wird unwahrscheinlicher.

Bei WinUAE kann ich nur empfehlen, 32MB Graka RAM einzustellen. Dann wird kaum noch geswapped.

--
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 - ]
18.02.2007, 19:37 Uhr

whose
Posts: 2156
Nutzer
Zitat:
Original von Holger:
Zitat:
Original von Der_Wanderer:
Für Fullscreen gibt es noch einen Trick, nähmlich einen Screen zu allocieren, der Doppelt so hoch ist wie sichtbar. So ist auf jeden Fall garantiert, dass die versteckte Bitmap im Graka RAM liegt, ohne das Cybergfx oder Picasso die Bitmap swappen kann. Ist allerdings etwas unsauber.
Eine solche Garantie gibt es nicht. Da auch weiterhin der Direktzugriff auf BitMaps verboten ist, könnte durchaus auch die zweite Hälfte der BitMap außerhalb der Grafikkarte liegen.
Nur weil Dein System so etwas nicht macht, sollte man nicht gleich von einer Garantie reden. Hohe Wahrscheinlichkeit, bestenfalls.

Nein, bei "doppelt hohem Screen" gibt es keine "zweite Hälfte". Da gibt es nur eine durchgehende Bitmap von bspw. 960 Pixeln Höhe statt 480 sichtbaren und 480 unsichtbaren Pixeln in jeweils eigenen Bitmaps.

Entweder liegt diese komplett im Video-RAM oder gar nicht. Es kann durchaus passieren, daß diese Gesamtbitmap einmal ausgelagert wird, aber spätestens, wenn sie wieder (teilweise) sichtbar im Bild ist, wird sie wieder komplett ins Video-RAM verlagert und andere Bitmaps werden dafür im Fast RAM "geparkt". Sollte das nicht möglich sein, bleibt sie im Fast (mit entsprechenden Einbußen in Sachen Geschwindigkeit).

ChangeScreenBuffers() könnte da was anderes ergeben, ist aber auch ein anderes Thema.

Ralfs Problem sieht verdächtig nach fehlendem BMF_MINPLANES aus, ich könnte mir gut vorstellen, daß seine Bitmap im Chip RAM landet, was diese Geschwindigkeitsunterschiede prima erklären würde.

Grüße

--
---

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

[ - Antworten - Zitieren - Direktlink - ]
18.02.2007, 19:40 Uhr

Der_Wanderer
Posts: 1229
Nutzer 		@whose

Aber die Screenbitmap MUSS im Graka RAM liegen, solange der Screen sichtbar ist, sonst sieht man nur ein schwatzes Bild ;-)
Wenn das nicht ins Graka RAM passt, würde der Screen sich nicht öffnen lassen.

--
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 - ]
18.02.2007, 19:42 Uhr

whose
Posts: 2156
Nutzer 		@Der_Wanderer:

Wenn Du bei AsteroidsTR auch einen doppelt hohen Screen fürs DoubleBuffering verwendest, brauchst Du Dich über häufiges Swappen bei wenig Speicher und vielen kleinen Offscreen-Bitmaps nicht zu wundern.

Rechne doch mal zusammen, wie viel Video-RAM alle Bitmaps verbrauchen, die in einem Frame-Zyklus zum Einsatz kommen. Das könnte Dich erstaunen ;)

Bei einem Programm, daß ich gerade in Arbeit habe, komme ich schon bei einer Fenster-Größe von 480*320 Pixeln in Schwulitäten, wenn es auf 24Bit laufen soll und die GraKa "nur" 4MB hat.

Zitat:
Aber die Screenbitmap MUSS im Graka RAM liegen, solange der Screen sichtbar ist, sonst sieht man nur ein schwatzes Bild ;-)
Wenn das nicht ins Graka RAM passt, würde der Screen sich nicht öffnen lassen.

Ja, das ist logisch. Aber was willst Du damit sagen? ;) Ich könnte mir gut vorstellen, daß die RTG-Systeme im Notfall die Screen-Bitmap nur teilweise ins Video-RAM verlagern, wenns gar nicht anders geht.

Aber wenns anders geht, wäre es ja Blödsinn, nur den (scheinbar) sichtbaren Teil ins Video-RAM zu bringen. Für so schlau halte ich die RTG-Macher schon ;)

Grüße

--
---

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


[ Dieser Beitrag wurde von whose am 18.02.2007 um 19:50 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]
18.02.2007, 19:54 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von whose:
Nein, bei "doppelt hohem Screen" gibt es keine "zweite Hälfte".
Das sagst Du, aber bist Du der Maintainer des AmigaOS-API? Falls ja, solltest Du bitte daran denken, diese Garantie auch in die P96-Spezifikation aufzunehmen, weil bislang alle RTG-Spezifikation unisono sagen, dass man über nicht gelockte BitMaps überhaupt keine Annahmen machen darf. Also auch nicht, dass sie immer aus einem Stück bestehen.
Zitat:
Ralfs Problem sieht verdächtig nach fehlendem BMF_MINPLANES aus, ich könnte mir gut vorstellen, daß seine Bitmap im Chip RAM landet, was diese Geschwindigkeitsunterschiede prima erklären würde.
Ob Chip-RAM oder Fast-RAM, beides ist langsam im Vergleich zum Grafikkarten-Speicher. Falls es nicht an der schon längst angesprochenen Tiefe von 1 liegt. Wenn der verwendete Grafikkarten-Chip keine entsprechende Konvertierung in's Screenformat durchführen kann, wäre Grafikkartenspeicher sogar die langsamste Variante von allen.

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

[ - Antworten - Zitieren - Direktlink - ]
18.02.2007, 19:55 Uhr

Ralf27
Posts: 2779
Nutzer 		How, das scheint ja ein heißes Thema zu sein. :)

@thomas:
Ich dachte bei Grafikkartensystemen nur an echte Amigas mit einer Grafikkarte.

Ich hatte wirklich MINPLANES nicht drin, aber auch mit BMF_MINPLANES ändert sich nichts: AGA ist schneller als Grafikkarte.

Es ist halt so das die Zeichenebene 1 Bit tief ist und ich nur mit Move() und Draw() eine Zeichnung aufbaue. Der Blit geht halt nach alter Manier mit BltBitmapRastport()

In Sudoku hab ich auch kein BMF_MINPLANES angegeben und dennoch sind die Bitmaps wohl im Fastram, weil der Chipram nicht rapide abnimmt, bzw. nicht die Bitmaps da drin sind(würd ich merken wenn ich nur noch die Hälfte an Chipram hätte. :D )

Die Sache mit dem eingebauten Buffersystem ab OS3.0 hab ich mir zwar kurz angesehn, aber nunja.. was soll ich tippen... :glow: ...ich hab es erst mal nicht verstanden.

EDIT: Achja, die Farbtiefe, hab ich auch mal testweise angepast, bzw. auch mal ein Bitmap aufgebaut die doppelt so hoch ist wie benötigt und dann geblittet, sodas die bitmap halt gleich ist.
Selbst wenn MB extrem langsam ist, aber es sollte doch mindestens die gleiche Geschwindigkeit drin sind.

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

[ Dieser Beitrag wurde von Ralf27 am 18.02.2007 um 19:58 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]
18.02.2007, 19:56 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von whose:
Ja, das ist logisch. Aber was willst Du damit sagen? ;) Ich könnte mir gut vorstellen, daß die RTG-Systeme im Notfall die Screen-Bitmap nur teilweise ins Video-RAM verlagern, wenns gar nicht anders geht.
Ach, jetzt auf einmal doch? 8o

[ - Antworten - Zitieren - Direktlink - ]
18.02.2007, 19:59 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von Ralf27:
In Sudoku hab ich auch kein BMF_MINPLANES angegeben und dennoch sind die Bitmaps wohl im Fastram, weil der Chipram nicht rapide abnimmt, bzw. nicht die Bitmaps da drin sind(würd ich merken wenn ich nur noch die Hälfte an Chipram hätte. :D )

FastRAM ist aber nicht VideoRAM. Und nun probier doch mal den Offscreen-Buffer in derselben Tiefe wie den Ziel-Screnn, ja?

mfg

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

[ - Antworten - Zitieren - Direktlink - ]
18.02.2007, 20:07 Uhr

whose
Posts: 2156
Nutzer
Zitat:
Original von Holger:
Zitat:
Original von whose:
Ja, das ist logisch. Aber was willst Du damit sagen? ;) Ich könnte mir gut vorstellen, daß die RTG-Systeme im Notfall die Screen-Bitmap nur teilweise ins Video-RAM verlagern, wenns gar nicht anders geht.
Ach, jetzt auf einmal doch? 8o

Nicht "auf einmal". Im Extremfall.

Aber Dein Hinweis auf Offscreen-Tiefe = Screen-Tiefe könnte wohl hilfreich sein ;)

Grüße

--
---

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

[ - Antworten - Zitieren - Direktlink - ]
18.02.2007, 20:08 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von Der_Wanderer:
Dann werden die Objekte ins Graka RAM verschoben, und die "fette" Hintergrundbitmap herausgenommen. Es wäre aber wesentlich performanter, die Hintergurndbitmaps drin zu lassen und jedesmal die kleinen Bitmaps zu schieben. Das kann Picasso aber ja nicht wissen.

Einmal ins Swappen gekommen, wird soz. immer im Kreis geswapped und die FPS brechen auf 25% ein oder noch mehr.
Ringtausch wäre wirklich ein ziemlich ineffizienter Algorithmus. Aber Du könntest ein wenig nachhelfen, in dem Du die kleinen BitMaps lockst und wieder freigibst, auf die Art werden sie ja erzwungenermaßen in's FastRAM geholt, was die Reihenfolge ändern sollte.
Zitat:
Deshalb drehen sich in AsteroidsTR die Asteroiden nicht in der Light Version. Dadruch werden weniger Graka RAM gebraucht und swappen wird unwahrscheinlicher.

Light und Fat Version? Wärs nicht besser, den verfügbaren Videospeicher dynamisch abzufragen? P96 bietet das ja an...
Das wäre auch für o.g. Trick anzuraten, das erzwungene Ins-FastRAM-holen nur dann durchzuführen, wenn man merkt, das Swapping unvermeidlich ist.

mfg

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

[ - Antworten - Zitieren - Direktlink - ]
18.02.2007, 20:13 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von whose:
Nicht "auf einmal". Im Extremfall.
Nix anderes heißt es, wenn ich sage, dass es keine Garantie gibt. Heutige Systeme machen das vielleicht nur im Extremfall, neuere vielleicht nach Lust und Laune...
Ich hoffe ja auch, dass der Ringtausch durch einen besseren Algorithmus abgelöst wird/wurde, falls er wirklich benutzt wird/wurde...

Fazit: garantiert ist nur, was so auch spezifiziert wurde. Und selbst das nicht zu 100%.

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

[ - Antworten - Zitieren - Direktlink - ]
18.02.2007, 20:18 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von Ralf27:
EDIT: Achja, die Farbtiefe, hab ich auch mal testweise angepast, bzw. auch mal ein Bitmap aufgebaut die doppelt so hoch ist wie benötigt und dann geblittet, sodas die bitmap halt gleich ist.

Mich deucht, Du hast nicht ganz verstanden, worum es dabei überhaupt ging. Wir reden doch immer noch von einem Fenster auf einem public screen, oder?

Vielleicht solltest Du erst mal Dein Programm ohne double-buffering testen. Wenn Dein Linien Zeichnen an sich schon langsamer als AGA sein sollte, hätte es nämlich kaum Sinn, sich über die Buffer-Strategien den Kopf zu zerbrechen.

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

[ - Antworten - Zitieren - Direktlink - ]
18.02.2007, 23:43 Uhr

whose
Posts: 2156
Nutzer
Zitat:
Original von Holger:
Zitat:
Original von Ralf27:
EDIT: Achja, die Farbtiefe, hab ich auch mal testweise angepast, bzw. auch mal ein Bitmap aufgebaut die doppelt so hoch ist wie benötigt und dann geblittet, sodas die bitmap halt gleich ist.

Mich deucht, Du hast nicht ganz verstanden, worum es dabei überhaupt ging. Wir reden doch immer noch von einem Fenster auf einem public screen, oder?

Vielleicht solltest Du erst mal Dein Programm ohne double-buffering testen. Wenn Dein Linien Zeichnen an sich schon langsamer als AGA sein sollte, hätte es nämlich kaum Sinn, sich über die Buffer-Strategien den Kopf zu zerbrechen.

Du bist aber auch ein unverbesserlicher Pessimist ;)

Ralf hat meines Wissens eine BlizzardPPC samt zugehöriger BVisionPPC. Wenn er die Linien per Move() und Draw() zeichnen läßt, ist diese Kombo garantiert um ein Vielfaches flotter als AGA, auch ohne Offscreen-Bitmap :D

Das ist selbst die CyberVision64/3D in meinem 1200er im Zorro2-Modus. Geswapt wird da auch nichts, die 8MB RAM der BVisionPPC reichen für einige Spielereien.

Er sollte wirklich mal schauen, wie er seine Offscreen-Bitmap zusammenbaut und vor allem zusehen, daß sie wirklich der Screen-Bitmap entspricht vom Aufbau her.

Eventuell könnte es helfen, die entsprechenden Stellen in seinem Programm zu posten.

@Ralf27:

Zeig doch einmal, wie Du die Bitmap anlegst. Eventuell zeigt sich das Problem dann ohne viel Diskussion. Eigentlich ist das gar nicht so schwierig mit den Offscreen-Bitmaps.

Grüße

--
---

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

[ - Antworten - Zitieren - Direktlink - ]
19.02.2007, 18:12 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von whose:
Ralf hat meines Wissens eine BlizzardPPC samt zugehöriger BVisionPPC. Wenn er die Linien per Move() und Draw() zeichnen läßt, ist diese Kombo garantiert um ein Vielfaches flotter als AGA, auch ohne Offscreen-Bitmap :D

"auch ohne" ist schon mal falsch. Es ist sicher, dass es ohne offscreen-BitMap schneller geht. Ob es aber auf einem TrueColor-Display mit möglicherweise bis an die Grenze des Pixeltakts hochgetriebener Auflösung immer noch schneller als auf einem 4-Farb-AGA-Screen ist, kann man pauschal nicht beantworten.

Wir kennen weder die von Ralf verglichenen Konfigurationen, noch seine Messmethodik und bekommen offenbar auch keine Code-Beispiele zu den eigentlichen Operationen.

Also, lass Dich da nicht von Glauben lenken...

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

[ - Antworten - Zitieren - Direktlink - ]
19.02.2007, 20:04 Uhr

Ralf27
Posts: 2779
Nutzer
Zitat:
Original von Holger:
Wir kennen weder die von Ralf verglichenen Konfigurationen, noch seine Messmethodik und bekommen offenbar auch keine Code-Beispiele zu den eigentlichen Operationen.

Leider kann ich nicht rund um die Uhr am Rechner sein, ich hab auch noch andere Sachen zu tun wie z.b.schaffe gehn. Also bitte nicht so schnell Schlussfolgerungen schliesen. :D I-)

Ich bin euch ja dankbar das ihr mir helfen wollt. Ich werden ein Codebeispiel noch nachliefern. Ich teste ja erst mal alles auf meinem A1200 mit BVision. Die tests laufen übrigens mit FPS, also wie schnell ich etwas zeichnen und dann wiedergeben kann. Wenn ich z.b. unter AGA ca. 10fps erreiche, bricht dies auf der Grafikkarte etwas zusammen, obwohl ich mehr erwartet hätte.

So, lasst mich erst mal wieder etwas Code sortieren, dann poste ich es hier.
--
http://www.alternativercomputerclub.de.vu

[ - Antworten - Zitieren - Direktlink - ]
19.02.2007, 20:45 Uhr

Ralf27
Posts: 2779
Nutzer 		Hier einmal der Code:

Denn Originalcode hab ich im Internet gefunden. Dieser war für AmigaBasic und extrem langsam. Ich hab auch mal denn Autor kontaktiert bzw. ob ich denn Code benutzen und weiterentwickeln kann. Ich hab vor einen Editor dafür zu schreiben, mit dem man das ganze in Echtzeit verändern kann.

Der folgende Code ist komplett, man kann ihn also so mit MB übersetzen. Ich brauche für einen Frame unter AGA 0.125 Sekunden, auf der Grafikkarte dauert es etwas länger, ca. 0.17.

Achja, ich seh da noch einiges an Optimierungsmöglichkeiten. Da kann man noch was machen. Und mir ist schon klar das es mit C oder AmiBlitz nur so flutschen würde. Ich sollte wirklich mal die Sprache wechseln...

code:
REM $nowindow
REM $noerrors
REM $nolines
REM $nojumps
REM $library
REM $nodebug
REM $nobreak
REM $noevent
REM $nooverflow
REM $novarchecks
REM $noautodim
REM $noaddicon
REM $noarray
REM $nostack

REM $INCLUDE Asl.bh
REM $INCLUDE Exec.bh
REM $INCLUDE Graphics.bh
REM $INCLUDE Intuition.bh
LIBRARY OPEN "exec.library", LIBRARY_MINIMUM&
LIBRARY OPEN "intuition.library", 39
LIBRARY OPEN "graphics.library", 39
LIBRARY OPEN "asl.library", LIBRARY_MINIMUM&

 DEFINT a-z
 
 CONST sBreite=640
 CONST sHoehe=512
 
 tagsl&=AllocVec&(100,MEMF_PUBLIC&)
 IF tagsl&=0 THEN Ende
 
 TAGLIST tagsl&,_
 ASLSM_TitleText&,"Benötigt:"+STR$(sBreite)+"*"+STR$(SHoehe),_
 ASLSM_Window&,win&,_
 ASLSM_InitialDisplayID&,DisplayID&,_
 TAG_END&
 fr&=AllocAslRequest&(ASL_ScreenModeRequest&,tagsl&)
 IF fr& THEN
  IF AslRequest&(fr&,0)THEN DisplayID&=PEEKL(fr&)
  FreeASlRequest fr&
 END IF
 IF DisplayID&=0 THEN Ende
 
 TAGLIST tagsl&,_
 SA_Depth&, 1,_
 SA_Width&, sBreite, _
 SA_Height&, sHoehe, _
 SA_DisplayID&, DisplayID&, _
 TAG_END&
 eigenerscr&=OpenScreenTagList&(0,tagsl&)
 IF eigenerscr&=0 THEN Ende
 TAGLIST tagsl&, _
 WA_IDCMP&,IDCMP_VANILLAKEY&, _
 WA_Flags&,WFLG_BORDERLESS&+ _
           WFLG_ACTIVATE&,_
 WA_CustomScreen&,eigenerscr&,_
 TAG_END&
 win&=OpenWindowTagList&(0,tagsl&)
 IF win&=0 THEN Ende
 winrp&=PEEKL(win&+RPort)
 userport&=PEEKL(win&+UserPort)
 ScreenBitmap&=eigenerScr&+ScreenBitMap
 
 BufferBitmap&=AllocBitMap&(sBreite,sHoehe,1,BMF_INTERLEAVED&+BMF_MINPLANES&,ScreenBitMap&)
 IF BufferBitmap& THEN
  Bufferrp&=AllocVec&(RastPort_sizeof,MEMF_PUBLIC&)
  IF Bufferrp& THEN
   InitRastPort Bufferrp&
   POKEL Bufferrp&+RastPortBitMap,BufferBitmap&
  ELSE
   GOTO Ende
  END IF
 ELSE
  GOTO Ende
 END IF
 rp&=Bufferrp&

 Pi!=4!*ATN(1!)
 
 i=0
WHILE Ende=0
 m&=GetMsg&(Userport&)
 IF m& THEN
  w&=PEEKL(m&+Class)
  w2&=PEEKW(m&+IntuiMessageCode)
  ReplyMsg m&
  IF w&=IDCMP_VANILLAKEY& THEN Ende=1
 END IF
 
 INCR i:IF i>32766 THEN i=0
 SetRast rp&,0
 
 x=184:y=385:z=47:Al!=3!+i*45!/z

ZeichneZahnrad x,y,4.9,z,Al!,1.25,1!,20!

BerechneNeulage 32,100.9453,4.9,z,x,y,Al!
ZeichneZahnrad x,y,4.9,z,Al!,1.25,1!,20!


BerechneNeulage 23,99.41803,4.9,z,x,y,Al!
ZeichneZahnrad x,y,4.9,z,Al!,1.25,1!,20!

BerechneNeulage 26,356!,4.9,z,x,y,Al!
ZeichneZahnrad x,y,4.9,z,Al!,1.25,1!,20!
BerechneNeulage 38,304!,4.9,z,x,y,Al!
x1=x:y1=y:Al1!=Al!:z1=z

ZeichneZahnrad x,y,4.9,z,Al!,1.25,1!,20!
BerechneNeulage 17,278.0417,4.9,z,x,y,Al!

ZeichneZahnrad x,y,4.9,z,Al!,1.25,1!,20!
BerechneNeulage 24,281.101,4.9,z,x,y,Al!

ZeichneZahnrad x,y,4.9,z,Al!,1.25,1!,20!
BerechneNeulage 27,3.372287,4.9,z,x,y,Al!

ZeichneZahnrad x,y,4.9,z,Al!,1.25,1!,20!
BerechneNeulage 21,105!,4.9,z,x,y,Al!

ZeichneZahnrad x,y,4.9,z,Al!,1.25,1!,20!
x=x1:y=y1:Al!=Al1!:z=z1
BerechneNeulage 25,8!,4.9,z,x,y,Al!

ZeichneZahnrad x,y,4.9,z,Al!,1.25,1!,20!
BerechneNeulage 22,77.05708,4.9,z,x,y,Al!

ZeichneZahnrad x,y,4.9,z,Al!,1.25,1!,20!
BerechneNeulage 20,177.2706,4.9,z,x,y,Al!

ZeichneZahnrad x,y,4.9,z,Al!,1.25,1!,20!

t#=TIMER:a$=STR$(t#-t2#):t2#=t#
move rp&,10,10
text rp&,SADD(a$),LEN(a$)

 junk=BltBitMapRastPort(BufferBitmap&,0,0,winrp&,0,0,sBreite,sHoehe,&Hc0)
WEND

Ende:
 IF win& THEN CloseWindow win&
 IF eigenerscr& THEN junk&=CloseScreen&(eigenerscr&)
 IF bufferrp& THEN FreeVec bufferrp&
 IF bufferbitmap& THEN FreeBitmap bufferbitmap&
 IF tagsl& THEN FreeVec tagsl&
END

SUB ZeichneZahnrad(BYVAL x,BYVAL y,BYVAL m!,BYVAL z,Al!,BYVAL hff!,BYVAL haf!,BYVAL Bet!)STATIC
 SHARED rp&,Pi!
 d!=m!*z
 df!=d!-2!*m!*hff!
 da!=d!+2!*m!*haf!
 Alr!=Al!/180!*Pi!
 Betr!=Bet!/180!*Pi!
 dg!=d!*COS(Betr!)
 IF df!<dg! THEN df!=dg!
 swfr!=SQR(df!*df!-dg!*dg!)/dg!
 swar!=SQR(da!*da!-dg!*dg!)/dg!
 Teilw!=2!*Pi!/z
 Delr!=TAN(Betr!)
 ww!=Teilw!/4!-Betr!+Delr!
 r!=dg!/2!
 ab!=swar!-swfr!
 Lwr!=Alr!        
 FOR Zahn=0 TO z-1
  w!=Lwr!-ww!
  a!=w!+swfr!:b!=swfr!*r!
  ax=x+r!*COS(a!)+b!*SIN(a!)
  ay=y-r!*SIN(a!)+b!*COS(a!)
  IF Zahn THEN
   Draw rp&,ax,ay
  ELSE
   Move rp&,ax,ay:ox=ax:oy=ay
  END IF
  a!=a!+ab!:b!=(a!-w!)*r!
  Draw rp&,x+r!*COS(a!)+b!*SIN(a!),y-r!*SIN(a!)+b!*COS(a!)
  w!=Lwr!+ww!
  a!=w!-swar!:b!=-swar!*r!
  Draw rp&,x+r!*COS(a!)+b!*SIN(a!),y-r!*SIN(a!)+b!*COS(a!)
  a!=a!+ab!:b!=(a!-w!)*r!
  Draw rp&,x+r!*COS(a!)+b!*SIN(a!),y-r!*SIN(a!)+b!*COS(a!)
  Lwr!=Lwr!+Teilw!
 NEXT
 Draw rp&,ox,oy
END SUB

SUB BerechneNeulage (BYVAL nz,BYVAL w!,BYVAL m!,z,x,y,Al!) STATIC
 a!=(z+nz)*m!/2!
 Um!=ATN(1!)/45!
 x=x+a!*COS(w!*Um!)
 y=y-a!*SIN(w!*Um!)
 Al!=w!-180!+180!/nz+(w!-Al!)*z/nz
 z=nz
END SUB
--
http://www.alternativercomputerclub.de.vu

[ - Antworten - Zitieren - Direktlink - ]
19.02.2007, 20:54 Uhr

Ralf27
Posts: 2779
Nutzer 		Kurz noch ne kleine Anmerkung wegen dem Code: Der ist so nur experimentel, also deswegen auch keine Fehlermeldungen, etc. und wie ich eben auch gesehn hab, kann man auch einige Zeilen drausen lassen wie z.b. bei der Tagliste zum ASL-Requester...
--
http://www.alternativercomputerclub.de.vu

[ - Antworten - Zitieren - Direktlink - ]
19.02.2007, 23:29 Uhr

whose
Posts: 2156
Nutzer 		@Ralf27:

Nimm da mal BMF_INTERLEAVED heraus, die wenigsten RTG-GraKas bieten Interleaved-Bitmap-Unterstützung. Für AGA-Screenmodes sollte Interleaved automagisch der Fall sein (auch ohne das Tag), sofern die Screen-Bitmap für einen AGA-Screenmode angelegt (also entsprechende DisplayID im Requester gewählt) und für Deine Offscreen-Bitmap als Friend genutzt wird.

So, wie es derzeit ist, wird die Bitmap wohl AGA-freundlich planar interleaved angelegt, da muß dann für eine RTG-Zielbitmap ständig gewandelt werden, was heftig bremsen kann.

Ich weiß jetzt aus dem Stegreif nicht, was mit solchen RTG-unfreundlichen Bitmaps speichertechnisch passiert, aber ich könnte mir gut vorstellen, daß diese im Fast RAM oder gar im Chip RAM landen, weil die so oder so nicht direkt darstellbar sind, wenn der von Dir benutzte RTG-Grafikchip keine interleaved-Bitmaps unterstützt.

Grüße

--
---

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

[ - Antworten - Zitieren - Direktlink - ]
19.02.2007, 23:50 Uhr

Ralf27
Posts: 2779
Nutzer 		@whose

Das macht leider auch keinen Unterschied, auf AGA ist es immer noch schneller...
--
http://www.alternativercomputerclub.de.vu

[ - Antworten - Zitieren - Direktlink - ]
20.02.2007, 00:52 Uhr

whose
Posts: 2156
Nutzer 		@Ralf27:

Wenn ich Zeit finde, übersetze ich das Programm mal so gut wie möglich nach C und teste es auf meinen Maschinen.

Derweil kannst Du ja noch etwas testen, was ich vorher übersehen hatte: Gib der Offscreen-Bitmap doch bitte noch das Flag BMF_DISPLAYABLE mit und probiers nochmal.

Grüße

--
---

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

[ - Antworten - Zitieren - Direktlink - ]
20.02.2007, 11:19 Uhr

Der_Wanderer
Posts: 1229
Nutzer 		Also du solltest folgendes probieren:

1. Öffne den Screen in der Tiefe, die vom ASL Requester kommt.
Eine 24bit modus mit Tiefe 1 zu öffnen ist schonmal ziemlich ineffizient.

2. Allociere die Bitmap auch in der gleichen Tiefe.
Ich allociere die Bitmaps so:

code:
... screen öffnen ....
*scr.Screen = ...

d.l = GetBitMapAttr_(*scrBitMap,#BMA_DEPTH)
If d<=0 Then d=24

*bmap.BitMap = AllocBitMap_(*scrWidth,*scrHeight,d,#BMF_DISPLAYABLE,*scrBitMap)
*layerinfo.LayerInfo  = NewLayerInfo_()
If *layerinfo Then *layer.Layer  = CreateUpfrontHookLayer_ (*layerinfo ,*bmap ,0,0,*scrWidth-1,*scrHeight-1,0,#LAYERS_NOBACKFILL,0)
If *layer Then *rp.RastPort  = *layerrp

Und du hast einen sauber allocierten RastPort zum zeichnen.
Bei mir ist das sehr schnell, auch auf einem Classic mit ZorroII
bekommst du 50Hz bei 16bit hin.

Das mit der Tiefe 1 ist keine gute Idee denke ich, und die Daten müssen jedesmal konvertiert werden und durch den Zorro Bus gedrückt werden, der langsamer ist als ChipMem.
eine Grafikkarte unterstützt normalerweise keine 1Bit Mode. Das sind einfach 8bit Modi.

--
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 - ]
20.02.2007, 15:51 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von Ralf27:
code:
ScreenBitmap&=eigenerScr&+ScreenBitMap

Böses Foul auf RTG-Screens, genaugenommen grundsätzlich falsch seit AOS3.0. Diese leider von AOS1.0-Entwicklern so oft eingesetzte Technik, Strukturen in andere Strukturen einzubetten, und das alles so public herauszureichen, beißt sich mit modernen Erweiterungen.

Die richtige BitMap ist als Pointer in der RastPort-Struktur eingetragen, die ihrerseits allerdings leider wieder eingebettet ist:
code:
ScreenBitmap&=PEEKL(eigenerScr&+RastPort%+RastPortBitMap%)

mfg

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

[ - Antworten - Zitieren - Direktlink - ]
20.02.2007, 16:04 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von Ralf27:
code:
TAGLIST tagsl&,_
 ASLSM_TitleText&,"Benötigt:"+STR$(sBreite)+"*"+STR$(SHoehe),_
 ASLSM_Window&,win&,_
 ASLSM_InitialDisplayID&,DisplayID&,_
 TAG_END&
 fr&=AllocAslRequest&(ASL_ScreenModeRequest&,tagsl&)

Constraints in die Titelzeile eines Requesters zu schreiben, ist eine ziemlich bekloppte Programmiertechnik. Gib dem System die Information, dann brauchst Du keine Fehlerbehandlung für den Fall, dass der Benutzer die Titelzeile nicht gelesen hat, zu programmieren. Vor allem kannst Du dann das in die Titelzeile schreiben, was da hingehört, nämlich den Zweck des Ganzen...
code:
TAGLIST tagsl&,_
 ASLSM_TitleText&,"Modus für ... auswählen",_
 ASLSM_Window&,win&,_
 ASLSM_InitialDisplayID&,DisplayID&,_
 ASLSM_MinHeight&, SHoehe, ASLSM_MinWidth&, sBreite,_
 TAG_END&
 fr&=AllocAslRequest&(ASL_ScreenModeRequest&,tagsl&)

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

[ - Antworten - Zitieren - Direktlink - ]
20.02.2007, 20:48 Uhr

Ralf27
Posts: 2779
Nutzer
Zitat:
Original von Holger:
Zitat:
Original von Ralf27:
code:
ScreenBitmap&=eigenerScr&+ScreenBitMap
Böses Foul auf RTG-Screens, genaugenommen grundsätzlich falsch seit AOS3.0. Diese leider von AOS1.0-Entwicklern so oft eingesetzte Technik, Strukturen in andere Strukturen einzubetten, und das alles so public herauszureichen, beißt sich mit modernen Erweiterungen.

Oh, danke, das war mir jetzt wirklich unbekannt. hm, ich will ja gar nicht wissen was ich alles falsch mache wo ich wirklich denke das es stimmt.

Ich hab es gleich mal eingebaut und getestet... leider ist es als noch langsamer als unter AGA, bzw. hat sich nichts verändert. Es muß auch noch woanderst hängen.

Aus reiner Neugierde: Wo steht das eigentlich, das man das nicht mehr machen darf? Wie schon geschrieben, meine ganzen Handbücher sind OS1.2, bzw. die neuesten OS1.3 ...
--
http://www.alternativercomputerclub.de.vu

[ - Antworten - Zitieren - Direktlink - ]
20.02.2007, 20:54 Uhr

Ralf27
Posts: 2779
Nutzer
Zitat:
Original von Holger:
Constraints in die Titelzeile eines Requesters zu schreiben, ist eine ziemlich bekloppte Programmiertechnik.
Das mag schon sein, ich hab jetzt mal die beiden TAGs hinzugefügt, aber an der Auswahlliste hat sich nichts verändert. Ich denk mir mal, das das nur bei der Auflösung an sich und nicht an den Screenmode gerichtet ist, kann das sein? Also z.b. LowRes und dann mindestens 640*512. Ist aber auch nicht gerade sinnvoll. Oder ich müßte dann gar ein Hook einbauen, was ich bei einem MB-Demo gesehn habe, aber die Demos kann mann gelinde gesagt eh kaum verstehn. :(
--
http://www.alternativercomputerclub.de.vu

[ - Antworten - Zitieren - Direktlink - ]

-1- 2 [ - Beitrag schreiben - ]


amiga-news.de Forum > Programmierung > AGA<->CyberGraphX: Buffer [ - Suche - Neue Beiträge - Registrieren - Login - ]


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