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

amiga-news.de Forum > AROS und Amiga-Emulatoren > AROS, doch noch so instabil ?! [ - Suche - Neue Beiträge - Registrieren - Login - ]

1 -2- 3 [ - Beitrag schreiben - ]

28.04.2013, 14:27 Uhr

Floppy
Posts: 392
Nutzer
Zitat:
Original von wawa:
@jolo:
ich glaube jason hat versucht soweit wie moeglich in richtung vbcc vorzustossen, hat die arbeit aber abgebrochen als es zu kompliziert wurde und andere aufgaben dringender waeren. das alles kein boeser wille, es fehlt halt an mannschaft.

koenntest du nicht aros team dabei unterstuetzen die idcmp und rastport angelegenheit auszubuegeln? ich denke echt es ist prioritaer, vielleicht laesst sich deadwood oder kalamatee dazu bewegen.


Ja, ich bin mir sicher, dass sich jemand schnell darum kümmern wird, wenn der Bug schon soweit eingegrenzt werden kann. Ein Eintrag im Bugtracker wäre Klasse, aber die Beschreibung des Fehlers mit einem nachvollziehbaren Szenario hilft auch schon. Deshalb schließe ich mich wawa an und möchte Dich bitten, die genauen Details hier oder auf aros-exec zu erklären.

[ - Antworten - Zitieren - Direktlink - ]

28.04.2013, 14:29 Uhr

Floppy
Posts: 392
Nutzer
Zitat:
Original von wawa:
@Floppy:
nichtdesto weniger finde ich bedenklich dass die library in frage auf aos trotzdem funktioniert aber auf aros68k nicht. eigentlich von anspruch der kompatibilität abgeleitet sollte man nach dem problem und lösung auf aros seite suchen anstatt die applikationen na aros anzupassen.


Deshalb meinte ich ja, der Wanderer sollte sich am Besten mit den AROS-Devs in Verbindung setzen. Wenn es ein Bug in AROS ist, werden die daran arbeiten, diesen zu fixen.

[ - Antworten - Zitieren - Direktlink - ]

28.04.2013, 15:59 Uhr

wawa
Posts: 314
Nutzer
@Floppy:
vielen ist es zuviel aufwand sich auf noch einen forum anzumelden, ich kann gerne auch einen boten machen, tu ich eher nicht seit heute. ich muss nur konkrete botschaften zu vermitteln haben.

[ - Antworten - Zitieren - Direktlink - ]

28.04.2013, 18:35 Uhr

Der_Wanderer
Posts: 1229
Nutzer
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

[ - Antworten - Zitieren - Direktlink - ]

28.04.2013, 19:43 Uhr

wawa
Posts: 314
Nutzer
@Der_Wanderer:
ich weiss nicht ob das abstruserweise ist, am mac gab auch fat binaries, und die ganze cpu-abhängigen libraries gemetzel am amiga hat mich schon immer auf die palme getrieben. ich denke für einen normalen user istz das ne zumutung immer die passende version der lib unter haufenweise versionen zu finden. aber egal..

okay, also es stürzt gleich beim start ab. ich nehme an, es geht um diese library hier:
http://aminet.net/package/util/libs/zlib-library
gibt es ein möglichst einfaches (am besten cli) utility welches diese lib benutzt? ich werde toni sofort darauf ansprechen.

noch eine frage vorweg, denn ich erwarte einen einwand von toni, gibt es weitere solche libraries? schnellsuche in aminet lieferte keine ergebnisse. es sieht ziemlich nach einen sonderfall aus.

[ Dieser Beitrag wurde von wawa am 28.04.2013 um 19:45 Uhr geändert. ]

[ Dieser Beitrag wurde von wawa am 28.04.2013 um 19:47 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

28.04.2013, 21:34 Uhr

Floppy
Posts: 392
Nutzer
Zitat:
Original von wawa:
@Floppy:
vielen ist es zuviel aufwand sich auf noch einen forum anzumelden, ich kann gerne auch einen boten machen, tu ich eher nicht seit heute. ich muss nur konkrete botschaften zu vermitteln haben.


Der Wanderer ist bereits auf aros-exec registriert. ;) Aber nun ist es erledigt ...

@Wanderer

Benutzt nicht AmiBlitz3 ebenfalls die zlib.library oder habe ich das nur falsch verstanden? Denn AmiBlitz3 crashed meines Wissens auf AROS68k nicht.

[ - Antworten - Zitieren - Direktlink - ]

28.04.2013, 21:49 Uhr

wawa
Posts: 314
Nutzer
@Floppy:
it wasnt working dependably last time i tried afair, but its a while back. anyway as testcase a simple one is needed.

[ - Antworten - Zitieren - Direktlink - ]

28.04.2013, 22:09 Uhr

Floppy
Posts: 392
Nutzer
@wawa:

Hilft das hier:
http://aminet.net/package/util/pack/zlibexample ?

Und vor allem: Crashed das auch gleich beim Öffnen auf AROS68k?

Dieser DMX hat übrigens, soviel ich weiß, auch die AROS zlib für i386 portiert.

[ Dieser Beitrag wurde von Floppy am 28.04.2013 um 22:28 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

29.04.2013, 12:18 Uhr

wawa
Posts: 314
Nutzer
@Floppy:

>http://aminet.net/package/util/pack/zlibexample

könnt ihr den test oben bestätigen, ich habe es gerade zwei mal unter aros68k (winuae), unter nightly einer der letzten tage zwei mal versucht und es hat funktioniert!

[ Dieser Beitrag wurde von wawa am 29.04.2013 um 12:18 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

29.04.2013, 13:20 Uhr

Der_Wanderer
Posts: 1229
Nutzer
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. ]

[ - Antworten - Zitieren - Direktlink - ]

29.04.2013, 13:27 Uhr

OlafSch
Posts: 91
Nutzer
@Der_Wanderer:

weiss nicht ob das hilft.

Ich habe das gefunden:
http://aminet.net/package/dev/basic/Blitz_zlib

enthalten ist u.a. ein Beispiel mit Source das zu funktionieren scheint und nicht crasht

[ - Antworten - Zitieren - Direktlink - ]

29.04.2013, 13:27 Uhr

wawa
Posts: 314
Nutzer
@Der_Wanderer:
also ich schnalle es nicht ganz, wenn zlib code funktioniert, liegt es daran wie amiblitz die mixed shared lib aufmacht? kannst du mit c code den gleichen effekt hervorrufen? test source und binary liefern? es wird schwierig an die aros devs mit amiblitz heranzutreten, sorry, kaum zu erwarten, die kennen sich damit aus.

[ - Antworten - Zitieren - Direktlink - ]

29.04.2013, 13:28 Uhr

Der_Wanderer
Posts: 1229
Nutzer
@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. ]

[ - Antworten - Zitieren - Direktlink - ]

29.04.2013, 13:30 Uhr

OlafSch
Posts: 91
Nutzer
@Der_Wanderer:

hast du das oben schon getestet?

http://aminet.net/package/dev/basic/Blitz_zlib

[ Dieser Beitrag wurde von OlafSch am 29.04.2013 um 13:31 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

29.04.2013, 13:31 Uhr

Der_Wanderer
Posts: 1229
Nutzer
@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

[ - Antworten - Zitieren - Direktlink - ]

29.04.2013, 13:40 Uhr

Floppy
Posts: 392
Nutzer
@Der_Wanderer:
"stay tuned"

Da kannst' Dich drauf verlassen. :)

[ - Antworten - Zitieren - Direktlink - ]

29.04.2013, 13:44 Uhr

Der_Wanderer
Posts: 1229
Nutzer
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

[ - Antworten - Zitieren - Direktlink - ]

29.04.2013, 14:10 Uhr

wawa
Posts: 314
Nutzer
@Der_Wanderer:
Zitat:
Interessant. Das würde bedeuten, dass die Blitz Anbindung korrupt ist.
wäre meine vermutung auch, trotzdem interessant wieso es auf aros crasht auf aos aber nicht.

was ein consens betreffend z-libraries anbetrifft, vielleicht lässt sich doch einer finden oder zumindest der weitere wildwuchs einschränken.

mein vorschlag: ein thread auf amiga-coding.de, oder gleich hier auf aros-exec:
http://aros-exec.org/modules/newbb/viewtopic.php?topic_id=8201&forum=22&post_id=81160#forumpost81160

mit möglichst allen beteiligten, ein deutchsprachiges forum ist vermutlich nicht geeignet genug.

seitens os4 schlage ich salass00 vor, der ein set von z-libraries mit seinem diskimage-device bereits für alle amiga-platformen anbietet. (salass ist ein mitglied von os4 team also ein gute ansprechspartner derseits denke ich, hat sich auch schon selbst zu wort gemeldet)

aros v1 ist in dieser beziehung vermutlich sowieso noch flexibel, da die api ist nicht stable und das library set kann angepasst werden.

[ Dieser Beitrag wurde von wawa am 29.04.2013 um 14:11 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

29.04.2013, 17:07 Uhr

Georg
Posts: 107
Nutzer
Zitat:
Original von jolo:
Zudem gibt es einen massiven Bug beim Locken von RastPorts bei Verwendung von eigenen BOOPSI-Klassen, der das gesamte System einfriert.


Was meinst du genau? Rastports können nicht gelockt werden. Wenn RastPort->Layer gemeint ist: wie sieht der Code aus, der das System einfriert?

[ - Antworten - Zitieren - Direktlink - ]

29.04.2013, 18:12 Uhr

KeHo_Software
Posts: 1
Nutzer
Hallo - ich habe mir wegen AROS auch ein Aspire One Netbook zugelegt.
Installiert ist bei mir eine AspireOS Version auf dem USB-Stick - Ubuntu ist weiterhin auf dem Netbook, Ich muss sagen bei mir läuft alles sehr stabil.

Gruss Achim :bounce:

[ - Antworten - Zitieren - Direktlink - ]

29.04.2013, 20:15 Uhr

jolo
Posts: 110
Nutzer
Zitat:
wawa:
ich glaube jason hat versucht soweit wie moeglich in richtung vbcc vorzustossen, hat die arbeit aber abgebrochen als es zu kompliziert wurde und andere aufgaben dringender waeren. das alles kein boeser wille, es fehlt halt an mannschaft.


Das SDK selber wird nicht ohne weiteres unter 'vbcc' verwendbar sein, da es maßgeschneidert für 'gcc' ist. Wäre man in 2005(?) auf Frank Willes Anregungen eingegangen und hätte das SDK so erweitert, dass die Compiler-spezifischen Sachen in Unterverzeichnisse gewandert wären, hätte sich das für mich leidige Thema "AROS is programmable only by means of the gcc-compiler!" erübrigt.


Zitat:
wawa:
koenntest du nicht aros team dabei unterstuetzen die idcmp und rastport angelegenheit auszubuegeln?


Bug-Report bezüglich des Render-Bugs wurde von mir 2011 eingestellt.
Das IDCMP-Handling können die AROS-Entwickler nach Gutdünken handhaben; es ist kein Bug sondern eine Inkompatibilität zu OS3, MorphOS, AmigaOS4.


Zitat:
Georg:
Was meinst du genau? Rastports können nicht gelockt werden. Wenn RastPort->Layer gemeint ist: wie sieht der Code aus, der das System einfriert?


Hier ist der Code, aber ich glaube kaum, dass Du mit diesem was anfangen kannst, daher beschreibe ich unten das Problem.


code:
case GM_RENDER:
{
    struct GadgetInfo *ginfo = ((struct gpRender *) msg)->gpr_GInfo;
    struct RastPort *rp = ((struct gpRender *) msg)->gpr_RPort;
    struct Gadget *gad = (struct Gadget *) o;
    #if defined(__AROS__)
    ULONG x, y;
    #endif

    #ifdef DEBUG
    kprintf( "GM_Render called!\n");
    #endif

    ged = INST_DATA( cl, o);
    if (rp && ginfo)
    {
        if ( (gad->Flags & GFLG_SELECTED) && !(gad->Flags & GFLG_GADGHNONE))
            DrawSelected( (struct Gadget *) o, ged, ginfo, rp);
        else
            DrawUnselected( (struct Gadget *) o, ged, ginfo, rp);

        /* Blast the entire pre-drawn image into the display if it
           is of type PROGRESS BAR */
        if (ged->type == RGB24TYPE_PROGRESS)
        {
    #if !defined(__MORPHOS__) && !defined(__AROS__) && !defined(__amigaos4__)

            /* OS3 stuff is more complicated than the others, because we
               can't draw directly texts into a 24-bit offscreen
               PixelArray */
            if ( ged->oldX > ged->newX || (ged->newX == 0 && ged->oldX == 0) ||
                 (ged->flags & FORCE_REFRESH) )
            {
                ged->flags &= ~FORCE_REFRESH;

                /* Entire gadget to be rendered */
                ClipBlit( &ged->rp, 0, 0,
                          rp,
                          gad->LeftEdge, gad->TopEdge,
                          gad->Width, gad->Height,
                          0xC0);    /* Cookie cut */
                ged->oldX = 0;
                ged->newX = 0;
            }
            else
            {
                /* Just render what is affected */
                ClipBlit( &ged->rp, ged->oldX, 0,
                          rp,
                          gad->LeftEdge + ged->oldX, gad->TopEdge,
                          ged->newX - ged->oldX, gad->Height,
                          0xC0);    /* Cookie cut */
                ged->oldX = ged->newX;
            }

            if (ginfo && ((struct Gadget *) o)->GadgetText)
            {
                if (ged->oldX == 0 || (ged->flags & FORMAT_USED) )
                    RenderGadText( (struct Gadget *) o, ged, ginfo, rp);
            }
    #else
            /* MorphOS, AROS, AmigaOS4 */
            ged->flags &= ~FORCE_REFRESH;

            /* Render the text into the 24-bit PixelArray */
            if (ginfo && ((struct Gadget *) o)->GadgetText)
                RenderGadText( (struct Gadget *) o, ged, ginfo, rp);

            /* ...and bring it to the display */
            #if !defined(__AROS__)
            ClipBlit( &ged->rp, 0, 0,
                      rp,
                      gad->LeftEdge, gad->TopEdge,
                      gad->Width, gad->Height,
                      0xC0);    /* Cookie cut */
            #else   /* AROS has got serious problems with the destination
                       RastPort, Layer respectively */
            x = ginfo->gi_Window->LeftEdge;
            y = ginfo->gi_Window->TopEdge;
            BltBitMap( ged->bm, 0, 0,
                      rp->BitMap,
                      gad->LeftEdge + x, gad->TopEdge + y,
                      gad->Width, gad->Height,
                      0xC0,         /* Cookie cut */
                      ~0,           /* All BitPlanes */
                      NULL);        /* No temporary allocated raster */
            /* Using either ClipBlit, BltBitMapRastPort and alike functions
               under AROS result in a complete lockdown of Intuition! */
            #endif

            ged->oldX = 0;
            ged->newX = 0;
    #endif
        }
        else    /* Normal button, render text directly to the display */
        {
            if (ginfo && ((struct Gadget *) o)->GadgetText)
                RenderGadText( (struct Gadget *) o, ged, ginfo, rp);
        }
    }
    else
    {
        #ifdef DEBUG
        kprintf( "GM_RENDER: No Rastport!\n");
        #endif
    }

    retval = ANYTHING;
}
break;



Bei der Verwendung aus einer eigenen BOOPSI-Klasse heraus, die mittels ClipBlit() oder BltBitMapRastPort() eine Off-Screen-Bitmap (RGB24) ins entsprechende Fenster zeichnen will (GM_RENDER), hängt sich das System unter AROS auf. Unter AmigaOS3, MorphOS und AmigaOS4 hingegen nicht.
Abhilfe schafft hier nur das Umgehen der Layer-basierenden Zeichenmethoden, also das direkte Zeichnen in die On-Screen-Bitmap mittels BltBitMap(), unter Verwendung von "rp->BitMap" und manuelles addieren der Offsets (entnommen von gi_Window). Dabei kann es aber passieren, dass beim verkleinern des betreffenden Fensters über die Fenstergrenze hinaus gezeichnet wird… Unschön, aber derzeit nicht anders möglich...

Ist so auch als Bug-Report von mir gepostet worden.

[ - Antworten - Zitieren - Direktlink - ]

29.04.2013, 20:54 Uhr

Georg
Posts: 107
Nutzer
@jolo:

Ich schau' mir das mal die nächsen Tage an. Hängt das jedesmal wenn ClipBlit oder BltBitMapRastPort() in GM_RENDER benutzt wird, oder nur in best. Situationen (z. B. Fenster Vergrößern oder Verschieben wenn es ein SIMPLE REFRESH Fenster ist)? btw: innerhalb eines BeginRefresh()/EndRefresh() keine Funktionen benutzen die direkt/indirekt Gadget Rendern auslösen können!


[ - Antworten - Zitieren - Direktlink - ]

29.04.2013, 21:21 Uhr

wawa
Posts: 314
Nutzer
@jolo:
Zitat:
Hier ist der Code, aber ich glaube kaum, dass Du mit diesem was anfangen kannst, daher beschreibe ich unten das Problem.

super, danke!

@georg
danke! na dann hat es vielleich doch zu was geführt. was jolo beschreibt ist nämlich wirklich in vieler hinsich ein problem, es hört sich so an als wenn fix an dieser stelle einige vordergründig nicht zusammenhängende erscheinungen beseitigt die beim fenster-zeichnen in aros sehr nervig sind.

@jolo
Zitat:
Das SDK selber wird nicht ohne weiteres unter 'vbcc' verwendbar sein, da es maßgeschneidert für 'gcc' ist. Wäre man in 2005(?) auf Frank Willes Anregungen eingegangen und hätte das SDK so erweitert, dass die Compiler-spezifischen Sachen in Unterverzeichnisse gewandert wären, hätte sich das für mich leidige Thema "AROS is programmable only by means of the gcc-compiler!" erübrigt.
das könnte jetzt mit v1 nachgeholt werden. mann musste nur bischen vehementen lobbing dafür betreiben, und jemand musste vbcc seite/port maintainen. ich wäre dafür, insbesondere wegen 68k und ich habe das gefühl es würden sich noch manche finden, die frage ist eher wer soll das tun...

kann man aros mit vbcc erwartungsgemäss wirklich bauen? das bedeutet ja dass der toolchain vbcc mit allen benötigten link libs und alles was dazu gehört sich kompilieren liesse. meinst du wirklich, das lässt sich machen, denn wenn ja wäre das vielleicht das ideale um aros auf aros zu bauen?

[ - Antworten - Zitieren - Direktlink - ]

29.04.2013, 21:35 Uhr

Floppy
Posts: 392
Nutzer
Zitat:
Original von jolo:
Bei der Verwendung aus einer eigenen BOOPSI-Klasse heraus, die mittels ClipBlit() oder BltBitMapRastPort() eine Off-Screen-Bitmap (RGB24) ins entsprechende Fenster zeichnen will (GM_RENDER), hängt sich das System unter AROS auf. Unter AmigaOS3, MorphOS und AmigaOS4 hingegen nicht.
Abhilfe schafft hier nur das Umgehen der Layer-basierenden Zeichenmethoden, also das direkte Zeichnen in die On-Screen-Bitmap mittels BltBitMap(), unter Verwendung von "rp->BitMap" und manuelles addieren der Offsets (entnommen von gi_Window). Dabei kann es aber passieren, dass beim verkleinern des betreffenden Fensters über die Fenstergrenze hinaus gezeichnet wird… Unschön, aber derzeit nicht anders möglich...

Ist so auch als Bug-Report von mir gepostet worden.


Auch von meiner Seite danke fürs Erklären. Ich habe Deinen Bugreport aus 2011 jetzt auch gefunden. Da wäre ein Code-Schnipsel wahrscheinlich auch besser gewesen zum Verständnis, aber ich glaube bei Georg ist das jetzt erst einmal gut aufgehoben. :)

[ - Antworten - Zitieren - Direktlink - ]

29.04.2013, 22:02 Uhr

Floppy
Posts: 392
Nutzer
Zitat:
Original von wawa:
@jolo
Zitat:
Das SDK selber wird nicht ohne weiteres unter 'vbcc' verwendbar sein, da es maßgeschneidert für 'gcc' ist. Wäre man in 2005(?) auf Frank Willes Anregungen eingegangen und hätte das SDK so erweitert, dass die Compiler-spezifischen Sachen in Unterverzeichnisse gewandert wären, hätte sich das für mich leidige Thema "AROS is programmable only by means of the gcc-compiler!" erübrigt.
das könnte jetzt mit v1 nachgeholt werden. mann musste nur bischen vehementen lobbing dafür betreiben, und jemand musste vbcc seite/port maintainen. ich wäre dafür, insbesondere wegen 68k und ich habe das gefühl es würden sich noch manche finden, die frage ist eher wer soll das tun...

kann man aros mit vbcc erwartungsgemäss wirklich bauen? das bedeutet ja dass der toolchain vbcc mit allen benötigten link libs und alles was dazu gehört sich kompilieren liesse. meinst du wirklich, das lässt sich machen, denn wenn ja wäre das vielleicht das ideale um aros auf aros zu bauen?


Das Problem ist wie so oft, einfach nur die Zeit der Devs. Jason hat gerade überhaupt keine Zeit für AROS...

Die Erklärung mit einfach nur etwas in Unterverzeichnisse schieben, klingt mir zu einfach. Das hätte bestimmt schon jemand gemacht. Hier wird das viel aufwändiger beschrieben:
http://en.wikibooks.org/wiki/Aros/Platforms/68k_support/Developer/Compiler#VBCC

[ - Antworten - Zitieren - Direktlink - ]

29.04.2013, 22:21 Uhr

Der_Wanderer
Posts: 1229
Nutzer
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. ]

[ - Antworten - Zitieren - Direktlink - ]

29.04.2013, 22:24 Uhr

wawa
Posts: 314
Nutzer
@Floppy:
Zitat:
http://en.wikibooks.org/wiki/Aros/Platforms/68k_support/Developer/Compiler#VBCC
ist frank wille informiert?
olaf, oder whomever interessiert, könnt ihr matthey auf amiga-coding oder natami.net darauf ansprechen was er darüber denkt. matt hat fran beim vasm unterstützt und ist gut 68k asm versiert. ich kenn ihn, er wird sicher interesse haben da er auch 68k fan ist aros vbcc kompilierbar zu machen. er kennt sich aber nicht so gut in c aus.

[ - Antworten - Zitieren - Direktlink - ]

29.04.2013, 22:26 Uhr

wawa
Posts: 314
Nutzer
@Der_Wanderer:
Zitat:
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.
du bist vielleicht auf der spur eines bugs, falls du näheres herausfindest muss man am besten deadwood (krzysztof smiechowicz) benachrichtigen. kann ich machen.

[ - Antworten - Zitieren - Direktlink - ]

30.04.2013, 10:09 Uhr

Georg
Posts: 107
Nutzer
@jolo:

Also ich hab' das hier (ABI V0) getestet und sowohl BltBitMapRastPort() als auch ClipBlit() funktionieren in GM_RENDER.

Hab' zum Testen das Rendering der Button Images in der asl.library (workbench/libs/asl/buttonclass.c/AslButton__GM_RENDER()) geändert von WriteLUTPixelArray() zu:

tempbm = AllocBitMap(w,h,0,0,msg->gpr_RPort->BitMap);
InitRastPort(&temprp);
temprp.BitMap = tempbm;
WriteLUTPixelArray(... , &temprp, ...);

BltBitMapRastPort(tempbm, ...) bzw.
ClipBlit(&temprp, ...)


Und andere BOOPSI Klassen in AROS benutzen BltBitMapRastPort() oder ähnliches in GM_RENDER ja eh' auch, wie z. B. das colorwheel Gadget oder der picture.datatype.


[ - Antworten - Zitieren - Direktlink - ]

30.04.2013, 10:13 Uhr

Georg
Posts: 107
Nutzer
@Der_Wanderer:

Überprüf mal ob die zurückgegebenen Werte im BitMapHeader (bmhdp) stimmen/Sinn machen.

Versuch' mal ein kleines Test Programm das NewDTObject(), ..., PDTM_READPIXELARRAY macht wie beschrieben, aber als C Programm mit gcc kompiliert, nicht AmiBlitz.


[ - Antworten - Zitieren - Direktlink - ]


1 -2- 3 [ - Beitrag schreiben - ]


amiga-news.de Forum > AROS und Amiga-Emulatoren > AROS, doch noch so instabil ?! [ - Suche - Neue Beiträge - Registrieren - Login - ]


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