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

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

Erste << 8 9 10 11 12 -13- 14 15 16 17 18 >> Letzte Ergebnisse der Suche: 1229 Treffer (30 pro Seite)
Der_Wanderer   Nutzer

28.04.2010, 10:53 Uhr

[ - Direktlink - ]
Thema: C oder C++?
Brett: Programmierung

Hallo!

Ich portiere gerade etwas Code von Amiblitz nach C (oder C++), damit ich es unter Windows/Linux etc. nutzen kann.
Ich möchte den C Code aber auch auf dem Amiga weiterhin nutzen können.

Ist das problematisch, wenn ich C++ benutze, oder sollte man sich lieber an plain C halten?
C++ hat einige Vorzüge, die ich gerne nutzen würde. Wenn ich damit aber auf dem Amiga in Teufels Küche komme, dann mache ich das lieber strikt in C.
Momentan habe ich auf dem Amiga GCC 2.x installiert, und würde ungern an der Install rumpfuschen müssen.

Wenn ich C++ sage, dann meine ich nicht exzessiv mit OOP, Templates, STL etc., sondern lediglich simple Dinge wie Referenzparameter etc.
Der Unterschied zu plain C ist also nicht gross.

Sorry, wenn die Frage etwas dämnlich ist, aber auf dem Amiga hab ich mit C kaum Erfahrung.

--
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

 
Der_Wanderer   Nutzer

11.04.2010, 23:08 Uhr

[ - Direktlink - ]
Thema: Algo zum Kreiszeichnen
Brett: Programmierung

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

 
Der_Wanderer   Nutzer

11.04.2010, 22:26 Uhr

[ - Direktlink - ]
Thema: Algo zum Kreiszeichnen
Brett: Programmierung

> Ich bleib aber bei w und b um Speicher zu sparen. Ich bin noch auf einem echten Amiga.
Du sparst satte 4 Bytes, bist aber dafür langsamer. Schlechter Deal!

Zur graphics.lib:
Ja, sieht unoptimiert aus, als würde es WritePixel verwenden.
Ohne WritePixel wäre man vermutlich 10-20 mal schneller.

Nicht dass WritePixel per se schlecht wäre, aber wenn man vor hat 100 Pixel zu zeichnen ist das schlecht, weil der eine WritePixel nichts von den anderen 99 WritePixels weis. Jeder Pixel muss also erneut testen, ob er im Layer sichtbar ist, sich den Pen holen, die Farbe auflösen, Addresse in der Bitmap ermitteln etc. etc.

Direkt spart man sich da massig Arbeit. Also die Bitmap EINMAL locken, einen Pixel zeichnen, Pixel Wort-Breite ermitteln und den Pixel dann direkt im Speicher kopieren. Etwas unsauber, wenn man nicht der Treiber ist, dürfte aber zu 99% überall laufen.
Wobei man hier noch zwischen Graka und AGA unterscheiden muss.

Geht denn der "schnelle" Maxon Befehl überall (AGA/RTG ?)


--
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

 
Der_Wanderer   Nutzer

11.04.2010, 22:08 Uhr

[ - Direktlink - ]
Thema: Algo zum Kreiszeichnen
Brett: Programmierung

Amiblitz3 speichert als ASCII, man muss die Datei Endung .ab2 oder .ab3 (ab Version 3.5) angeben. Nur das veraltete .bb2 Format speichert proprietär.

Ein wenig mehr Speed bekommst du, wenn du statt .b oder .w den Typ .l verwendest, zumindest auf EMUs ist 32bit schneller als 16 oder 8bit.

Aber der Algorithmus ist schon extrem optimiert, bei AB3 schätze ich mal 99% WritePixel und 1% Algorithmus. D.h. selbst wenn Maxon 10mal langsamer wäre, fällt das kaum ins Gewicht.

Wenn du also die Speed der Srpachen testen willst, dann kommentiere WritePixel aus und teste dann mal. Verwende die eclock, das ist viel genauer. Timer nutzt vermutlich den Vertical Blank.

Der atomare Maxon Circle Befehl ist vermutlich deshalb schneller, weil er kein WritePixel verwendet (das mss ja jedesmal den Layer abklopfen), sondern evtl. nur einmal und dann direkt die Bitmap bearbeitet.
--
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

 
Der_Wanderer   Nutzer

11.04.2010, 21:38 Uhr

[ - Direktlink - ]
Thema: Algo zum Kreiszeichnen
Brett: Programmierung

Poste doch mal den Code. (bin allerdings jetzt erstmal 2 Wochen im Urlaub ;-)

Auf jedenfall bestätigen deine Beobachtungen, dass die meiste Zeit in WritePixel verbracht wird. D.h. es ist egal, ob WritePixel nun von hoch optimiertem ASM, C, Amiblitz3 oder Maxon aufgerufen wird, es bleibt ja immer gleich schnell.

Was du machen kannst ist, einfach mal WritePixel auskommentieren, und schau mal dann wie lange es dauert (dazu die Anzahl der Durchläufe erhöhen!). Vermutlich nur noch 10% oder weniger. Dann siehst du erst die Unterschiede zwischen den Programmiersprachen.

Bei Amiblitz musst du auf jeden Fall den Debugger ausmachen und "Optimize 7" verwenden, sowie keine .q "Quicks" sondern Floats und Integer.
Zeitmessen kannst du sher genau mit der eclock.inlcude:
Also:
code:
optimize 7
syntax 2
XINCLUDE "eclock.include.bb2"

WBToScreen 0 ; Workbench holen
Window 0,0,0,320,200,$0,"Circle Test",1,0 ; Fenster aufmachen

*rp.RastPort = RastPort(0) ; Rastport von Fenster holen
SetApen_ *rp,1 ; schwarz setzen
eclock_Start{1000} ; 1/1000 sec Auflösung für die Uhr und los geht's


; dein Algorithmus
...
x.l = ...
y.l = ...
WritePixel_ *rp,x,y ; Pixel malen
...

elapsed_ms.l = eclock_Stop{} ; Zeit stoppen

; Bericht ausgeben
message{"Verstrichene Zeit: "+str$(elapsed_ms)+" ms!"}
End


P.S.: "all.res" nicht in den Compiler Settings vergessen, wegen den AmigaOS Defines. Am besten das WBApp Template nehmen.

--
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



[ Dieser Beitrag wurde von Der_Wanderer am 11.04.2010 um 21:40 Uhr geändert. ]

[ Dieser Beitrag wurde von Der_Wanderer am 11.04.2010 um 21:43 Uhr geändert. ]
 
Der_Wanderer   Nutzer

11.04.2010, 14:34 Uhr

[ - Direktlink - ]
Thema: Algo zum Kreiszeichnen
Brett: Programmierung

Die Geschwindigkeit hängt vor allem davon ab, wie die Pixel gesetzt werden. Wie machst du das in Maxon?
Vermutlich "illegal" durch direktes schreiben der Bitmap?
--
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

 
Der_Wanderer   Nutzer

11.04.2010, 14:25 Uhr

[ - Direktlink - ]
Thema: Algo zum Kreiszeichnen
Brett: Programmierung

Der Kreisbefehl in Maxon ist ja nicht in Maxon geschrieben, oder?
Ich nehme mal an der ist in Assembler geschrieben.
Irgendwo optimiert er dann besser oder lässt was weg, vielleicht berücksichtigt er keine Layer etc.

> Wie zeichnet eigentlich das System Kreise?
Das hängt wohl ganz vom Treiber ab.

Da wir aber keinen der Sourcen kennen, ist das schwer zu sagen. Ein Unterschied von 50% ist aber noch gar nicht so gross.

--
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

 
Der_Wanderer   Nutzer

29.01.2010, 19:24 Uhr

[ - Direktlink - ]
Thema: RastPort und Multithreading
Brett: Programmierung

Im Prinzip ist hier nun alles gesagt. Danke euch allen!

--
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

 
Der_Wanderer   Nutzer

28.01.2010, 14:52 Uhr

[ - Direktlink - ]
Thema: RastPort und Multithreading
Brett: Programmierung

@DiskSalv

Ja, wenn man von vornherein weis, dass man längere Zeit nicht reagieren können wird, dann sollte man die Buttons (außer dem Abbruch Button) disablen, oder gleich das ganze Fenster und einen exklusiven Dialog mit Progressbar und Abbruch Button.
Evtl. käme dann auch ein Feature wie unter Windows gelegen, wo man nur einen Knopf drücken kann, dann wird das Fenster blockiert, wenn die Message nicht innerhalb eines kurzen Zeit abgeholt wird, solange bis die Applikation wieder Messages abholt. (automatischer Busy Pointer)

Ausser Feelin (was sehr ähnliches Konzept wie NTUI hat) gibt es aber unter OS3.x kein GUI Toolkit mehr, das weiterentwicklet wird. Und allen Toolkits fehlen Dinge wie AlphaChannel Support, Skins etc.

--
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

 
Der_Wanderer   Nutzer

28.01.2010, 14:14 Uhr

[ - Direktlink - ]
Thema: RastPort und Multithreading
Brett: Programmierung

@whose

Nicht jedes tuiObjekt hat einen eigenen Thread am laufen.
Bisher gibt es nur den Hauptthread, wenn der GetEvent() aufruft wird alles anstehende erledigt. Plan ist, einen zweiten Thread laufen zu lassen, der trivale Dinge schon vorher erledigen kann, wie z.B. den Zustand eines gedrückten Buttons neu zeichnen, damit die GUI responsiver ist, wenn die Applikation gerade mal "nicht kann".

Eigentlich wirkt es nur schneller, aber das visuelle Feedback erlaubt schnelleres Arbeiten, da man bereits den Knopfdruck im Gehirn abhacken kann. Ohne visuelles Feedback ist man geneigt abzuwarten, ob es nun auch wirklich geklappt hat mit dem Knopfdruck.
Viele interne Aktionen kann man ja weder sehen noch fühlen, da kommt das das visuelle Feedback subjektiv dem Erledigen der Aktion bereits gleich.

--
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



[ Dieser Beitrag wurde von Der_Wanderer am 28.01.2010 um 14:17 Uhr geändert. ]
 
Der_Wanderer   Nutzer

28.01.2010, 14:11 Uhr

[ - Direktlink - ]
Thema: RastPort und Multithreading
Brett: Programmierung

Beides ist möglich und auch notwendig.

Ein Video Player würde aus eigenem Antrieb den Custom View neu bemalen, wenn nämlich ein Bild fertig decodiert ist.

Ein Bildanzieger würde den Custom View nur dann neu zeichnen, wenn man das Fenster re-sized oder die Verdeckung sich ändert oder das Custom View aus anderen Gründen zerstört worden ist. NTUI schickt daraufhin die entsprechende Refresh Message.

--
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

 
Der_Wanderer   Nutzer

28.01.2010, 13:48 Uhr

[ - Direktlink - ]
Thema: RastPort und Multithreading
Brett: Programmierung

Also eigentlich habe ich hier ja nur mal ins Blaue gefragt, da man hier oft sehr interessante Hinweise bekommt.

Ich muss aber ein wenig mehr erläutern:

Das Konzept meines GUI Toolkit sieht eher aus wie MUI, und ist schon recht weit durchdacht und auch bereits zu grossen Teilen implementiert.

Sämtliche Kommunikation mit dem Benutzer läuft über die ntui.library.
Alle Events, seien es IDCMP, AREXX, ScreenNotify, App oder etwas, was in Zukunft noch kommt, bekommt man von EINER Warteschlange, die man mit EINER Funktion abfrägt. Die Messages gehören nicht notwendigerweise zu einem "physikalischen" Fenster. Eine Message trägt die ID der Aktion, nicht die ID des auslösenden GUI Elements. (soweit dies Möglich ist)
Aus Applikations-Sicht ist es mir ja auch völlig wurscht, wenn man ein Fenster schließen möchte, ob der User nun auf das CloseGadget gedrückt hat, ESC gedrückt oder einen "Exit" Knopf betätigt hat. Wenn man das doch unterschieden möchte, trifft man die Unterscheidung beim Designen der GUI, nicht beim Implementieren der App.

Die Abkopplung von AmigaOS Fenstern ist wichtig, damit tuiObjecte z.B. an/abgedockt werden können und vieles mehr. Ein tuiObjekt muss auch nicht immer sichtbar sein, trotzdem kann man es manipulieren, mit Daten füllen usw. Aus Sicht der Applikation ist das völlig egal.

Die Messages, die man verarbeitet, sind auch nicht mehr Amiga spezifisch, d.h. wenn man mit NTUI arbeitet tauchen (normalerweise) keinerlei AmigaOS Defines oder Funktionen mehr auf. Das ist wichtig für eine evtl. Portierbarkeit. Kleine Ausnahme ist hier das zeichnen eigener Custom Views, da man hier sowieso Amiga Spezifischen Code erwarten muss. Wobei das Konzept des RastPort natürlich auf so gut wie allen Betriebssystemen verwendet wird, unter Windows ist das der DrawContext.
Da gebe ich allerdings wirklich den RastPort raus, und nicht einen abstrahierten "DrawContext", damit man alle AmigaOS und 3rd Party Funktionen nutzen kann, die ja normalerweise auf einem AmigaOS RastPort arbeiten.

Momentan läuft NTUI synchron (wie MUI), d.h. jedesmal, wenn die Applikation ntui_GetEvent() aufruft, um an neue Events zu kommen, werden alle Operationen durchgeführt wie GUI Refresh, abholen aller Arten von Messages.
Das funktioniert auch gut so, solange die Applikation nicht blockiert ist. Das ist ja der häufigste Kritikpunkt an MUI. Deshalb möchte ich, zumindest in der Version 2.0, das Abholen der Messages und das optische Reagieren der GUI in einem separaten Thread machen. Für den App Programmierer ist das natürlich alles transparent. Synchron/Asynchron kann man dann evtl. in den Preferences von NTUI wählen.

Auch da ist eigentlich alles vorbereitet, nur mache ich mir Gedanken über den RastPort, der eben auch von der Applikation selbst bearbeitet werden können muss.
NTUI soll so einfach wie nur irgendwie möglich für den App Programmierer sein. Also deutlich einfacher als BOOPSI oder MUI.
Mein Ziel ist es, dass der App Programmierer sich auf die App konzentriert, während es bei den meisten Amiga Toolkits schon fast die Hauptaufgabe der App ist, sich mit der GUI auseinanderzusetzen.

Und da benötige ich einen geeigneten Mechanismus, wie der Thread von NTUI nicht mit dem Thread der Applikation in die Quere kommt.

Ich denke die Lösung mit "ntui_ObtainRastPort" ist wohl die beste.
D.h. der App Programmierer muss sich den RastPort jedesmal erfragen. So kann ich seine Zeichenoperationen auch beliebig umleiten, z.B. für DoubleBuffering.
Das sollte den App Programmierer ja nicht weiter stören. Irgendwoher muss er sich den RP ja sowieso besorgen.

Und noch für alle, die evtl. den Kopf schütteln und sich denken "noch so ein GUI Ding":
Ich denke dass NTUI tatsächlich einige Vorteile bietet, für den User und für den App Programmierer, die die anderen Toolkits nicht haben.
Aber ob es jemand benutzen wird ausser mir, muss man erst noch sehen...

--
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



[ Dieser Beitrag wurde von Der_Wanderer am 28.01.2010 um 13:57 Uhr geändert. ]

[ Dieser Beitrag wurde von Der_Wanderer am 28.01.2010 um 14:00 Uhr geändert. ]
 
Der_Wanderer   Nutzer

27.01.2010, 18:25 Uhr

[ - Direktlink - ]
Thema: RastPort und Multithreading
Brett: Programmierung

Nein, den Aufrufer muss ich nicht identifizieren.
Jedes Applikation erzeugt ja eine (oder mehrere) tuiEngines (siehe Objektgraph).
Und jedes tuiObject kennt auch seine tuiEngine. (die tuiEngine ist nichts anderes als das oberste (Wurzel) tuiObject von der Unterklasse tuiEngine im Baum).

--
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

 
Der_Wanderer   Nutzer

27.01.2010, 16:47 Uhr

[ - Direktlink - ]
Thema: RastPort und Multithreading
Brett: Programmierung

Also erstmal sollte der App Programmierer nicht davon ausgehen, dass er ein bestimmtes Fenster haben möchte. Was er möchte ist der RastPort, in den er zeichnen muss wenn er sein Custom View Widget füllen will. Der kann auch NULL sein, wenn z.B. der Custom View gar nicht sichtbar ist.
Ob das nun von einem Fenster kommt oder sonst woher sollte - und muss - ihm egal sein, sonst kann man z.b. auch kein (für ihn) transparentes Double Buffering machen. (d.h. die Funktion stellt ihm nicht den Fenster RastPort, sondern einen Off-screen-RastPort, nach dessen Release wird das ganze im Fenster sichtbar. <= wäre denkbar, ist momentan noch nicht geplant).

Also idealerweise würde es so aussehen:

code:
RastPort *rp = ntui_ObtainRastPort(tuiObject *myCustomViewTuiObject);
if (rp) {

  werkel();

  ntui_ReleaseRastPort(rp);
}


Leider weiss der arme RastPort ja nichts von NTUI. Und ich kann ihm das auch nicht beibringen, da AmigaOS Struct.

Also müsste ich es wohl so machen:

code:
tuiObject *myCustomView = ...
RastPort *rp = ntui_ObtainRastPort(myCustomView);
if (rp) {

  werkel();

  ntui_ReleaseRastPort(myCustomView, rp);
}


Ist ein Parameter mehr, wo man was verbocken kann. Aber evtl. noch akzeptabel. (ich versuche eben die API sehr effizient zu machen).

--
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



[ Dieser Beitrag wurde von Der_Wanderer am 27.01.2010 um 16:49 Uhr geändert. ]
 
Der_Wanderer   Nutzer

27.01.2010, 16:08 Uhr

[ - Direktlink - ]
Thema: RastPort und Multithreading
Brett: Programmierung

Aber um nochmal drauf zurückzukommen:

Die meisten Dinge werden per Messages oder eben im Toolkit Kontext erledigt. Das geht beim Zeichnen aber nicht wirklich, wenn eine Applikation etwas "eigenes" darstellen will. Da kommt man nicht drumherum, der Applikation einen RastPort zu überreichen, auf dem sie dann rum-malen darf.


--
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

 
Der_Wanderer   Nutzer

27.01.2010, 15:45 Uhr

[ - Direktlink - ]
Thema: RastPort und Multithreading
Brett: Programmierung

Sehr geehrter Herr Holger,

Wenn ich mir die Unbeschwertheit deiner Signatur so anschaue, würde ich mir selbst empfehlen von dir keinen Rat anzunehmen.
Die klugen Köpfe in der Amiga Szene sind aber leider sehr rar geworden, und ich schätze dich als einer der wenigen verbleibenden AmigaOS API Großmeister. Deshalb reiße ich mich jetzt ein wenig zusammen und werde nicht ausfallend.

Was stört dich an dem Objektgraphen von oben?

Andere Teile (z.B. der Applikations-übergreifende Bitmap Cache) sind bereits mit Semaphoren synchronisiert. Mine Frage ging um den RastPort, ob es da eben AmigaOS seitig Möglichkeiten gibt, da ein RastPort kein von mir erzeugtes Objekt ist dem ich so einfach eine Semaphore verpassen könnte. Und ich wollte auch das tuiWindow Objekt nicht gerne missbrauchen, denn ein RastPort muss auch nicht zwingend von einem Fenster kommen.

--
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



[ Dieser Beitrag wurde von Der_Wanderer am 27.01.2010 um 15:46 Uhr geändert. ]
 
Der_Wanderer   Nutzer

27.01.2010, 11:08 Uhr

[ - Direktlink - ]
Thema: RastPort und Multithreading
Brett: Programmierung

> Ein solches gleichzeitiges Werkeln sollte schon konzeptionell ausgeschlossen werden.
Entweder durch Semaphoren oder kein Multithreading. Wie sollte man das sonst bewerkstelligen? Die Applikation wird immer auf dem Fenster was tun wollen, z.B. bei Custom Views wie bei HD-Rec oder ArtEffekt.

--
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

 
Der_Wanderer   Nutzer

26.01.2010, 22:12 Uhr

[ - Direktlink - ]
Thema: RastPort und Multithreading
Brett: Programmierung

Alle Objekte sind tuiObjekte in NTUI, selsbt die Engine.
Und eben auch Fenster. Sie haben eine Größe, Position, Border und Kinder/Eltern tuiObjekte, eine Layout, EventHandle, Get/SetAttr, MinSize, Draw Methode wie alle anderen tuiObjekte auch.

Das AmigaOS Fenster ist nur dazu da, um es anzuzeigen und wird in einem Feld des tuiWindow Structs referenziert. Ein tuiWindow muss nicht sichtbar sein um zu existieren.


Bild: http://www.hd-rec.de/pics/tuiconcept.png

> Ich bin davon ausgegangen, dass die Anwendung das Toolkit anweist, ein Fenster zu schließen.
Das muss nicht sein. Das Toolkit kann Fenster auch auf eigeninitiative Schliessen, z.B. wenn der Screenmode Prefs sich ändert oder die Preferences von NTUI. Die Applikation muss davon nichts mitbekommen, aber wenn sie auf einem Fenster rumwerkelt, dann muss das Fenster/RastPort solange blockiert sein.

--
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



[ Dieser Beitrag wurde von Der_Wanderer am 26.01.2010 um 22:15 Uhr geändert. ]

[ Dieser Beitrag wurde von Der_Wanderer am 26.01.2010 um 22:19 Uhr geändert. ]

[ Dieser Beitrag wurde von Der_Wanderer am 26.01.2010 um 22:22 Uhr geändert. ]
 
Der_Wanderer   Nutzer

26.01.2010, 17:40 Uhr

[ - Direktlink - ]
Thema: RastPort und Multithreading
Brett: Programmierung

> Dann verpaß doch dem tuiObject einen Semaphore und laß dir bei
> ReleaseRastPort das tuiObject übergeben und nicht den RastPort.
Es kann aber auch zwei tuiObject geben, die sich einen RastPort teilen.
Ich müsste den Lock hochpropagieren bis zum tuiObject, das den RastPort hält.

Der Sinn des Toolkits ist (unter anderem), eben nicht das OS Gadgets Gemurkse zu nutzen. Ansonsten käme das GIRPort doch recht nahe an das, was ich suche.


--
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

 
Der_Wanderer   Nutzer

26.01.2010, 16:50 Uhr

[ - Direktlink - ]
Thema: RastPort und Multithreading
Brett: Programmierung

Zitat:
Original von Holger:
Zitat:
Original von Der_Wanderer:
Dazu müsste ich den RastPort des Fensters clonen und aktuell halten.

Was verstehst Du unter "aktuell halten"?
Wenn sich was im Fenster ändert, z.b. der Layer, die Bitmap (?) oder sonstwas. Eigentlich bei jedem Pointer den man dupliziert läuft man Gefahr, dass er ungültig wird.

Zitat:
Zitat:
Der Layer kann sich ja bei jedem Fenster Resizing ändern.
?
Der RastPort besitzt einen Zeiger auf den Layer und dieser Zeiger bleibt immer der gleiche.

Ist das so? OS4 hat manchmal NULL im Layer stehen, oder?
Und was passiert, wenn ich beim Zeichen die Clip Region verändere?

Zitat:
Zitat:
Den RastPort müsste sich die Applikation trotzdem noch holen/freigeben, damit ich z.B. nicht mittem im Zeichnen das Fenster unter des Füssen wegschliesse, z.b. wenn eine ScreenNotify Message kommt.
Ja, wenn Du die Fenster schließt und nicht die Anwendung, dann müssen Du und die Anwendung wohl miteinander reden. Da führt dann kein Weg vorbei.
Auch wenn die Applikation das Fenster schliesst, müssten wir miteinander kommunizieren.

Und im ganzen betrachtet, würde sich doch der Layer als Semaphore eigenen, oder nicht?
Allerdings ist das sehr heikel, falls man einen Intuition Aufruf machen muss. Deshalb wäre mir eine andere Lösung lieber.

Ich könnte noch dem Fenster eine Semaphore anhängen. Aber bessere wäre es an den RastPort, aber der ist kein "tuiObject" was ich einfach erweitern kann.




--
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



[ Dieser Beitrag wurde von Der_Wanderer am 26.01.2010 um 16:51 Uhr geändert. ]
 
Der_Wanderer   Nutzer

26.01.2010, 16:26 Uhr

[ - Direktlink - ]
Thema: RastPort und Multithreading
Brett: Programmierung

@Thomas, Holger

Diese beiden Antworten habe ich erwartet.

@Thomas:
Das geht nicht, weil nicht alle Widgets unter der Verwaltung des GUI Toolkits stehen. Z.b. Custom View Widgets werden vom Benutzer innerhalb des Applikations Kontextes gezeichnet.

Der Applikations Programmierer muss sich, damit das geordnet abläuft, den RastPort erst reservieren:

code:
RastPort *rp = ntui_ObtainRastPort(tuiObject);
if (rp) {

  ... tue hier etwas mit dem RastPort

  ntui_ReleaseRastPort(rp);
}


So, wie das auf anderen Betriebssystemen Gang und Gebe ist.

@Holger
Das kann man mit eigenen RastPorts tun, aber wie geht das bei einem Fenster?

Dazu müsste ich den RastPort des Fensters clonen und aktuell halten. Der Layer kann sich ja bei jedem Fenster Resizing ändern.
Ich sehe nicht, wie das vernünftig möglich sein sollte. Intuition hat eigene RastPorts für die Fenster Dekoration, aber Intuition kann das natürlich alles kontrollieren.

Den RastPort müsste sich die Applikation trotzdem noch holen/freigeben, damit ich z.B. nicht mittem im Zeichnen das Fenster unter des Füssen wegschliesse, z.b. wenn eine ScreenNotify Message kommt.

--
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

 
Der_Wanderer   Nutzer

26.01.2010, 14:40 Uhr

[ - Direktlink - ]
Thema: RastPort und Multithreading
Brett: Programmierung

Hallo!

Ich arbeite an einem GUI Toolkit, das mutlithreaded arbeitet, damit visuelles Feedback unabhängig von der eigentlichen Applikation möglich ist.
Da beide, der GUI Thread und der Applikations Thread auf den RastPort des gleichen Fensters zugreifen, muss ein synchronisations Mechanismus her, da es sonst logischerweise Chaos gibt.

Wie würdet ihr das machen?

Im Moment scheint mir LockLayer()/UnlockLayer() am geeignetsten, obwohl es mir nicht nur um den Layer geht, sondern auch um den RastPort Zustandspeicher, sprich A/B Pen, Fonts etc.
Da LockLayer wie eine Semaphore arbeitet, bietet sich das an, um den ganzen RastPort zu schützen.
Eine eigene Semaphore will ich nicht unbedingt mitführen, das würde die API um einen Parameter mehr aufblähen.

Allerdings kann ich mich noch dunkel daran erinnern, dass unter OS4 ein Fenster RastPort nicht zwingend einen Layer hat, sondern der entsprechende Eintrag in der RastPort Struktur NULL sein kann. In dem Fall kann man logischerweise auch nichts locken. Ist das tatsächlich so?


--
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



[ Dieser Beitrag wurde von Der_Wanderer am 26.01.2010 um 14:42 Uhr geändert. ]
 
Der_Wanderer   Nutzer

20.01.2010, 17:15 Uhr

[ - Direktlink - ]
Thema: Frage: Was kann AmigaOS&Kompatible was Windowas nicht kann ?
Brett: Get a Life

@Maja
Fenster Dimensionen >= Interessanter Bereich

--
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

 
Der_Wanderer   Nutzer

20.01.2010, 14:52 Uhr

[ - Direktlink - ]
Thema: Frage: Was kann AmigaOS&Kompatible was Windowas nicht kann ?
Brett: Get a Life

@Holger
Man kann sich nicht immer raussuchen, mit welcher Software man arbeitet. Und nicht jede Software ist optimal angepasst.
Generell kann man aber sagen, dieses "Vordergrund Feature" stört immer dann, wenn man Informationen irgendwo ablesen muss und woanders eintragen, und das ganze nicht in einem Rutsch per Clipboard machbar ist, z.B. weil man mehrer Dinge kopieren muss oder weil dazwischen eine Manipulation der Daten stattfindet, die kognitive Fähigkeiten benötigt, z.B. das umformulieren eines Textes etc.

--
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

 
Der_Wanderer   Nutzer

14.01.2010, 22:41 Uhr

[ - Direktlink - ]
Thema: Windows 7 cooler als der Mac...
Brett: Get a Life

@CarstenS

Ich habe auf meiner Maschine beides gehabt, Vista und Win7. Unter Win7 "fühlt" sich die Maschine etwa doppelt so schnell an. Viele Apps starten nun unglaublich flott. Ich weiss nicht wie die das gemacht haben. Booten ist viel schneller, und auch nachdem der Desktop da ist kann man quasi sofort arbeiten, während ich unter Vista immer noch warten musste.

Verwaltung von USB Geräten ist auch besser, wenn man z.B. einen Stick abdocken möchte wird er direkt mit Namen etc. gezeigt.

Und die neue Startleiste (ich meine eher die Taskleiste) ist deutlich besser da sie ein neues (für Windows neu) Konzept eingeführt haben, nicht nur größere und buntere Icons. Ähnlich wie beim Mac wird nicht mehr zwischen laufendem Program und Start Icon unterschieden. Das hilft enorm den Überblick zu behalten, und interessiert ja letztendlich auch nicht, ob die App schon läuft oder nicht.

--
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

 
Der_Wanderer   Nutzer

14.01.2010, 20:35 Uhr

[ - Direktlink - ]
Thema: Windows 7 cooler als der Mac...
Brett: Get a Life

Win7 hat eine bessere Start Leiste und ist viel flotter (weniger bloated) als Vista. Ich habe meinen Rechner upgegraded und bin sehr froh drüber.

--
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

 
Der_Wanderer   Nutzer

13.01.2010, 11:27 Uhr

[ - Direktlink - ]
Thema: Warum werden Midi Anwendungen so stiefmütterlich behandelt?
Brett: Amiga, AmigaOS 4

Also vielleicht sollte man erstmal klären was MIDI ist:

1. MIDI ist ein Protokoll zur Datenübertragung in Echtzeit, speziell auf Musik Noten/Events zugeschnitten. Audiodaten sind i.A. dabei nicht enthalten.

2. MIDI Files (.mid) sind Dateien, die einen "eingefrohrenen" Datenstrom enthalten der dem MIDI Protokol entspricht, mit Zeitstempeln dazwischen um die zeitlichen Ablauf festzuhalten.

3. MIDI Schnittstelle ist eine serielle Schnittstelle mit 31250 (<= ja) Baud, die über einen 5 poligen DIN Stecker verbunden wird. Heute benutzt man aber i.A. USB, da die Datenübertragung schneller ist und USB verbreiteter ist.

Zur Wiedergabe von .mid Dateien benötigt man einen Klangerzeuger, z.b. einen Synthesizer wie man ihn heute auf vielen Soundkarten findet.
Wobei primär nicht festgelegt ist, welches Instrument was zu spielen hat. Bei eigenen Kompositionen, die man als Audio veröffentlichen will, kann man das frei wählen. Das klingt dann natürlich Bockmist, wenn jemand anders das abspielen will und hat nicht genau die gleichen Instrumente.
Deshalb gibt es General MIDI (GM), das ist nichts anderes als eine Konvention, welches Instrument welches "MIDI Program" spielen soll, und dass MIDI Kanal 10 immer das Schlagzeug ist.
Dabei gibt es 128 Instrumente und 128 Drum Samples. Da diese alle erdenklichen MIDI Files abspielen können müssen, dürfen diese Sound nicht zu extravagant sein. Deshalb werden MIDI Files i.A. als charakterloses Gedudel empfunden, im vergleich zu MODs.
Muss aber nicht so sein. So gut wie alle professionellen Musikproduktionen werden mit Hilfe von MIDI erstellt. Von der Darstellung der Noten her ist es wesentlich mächtiger als MOD.

Auf dem Amiga:
Das einzige MIDI Treiber System ist CAMD.
Das ist eine Library womit Applikationen MIDI Daten an andere Applikationen schicken können. eine kann Z.b. ein Treiber sein, der das dann über USB oder die Serielle Schnittstelle "nach draussen" funkt. Logischerweise muss man da was angeschlossen haben was mit den Daten was anfangen kann.

Als Applikationen um MIDI Dateien zu erstellen gibt es jede Menge:
- Bars&Pipes
- HD-Rec
- Horny
- MusicX (?)
- diverse Tracker

MIDI wird zum Playback genutzt von:
- MIDI Player von den CAMD tools
- ScumVM
- DoomII etc. (in der PC Welt ist MIDI für Spiele lange Standard gewesen, so wie MOD auf dem Amiga)
- Timidity

Sowohl für MOS als auch für OS4 gibt es die CAMD library, allerdings als Re-implementation. Die original CAMD war vom Commodore und es ist kein Source Code verfügbar. Da die Serielle Schnittstelle des Classic als default Treiber integriert ist, läuft das nicht auf OS4 und MOS.

Es gibt aber nur den Emu10k Treiber für die Soundblaster Live!, und möglicherweise USB (Poseidon). Sonst gibt es keine Treiber soweit ich weiss.

Echtzeit Klangerzeuger für MIDI gibt es nur wenige:

- HD-Rec Plugins (Sweeper, Bernds Sampler, Pasis Organ, Beeper...)
- Horny hat einen built-in Sample Player
- CAMD Tools hat einen Sample Player, aber direkt via Paula (Classic only)

Man könnte als z.B. HD-Rec starten, Sweeper starten und eine GM Bank laden. Dann würde ScumVM über HD-Rec spielen (sofern ScrumVM die CAMD Cluster configurieren lässt).


--
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

 
Der_Wanderer   Nutzer

12.01.2010, 00:04 Uhr

[ - Direktlink - ]
Thema: Warum werden Midi Anwendungen so stiefmütterlich behandelt?
Brett: Amiga, AmigaOS 4

Da es keinen Buchstaben mehr nach z gibt, wird die nächste Version eben 1.0 sein. Aber hängt euch nicht an Zahlen auf!
Das ist nun mal die neueste Version die es gibt. Es fehlen noch ein paar DSP Effekte und Plugins, die ich noch für die OpenSource Veröffentlichung aufbereiten muss, dann nenne ich es 1.0.

Aber es kostet halt alles (frei-)Zeit und davon haben wir heute nicht mehr so viel wie früher als Studenten.

Auf dem Amiga gibt es vielleicht weltweit noch ca. 5 Leute die ein Program wie HD-Rec ernsthaft benutzen würden. Das ist kein Markt mehr. Selbst wenn jeder 1000 EUR dafür zahlen würde, könnte ich mich nicht mal einen Monat mehr Vollzeit darum kümmern. Das Leben ist hart und teuer ;-)

BTW, ist ScummVM eine MIDI Software?

Und HD-Rec ist eine 68k Entwicklung. Es gibt aber PPC native DSP Effekte.

Ich denke im Gegensatz zu anderer Software ist der Amiga noch gut bestückt mit Musik Software. Ich glaube es gibt kaum eine Platform mit deutlich mehr Musik Apps als Musiker ;-)
--
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

 
Der_Wanderer   Nutzer

11.01.2010, 19:01 Uhr

[ - Direktlink - ]
Thema: Frage: Was kann AmigaOS&Kompatible was Windowas nicht kann ?
Brett: Get a Life

> Eine ordentliche IDE bettet den Shell-Output ein.
Der Shelloutput muss ja nicht aus einer Quelle kommen, die das IDE kennt.

Was ich meine ist:

Es gibt viele Situationen, wo man in einer Anwendung etwas modifiziert und in einer anderen Anwendung Informationen dazu ablesen will.
I.A. verlangt das noch kognitive Verarbeitung und nicht nur eine textuelle Kopie, wie sie ein Clipboard leisten kann.

Natürlich kann man das dann alles nebeneinander Rücken, aber das ist wegen der Fenster Dekoration sehr viel schwieriger und nerviger als auf dem Amiga, wo oft nur ein Teil des Fensters ausreicht um sichtbar zu sein.

Und äh - nicht jedes IDE ist ordentlich, wenn es überhaupt ein IDE gibt. Deshalb sollte es das OS nicht erschweren, trotzdem was damit zu machen.

--
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



[ Dieser Beitrag wurde von Der_Wanderer am 11.01.2010 um 19:03 Uhr geändert. ]

[ Dieser Beitrag wurde von Der_Wanderer am 11.01.2010 um 19:05 Uhr geändert. ]
 
Der_Wanderer   Nutzer

11.01.2010, 18:11 Uhr

[ - Direktlink - ]
Thema: Frage: Was kann AmigaOS&Kompatible was Windowas nicht kann ?
Brett: Get a Life

> Stimmt, aber die einfache Lösung lautet, dein Monitor und / oder deine Auflösung ist zu klein.
26" mit 1920x1200. Sollte man meinen das reicht... Es ist ja aber nicht der Platz, sondern das verhalten der Fenster. Platz habe ich genug.

Das Libs Verzeichnis ist doch übersichtlich. Da liegen einfach nur Libs drin, die tun niemandem weh. Bei fast allen weis ich was sie machen.
--
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

 
 
Erste << 8 9 10 11 12 -13- 14 15 16 17 18 >> Letzte Ergebnisse der Suche: 1229 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

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