ENGLISH VERSION |
|
Links | | | Forum | | | Kommentare | | | News melden |
Chat | | | Umfragen | | | Newsticker | | | Archiv |
amiga-news.de Forum > Suche | [ - Suche - Neue Beiträge - Registrieren - Login - ] |
|
||||||
Der_Wanderer
Nutzer
29.04.2013, 13:31 Uhr [ - Direktlink - ] |
Thema: AROS, doch noch so instabil ?!
Brett: AROS und Amiga-Emulatoren @OlafSch: Interessant. Das würde bedeuten, dass die Blitz Anbindung korrupt ist. Kann ich aber leicht überprüfen, stay tuned. -- -- Author of NTUI, AIDE, A/A++, HD-Rec, MacroWave, Sweeper, Samplemanager, ArTKanoid, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ImageConverter, ScreenCam, AB3 Includes und viele mehr... Homepage: http://www.hd-rec.de |
|||||
Der_Wanderer
Nutzer
29.04.2013, 13:28 Uhr [ - Direktlink - ] |
Thema: AROS, doch noch so instabil ?!
Brett: AROS und Amiga-Emulatoren @wawa Die einfachste Lösung für mich wäre eine eigene Library zu bauen. Nur dann gibt es vermutlich niemand dem das wichtig genug ist und das portiert für andere Plattformen. Wie man es dreht und wendet, die einzige gescheite Lösung wäre, wenn es eine Instanz gäbe die sowas kontrolliert und eine sog. "stable API" definiert, die man gefahrlos benutzen darf weil dafür gesorgt ist, dass es auf allen Plattformen in guter Qualität zur Verfügung steht. Nur gibt es leider keine solche Instanz, deshalb der Wildwuchs. Ich würde sogar behaupten, auf dauer wird dadurch das OS immer weiter degenerieren bis es unbenutzbar wird. Der einzige Grund warum das noch nicht passiert ist, ist der Mangel an Entwicklern und die dadurch langsame Entwicklung. -- -- Author of NTUI, AIDE, A/A++, HD-Rec, MacroWave, Sweeper, Samplemanager, ArTKanoid, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ImageConverter, ScreenCam, AB3 Includes und viele mehr... Homepage: http://www.hd-rec.de [ Dieser Beitrag wurde von Der_Wanderer am 29.04.2013 um 13:29 Uhr geändert. ] |
|||||
Der_Wanderer
Nutzer
29.04.2013, 13:20 Uhr [ - Direktlink - ] |
Thema: AROS, doch noch so instabil ?!
Brett: AROS und Amiga-Emulatoren Leute, es liegt doch nicht an dem zlib Code. Der zlib Code funktioniert einwandfrei. Es liegt an der Umsetzung des ganzen als Shared Library. Und da gibt es in etwa so viele Libraries (die untereinander inkompatibel sind) wie es Entwickler gibt, die das gebraucht haben. Und in Amiblitz habe ich die zlib.library von Achim Stegemann benutzt. (http://aminet.net/package/util/libs/zlib-library), um nicht noch einen Port anzufangen. Das Amiblitz IDE/Compiler braucht die nicht, aber Programme die man erstellt, welche PNGs laden/speichern wollen. Diese zlib ist ein WOS Mixed Binary, und scheint auf AROS68K zu crashen. Ein Beispielprogramm ist schnell gestrickt: code:*zlibbase.Library = OpenLibrary_("zlib.library",0) ; <= Peng! If *zlibbase Then CloseLibrary_(*zlibbase) End Geht auch genauso in C oder in [Sprache deiner Wahl]. -- -- Author of NTUI, AIDE, A/A++, HD-Rec, MacroWave, Sweeper, Samplemanager, ArTKanoid, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ImageConverter, ScreenCam, AB3 Includes und viele mehr... Homepage: http://www.hd-rec.de [ Dieser Beitrag wurde von Der_Wanderer am 29.04.2013 um 13:22 Uhr geändert. ] |
|||||
Der_Wanderer
Nutzer
28.04.2013, 18:35 Uhr [ - Direktlink - ] |
Thema: AROS, doch noch so instabil ?!
Brett: AROS und Amiga-Emulatoren Woher soll ich wissen warum die zlib crashed? Ich habe weder AROS noch zlib noch die zlib Shared Library geschrieben. Ich kann nur beobachten, dass es beim öffnen sofort abstürzt. Es war nur meine Vermutung, dass es am PPC Code liegen könnte, der abstruser Weise mit 68K zusammengepappt wurde, wo es doch sicherlich einfacher gewesen wäre zwei Libs zu bauen. -- -- Author of NTUI, AIDE, A/A++, HD-Rec, MacroWave, Sweeper, Samplemanager, ArTKanoid, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ImageConverter, ScreenCam, AB3 Includes und viele mehr... Homepage: http://www.hd-rec.de |
|||||
Der_Wanderer
Nutzer
27.04.2013, 21:58 Uhr [ - Direktlink - ] |
Thema: AROS, doch noch so instabil ?!
Brett: AROS und Amiga-Emulatoren JA, eigentlich wäre der Ball bei AROS das zu fixen, da es kein Bug in der zlib ist sondern mangelnde Unterstützung für dieses Binary format. Hätte alle mehr davon wenn das auf AROS Seite gefixt würde. -- -- Author of NTUI, AIDE, A/A++, HD-Rec, MacroWave, Sweeper, Samplemanager, ArTKanoid, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ImageConverter, ScreenCam, AB3 Includes und viele mehr... Homepage: http://www.hd-rec.de |
|||||
Der_Wanderer
Nutzer
26.04.2013, 14:23 Uhr [ - Direktlink - ] |
Thema: AROS, doch noch so instabil ?!
Brett: AROS und Amiga-Emulatoren @Holger: Der Code ist nicht groß, ca. 50kB. Es geht aber darum, das sich Amiblitz nutze und dort kann ich nur Shared Libaries einbinden, bzw. so kann das Programm auch einen Speedup erfahren ohne dass es nativ ist. Evtl. sollte ich lieber alles in eine Shared Library zusammenkompilieren, und die dann "amiblitz_support.library" nennen oder so. Dann gibt's keine Konflikte. -- -- Author of NTUI, AIDE, A/A++, HD-Rec, MacroWave, Sweeper, Samplemanager, ArTKanoid, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ImageConverter, ScreenCam, AB3 Includes und viele mehr... Homepage: http://www.hd-rec.de |
|||||
Der_Wanderer
Nutzer
26.04.2013, 10:01 Uhr [ - Direktlink - ] |
Thema: AROS, doch noch so instabil ?!
Brett: AROS und Amiga-Emulatoren @Floppy: Die AROS zlib/i386 ist nur eine Linker lib. Das Problem bei Amiga allgemein ist, lasst es mich mal so beschreiben: * zlib downloaden (http://zlib.net/) und per GCC kompilieren => 5 min * zlib Wrapper Code für Amiga Shared library schreiben => 5 h * merken dass jedes System seine eigenen libs hat die inkompatibel sind, und gute Lösung dafür finden => 5 d bzw. never ending story Unter Windows, Linux oder MacOS bin ich nach Punkt eins quasi fertig, da ich im IDE nur anhaken muss dass ich eine .dll, .so etc. will. Bzw. z.B. bei iOS oder Android muss ich mich überhaupt nicht drum kümmern da die zlib schon OS-seitig zur Verfügung steht. Auf dem Amiga bin ich zum Großteil mit hausgemachten Problemen beschäftigt, statt mit der eigentlichen Entwicklung. Deshalb ist die Produktivität so gering auf dem Amiga, bei dem ohnehin die Resourcen so knapp sind. Sorry für mein Ranting, aber die Sache mit der zlib ist schon frustrierend. -- -- Author of 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
25.04.2013, 20:58 Uhr [ - Direktlink - ] |
Thema: AROS, doch noch so instabil ?!
Brett: AROS und Amiga-Emulatoren Das Problem ist dass die zlib.library unter AROS 68K crashed, ich vermute mal stark weil es ein warp-up PPC mixed binary ist. Daraufhin habe ich die Amiblitz Runtime auf z.library umgestellt. Nur dass ich jetzt erfahren musste, dass es auch hier Probleme gibt weil die MOS Version nicht kompatibel ist. Drum bin ich jetzt am überlegen ob ich nicht die zlib.library re-compiliere, ohne PPC Support. Das wäre eigentlich die beste Lösung. Nur ist der Source mir nicht ganz verständlich, vermutlich wegen der Verrenkungen der Mix binary, d.h. ich werde es nicht re-compilieren sondern nachbauen. -- -- Author of 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
25.04.2013, 10:57 Uhr [ - Direktlink - ] |
Thema: AROS, doch noch so instabil ?!
Brett: AROS und Amiga-Emulatoren Also ich habe das mal versucht mit WinUAE + AROS 68K Distro von Olaf. Ich habe es zum laufen bekommen, aber arbeiten kann man damit noch nicht. Es gibt zu viele Glitches und Crashes. Ich würde gerne zu einem stabilieren AROS beitragen, aber weniger von Developer Seite als von Tester Seite. Gibt es irgendwo einen Bugtracker o.ä. wo man solche Dinge eintragen kann? -- -- Author of 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
24.02.2013, 19:52 Uhr [ - Direktlink - ] |
Thema: Spiele mit Editor gesucht
Brett: Programmierung Toadies: Bild: http://www.amiforce.de/screenshots/Toadies_Rocks1.png http://toadies.hd-rec.de -- -- Author of 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 24.02.2013 um 20:28 Uhr geändert. ] |
|||||
Der_Wanderer
Nutzer
08.02.2013, 13:27 Uhr [ - Direktlink - ] |
Thema: AmigaOS3.x unter Linux
Brett: AROS und Amiga-Emulatoren "virtual mouse driver" fixt zumindest den Mouse Pointer. Allerdings geht dann z.B. Solid Window Moving via MCP nicht mehr und ein paar andere kleinere Glitches. Alles in allem ist es keine wirklich empfehlenswerte Lösung, um einen guten UAE auf Linux zu haben. Ich werde mal noch WINE+WinUAE und FS-USE ausprobieren. Viele Dank für eure Hilfestellung. -- -- Author of 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
07.02.2013, 17:05 Uhr [ - Direktlink - ] |
Thema: AmigaOS3.x unter Linux
Brett: AROS und Amiga-Emulatoren Hallo! Ich möchte UAE+AmigaOS3.x unter Linux (Ubuntu) laufen lassen. Ich habe UAE ausprobiert (0.8.x), damit bin ich auch recht weit gekommen aber es scheint keinen JIT zu haben. Meine Anwendung benötigt JIT, FPU, RTG und AHI 16bit. E-UAE crasht sofort. Also habe ich Virtual Box installiert, darauf eine Windows7 Install geplanscht, und dort WinUAE installiert, so wie ich es von meiner Windoze Maschine her kenne. Dort habe ich 1:1 meine AmigaOS3.x Install rüberkopiert. Das Problem was ich nun habe ist, dass die Maus wie wild rumspringt. Ich habe ausprobiert in den I/O Port Settings: 1. Windows Mouse - springt wie wild auf der Y-Achse) 2. PS/2 Mouse - springt wie wild in alle Richtungen, lässt sich per AmgiaOS Settings etwas zähmen, ist aber viel zu ungenau für produktives Arbeiten. 3. HID-Conform Mouse - bliebt tot Dabei scheinen die Settings in "Input" keinen Einfluss zu haben, lediglich "Game Ports". Weis jemand was ich falsch mache? EDIT: I/O Ports => Game Ports, sorry -- -- Author of 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 07.02.2013 um 17:58 Uhr geändert. ] |
|||||
Der_Wanderer
Nutzer
07.10.2012, 18:39 Uhr [ - Direktlink - ] |
Thema: Menschliche SPAM-"Bots"?
Brett: Get a Life Das Problem haben wir bei Amiforce auch schon gehabt. Ich denke dass das alles Bots sind. Nur eben etwas weiterentwickelt, aber auch keine Magie. Man muss nur Sprüche raussuchen, die relativ universal passen wie "Das finde ich toll was du da machst, kannst du etwas mehr dazu schreiben" oder sowas, und das nicht ganz so aggressiv angehen, damit die Links länger überleben (hat beim Amiforce Admin auch geklappt, gelle ;-). Scheinbar setzt man bei SPAM auch mittlerweile mehr auf Qualität als Quantität. Evtl. findet sogar Keyword Spotting statt ähnlich wie Siri, um nicht so leicht überführt zu werden. Nur bei Amiga Foren ist das halt schwierig. Es gibt keinen User der sich einfach mal so anmeldet und irgendwas interessant findet. Normalerweise geht es im ersten Post schon zur Sache mit amigaspezifischen Begriffen. Ich könnte mir durchaus aber auch vorstellen, dass die Bots teilweise hyprid arbeiten, also z.B. bei der Anmeldung oder wenn eine nicht-trivale Frage beantwortet werden soll. Ich glaube man darf sich das auch nicht so vorstellen, dass der Spammer die Foren per Webbrowser ansurft, sondern ein Tool hat wo er fließbandmäßig die Posts abarbeiten kann wie in einem Call-Center. -- -- Author of 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 07.10.2012 um 18:42 Uhr geändert. ] |
|||||
Der_Wanderer
Nutzer
15.06.2012, 13:26 Uhr [ - Direktlink - ] |
Thema: Eure Anforderungen an eine IDE für AmigaOS?
Brett: Programmierung @Reth Du musst ja keinen Code generieren und linken, sondern nur das aktuelle Modul kompilieren. Das geht schnell. Ausserdem soll das natürlich asynchron laufen, mit niedriger Pri sodass der User im Editor nicht gestört wird. Ob ein Fehler nach 1 sek oder 10 sek angezeigt wird ist nicht so wichtig. Hauptsache man spart sich das manuelle anstoßen des Kompiler Vorgangs und das springen zu den Fehlern, was in der Regel mehrere Klicks und ein paar Sekunden Wartezeit kostet, oft nur um zu merken dass man ein ";" vergessen hat oder solche Kleinigkeiten. Wenn das automatisch im Hintergrund passiert spart man sich auf dauer massig Geklicke und Wartezeiten. Man kann auch Gedanklich 100% im Editor bleiben, und muss keinen "Context Switch" im Hirn durchführen, bei komplexen Aufgaben ist das nicht zu unterschätzen. Und weil ein Classic dafür zu langsam sein könnte ist ja wirklich kein Argument dagegen. Per Prefs kann man das ja abschaltbar machen. -- -- Author of 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.06.2012, 20:37 Uhr [ - Direktlink - ] |
Thema: Eure Anforderungen an eine IDE für AmigaOS?
Brett: Programmierung Eines der wichtigsten Features finde ich Auto-Kompilierung und Anzeige von Warnings/Errors im Source. D.h. das IDE kompliliert nach jeder signifikanten Änderung des Quelltextes automatisch neu und highlighted die Fehler, so wie eine Rechtschreibprüfung. Das spart enorm viel Zeit. Gleich nebenauf sind natürlich ein Source-Level Debugger mit Single Step Funktion und die Möglichkeit, die Inhalte von Variablen zu durchstöbern. Code Completion, vor allem bei Structs ist auch wichtig. -- -- Author of 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
18.03.2012, 16:35 Uhr [ - Direktlink - ] |
Thema: Bounding Box eines Layers
Brett: Programmierung * kopfklatsch * Das RefreshWindowFrame() war noch drin. Wenn ich das rausnehme, funktioniert mein Refresh auch innterhalb des Begin/EndRefreshes. Danke für den Hinweis. Allerdings kam di eErnüchterung ziemlich schnell: Auch hier bin ich beim Resizen nicht davor geschützt, den Rand zu übermalen. Desweiteren bekomme ich Aussetzer beim Refresh, vermutlich muss ich noch den ScreenLayerInfo locken. EDIT: soo, mit ScreenLayerInfo Lock funktioniert es nun wie es soll. Puh! Keine triviale Sache, das mit dem Refresh... -- -- Author of 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 18.03.2012 um 16:39 Uhr geändert. ] |
|||||
Der_Wanderer
Nutzer
17.03.2012, 22:58 Uhr [ - Direktlink - ] |
Thema: Bounding Box eines Layers
Brett: Programmierung Das war nur ein versehen in dem Pseudo Code fürs Posting. Das merke ich mir natürlich in einer extra Variablen. -- -- Author of 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
17.03.2012, 17:13 Uhr [ - Direktlink - ] |
Thema: Bounding Box eines Layers
Brett: Programmierung @Georg Ja so ähnlich macht das NTUI. Jedes Widget, das zum Zeichnen eine ClipRegion installieren möchte, setzt diese nicht direkt sondern AND-verknüpft sie auf die aktuelle, und nachdem alles gezeichnet ist stellt die die wieder her. Das ist notwendig, weil ein Widget ja nicht unbedingt komplett sichbar ist, z.B. innerhalb eines ScrollViews. Im Refresh Fall mache ich eine Kopie der Damage Region innerhalb des Begin/EndRefreshs. Dann rufe ich EndRefresh auf, installiere die Kopie und das normale Zeichnen kann beginnen. Ich habe das jetzt nochmal versucht mit code:... if (win->Flags&WFLG_WINDOWREFRESH) { EndRefresh(win, FALSE); } oldRegion = InstallClipRegion(newRegion); if (win->Flags&WFLG_WINDOWREFRESH) { BeginRefresh(win); } ... // Draw widget // ... // restore oldRegion and dispose newRegion , wenn WFLG_WINDOWREFRESH gesetzt ist. Das scheint aber nicht das Problem gewesen zu sein, weshalb mein Code freezed wenn ich innerhalb Begin/EndRefresh neuzeichne. Ich habe übrigends festgestellt, dass der erste Refresh durchläuft, und es freezed in zweiten Aufruf von BeginRefresh, also wenn die zweite IDCMP_WINDOWREFRESH message kommt. Mein Refresh funktioniert fast Ok auch ausserhalb Begin/EndRefresh, ich könnte also zufrieden sein. Allerdings nur fast, bei wildem Resizen des Fensters übermale ich beim Verkleinern des Fensters den Fensterrahmen mit einer veralteten, zu grossen Position und Intuition malt danach den Fensterrahmen nicht mehr neu. Ich musste das so fixen, dass ich den Rahmen manuell neuzeichne, was für meinen Geschmack aber 1x Neuzeichnen zu viel ist. Ich erhoffe mir davon, innerhalb des Begin/EndRefreshs zu malen, dass ich mir das dann sparen kann und optimales Refresh erreicht habe. -- -- Author of 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 17.03.2012 um 17:18 Uhr geändert. ] [ Dieser Beitrag wurde von Der_Wanderer am 17.03.2012 um 17:20 Uhr geändert. ] [ Dieser Beitrag wurde von Der_Wanderer am 17.03.2012 um 17:20 Uhr geändert. ] |
|||||
Der_Wanderer
Nutzer
17.03.2012, 10:30 Uhr [ - Direktlink - ] |
Thema: Bounding Box eines Layers
Brett: Programmierung Ja, so ähnlich ist das Beispiel im RKM auch aufgebaut. Das ist nur etwas blöd, weil ich NTUI ziemlich oft ClipRegions brauche, und der Zeichenvorgang müsste dann immer wissen, ob er sich innerhalb Begin/EndRefresh befindet oder nicht. Allerdings könnte ich das wie im Code oben lösen, denn die einzelnen Widgets machen natürlich nicht selbst die ClipRegion sondern rufen eine NTUI Funktion dafür auf. Wobei man den Parameter "refresh" sich sparen könnte, denn das Window hat das "WFLG_REFRESHWINDOW" gesetzt. -- -- Author of 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
16.03.2012, 21:32 Uhr [ - Direktlink - ] |
Thema: Bounding Box eines Layers
Brett: Programmierung @Holger: Ok, ich habe den Link gelesen und verifiziert. Bei mir unser OS3+AfA ist auch die ClipRegion tatsächlich Null. Wenn ich das recht verstehe, Clipped aber AmigaOS trotzdem alle Zeichenaufrufe innerhalb Begin/End Refresh. Ich meine, was wäre sonst der sinn der ganzen, bzw. der einzige Sinn wäre die Garbadge Collection der DamageList. Was ich jetzt auch nicht verstehe ist, warum es sich aufhängt wenn ich innerhalb Begin/EndRefresh neuzeichne. Scheinbar mache ich da irgendwas, was AmigaOS nicht passt. Ich dachte es wäre die Manipulation der ClipRegion. -- -- Author of 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
16.03.2012, 17:26 Uhr [ - Direktlink - ] |
Thema: Bounding Box eines Layers
Brett: Programmierung Zitat:Das schrieb ja Reth. Zitat:Wenn ich alles richtig verstehe, ist die Bounding Box der Damage Region eine Über-Fläche der Bounding Box innerhalb von Begin/EndRefresh. Insofern kann ich nichts verpassen, höchstens etwas zu viel zeichnen.Zitat:Äh, ja. Wobei Du das „auch“ streichen kannst. Die Bounding Box der Damage-Region ist nicht die Bounding Box der Clip-Region (siehe unten). Zitat:Also InstallClipRegion gibt die alte Region zurück. Die kann man dann später wieder herstellen, und danach die eigene freigeben.Zitat:Das ist nicht das Problem. Die Frage ist vielmehr: wo kommt die alte Clip-Region überhaupt her? Zitat:Jain. Zumindest will ich es mir nicht verbauen. -- -- Author of 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
16.03.2012, 13:43 Uhr [ - Direktlink - ] |
Thema: Bounding Box eines Layers
Brett: Programmierung @Reth In deinem Fall kannst du natürlich über die selbe Funktion malen, RedrawMyPlayfield(RastPort,x1,y1,x2,y2), rufst die aber auf Eigeninitiative auf. Mit den InutiMessages hat das nichts zu tun, da ja nicht Intuition den Bereich "damaged", sondern du in deinem Programmablauf selbst entscheidest dass dieser Bereich neu gezeichnet werden muss. Wenn neu-malen schnell genug ist, hast du ja sowieso überhaupt kein Problem. Theoretisch kannst du dann auch NOCAREREFRESH nutzen, dein Fenster ist ja dann maximal für einen Frame "damaged". @Holger Danke. Ich wollte mir nur deinen Segen dazu abholen. Wobei im Falle eines BeginRefresh/EndRefreh kann ich mir die Bounding Box auch so besorgen, oder? code:BeginRefresh_ *oswin clip.tuiRectleft = *oswinWLayerDamageListboundsMinX clip.tuiRecttop = *oswinWLayerDamageListboundsMinY clip.tuiRectright = *oswinWLayerDamageListboundsMaxX clip.tuiRectbottom = *oswinWLayerDamageListboundsMaxY EndRefresh_ *oswin,1 _ntui_Redraw{*obj,clip} Und da taucht eine weitere Frage auf: Wenn ich innerhalb des Refreshs neu zeichne, freezed das System. Deshalb steht _ntui_Redraw{} nach dem EndRefresh. Ich denke mal das liegt daran, dass ich in _ntui_Redraw{} selbst die ClipRegion manipuliere. Ich stelle zwar fein säuberlich sicher, dass beim Verlassen von _ntui_Redraw{} die alte ClipRegion wiederhergestellt ist, aber vermutlich darf ich erst gar keine neue setzen weil die Layer (oder LayerInfo) gelockt sind? Da stellt sich mir die Frage: Wann darf ich InstallClipRegion() NICHT aufrufen? Wenn der Layer oder die LayerInfo gelockt ist? Desweiteren habe ich eine Funktion in NTUI die es dem User erlaubt den RastPort eines bestimmten GUI Objectes zu holen. Dazu gibt es code:Der Grund warum ich Obtain und Release mache ist, dass der User garantiert bekommt, dass ihm der RastPort in der Zwischenzeit nicht weggenommen wird und ihm auch niemand anderes (z.B. NTUI) reinmalt.ntui_ObtainRastPort{*obj} ... ntui_ReleaseRastPort{*obj} NTUI selbst nutzt auch diese beiden Funktionen wenn es neu zeichnen will. Ist es sinnvoll auch ein LockLayer zu machen um zu verhindern dass innherhalb dieser Zeit intuition das Fenster nicht resized oder den Layer ändert? Welchen Layer müsste ich dazu Locken? in einem Beispiel habe ich gesehen, der Screen LayerInfo wird gelockt. -- -- Author of 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 16.03.2012 um 13:47 Uhr geändert. ] |
|||||
Der_Wanderer
Nutzer
15.03.2012, 21:19 Uhr [ - Direktlink - ] |
Thema: Bounding Box eines Layers
Brett: Programmierung Um das Clipping musst du dich ja nicht aktiv kümmern. Innerhalb von BeginRefresh und EndRefresh wird die Clipregion so gesetzt, dass nur die getrashten Bereiche neu gemalt werden. Das ist auch ok so, solange eben die Hauptlast auf den Zeichenfunktionen liegt. Wenn deine GUI aber etwas recht Komplexes darstellt und man viel Rechnen muss und viele einzlene Grafikoperationen hat, dann ist es doch sehr aufwendig. z.B. bei dem Arranger Fesnter in HD-Rec. Wenn da nur ein Ecke des Fensters refreshed wird muss ich nicht deshalb alle Waveformen neu malen, da die Zeichenoperationen sowieso ins Nirvana gehen. Als Optimierung lese ich mir dann die Clip Bounds aus, und male nur Elemente neu, die mit der Bounding Box überlappen. Alle ausserhalb kann ich überspringen. z.B. hier: Wenn ich hier eines der Vordergrund Fenster bewege, muss ich oft nur ein oder zwei der "Elemente" neu zeichnen, aber nicht alle 100 mit all ihren kleinen Details. Bild: http://hd-rec.de/HD-Rec/pics/screenshots/hdrec_sweeper.png -- -- Author of 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 15.03.2012 um 21:20 Uhr geändert. ] |
|||||
Der_Wanderer
Nutzer
15.03.2012, 09:44 Uhr [ - Direktlink - ] |
Thema: Bounding Box eines Layers
Brett: Programmierung Meine Befürchtung ist nur, dass evtl. unter neueren AmigaOS Varianten die Strukturen nicht aufgebaut werden, wenn z.B. die ClipRegion eine Maske ist und keine Ansammlung von Rechtecken. Wenn ich mir das oben gepostete anschaue, dann ist das aber auch recht harmlos, stimmt. In TUI hatte ich das etwas komplizierter, wo ich tatsächlich durch alle Rectangles durchgehe und die minimale Box selbst berechne. Aber hier lese ich eigentlich nur die "bounds" Werte aus, und die sollten eigentlich immer gesetzt werden können. -- -- Author of 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.03.2012, 16:02 Uhr [ - Direktlink - ] |
Thema: Bounding Box eines Layers
Brett: Programmierung Gibt es einen legalen Weg, um an die Bounding Box eines Layer zu kommen, vielmehr der ClipRegion die installiert ist? Mit Bounding Box ist das kleinste Rechteck gemeint, das alle bemalbaren Bereiche einer ClipRegion enthält. Warum brauche ich das? Normalerweise soll man bei einem Refresh einfach den Damage Bereich setzen (BeginRefresh) und alles malen. Das ist bei einfachen Oberflächen auch i.O. so, da die Hauptlast auf dem malen und nicht auf der Logik dahinter liegt. Wenn wir jetzt aber etwas sehr komplexes haben, dann ist das nicht mehr egal. Dann möchte ich nicht Megabyte Daten durchackern müssen um eine kleines Rechteck neu zu malen. d.h. wenn die Zeichenfunktion den Bereich aktiv kennt, ist sie sehr viel schneller. Bisher mache ich das so: code:;/////////////////////////////////////////////////////////////////////////////// ;/ / ;/ Syntax: !image_GetClipBounds{*rp.RastPort,minx.l,miny.l,maxx.l,maxy.l} / ;/ / ;/ Description: / ;/ Get the outer clip bounds of a RastPort with a layer attached, relative t:: / ;/ o the underlying bitmap. / ;/ / ;/ Inputs: / ;/ - *rp.RastPort : RastPort to get the clip bounds from / ;/ - minx.l : x of top left edge / ;/ - miny.l : y of top left edge / ;/ - maxx.l : x of bottom right edge / ;/ - maxy.l : y of bottom right edge / ;/ / ;/////////////////////////////////////////////////////////////////////////////// Macro image_GetClipBounds ;{*rp.RastPort,minx.l,miny.l,maxx.l,maxy.l} If *rpLayer If *rpLayerClipRegion ; get the bbox from clipregion *cliprec.Rectangle = *rpLayerClipRegionbounds minx = *cliprecMinX miny = *cliprecMinY maxx = *cliprecMaxX maxy = *cliprecMaxY Else ; no clipregion, get the bbox from layer bounds *cliprec = *rpLayerbounds minx = 0 miny = 0 maxx = *cliprecMaxX - *cliprecMinX maxy = *cliprecMaxY - *cliprecMinY End If Else ; no layer? minx = 0 miny = 0 If *rpBitMap ; ask the bitmap maxx = GetBitMapAttr_(*rpBitMap,#BMA_WIDTH) maxy = GetBitMapAttr_(*rpBitMap,#BMA_HEIGHT) Else maxx = 0 maxy = 0 End If End If End Macro -- -- Author of 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 14.03.2012 um 16:05 Uhr geändert. ] |
|||||
Der_Wanderer
Nutzer
06.03.2012, 21:34 Uhr [ - Direktlink - ] |
Thema: HD-REC
Brett: Amiga, AmigaOS 4 @cgutjahr: z.library != zlib.library http://aminet.net/package/util/libs/zlib-library Die mpega, ptplay sind optional. camd (für MIDI), zlib (für AISS) werden gebraucht. wizard.library wird zwar erfragt aber nicht gebraucht. -- -- Author of 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 06.03.2012 um 21:34 Uhr geändert. ] |
|||||
Der_Wanderer
Nutzer
13.02.2012, 10:08 Uhr [ - Direktlink - ] |
Thema: HD-REC
Brett: Amiga, AmigaOS 4 Meinst du sowas: code:--e|-------------0---1-0------------------------------------------ h|------1---3-----------3---0--------0--1---------------0------- G|---2--2------0--------0------0---2----2---2--2---1-2------1--- D|-----------------------------0-------------------------------2 A|------0------3------------------------0------0---------------- E|----------------------3------3------------------------0------- -- Author of 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.02.2012, 11:08 Uhr [ - Direktlink - ] |
Thema: HD-REC
Brett: Amiga, AmigaOS 4 Du kannst auch AHI ausschalten, oder einen Code vergeben, allerdings sollte der dezimal sein oder bei hex ein "$" vorne dran. 0 ist der default AHI modus. Du kannst aber AHI ausschalten, dann solltest du in den HD-Rec Prefs den Modus bequem auswählen können. !! Allerdings ist das nicht das Problem was du hast. !! Egal welcher AHI Modus, wenn es der gleiche Treiber ist, wird es nicht funktionieren. Du solltest das Recording (rec_wanted=0) ausstellen. Dann gibt es keinen Memtrash mehr und keine Crashs deshalb. ahi_on=1 ahi_mode=0 rec_wanted=0 Der Crash beim Exit ist vermutlich eine Folge von Memtrash wegen den 8000 vs. 2000. Das solltest du dem Author des Treibers melden. Um welchen Treiber handelt es sich denn nun, oder das der emu10k von Martin oder was anderes? Wenn CAMD nicht geht, hast du vermutlich nicht die richtige camd.library. Die original von Commodore funktioniert unter MOS nicht. Es gibt diverse Replacement Libs für MOS, von denen allerdings nur eine funktioniert, der Rest ist Müll. Versuche mal die CAMD library im Contributions Verzeichnis für MOS. Wenn die nicht geht, sollte ich sie aus dem Archive entfernen. Ich kann das leider nicht testen. -- -- Author of 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 12.02.2012 um 11:18 Uhr geändert. ] |
|||||
Der_Wanderer
Nutzer
11.02.2012, 21:31 Uhr [ - Direktlink - ] |
Thema: HD-REC
Brett: Amiga, AmigaOS 4 Ist das der Emu10K Treiber? Der sollte eigentlich funktionieren. Auf jeden Fall sollte es funktionieren, wenn man das Recording abstellt in den HD-Rec Prefs. (wenn das nicht geht, kann man die Config editieren und "ahi_on = 0" stellen. Wo genau stürzt das ganze denn ab? Wenn die oben besagte Meldung kommt, dann wurde AHI bereits initialisiert. Der Requester kommt, wenn die RecFunc nicht den Wert übergeben bekommt, mit dem sie eingerichtet wurde. Der Requester hat historische Gründe weil genau der Fehler auch früher im WinUAE AHI Treiber war. Die 8000 vs. 2000 in dem Requester sehen sehr verdächtig aus, weil 2000x4 bytes = 8000 sind, d.h. Bytelänge wurde mit Samplelänger verwechselt. HD-Rec macht das bestimmt nicht falsch, sonst würde man auf allen anderen Systemen auch Fehlermeldungen bekommen. -- -- Author of 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.02.2012, 20:09 Uhr [ - Direktlink - ] |
Thema: HD-REC
Brett: Amiga, AmigaOS 4 Der DOS Requster hat übrigends auch einen "Abbrechen" Button. Den sollte man drücken, wenn man kein AISS installiert hat. Die Abfrage ob AISS installiert ist habe ich so geändert, dass sie keinen Requester mehr verursacht. Kommt im nächsten Update. Trotzdem kann ich natürlich AISS nur empfehlen, gefällt mir mittlerweile besser als meine eigenen Grafiken. Das mit AHI ist sehr wahrscheinlich ein Bug im Treiber, nicht in HD-Rec, deshalb kommt ja der Requester mit dem Text der darauf hinweist. Da hat der Author des Treibers vergessen, die Anzahl der Bytes des Buffers (hier 8000) durch die Sample-Frame Größe zu teilen (hier 4). -- -- Author of 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.02.2012 um 20:11 Uhr geändert. ] |
|||||
|
Impressum |
Datenschutzerklärung |
Netiquette |
Werbung |
Kontakt
Copyright © 1998-2024 by amiga-news.de - alle Rechte vorbehalten. |