Zitat:

---

Original von Maja:

Und dann noch zu dem, was in Deinem Beitrag von Dir stammt:
> Mac OS X kaufen, das System macht die Upadtes automatisch !
> Dazu brauche ich kein Online-Medien oder Print-Magazine.

Diese Aussage trifft auf Windows gleichermaßen zu. Nun hat OS4 aber nun mal keine Online-Update-Funktion. So what?

Hatte ja schon die Frage in den Raum gestellt, ob es nicht vielleicht sinnvoll wäre, eine solche Funktion in OS4 zu implementieren.

---

Sowas ist schon in Arbeit, sogar in mehreren "Geschmacksrichtungen" Da allerdings wenig Hardware für die Entwickler zur Verfügung steht, käme was Neues gerade recht. Mal sehen, was die Italiener da reißen können...

Zitat:

---

Allerdings wollte ich dabei keinen OS4-User zu Windows "missionieren".

---

Dürfte auch schwierig werden

Grüße

--
---

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

Zitat:

---

Original von DariusBrewka:
Wäre nicht Schlecht, ansonsten werde ich auf IFF ausweichen und DataTypes nutzen, wie gesagt unter AROS kann ich auch mit Datatypes JPEGS speichern, wäre schön wenn das auch unter OS4 ginge.

---

Das ist eine Frage des Datatypes. Soweit ich weiß, gibts auch für die 68K-Systeme kein Datatype, das JPEG speichern kann. Vielleicht die akDatatypes, aber genau weiß ich das auch nicht. Ich habe immer nur IFF verwendet

Grüße

--
---

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

Zitat:

---

Original von DariusBrewka:
Ich habe kein OS4, wie greife ich auf 68k libraries zu? ich habe halt nur die 68k Includes und das Programm ist ansonsten PPC native.

---

Bei 68K-Code wie gewohnt, für PPC-Code muß für die 68K-Library noch eine Datei mit Glue-Code für die Library vorhanden sein (mit Endung .l.main, die stellt das Library Interface "main" für OS4-PPC-Code zur Verfügung).

Ich schau nachher mal, ob ich das Zeug für die jpeg.library irgendwo rumsegeln hab. Ansonsten müßte das mittels idltool erzeugbar sein.

Grüße


--
---

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

Zitat:

---

Original von DariusBrewka:
Gibt es eine einfache Möglichkeit unter OS4 jpegs zu specihern?, mit Datatypes wie unter AROS geht's leider nicht und die jpeg.library wie ich die unter OS3.x nutze gehts wohl auch nicht, da es diese für OS4 nicht gibt.

---

Mit der 68K-Variante sollte es aber gehen. PerfectPaint benutzt auch jpeg.library, soweit ich weiß, und das tut unter OOS4 inzwischen. Im Zweifel kannst Du mir ja ein Testprogramm schicken, dann probiere ich das aus.

Grüße

--
---

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

code:

---

WHILE myseconds%<20
        POKEW tr& + tr_node% + IORequestio_Command%, TR_GETSYSTIME&
        junk& = DoIO&(tr&)

        mymicros&=PEEKL(tr& + tr_time% + tv_micro%)
        mysecs&=PEEKL(tr& + tr_time% + tv_secs%) REM So!

        POKEW tr& + tr_node% + IORequestio_Command%, TR_ADDREQUEST&
        
        POKEL tr& + tr_node% + tv_secs%, mysecs& REM und so!
        POKEL tr& + tr_time% + tv_micro%, mymicros&+125& REM 125=8000Hz

        SendIO&(tr&)
        INCR mycount%:IF mycount%=8000 THEN mycount%=0:INCR myseconds% rem :move rpS&,20,25:Text rpS&, SADD(TIME$+CHR$(0)),8
        REM bla%=goertzel%((PEEKB(&hBFE101) - 127)<<8)
        junk& = WaitIO&(tr&) REM junk% = finish_wait(tr&)
      WEND

---

Du solltest Dich noch mal kundig machen, wofür die Struktur-Einträge gut sind und was sie bedeuten.

Grüße

--
---

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


[ Dieser Beitrag wurde von whose am 10.09.2006 um 14:07 Uhr geändert. ]

Zitat:

---

Original von bernd_roesch:

>Kein Heckmeck mit "unpassenden" Erweiterungen, wo man ewig lange auf Treiber warten muß. Das Ding läuft, gut ist.

naja was gibts denn für erweiterungen für den micro aone.Wo nix reinzubauen geht kann es auch keine Probleme geben.
schmeis halt in deinem PC alle steckkarten und sonstiges raus,was der microaone nicht hat dann haste auch keine Probleme.

---

Also, es wäre schon cool, wenn Du bei den Zitaten angibst, von wem sie stammen. Da war zwischendurch mal ein Teil von Maja drin, es liest sich aber so, als gehörte das zu meinem Posting

Zum Thema Erweiterungen: Ich hatte in der Zwischenzeit im µA1 mal eine Terratec Audiokarte und eine Envy zum Testen. Zur Zeit tut ein SII 0680 seinen Dienst. Also geht da was einzubauen

Beim Amithlon gabs bei mir vor allem Streß mit den Netzwerkkarten. RTL8039 kriegte ich nie zum Laufen, warum auch immer. Ne olle 8029 wollte auf Anhieb, aber das war irgendwie doof. Da hat man schon nen 1,6GHz Athlon und das Netzwerk läuft nur mit 10MBit. Andere Hersteller waren erst Recht keine Option, es gab ja keine Treiber

Von dem GraKa-Theater mal gar nicht zu reden. Die GeForce2 war zu dem Zeitpunkt, wo ich den Amithlon mal ernsthaft aufgesetzt habe, kaum zu bekommen. Ich habe mir dann mit einer Uralt-TNT2 vom Grabbeltisch aufm Flohmarkt geholfen, weil alles andere No-Op war. Keine Treiber.

Für mich war all das der Grund, Amithlon Amithlon sein zu lassen und statt dessen auf WinUAE zu setzen. Da mußte ich nicht viel basteln und rumprobieren, das Teil läuft. Egal, welche Netzwerkkarte oder Grafikkarte. Genau wie beim µA1. Der läuft, ohne Zicken, ohne irgendwelche Experimente. Und ich kann dir aus meiner H&P-Support-Zeit versichern, daß ich nicht der einzige mit den Amithlon-Sorgen war.

Im Prinzip war die Idee von Amithlon nicht schlecht, aber die Ausführung war lange nicht so gut, wie sie hätte sein müssen, um ein Kassenschlager zu werden. Der Zug ist ja nun abgefahren (Amithlon ist nicht mehr erhältlich, es sei denn gebraucht oder gar als Raubkopie) und im Endeffekt hat das Desaster auch gezeigt, das und vor allem warum x86 keine wirkliche Option ist. Meine Meinung.

Grüße

--
---

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

Zitat:

---

Original von Andreas_B:

@whose
>> Zumindest ein ADF für die Workbench samt HDToolBox
>> müßtest Du auf Deinem echten Amiga produzieren

Das ist nicht korrekt:
http://thomas-rapp.homepage.t-online.de/os39uae/

---

Wenn er statt OS3.9 z.B. ein AmiKit-System aufsetzen will, braucht er auch eine Workbench, da AmiKit bestimmte Teile davon installiert, sofern man es nicht mit OS3.9 zusammen aufsetzen will. Besser, er bereitet das einmal vor

Zitat:

---

>> Man kann WinUAE aber auch "tunen"

Man kann auch einfach die Prozesspriorität absenken, wenn man nicht mit WinUAE arbeitet. Aber auch so stört WinUAE nicht mal großartig meinen Pentium 700 bei flüssiger Arbeit wenn es minimiert ist.

---

Eben aus dem Grund. Standardmäßig geht WinUAE mit der Priorität runter, wenn es minimiert ist. Wäre das nicht der Fall, würde der Pentium 700 ziemlich "einknicken".

Grüße

--
---

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

Zitat:

---

Original von MaikG:
>Allein das ist schon merkwürdig. Die Textausgaben kosten eine Menge
>Zeit, da sollte sich ein Weglassen schon bemerkbar machen.

1x Pro Sekunde die Zeit über Intuition ausgeben kostet nicht
viel Zeit. Dann würde das Programm ja auch querschlagen wenn ich
Clock auf der WB hätte...

---

Zitat:

---

>Einen Request mit TR_GETSYSTIME schicken, das Ergebnis + 125 micros
>in den IOrequest eintragen, weg damit zum timer.device, warten.

Okay, das muss ich mal probieren.

---

Nicht vergessen, aus TR_GETSYSTIME dann TR_ADDREQUEST zu machen. Oder, noch besser, mit zwei IORequests arbeiten.

Grüße

--
---

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

Zitat:

---

Original von Daniel01:
Hallo allerseits,

nun, den PC habe ich nun ab und an mal eingeschaltet und auch das eine oder andere male im Internet damit geschaut.

Nur richtig anfreunden kann ich mich nicht mit dem PC. Ständig gehen im Internet irgend welche Nervfenster auf mit Warnungen (vermutlich Cockies) oder wegen Sicheren Verbindungen oder das er sich sonst was runter laden will das dies wirklich nicht im geringsten mehr Spaß macht.
Habe auch bemerkt, das selbst mit 3.22 GHz der PC im Internet nich weltbewegend schneller ist als der Amiga. Und ich benutze DSL 6000!

---

Ja, was nützt die dickste Pipeline, wenn man nur ne Gieskanne voll Öl vom Lieferanten bekommt?

Zitat:

---

Wegen WinUAE, wäre ne überlegung wert, nur wo bekomme ich das her? Habe schon mal im Aminet gestöbert aber nix gefunden außer Bilder davon.

---

Zitat:

---

Und wenn ich das WinUAE dann habe, dann müßte ich dann doch auch die OS3.9 und MUI usw. auf dem PC install sonst funktionieren doch die AmigaProgs nicht einfach mal so auf nem PC ohne Workbench und ohne MUI? Funktioniert dann auch Opus?

---

Naja, das ist (für die Workbench) etwas komplexer. Zumindest ein ADF für die Workbench samt HDToolBox müßtest Du auf Deinem echten Amiga produzieren. Dann noch ein ROM-Image. Das ist aber recht gut erklärt in der Anleitung zu WinUAE/UAE.

Sobald das alles läuft, kannst Du ein Festplatten-Image (virtuelle Festplatte) einrichten und von CDROM OS3.9 darauf installieren. Oder eben WB 3.1 mit Hilfe von Disketten-Images der Installationsdisketten.

Der Rest funktioniert, wie Du es von Deinem Amiga her kennst. Sogar AWeb/IBrowse/Voyager kannst Du installieren und benutzen. Und natürlich auch das halbe Aminet leersaugen

Zitat:

---

Was sollte ich beachten und was müßte ich da noch alles install oder überhaupt alles Install wenn ich WinUAE benutze (sofern ich es überhaupt erst mal finde) das die Amigaprogramme auch auf dem PC laufen. Das die PPC Programme nicht auf dem PC laufen weis ich schon, aber die 060er müßten dann doch laufen wie z.B. Yam oder DOpus.

---

Eine sehr nette Sache in dem Zusammenhang ist AmiKit (habe den Link gerade nicht parat. Eine kleine Suche via AN-Suche oder Google dürfte da aber helfen ).

Wenn Du das noch dazu saugst und (laut Anleitung) installierst, hast Du n richtig nettes OS3.x-System mit allen denkbaren und undenkbaren Utilities/Tools drauf. Ich finds jedenfalls nicht schlecht.

Für die Arbeit habe ich allerdings ein OS3.9-System (ganz normal installiert), weil das doch auf einigen Schnickschnack verzichtet, der bei AmiKit standardmäßig draufgeschmissen wird. Im Fenster-Modus von WinUAE läuft das doch etwas flotter, als ein vollständiges AmiKit-System.

Und nein, Windoof wird von WinUAE nicht "kastriert". Wenn WinUAE den Fokus hat, läufts etwas hakeliger, das ist aber auch alles. Man kann WinUAE aber auch "tunen", so daß Windoof von der Emulations-Arbeit nicht allzu sehr beeinträchtigt wird, was das Tempo angeht.

Grüße

--
---

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


[ Dieser Beitrag wurde von whose am 09.09.2006 um 02:34 Uhr geändert. ]

Zitat:

---

Original von MaikG:

>Ich vermute, daß irgendwo zu viel Zeit verplempert wird,
>bevor der Timer neu gestartet wird. Das muß sehr flott gehen,
>alles andere kann und muss warten.

Nee, ich kann zwischen SendIO und WaitIO alles rausnehmen, trotzdem
ist das saulahm und liefert keine korrekten werte.
125 wird nicht ganz erreicht, gebe ich z.B. 25 ein wird die
gleiche Zeit benötigt.

---

Zitat:

---

>Im BASIC-Programm dürften die Textausgaben störend wirken, nun weiß
>ich nicht, wie viele davon schon zu Testzwecken weggelassen wurden,
>um das Ganze schneller zu kriegen. Da dürfte auf jeden Fall noch
>was zu holen sein.

Ich habe die Textausgaben zu 100% weggelassen, das macht gar keinen
unterschied.

---

Zitat:

---

>Und da ich in meinem C-Programm mittels WAIT_UNTIL auf die
>vorberechnete Zeit gewartet habe, kann es gar nicht am Verplempern
>der Zeit liegen, weil der Request ja sofort zurückkommen müsste,
>wenn der angegebene Zeitpunkt schon überschritten ist. Es seit denn,
>der timer selber ist langsamer geworden.

WaitUntil ist wie MircoHZ, kein unterschied, allerdings verstehe
ich das mit der vorberechneten Zeit nicht.

---

Einen Request mit TR_GETSYSTIME schicken, das Ergebnis + 125 micros in den IOrequest eintragen, weg damit zum timer.device, warten.

Grüße

--
---

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

Zitat:

---

Original von Holger:

Zitat:

---

Original von whose:
125 µHz liefern die CIA-Timer relativ problemlos und selbst bei hoher Last ohne große Drift. Viele AHI-Treiber z.B. benutzen diese Timer. Ich vermute, daß irgendwo zu viel Zeit verplempert wird, bevor der Timer neu gestartet wird. Das muß sehr flott gehen, alles andere kann und muss warten.

Ich weiß auch nicht, ob es so sonderlich genial ist, ein WaitIO() vor den Neustart des Timers zu setzen (C-Variante). Das würde ich mal weglassen.

---

Man MUSS den gesendeten Request wieder abholen, bevor man ihn erneut versendet. Und jedesmal einen neuen Request anlegen, wäre genauso unsinnig, dann läuft der Speicher voll. Also auf die Antwort MUSS man warten, ob nun via WaitIO oder WaitPort/GetMsg ist gehupft wie gesprungen.

---

Zitat:

---

Und da ich in meinem C-Programm mittels WAIT_UNTIL auf die vorberechnete Zeit gewartet habe, kann es gar nicht am Verplempern der Zeit liegen, weil der Request ja sofort zurückkommen müsste, wenn der angegebene Zeitpunkt schon überschritten ist. Es seit denn, der timer selber ist langsamer geworden.

---

Zitat:

---

An dem Rest des Programms kanns ja nicht liegen, der rennt, wenn man den timer weglässt, in einem zehntel der Zeit durch.

---

Ja und? Was heißt das? Ich weiß nur, daß die Timer recht genau laufen, auch bei sehr kleinen Zeitabschnitten. Die Drift wird erst dann sehr hoch, wenn ein anderer Task fast 100% der Systemzeit bekommt/frißt. Die Drift kann dabei in beide Richtungen laufen.

Wenns denn unbedingt sein muß, nutz doch mal die Zähler der CIA direkt. Irgendwo in den RKMs geistert ein Beispiel dafür rum, wie man das macht. Dann siehst Du ja, ob die Timer tatsächlich "langsamer" werden. Ich glaube da nicht so wirklich dran.

Grüße

--
---

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

Zitat:

---

Original von Holger:

Zitat:

---

Original von whose:
@Holger:
Und welches System ist das genau? Zumindest hast Du damit gezeigt, daß die von Dir befürchtete "Inkompatibilität" nicht (mehr) besteht. Obwohl ich dieses Funktionieren eher als Workaround betrachten würde.

---

AOS3.9
Ich sehe das nicht als Workaround, es ging ja nur um die Frage, ob die Funktion exakt so, wie dokumentiert, funktioniert, also die Maske lediglich die gleiche bytesPerRow aufweisen muss, oder ob man tatsächlich pro Bitplane die Maskendaten wiederholen muss.

---

Zitat:

---

Das Problem der Speicherverschwendung löst sich dadurch nicht.
Es sei denn, man hat bis zu acht gleich große Bilder, dann könnte man die zugehörigen Masken verzahnt im Speicher ablegen.

---

Hm, da hast Du eine interessante Idee ins Spiel gebracht... ich notier mir das mal

Zitat:

---

Zitat:

---

Hast Du das Programm mal auf nem "echten" AGA-Amiga getestet?

---

Was heisst echt?
Ich habe von einer Interleaved BitMap auf eine Interleaved BitMap (Workbench 256Farben) kopiert.
Dass der AGA-Chip von UAE emuliert wurde, halte ich nicht für relevant. Der verhält sich exakt so, wie die Software, in diesem Fall die graphics.library, ihm befiehlt. Sonst würden die Spiele kaum funktionieren, wenn die Behandlung von Modulo und Masken in der Blitteremulation nicht exakt wäre.

---

Das ist richtig. Ich meinte allerdings mehr einen bspw. A1200, wie er zum Spielen gern verwendet wird. Also ohne OS3.9 und ohne P96. Darauf dürfte Dein Programm wahrscheinlich Probleme machen. Für Spiele (die kommerziellen Titel vor allem) ist die graphics.library wohl auch nicht so sehr von Belang. Selbst viele PD-Titel haben die fürs Blitten außen vor gelassen.

Die Geschichte wurde von Darius, malte2 und georg ja nicht nur so aus Spaß erwähnt...

Um mal wieder aufs letzte Thema zu kommen: Gibts eigentlich Informationen darüber, welche GraKas WaitTOF() bzw. WaitBOVP() in Hardware unterstützen oder wie die Emulation dieser Funktionen per Software genau funktioniert? Es ist irgendwie lästig, daß man sich nie sicher sein kann, ob eine Grafik flackerfrei auf den Bildschirm kommt, je nach System.

Grüße

--
---

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

Zitat:

---

Original von bubblebobble:
Ich denke das mit den Bitmasks haben jetzt alle verstanden.

Was haltet ihr denn von WaitBOVP() ?

WaitBOVP() scheint unter WinUAE nur gefakted zu sein, und stimmt nicht 100% mit dem Monitor VSync überein. Dadruch hat man einen versatz z.B. bei horizontalem scrolling. Ist aber immer noch besser und "stabile" snzuschauen als wenn man willkürlich den Bilschirm updated. Aber vielleicht ist es ja auch anderen Systemen korrekt.
(vielleicht auch überhaupt nicht,und bringt nur den Standard 50Hz, der nichts mit dem heutigen Monitoren zu tun hat.)

---

Das ist auch bei CGFX/P96 auf 68K-Maschinen und GraKa so. WaitBOVP() ist auf GraKas nicht zu gebrauchen (ist das technisch überhaupt machbar? Da war doch irgendwas, daß der Copper für den BOVP-Sync zuständig ist?).

Wie das für WaitTOF() aussieht, kann ich nicht genau sagen, das scheint aber zu funktionieren, da die DB-Funktionen des OS einwandfrei ihren Dienst tun (wenn auch etwas komplex zu handhaben). Bisher ist mir dabei noch kein Geflacker begegnet.

Grüße

--
---

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

Zitat:

---

Original von Mad_Dog:

Zitat:

---

Original von whose:

Es kann natürlich sein, daß UNIT_MICROHZ in den MB-Includes nicht korrekt definiert wurde. Ansonsten stellt es aber kein wirklich großes Problem dar, diesen (in C normalerweise als int-Konstante angegebenen) Wert in ein MB-Long zu packen.

---

Falls x& in MaxonBasic "Adresse von x" bedeudet, dann wird statt dem gewünschten Wert die Adresse übergeben, wo der Wert im Speicher steht. Was dann dauskommen würde, wäre ein Zufallsergebnis.

---

Ja, falls. Wenn Du Dir den Rest des MB-Programms ansiehst, wird Dir & als Bezeichnerteil noch öfter begegnen. Daher vermute ich ganz stark, daß & einen long-Wert bezeichnet und MB keine Zeiger als Typ kennt.

Grüße

--
---

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


[ Dieser Beitrag wurde von whose am 06.09.2006 um 11:30 Uhr geändert. ]

Zitat:

---

Original von Mad_Dog:
Ich kenn mich mit MaxonBasic zwar nicht aus (hatte damals AMOS ), aber mir sieht das mehr nach nem Zeiger aus. Womöglich funktioniert deshalb der Timer hier nicht. UNIT_MICROHZ ist (in C) nur eine symbolische Konstante für einen int-Wert.

---

Ich kenne mich mit MB auch nicht so aus (AmigaBASIC bzw. ACE waren meine letzten BASIC-Erfahrungen auf dem Amiga)

Es kann natürlich sein, daß UNIT_MICROHZ in den MB-Includes nicht korrekt definiert wurde. Ansonsten stellt es aber kein wirklich großes Problem dar, diesen (in C normalerweise als int-Konstante angegebenen) Wert in ein MB-Long zu packen. Die Prototypen in C zeigen für OpenDevice() jedenfalls ein ULONG für die Unit, insofern sollte das passen.

Zeiger kennt MB meines Wissens nach auch nicht (gibts außer Blitz eigentlich einen Dialekt, der Zeiger direkt unterstützt?), ich gehe daher davon aus, daß auch Zeigerwerte (sinnvollerweise) in einer long-Variablen landen. Technisch ist das ja kein Unterschied und wäre in C (mit Cast) genauso machbar, wenn auch sehr unschön

Grüße

--
---

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

Zitat:

---

Original von Mad_Dog:

Zitat:

---

Original von Holger:

code:

---

r& = OpenDevice&(SADD("timer.device" + CHR$(0)), UNIT_MICROHZ&, timerIO&, 0)

---

---

Bist Du sicher, daß das so richtig ist? Was bedeutet "&" in MaxonBasic? UNIT_MICROHZ ist eine Konstante.

---

& bedeutet long, wenn ich mich nicht irre. Und die Includes sind für Basic etwas anders aufgebaut, einen Präprozessor scheints bei MaxonBasic nicht zu geben. Daher behilft man sich wohl mit long-Variablen, evtl. in Form von const UNIT_MICROHZ& = ...

Grüße

--
---

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

Zitat:

---

Original von DariusBrewka:

Zitat:

---

Original von whose:
@DariusBrewka:

Ich glaube, nun hab ichs, worauf Du hinauswillst. Die Tatsache, daß die Vor-OS3.5-Icons keine Maske "transportieren", oder?

---

Nee, wie kommst du darauf? Ich wollte mit dem Icon zeux nur zeigen das Funktionen Quark sind die Masken liefern, da die Masken wie es wohl sein wird Ursprünglich verschieden sind ob man Interleaved Targets oder nicht hat. Wenn ich jetzt eine solche Maske habe und Beispielweise auf eine 3.x WB (defaultmäßig Interleaved) blitte müßte ich ein anderes Resultat erhalten als wenn ich auf einen NON-Interleaved Screen blitte. Daraus habe Ich den Schluß gezogen dass die Masken gleich sein müssen, ansonsten müsste man immer mit angeben ob man Interleaved oder Nichtinterleaved Masken haben will, das Kann ich NICHT, d.h. die Maske wird in einem beider Formate geliefert. Ich kann das Image aber mit DrawIconStateA() etc malen und diese Funktioniert auf jedem Screen / RastPort, da diese Funktion nichts umblitten kann (s.o.) und BltMaskBitMapXXX() auch nicht funktioniert, muß diese das Bild irgendwie per Hand maskieren.

---

Ach so... ja, in die Falle laufe ich auch dauernd. Holger sagte es mir ja schon: Wichtig ist die Auslegung der Quell-Bitmap, nicht die des Ziels. Also sind die von den Icon-Funktionen gelieferten Masken schon korrekt und sollten die richtigen Ergebnisse beim Blitten bringen.

Das Problem "Interleaved" stellt sich immer dann, wenn man innerhalb einer Bitmap "herumblittet" und die Quelle sowie die dazugehörige Maske nicht "selbst gebaut" hat bzw. die Maske zu der "fremden" Quelle bauen muß.

Grüße

--
---

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

Zitat:

---

Original von Holger:

Zitat:

---

Original von whose:
Die sollten normalerweise die korrekten Masken liefern. Ich hab mich mit den Icon-Funktionen noch nicht beschäftigt. Haben die denn kein Argument alá Friend bei AllocBitmap()? Also eine Angabe, für welchen Screen man die Maske gerne hätte?

---

Wozu?
Die Maske muss korrekt an die QuellBitMap angepasst sein, also die des Icons.

---

Argh... ja, ich mal wieder...

Dann verstehe ich Darius' Probleme mit den Icon-Masken allerdings nicht.

Grüße

--
---

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

Zitat:

---

Original von Holger:

Zitat:

---

Original von whose:
Autodocs, intuition/screens.h, Tag SA_INTERLEAVED. Defaults to: FALSE.

---

Ja, aber Du kannst der AOS3.x Workbench ruhig zutrauen, das Tag mit einem anderen Wert an OpenScreen zu übergeben. Oder hast Du nur das mit dem default (für die Workbench!) missverstanden?

---

Zitat:

---

Zitat:

---

Wäre auch reichlich gemein, wo das doch ein "New for OS3.1/AGA"-Feature ist, wenn es Default wäre. Das würde alle Programme, die den Blitter benutzen und Bitmaps für Blitmasken auf dem OS1.x-Weg anlegen, vor die Wand rennen lassen.

---

Da würde ja lediglich Blits mit dem Screen als Quelle betreffen (die eher die Ausnahme sind). Und wenn man bytesPerRow korrekt berücksichtigt, gibt es die Probleme ja gar nicht. Aber CustomScreens haben trotzdem den default {SA_INTERLEAVED, FALSE}.

---

Hm, das würde also bedeuten, daß Programme, die auf der WB laufen und innerhalb ihres Fensters mittels Blitter und Blitmaske z.B. Grafik "verschieben", versagen, sofern sie auf "altväterlichem" Weg die Maske anlegen? Wenn ja, sollte ich mir das dringend notieren, weil ich so ein Programm in Arbeit habe, das evtl. auch auf OS3.0/3.1 laufen soll...

Grüße

--
---

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

Zitat:

---

Original von DariusBrewka:

Zitat:

---

Original von whose:
Meines Wissens nach läuft die Workbench auch auf einem normalen Screen, wenn nicht dran "gedreht" wurde. Überprüfen kann man das mit Darius' Hinweis auf das "Flackern" (bei hoher Farbtiefe), ohne großen Aufwand. Flackert ein normalgroßes Piktogramm beim Anklicken (ggf. mal auf mehr als 32 Farben stellen), ist es definitiv nicht interleaved.

---

??? Also da ist mir schon der Aufwand zu hoch den ScreenSelector aufzurufen um einen AGA/ECS Screen zu öffnen. Wie Georg schon erwähnt hat, wird es wohl so vorgesehen sein dass man die Zeilen doppelt für Masken, aber glücklich ist das IMHO nicht insbesondere dann wenn man Systemfunktionen hat, die Masken liefern (z.B. IconControl()).

---

Zitat:

---

Damit brauchen Masken für Interleaved Images ebenso viel Speicher wie das Image selber, dann lieber ARGB.

---

Naja, einen Nachteil muß die Methode haben. Es gibt halt eher selten etwas, das nur Vorteile hat. Abgesehen davon muß man ja nicht zwingend mit Interleaved-Screens arbeiten, wenns ums Speicher sparen geht. Im Grunde hast Du aber Recht, die Planargrafik war letztendlich nicht der Weisheit letzter Schluß. Und AAA sollte ja Chunky-Grafik bringen, die wir nun mit den GraKas haben.

Grüße

--
---

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