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

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

-1- 2 3 4 5 6 >> Letzte Ergebnisse der Suche: 1229 Treffer (30 pro Seite)
Der_Wanderer   Nutzer

06.02.2014, 02:43 Uhr

[ - Direktlink - ]
Thema: BlitzBasic Decompiler?
Brett: Programmierung

Naja, wie gesagt kann der Assembler oder ein anderes Tool gar nicht wissen welche Code Stellen unbenutzt sind, es sei denn es gibt nur konstante Sprünge und keine (Sprung-)Adresse wird an externe Libraries rausgegeben.

Ist auch nicht notwendig. Natürlich wird durch das Dazulinken einer ganzen BlitzLib ein Mini-Hello World verhältnismäßig groß gegenüber ASM. Aber das Sinn beim Optimieren ist nicht ein Mini Program noch kleiner zu machen, sondern ein großes Program klein zu halten.
Sobald das Program komplexer wird sinkt der Anteil des BlitzLib Codes relativ zum eigenen Code, und man wird vermutlich auch mehr Funktionen als nur "Print" benutzen. Da die BlitzLibs relativ fein granular sind, ist das vertretbar, denke ich. Es wird ja nicht eine Mega Runtime dazu gelinked, sondern diese ist in ca. 250 kleine Module zerteilt, von denen selectiv gelinkt wird.


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

05.02.2014, 01:09 Uhr

[ - Direktlink - ]
Thema: BlitzBasic Decompiler?
Brett: Programmierung

Zitat:
Original von Blackbird:
@inq:

Das ist bei BB2 der Fall, bei Ab2/3 werden die nicht benötigten/unbenutzten Befehle per Functionsoptimizer "wegoptimiert"
--
regards
Blackbird

Um etwas Licht ins Dunkel zu bringen:
Nein, nur Funktionen werden wegoptimiert, also nicht benutzter Basic Code. BlitzLibs werden nach wie vor im ganzen dazugelinked.

Das Hello World mit OS Funktionen ist kleiner, weil das lediglich Stubs sind für die OS Funktionen, ohne zusätzliche Funktionalität. Wenn man so coded braucht man aber kein Basic ;-)
Wenn man die PrintLib von Basic dazu linkt, ist das logischerweise größer. Ich glaube aber nicht, dass ein Disassemlber das wegoptimieren kann. Sobald Addressen berechnet werden, weis ja niemand ob der Code erreichbar ist oder nicht. Das kann man eigentlich nur in Hochspreachen sicher wissen.

Und zu guter letzt, wen juckt das eigentlich? War die Frage nicht nach einem Decompiler weil der Source verloren gegangen war?
Wie gesagt, diese Frage kann man mit "Nein, das geht nicht und wird auch nicht (zufriedenstellend) gehen." beantworten.

--
--
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 05.02.2014 um 01:17 Uhr geändert. ]
 
Der_Wanderer   Nutzer

04.02.2014, 21:06 Uhr

[ - Direktlink - ]
Thema: Selfmade GUI Programmierung Tips?
Brett: Programmierung

Ja, Knopf Größen und solche Dinge sind ecklig zu berechnen. In NTUI wird daher der Offset eines Scroller nie in Pixel *gespeichert*. Pixelwerte sind immer nur temporär während dem Zeichnen.
Dabei verwende ich Floats umd auf Nummer sicher zu gehen.

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

03.02.2014, 07:41 Uhr

[ - Direktlink - ]
Thema: Selfmade GUI Programmierung Tips?
Brett: Programmierung

Grundsätzlich sollte jedes Objekt damit umgehen können, wenn es nicht die Größe bekommt die es braucht.
Mein Rat wäre, berechne die Größe nicht vorher sondern erst beim Layouten (dein SETLAYOUT?). Wenn es nicht drauf passt, musst du (vertikale) Scroller anzeigen. Wenn es drauf passt, sind alle glücklich.
Der Designer des Dialogs muss darauf achten, dass ein sinnvoller Platz dafür bereit steht. Im Falle des Float Textest kannst du die Situation nicht anders lösen.
Beispiel: Dein Text wird mit "Hallo Welt." initialisiert. Nun gibts du dir wahnsinnig viel Mühle den Platzbedarf zu berechnen. Also nächstes setzt der App Programmierer den Text neu mit einer Abschrift der Bibel im Klingonischen Original. Und jetzt?

EDIT: Wenn du bereits einen TextEditor hast, dann nimm einfach den und mache ihn Read-Only. Dann kann man den Text auch gleich markieren und kopieren.

--
--
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 03.02.2014 um 07:54 Uhr geändert. ]
 
Der_Wanderer   Nutzer

01.02.2014, 19:50 Uhr

[ - Direktlink - ]
Thema: BlitzBasic Decompiler?
Brett: Programmierung

Hm, was hat ein offline Konverter für Vorteile gegenüber einem JIT Konverter?
Offensichtlich hat man mehr Zeit für Optimierungen. Fraglich ist aber ob da viel zu holen ist.
--
--
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

01.02.2014, 00:26 Uhr

[ - Direktlink - ]
Thema: BlitzBasic Decompiler?
Brett: Programmierung

Amiblitz2/3 hat auch PPC inline Assembler, fyi.

Wie gesagt, Decompiler funktioniert nicht weil nicht nur Macros aneinandergepappt werden.
Man kann natürlich herausfinden, welche BlitzLibs eingelinkt wurden, da die immer komplett reingelinkt werden. Das kann ich aber auch vom bloßen Anschauen des Spiels schon sagen... und hilft nicht wirklich weiter.

--
--
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 01.02.2014 um 00:28 Uhr geändert. ]
 
Der_Wanderer   Nutzer

31.01.2014, 22:05 Uhr

[ - Direktlink - ]
Thema: BlitzBasic Decompiler?
Brett: Programmierung

Nein, gibt es nicht. Der Compilvorgang ist eine Einwegfunktion.

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

30.01.2014, 23:55 Uhr

[ - Direktlink - ]
Thema: xCORE IDE
Brett: Amiga, AmigaOS 4

D.h. im X1000 sind Chips für die man nicht entwickeln kann?

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

30.01.2014, 20:33 Uhr

[ - Direktlink - ]
Thema: xCORE IDE
Brett: Amiga, AmigaOS 4

Und wo ist das Problem mit Eclipse? Sollte doch unter Linux luppen, oder?
Ok, sorry, ich verstehe davon wohl zu wenig.

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

30.01.2014, 19:19 Uhr

[ - Direktlink - ]
Thema: xCORE IDE
Brett: Amiga, AmigaOS 4

Ich habe kein OS4 und will auch keins. Aber AIDE sollte unter OS4 laufen und man kann bliebige Compiler integrieren. Ich arbeite noch an dem C/C++ Source Code Scanner so dass man Hilfe beim Editieren bekommt (Typeahead, springen zu Definitionen etc.)
--
--
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

30.01.2014, 17:44 Uhr

[ - Direktlink - ]
Thema: xCORE IDE
Brett: Amiga, AmigaOS 4

Vielleicht will mir ja jemand bei AIDE helfen. Für Amiblitz funktioniert das bereits recht gut. C Unterstützung ist in der Mache.
--
--
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

21.01.2014, 05:34 Uhr

[ - Direktlink - ]
Thema: Selfmade GUI Programmierung Tips?
Brett: Programmierung

Ja, meine Vorredner haben es bereits erklärt.

Warte mit dem Layouten bis das Objekt überhaupt sichtbar wird, oder zumindest bis das Fenster sichtbar wird.

Es stellt sich auch noch eine andere Frage, das betrifft aber hauptsächlich den TextView, Label oder wie auch immer man es nennen will.

Was passiert wenn der Text sich ändert, der mehr Platz braucht als bereits berechnet (weniger ist ja kein Problem).

Bei Android (NTUI ist davon stark beeinflusst) ändert sich tatsächlich bei jeder Änderung auch das Layout des Dialogs.
Bei NTUI mache ich das aber nicht. Alle Objekte müssen mit der Größe zurecht kommen, die sie beim Layouten bekommen haben. Wird der Text also länger, wird er abgeschnitten. Möchte der GUI Programmierer eine Änderung des Layouts, muss er es explizit aufrufen. Er muss dan auch damit rechnen, dass das Fenster vergrößert wird.

Der Flow ist

*obj = Create() # jederzeit
CalculateSize() # screen ist gelocked, Fenster noch zu, berechnet minimale Größe
Layout() # Fenster ist offen, setzt tatächliche Größe
Draw() # Fenster ist offen, zeichne! (muss natürlich immer testen ob der Text passt)


CalculateSize() wird aufgerufen, bevor ein Fenster geöffnet wird. Es berechnet rekursive die minimal notwendige Größe bis hoch zum Fenster.
Das bestimmt dann auch wie klein man das Fenster sizen darf.

Layout wird beim öffnen sofort danach aufgerufen, aber auch bei jedem Resizen oder sonstigen Aktionen, die das Layout beeinflussen.

Draw wird jedesmal aufgerufen wenn gezeichnet werden muss.

Das sind die unterschiedlichen Stufen, kann man alle mit "invalidate" oder dirty Flags versehen. Dadurch verhindert man, dass "teure" Berechnungen nur einmal ausgeführt werden, auch wenn während dem Programmablauf das sehr oft angefragt wird.


--
--
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 21.01.2014 um 05:43 Uhr geändert. ]
 
Der_Wanderer   Nutzer

18.01.2014, 06:26 Uhr

[ - Direktlink - ]
Thema: Selfmade GUI Programmierung Tips?
Brett: Programmierung

Wenn du weder ein Window noch einen Screen hast, warum möchtest du das Layout berechnen?

Es macht nur Sinn das Layout zu berechnen wenn du vor hast das Fenster zu öffnen, und in dem Moment hast du einen Screen. Remember, bevor du ein Fenster öffnen darfst musst du auf einen Screen "uppoppen". Und dann kannst du dir Fonts, Pens etc, holen.

--
--
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 18.01.2014 um 06:34 Uhr geändert. ]
 
Der_Wanderer   Nutzer

18.01.2014, 04:56 Uhr

[ - Direktlink - ]
Thema: Selfmade GUI Programmierung Tips?
Brett: Programmierung

Das ist eigentlich recht einfach. Du musst die möglichen Einstiegspunkte zum Zeichnen reduzieren, idealerweise gibt es nur eine einzige Funktion, bei ntui ist das ntui_Redraw(*obj,*cliprect). Die Funktion testet ob das Objekt überhaupt innerhalb des Rechtecks sichtbar ist und kehrt sofort zurück wenn nicht, andernfalls wird gezeichnet.
Alle darunterliegenden Funktionen müssen nichts mehr testen, weil sie nur von ntui_Redraw() aufgerufen werden dürfen. D.h. pro Zeichenvorgang muss nur einmal getestet werden.

Darunter liegt die Funktion ntui_Draw(*obj,*cliprect,*rastport), die von ntui_Redraw() aufgerufen wird. Wie man sieht musst dafür bereits der RastPort bestimmt worden sein, und ist völlig unabhängig von Fenstern etc. Du kannst also auch ntui Objekte in deinen privaten RastPort zeichnen.

Der App Programmierer (und NTUI selbst) verwendet aber normalerweise keine der o.g. Funktionen direkt, sondern ruft "ntui_Damage(*obj,*rect)" auf. Damit teilt man der NTUI Engine mit, dass das Objekt in dem angegebenen Rechteck neu gezeichnet werden muss. Normalerweise passiert das Neuzeichnen dann erst, wenn der Focus an NTUI zurück gegeben wird, indem NTUI dann ntui_Redraw() aufruft. So wird nur einmal gezeichnet, auch wenn der App Programmierer an mehreren Stellen ntui_Damage() aufrufen muss.

Klassisches Beispiel ist der ListView, der nach jedem Eintrag der hinzugefügt wird ntui_Damage() aufruft. Ist nicht weiters schlimm, weil ntui_Damage() nichts zeichnet, sondern nur ein Flag setzt dass anzeigt dass das Objekt ein Neuzeichnen braucht. Ist also super leichtgewichtig. Wenn der ListView dann befüllt worden ist, und der Focus an NTUI zurückgeht, wird der ListView genau einmal neu gezeichnet und das Flag wieder gelöscht.

Oder z.B. bei SimpleRefresh Fenstern, wenn man Solid Window Moving hat, dann kann es sein dass sehr viele IDCMP_REFRESH Messages kommen, schneller als man den Inhalt neuzeichnen kann. Würde ich brute Force neuzeichnen, dann würden sich die Messages aufstauen und alles träge werden, bzw. das Fenster eine weile lang sich ständig neu zeichnen. Es gibt viele Apps bei AmigaOS wo man das Verhalten beobachten kann.
Bei NTUI allerdings wird beim Eingang der IDCMP_REFRESH message erstmal nichts gezeichnet, sondern nur das Flag gesetzt. Wenn keine Messages mehr anliegen, wird EINMAL neu gezeichnet. Wenn das neu zeichnen lange dauert, werden danach wieder ALLE anstehenden Messages augesammelt, und wieder nur EINMAL neugezeichnet.


--
--
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 18.01.2014 um 05:02 Uhr geändert. ]
 
Der_Wanderer   Nutzer

16.01.2014, 23:05 Uhr

[ - Direktlink - ]
Thema: Selfmade GUI Programmierung Tips?
Brett: Programmierung

Ja, aber show und hide trifft es nicht ganz.

Hier der App Lebenszyklus unter NTUI:


1. Create App (including all Windows and Widgets)

2. "PopUp" to a screen (screen is now locked)

3. Show Window (Opens AmigaOS Window) *)

...

4. Hide Window (Closes AmigaOS Window) *)

5. "Iconify" or leave Screen (screen is now unlocked)

6. Goto 2. or destroy App


Diese Liste gibt nur die Idee, aber ist nicht ganz korrekt *).

Man kann durchaus auch "Show Window" auf rufen ohne dass man auf einem Screen "GePopupped" ist. Passiert halt nur nichts. Bis man dann auf einen Screen geht, dann werden die Fenster automatisch geöffnet. (da sie ja aus NTUI sich offen sind).
Genauso muss man bei "Iconify" auch keine Fenster schliessen. Also wenn man z.B. lediglich von einem Screen auf einen anderen will, dann macht man "Iconfiy" und sofort "Popup" auf dem neuen Screen. Die Fenster werden dann dort geöffnet wie sie vorher waren.
Die Fenster waren aus NTUI sicht also nie geschlossen.

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

14.01.2014, 23:57 Uhr

[ - Direktlink - ]
Thema: Selfmade GUI Programmierung Tips?
Brett: Programmierung

Man könnte es auch WAKE und SLEEP nennen, aber die App schläft nicht notwenidgerweise, ist also auch nicht ganz korrekt.

Es ist sowas sie "Tauche auf" und "Tauche unter", oder eben "Gehe auf Sceen" oder "Verlasse Screen". "PopUp" finde ich ganz intuitiv von der Terminologie her. "Iconfiy" ist etwas irreführend, gebe ich zu, weil es nicht autoamtisch heisst, dass die App ein Icon auf der WB platziert, nur wenn man will.
Allerdings heist das unter Windows auch "Iconify", obwohl es nicht wirklich ein Icon gibt. Es bedeutet für mich nur "GUI zu", aber ansonsten weiterlaufen.


--
--
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 15.01.2014 um 04:54 Uhr geändert. ]
 
Der_Wanderer   Nutzer

13.01.2014, 23:30 Uhr

[ - Direktlink - ]
Thema: Selfmade GUI Programmierung Tips?
Brett: Programmierung

Du kannst eine Engine (App) anlegen. Da wird noch nichts gelocked.

Du kannst auch Fenster anlegen und alles weitere.

Jetzt ruft du

ntui_PopUp{engine,"Workbench"}

auf, und das aller aller erste was passiert ist, der Screen wird gelocked. Sonst kann man ihn dir ja wieder wegnehmen. Das passiert mit "LockPupScreen()", eine AmigaOS funktion. Wenn die fehlschlägt, dann wird ein eigener Screen mit diesem Pubnamen geöffnet.

Also z.B.

ntui_PopUp{engine,"MyProggy"}

Würde einen neuen Screen aufmachen, falls es noch nicht läuft. Der Leere Sting wird als Workbench interpretiert.

Wie auch immer, jetzt (nach PopUp) sind wir auf dem Screen, egal ob nun Fenster offen sind oder nicht. Bisher sind noch keine offen.
Jetzt kann man Fenster öffnen und schliessen wie man lustig ist. Kann man auch vorher schon, nur werden die Fenster dann nicht sichbar, da wir ja nicht auf einem Screen "gepopped" sind.
ntui_PopUp kann auch sofort Fenster sichtbar machen, die eigentlich offen sind.

Wenn wir uns von dem Screen zurückziehen wollen, rufe ich "ntui_Iconfiy{engine}" auf, dann werden alle AmigaOS Fenster zugemacht und der PubScreen unlocked. Falls noch NTUI Fenster offen sind, bleiben die offen für NTUI, aber sind nicht sichtbar.
So kann ich mit einer App komplet transaprent arbeiten, egal ob sie nun auf einem Screen ist oder nicht.
So kann man auch von einem Screen auf den anderen "umziehen", ohne die Session zu ändern, d.h. ein PopUp stellt ja alle offenen Fenster wieder sichtbar her.

Nach Iconfiy werden keinerlei Resourcen mehr auf dem Screen festgehalten, damit er geschlossen werden kann.
Die Basis Pens, Fonts werden beim PopUp geholt, un bei Iconfiy freigegeben. Eingie Resourcen werden erst geholt, wenn sie tatsächlich gebraucht werden, z.B. Bilder in einem ListView, Pens in einem farbigen Widget die nicht Standard Pens sind etc.
So muss man nicht wirklich alles komplett im PopUp tun, was evtl. langsam werden könnte. Generell ist "lzay" besser, z.B. du hast ein grosses "teures" Bild auf einem Reiter. Solange man aber den Reiter nicht sichtbar klickt, brauchst du ja auch das Bild nicht. Also schiebst du das laden so spät wie möglich, und mit etwas Glück musst du es gar nicht laden weil der User den Reiter nicht klickt, oder z.B. den ListView nicht ganz durchscrollt etc.

Pens allociere ich übrigends in einem Array mit 512 Eintägen (8x8x8), sortiert nach RGB, jeweils 3 bit. So kannst du super schnell remappen. 3bit pro Farbe reicht für die allermeisten Sachen auf Colormapped screens dicke aus. Mehr bit sieht nicht wirklich besser aus (höchstens bei Graustufen Gradienten), verbraucht aber wiederum massiv Pens des Screens. Wichtiger ist mir persönlich dass True Color gut unterstützt wird.
--
--
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

13.01.2014, 22:00 Uhr

[ - Direktlink - ]
Thema: Selfmade GUI Programmierung Tips?
Brett: Programmierung

Wie gesagt, der Screen muss ja gelocked werden zumindest bis du das erste Fenster offen hast. Des weiteren ist es kein Muss, in NTUI ein Fenster auch "physisch" offen zu haben. Im Gegensatz zu AmigaOS muss in NTUI ein Fenster nicht sichtbar sein, um zu existieren. Für den App Programmierer ist das völlig egal. Lediglich GUI updates sind eben nicht sichtbar.
--
--
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

13.01.2014, 17:24 Uhr

[ - Direktlink - ]
Thema: Selfmade GUI Programmierung Tips?
Brett: Programmierung

Also ich halte den Screen nicht immer gelocked. nur zwischen ntui_PopUp und ntui_Iconfiy.
--
--
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

13.01.2014, 16:40 Uhr

[ - Direktlink - ]
Thema: Selfmade GUI Programmierung Tips?
Brett: Programmierung

Zitat:
Original von AGSzabo:
@Der_Wanderer:

Danke. Ja, das hilft. Lockst Du den Screen wenn die Engine erzeugt wird, oder wenn Du das erste Fenster darauf öffnest? Ich brauche screenspezifische Daten noch bevor ich das Fenster öffne, zB Font/Größe und Fenster-Rahmenmaße/Sizegadgetmaße.

Und wann soll ich die Pens für den Screen obtainen und die Images für den Screen laden? Beim ersten Fenster öffnen oder wenn mein Screen geöffnet wird? Letzteres ist schwieriger, wenn es der WB Screen sein soll. Woher kann mein System wissen ob jemand die Workbench oder einen Publicscreen schließen oder neu öffnen will wegen Prefschanges zB?

Der Screen wird mit LockPubScreen() über den PubScreen Namen geholt. Falls der nicht exitiert, wird ein eigene Screen als WB Clone aufgemacht.
D.h der Screen ist immer gelocked.
Danach kannst du Pens obtainen, die Farbtiefe untersuchen, Fonts laden, Fensterramen untersuchen etc., bevor du irgendein Fenster öffnest.

Images laden ist davon unabhängig. Die werden entweder beim erstellen eines Objektes geladen, oder zu einem späteren Zeitpunkt verschoben, idealerweise erst beim Layouten oder Zeichnen. Z.B. wenn du ein ListView mit 1000 Einträgen hast, macht es keinen Sinn für alle Einträge ein Icon/Bildchen zu laden, wenn man nur 20-30 davon sieht. Laden sollte aber nicht vom Screen abhängen, wenn das Bild zwischen Apps geshared werden soll.

Alle Screenanpassungen passieren bei mir on-the-fly beim zeichnen. Könnte man auch cachen, müsste dann aber in der Engine, und nicht global gecached werden.

Wann ein Screen geschlossen werden soll kannst du (nur) über die screennotify.libray herausbekommen. So kann dein Programm auch auf Screenmode Prefs Änderungen reagieren.

--
--
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 13.01.2014 um 16:42 Uhr geändert. ]

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

13.01.2014, 06:04 Uhr

[ - Direktlink - ]
Thema: Selfmade GUI Programmierung Tips?
Brett: Programmierung

Ich habe das jetzt nicht alles durchgelesen, aber hier is mein Beitrag wie das in NTUI funktioniert.

Das was du "App" Objekt nennst heist in NTUI "engine". Eine Engine kann nur auf einem Screen gleichzeitig sein. Sie kann aber von Screen zu Screen "hüfpen".

Dafür gibt es die Funktionen "ntui_PopUp" und "ntui_Iconify", wobei PopUp sich auf einem Screen "anmeldet" (kann Workbench, Pubscreen oder eigener Screen sein). Dann können Fenster geöffnet werden.
Wenn man sich von dem Screen zurückziehen will ruft man "ntui_Iconfiy" auf. Das gibt alle Screen spezifischen Resourcen frei wie z.B. Pens.
(achja, also Pens werden pro Engine gespeichert, nicht global).

Ob man sich auf einem Screen befindet oder nicht ist 100% transparent für das Funktionieren der GUI. D.h. die App muss nicht wissen oder ständig abfragen ob die Fenster nun offen sind oder nicht.

Wenn die App auf mehreren Screens GLEICHZEITIG sein soll, dann macht man einfach mehrere Engines auf. Macht auch Sinn, denn die "Engines" sind voneinander völlig unabhängig, können also auch auf ganz verschiedenen Auflösungen und Farbtiefen laufen.

Pens werden bei ntui_PopUp "obtained", bzw. viele auch erst "on demand". Innerhalb ntui wird nicht mit AmigaOS Pens gearbeitet (da screen spezifisch und nach einem Screen wechsel nicht mehr gültig), sondern mit NTUI-Pens. Vor jedem Zeichenvorgang wird dann erst der AmigaOS Pen ermittelt mit Hilfe eines Table Lookups.

Bilder werden als True Color geladen. Dabei muss kein Screen offen sein, da True Color keine Paletten Informationen braucht.
AmigaOS Bitmaps lege ich gar nicht erst an. Bilder werden mit "WritePixelArray" auf den Screen gebracht. Das ist natürlich für True Color Screens am besten geeignet.
Auf Color Mapped Screens wird on-the-fly geremapped, d.h. es wird ein 8bit LUT PixelArray erstellt und mit WritePixelArray8 auf den Bildschirm gebracht. Da wir ja meistens kleine Bilder zeichnen und nicht ständig, ist das kein Performance Problem auf einigermassen modernen Systemen.

Letzter Tip: Verlasse dich so wenig wie möglich auf AmigaOS. AmigaOS API ist wie eine Pralinenschachtel, man weis nie was man kriegt... ;-)

Hoffe das hilft irgendwie weiter.
--
--
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

31.07.2013, 22:19 Uhr

[ - Direktlink - ]
Thema: Maus über Grafik mit AOS-API erkennbar?
Brett: Programmierung

Ich hoffe du fragst nicht, um das Hexagon zu bestimmen in das die Mauskoordinaten fallen, sondern um Objekte beliebiger Form testen zu können.
Also die Maske erstmal blitten um dann mit ReadPixel zu testen ist entweder furchtbar langsam (on-the-fly) oder hat Speicher overhead (gecached).
Warum testest du die Bitmaske nicht direkt?

(aus deinen Ausführungen errate ich mal, du hast Bitmasken, aber es wäre hilfreich wenn du verraten würdest wie du deine Bilder genau lädst und blittest, sonst kann keiner was genaueres sagen).

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

31.07.2013, 14:13 Uhr

[ - Direktlink - ]
Thema: Maus über Grafik mit AOS-API erkennbar?
Brett: Programmierung

Mit der Subtraktion meine ich, die Screen Koordinaten in Bitmap Koordinaten umzurechnen. Das hast du scheinbar bereits gemacht, und weist nun welchen X/Y Pixel der Bitmap du auf Transparenz befragen willst.
Wie das genau geht, hängt leider von dem Pixelformant der Bitmap ab, es gibt keine OS Funktion ReadOpacity() ala ReadPixel().
Wenn es sich um eine Bitmaske handlet, dann musst du die Addresse auf die Maske holen, die entsprechende Position berechnen und dann das bit ausmaskieren. Dazu musst du dich mit Bit Operatoren auseinandersetzen.

Wenn es ein Alphakanal ist, dann kannst du per Byte-Zugriff den Alphawert auslesen, entweder aus den ARGB Daten oder falls vorhanden externen Alpha Kanal Byte Array. Leider brauchst du in allen Fällen Zugriff auf die Bitmap, was dir z.B. AROS standardmäßig nicht erlaubt.
Evtl. ist es daher besser, die Bitmaps in einer eigenen Struktur zu halten und mit Read/WritePixelArray und einer eigenen Routine auf den Screen zu bringen. So mache ich das bei AB3 mit den Bitmaps.



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

30.07.2013, 21:35 Uhr

[ - Direktlink - ]
Thema: Maus über Grafik mit AOS-API erkennbar?
Brett: Programmierung

Du kennst die Koordinaten und Größen der Objekte. Damit kannst du ermitteln durch einfache Subtraktion, wo der gewünschte Punkt im Objekt liegt. Liegt er innerhalb des Begrenzungsrechtecks, dann muss genauer auf die Sichtbarkeit des Pixels geprüft werden. Und das geschieht indem man sich, je nach Grafikformat, die Bitmaske oder den Alphakanal an der betreffeneden Stelle anschaut. Ist die Bitmaske gesetzt, oder der Alphakanal größer als ein bestimmter Schwellwert, z.B. 192, dann gilt der Pixel als gesetzt und das Objekt als getroffen.

--
--
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.07.2013, 15:46 Uhr

[ - Direktlink - ]
Thema: Maus über Grafik mit AOS-API erkennbar?
Brett: Programmierung

Naja, zu irgendeinem Zeitpunkt hast du die GRafik ja auf den Bildschirm gemalt. Und deshalb kennst du die Koordinaten.
Dann prüft du zuerst, ob es innerhalb des Rechtecks sein soll. Wenn ja, dann kannst du noch detailierter die Bitmaske oder den Alphakanal testen, ob dort auch wirklich sichtbare Pixel sind. Ist das so schwer?

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

17.07.2013, 15:14 Uhr

[ - Direktlink - ]
Thema: Metacompiler PortablE
Brett: Amiga, AmigaOS 4

"HTML5" ist noch portabler als "Hollywood".

Soll "Hollywood "sowas ähnliches wie "HTML5" werden? Dann frage ich mich, wieso denn das Rad hier wieder neu erfunden wird.

Welche Vorteile bietet denn "Hollywood" gegenüber HTML5?
--
--
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

12.06.2013, 13:14 Uhr

[ - Direktlink - ]
Thema: FileManager asynchrones Kopieren
Brett: Programmierung

Hm.. du musst doch den Prozess nicht beenden, der den FileLister anzeigt. Er kann doch weiterlaufen bis alles kopiert ist und dann beenden. Alternativ schreibe dir doch einen "copy" Befehl, der einen Requester mit Fortschrittsanzeige öffnet. Dann ist es komplett unabhängig von dem ListView Prozess. Allerdings kannst du dann schwieriger Kopieranfragen queuen. Am besten machst du das mit zwei Threads. Einer für die GUI, und eine Command-Queue, wo die GUI commandos reinstellen kann, die dann synchron (aber asynchron zur GUI) abgearbeitet werden. Wenn der FileLister geschlossen wird, dann wird desssen Fenster geschlossen, aber die Command Queue kann zu Ende abgearbeitet werden und auch eine Fortschirttsanzeige kann weiter laufen.




--
--
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 12.06.2013 um 13:15 Uhr geändert. ]
 
Der_Wanderer   Nutzer

01.05.2013, 10:16 Uhr

[ - Direktlink - ]
Thema: AROS, doch noch so instabil ?!
Brett: AROS und Amiga-Emulatoren

Placebo.
--
--
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, 22:21 Uhr

[ - Direktlink - ]
Thema: AROS, doch noch so instabil ?!
Brett: AROS und Amiga-Emulatoren

So. Hier schrabbelt AROS ab.
Das hat nichts mit der zlib.library zu tun. Das muss ich mir auch noch angucken. Aber hier sieht es definitiv so aus, als ob #PDTM_READPIXELARRAY Probleme macht. Der Code funktioniert unter OS4, OS3, OS3+AfA und MOS. Aber vielleicht ist ja doch noch was falsch.

code:
Function.l image_LoadViaDT{image.l,filename.s,imgnum.l}
DEFTYPE.BitMapHeader *bmhdp
DEFTYPE.BitMap *bmap
DEFTYPE.pdtBlitPixelArray DTM
succ.l = False
If imgnum<0 Then imgnum=0
tag5.tag5\ti_Tag = #PDTA_DestMode, #PMODE_V43, #DTA_SourceType, #DTST_FILE, #DTA_GroupID, #GID_PICTURE, #PDTA_Remap, False,#PDTA_WhichPicture,imgnum,#TAG_DONE,0
*DTPic._Object = NewDTObjectA_ (&filename.s,tag5)
If *DTPic
  tag5.tag5\ti_Tag = #PDTA_BitMapHeader,&*bmhdp,#TAG_DONE,0
  GetDTAttrsA_ *DTPic,tag5
  If image_Create{image,*bmhdp\bmh_Width,*bmhdp\bmh_Height}
    If image_Lock{image}

      ; try to get as ARGB immediately, good datatpyes support this, but not all!
      ;If *bmhdp\bmh_Depth>8 ; dont even try if depth <=8
        DTM\MethodID            = #PDTM_READPIXELARRAY
        DTM\pbpa_PixelData      = \raw_ptr          ; /* The pixel data to transfer to/from */
        DTM\pbpa_PixelFormat    = #PBPAFMT_ARGB     ; /* Format of the pixel data (see "Pixel Formats" below) */
        DTM\pbpa_PixelArrayMod  = \bpr              ; /* Number of bytes per row */
        DTM\pbpa_Left           = 0                 ; /* Left edge of the rectangle to transfer pixels to/from */
        DTM\pbpa_Top            = 0                 ; /* Top edge of the rectangle to transfer pixels to/from */
        DTM\pbpa_Width          = *bmhdp\bmh_Width  ; /* Width of the rectangle to transfer pixels to/from */
        DTM\pbpa_Height         = *bmhdp\bmh_Height
        If DoMethodA (*DTPic,&DTM) Then succ = True <=== CRASH!!!
      ;End If
  ...


--
--
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 22:24 Uhr geändert. ]
 
Der_Wanderer   Nutzer

29.04.2013, 13:44 Uhr

[ - Direktlink - ]
Thema: AROS, doch noch so instabil ?!
Brett: AROS und Amiga-Emulatoren

Also beim reinen Öffnen crashed es bei beiden Methoden noch nicht.

Seltsam. Ich muss also ein kleines Demo schreiben.

Ich habe übrigends noch einen anderen Verdacht, nämlich dass es Probleme mit den Datatypes gibt. Denn auch nach dem Umstellen auf z.library crashen bei mir fast alle Programme, die mit Bilder zu tun haben.

--
--
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
 
 
-1- 2 3 4 5 6 >> 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-2022 by amiga-news.de - alle Rechte vorbehalten.
.