amiga-news DEUTSCHE VERSION
.
Links| Forums| Comments| Report news
.
Chat| Polls| Newsticker| Archive
.

amiga-news.de Forum > Programmierung > Anzahl der Farben unter Hi/True Color [ - Search - New posts - Register - Login - ]

-1- [ - Post reply - ]

2004-06-13, 15:55 h

DariusBrewka
Posts: 899
[Banned user] 		Unter cgx, p96 kann man ja einen Screen öffnen, welcher auf einem HI/TRUE Color Display erscheint (d.h. 2, 3 oder 4 Bytes hat), aber dennoch nur beispielweise 16 Pens unterstützt. Wie kann ich herausfinden ob man im Screenmoderequester dennoch mehr als 256 Farben eingestellt hat?

[ - Answer - Quote - Direct link - ]
2004-06-13, 18:33 h

Mazze
Posts: 263
User
code:
struct ScreenModeRequester
{
    ULONG sm_DisplayID;	   /* Display mode ID		       */
    ULONG sm_DisplayWidth;	   /* Width of display in pixels       */
    ULONG sm_DisplayHeight;	   /* Height of display in pixels      */
    UWORD sm_DisplayDepth;	   /* Number of bit-planes of display  */

Welcher Wert steht denn in sm_DisplayDepth? Ich bin jetzt zu faul, um es selbst auszuprobieren.

[ - Answer - Quote - Direct link - ]
2004-06-13, 23:29 h

DariusBrewka
Posts: 899
[Banned user] 		Es geht nicht so sehr um einen eigenen Screen zu öffnen, sondern um zu überprüfen, ob ein echter Hi/True-Color (PublicScreen) offen ist.

Ich kann mittels cgx/WritePixelArray() auf einen True/HiColor Screen zeichnen, wenn ich aber (zumindestens hier (WinUAE)) Hi/TrueColor PixelFormat einstelle mit ColorSlider mit weniger als der zum Mode eigentlich gehörenden Farben, so bleibt fast immer Trash übrig. ScreenDepth ist immer 15/16/24/oder 32 Bit unabhängig von der Anzahl der wirklich eingestellten Farben und ich weiss nicht, ob es so Sinnvoll ist, dort auch Hi/TrueColor zu zeichnen.

gruss

[ - Answer - Quote - Direct link - ]
2004-06-14, 01:36 h

Mazze
Posts: 263
User 		Jetzt bin ich platt.
Unter Amithlon ist der Farb-Regler bei 15/32-Bit Screens grau hinterlegt.
Aber unter WinUAE kann ich den Farbregler bei allen Modi verstellen. GetBitMapAttr(...depth) liefert aber nicht die eingestellte Tiefe zurück.


Um festzustellen, ob ein Paletten- oder ein Trucolor-Screen vorliegt, habe ich bisher immer mit GetBitMapAttr abgefragt, ob die BitMaptiefe größer oder kleiner gleich 8 ist. Sieht das jetzt bei WinUAE anders aus?

[ Dieser Beitrag wurde von Mazze am 14.06.2004 editiert. ]

[ - Answer - Quote - Direct link - ]
2004-06-14, 08:54 h

thomas
Posts: 7718
User
Das hat nichts mit WinUAE oder Amithlon zu tun. Bei OS3.9 ist der Regler fest, bei OS3.1 kannst du unsinnigerweise eine Tiefe einstellen. Ich bin mir nicht sicher, aber ich glaube, unter 16/24bit hat der Screen immer 256 Pens, egal, was man im Einsteller einstellt.

GetBitMapAttr(Screen->RastPort.BitMap,BMA_DEPTH) gibt jedenfalls immer 16 oder 24 aus (oder eben 8 oder kleiner). Das ist IMHO die richtige Methode, das abzufragen.

Ansonsten kannst du noch mit GetCyberMapAttr das Pixelformat abfragen.

Gruß Thomas
--
Email: thomas-rapp@web.de
Home: home.t-online.de/home/thomas-rapp/

[ - Answer - Quote - Direct link - ]
2004-06-14, 11:22 h

DariusBrewka
Posts: 899
[Banned user] 		Stimmt, unter OS3.9 kann ich die Anzahl der Farben nicht einstellen, aber ob das mit der Anzahl der Pens so stimmt bezweifele ich, denn wenn ich z.B. TurboText auf TrueColor öffne, kann mein Programm kein einzigen Pen mehr anfordern und bekanntlich? ist TurboText ein pen-fressendes Monster.

Es scheint aber, das man unter reqtools die Anzahl der Farben frei wählen kann, auch unter 3.9.

danke

[ - Answer - Quote - Direct link - ]
2004-06-14, 13:08 h

thomas
Posts: 7718
User 		Ich hab's gerade mal ausprobiert. Du bekommst immer so viele Pens, wie du als Tiefe eingestellt hast, aber nie mehr als 256.

Du kannst also einen 16bit-Modus mit zwei Farben einstellen. Sieht ziemlich seltsam aus, wenn die Workbench und die Fenster nur zweifarbig sind, aber das Hintergrundbild farbig angezeigt wird.

Hier ist mein Testprogramm:
code:
#include <proto/intuition.h>
#include <proto/graphics.h>
#include <proto/dos.h>

int main (void)

{
long i;
long n = 0;
struct ColorMap *cm;
short pen[256];
struct Screen *scr;

if (scr = LockPubScreen (NULL))
	{
	Printf ("screen depth = %ldn",GetBitMapAttr(scr->RastPort.BitMap,BMA_DEPTH));

	cm = scr->ViewPort.ColorMap;

	Printf ("max. number of pens = %ldn",cm->Count);

	for (i = 0; i < 256; i++)
		{
		pen[i] = ObtainPen (cm,-1,0,0,0,PEN_NO_SETCOLOR);
		if (pen[i] > 0)
			n ++;
		}

	Printf ("%ld pens allocatedn",n);

	for (i = 0; i < 256; i++)
		if (pen[i] >= 0)
			ReleasePen (cm,pen[i]);

	UnlockPubScreen (NULL,scr);
	}

return (0);
}

Gruß Thomas

--
Email: thomas-rapp@web.de
Home: home.t-online.de/home/thomas-rapp/

[ Dieser Beitrag wurde von thomas am 14.06.2004 editiert. ]

[ - Answer - Quote - Direct link - ]
2004-06-14, 14:00 h

DariusBrewka
Posts: 899
[Banned user] 		@thomas

Über die Colormap könnte es gehen, mein Problem war, dass ich auf diesen Screens Hi/TrueColor zeichnen will/kann/muss, mittels WritePixelArray(), aber wenn ich nur 4 Farben einstelle, so bleibt auf dem Screen manchmal müll übrig (Bunte Blöcke, so gross wie das mit WritePixelArray() gezeichnete).

Andererseits ist es ja auch nicht legal, >256 Farben zu zeichnen, wenn nur 4 Farben eigestellt sind, obwohl das Pixelformat das zulässt.

danke

[ - Answer - Quote - Direct link - ]
2004-06-14, 14:32 h

thomas
Posts: 7718
User
Zitat:
Andererseits ist es ja auch nicht legal, >256 Farben zu zeichnen, wenn nur 4 Farben eigestellt sind, obwohl das Pixelformat das zulässt.

Wo hast du denn diese Weisheit her ? WritePixelArray ist vollkommen unabhängig vom ColorMap-System.

Und was meinst du mit "bleibt Müll übrig" ? WritePixelArray beschreibt einen rechteckigen Bereich, wo soll da der Müll sein ?

Du darfst natürlich nicht mit ReadPixel an den Bereich drangehen, dann bekommst du "unpredictable results". D.h. ich glaube, es wird ein freier Pen zurückgeliefert, solange noch einer da ist.

Gruß Thomas
--
Email: thomas-rapp@web.de
Home: home.t-online.de/home/thomas-rapp/

[ - Answer - Quote - Direct link - ]
2004-06-14, 18:41 h

Mazze
Posts: 263
User 		Hmm, dann müssten da 2 Tiefeninformationen vom Screenmode-requester an den Screen übergeben werden. Steckt die echte (16/24/32) Tiefe in der Mode-ID?

[ - Answer - Quote - Direct link - ]
2004-06-14, 19:13 h

thomas
Posts: 7718
User
Zitat:
Steckt die echte (16/24/32) Tiefe in der Mode-ID?

Wenn der Modus z.B. "Radeon:1024x768 32bit BGRA" heißt, dann kannst du dir diese Frage sicher selbst beantworten, oder ?

Gruß Thomas

--
Email: thomas-rapp@web.de
Home: home.t-online.de/home/thomas-rapp/

[ - Answer - Quote - Direct link - ]
2004-06-15, 00:27 h

DariusBrewka
Posts: 899
[Banned user] 		@thomas

Nunja, ich öffne ein Fenster, zeichne mittels WritePixelArray() hinein, entferne das Fenster und Im Background bleibt Müll, aber nicht immer!, vieleicht aber auch nur bei WinUAE, wie auch anderes was nur bei WinUAE Probleme macht und man es deshalb nicht benutzen darf :-(.

Wenn ich in TurboText 32Bit einstelle, kann ich dennoch keinen Pen mehr allokieren, das bedeutet für mich, dass man nicht unbedingt von irgendetwas ausgehen soll, was vernünftig erscheint. Es kann Blödsinnigerweise auch sein, das beim refreshen eines Fensters auf einem 32Bit Screen, dennoch nur 8Bit oder weniger gespeichert werden, falls beim Screen weniger Farben eingestellt sind und wie das TTX Beispiel auch zeigt auch möglich ist. Ich denke nicht das TTX alle freien Farben belegt, nur dass ein anderes Programm keine mehr allokieren kann (ChaosPro macht das gleiche)

gruss

[ Dieser Beitrag wurde von DariusBrewka am 15.06.2004 editiert. ]

[ - Answer - Quote - Direct link - ]
2004-06-15, 09:04 h

thomas
Posts: 7718
User
Zitat:
Nunja, ich öffne ein Fenster, zeichne mittels WritePixelArray() hinein, entferne das Fenster und Im Background bleibt Müll, aber nicht immer!, vieleicht aber auch nur bei WinUAE, wie auch anderes was nur bei WinUAE Probleme macht und man es deshalb nicht benutzen darf :-(.

Kannst du mal den Programmabschnitt hier abdrucken ? Ich kann mir das nicht vorstellen. Ich habe PicShow fast nur unter WinUAE entwickelt und da gab es nicht Müll.

Außerdem, solange du es richtig machst, darfst du alles benutzen. Wenn WinUAE damit ein Problem hat, dann solltest du das an den Autor von WinUAE melden, damit es korrigiert wird.

Zitat:
Wenn ich in TurboText 32Bit einstelle, kann ich dennoch keinen Pen mehr allokieren, das bedeutet für mich, dass man nicht unbedingt von irgendetwas ausgehen soll, was vernünftig erscheint.

Du solltest nie von etwas ausgehen, das irgenwie erscheint, sondern immer nur von dem, was in den RKRM und den Autodocs steht. Vermutlich allokiert TurboText alle 256 Pens. Oder es setzt seine eigene ColorMap. Vielleicht gibt es auch noch andere Möglichkeiten, anderen den Zugriff auf die Palette zu verwehren.

Benutzt du vielleicht FullPalette ? Dann darfst du dich nicht wundern, daß du nie einen Pen allokieren kannst, denn FullPalette blockiert ja alle.

Zitat:
Es kann Blödsinnigerweise auch sein, das beim refreshen eines Fensters auf einem 32Bit Screen, dennoch nur 8Bit oder weniger gespeichert werden

Nein, das kann nicht sein. Bei einem SMARTREFRESH-Window wird der gesamte Bildschirminhalt automatisch aktualisiert, mit der gesamten Bildschirmtiefe.

Bei einem SIMPLEREFRESH-Window wird gar nichts automatisch aktualisiert, sondern das Programm muß das Fenster selbst neu zeichnen und dann werden natürlich nur die Farben benutzt, die das Programm kennt.


Ich fange langsam an, mich zu fragen, was du da eigentlich machst. Wenn du in fremde Fenster reinmalst, ist es klar, daß das Probleme gibt. Du solltest immer nur dein eigenes Fenster benutzen.

Gruß Thomas

--
Email: thomas-rapp@web.de
Home: home.t-online.de/home/thomas-rapp/

[ - Answer - Quote - Direct link - ]
2004-06-15, 12:29 h

DariusBrewka
Posts: 899
[Banned user]
Zitat:
Kannst du mal den Programmabschnitt hier abdrucken ? Ich kann mir das nicht vorstellen. Ich habe PicShow fast nur unter WinUAE entwickelt und da gab es nicht Müll.

Leider kommt dieser Fehler sehr sehr selten vor, ich kann mich eigentlich auch nicht erinnern, dass er in aälteren WinUAE Versionen vorkam. Ich muss nochmal austesten, wie dieser Fehler zu reproduzieren ist.

Zitat:
Außerdem, solange du es richtig machst, darfst du alles benutzen. Wenn WinUAE damit ein Problem hat, dann solltest du das an den Autor von WinUAE melden, damit es korrigiert wird.

das Problem mit WinUAE ist, dass ich scheinbar der einzige bin, der spezielle funktionen der P96 API nutzt, und mir dementsprechend einige Fehler auffallen (Beispielweise der 32BIT Slowdown mit WritePixelArray()). WriteRGBPixel() hat auch Fehler.
Was das Alles benutzen angeht, dieses bezweifele ich.

Zitat:
Du solltest nie von etwas ausgehen, das irgenwie erscheint, sondern immer nur von dem, was in den RKRM und den Autodocs steht. Vermutlich

Das kenne ich aber auch anders von dir (ist aber schon länger her).

Zitat:
allokiert TurboText alle 256 Pens. Oder es setzt seine eigene ColorMap. Vielleicht gibt es auch noch andere Möglichkeiten, anderen den Zugriff auf die Palette zu verwehren.

ChaosPro macht das auch!

Zitat:
Benutzt du vielleicht FullPalette ? Dann darfst du dich nicht wundern, daß du nie einen Pen allokieren kannst, denn FullPalette blockiert ja alle.

ja tue ich, vieleicht hast du hier ja recht, aber ist FullPalette nicht nur für die WB zuständig?

Zitat:
Nein, das kann nicht sein. Bei einem SMARTREFRESH-Window wird der gesamte Bildschirminhalt automatisch aktualisiert, mit der gesamten Bildschirmtiefe.

hier ist aber das Problem, dass du davon ausgehst, dass dem so ist, wenn es auch Natürlich so sein wird, dass alle 32Bit gesaved werden, steht nirgends, dass das so gemacht wird. Es könnte ja sein, dass wenn man trotz RGBA PixelFormats auch die Anzahl der Farben extra eingestellt werden könnte/kann, bei eingestellter einer Farbe auch nur "eine Plane" zum sichern des Hintergrundes benutzt wird. Aber das wird sicherlich nicht so gemacht.

Zitat:
Ich fange langsam an, mich zu fragen, was du da eigentlich machst. Wenn du in fremde Fenster reinmalst, ist es klar, daß das Probleme gibt. Du solltest immer nur dein eigenes Fenster benutzen.

wo steht etwas von fremden Fenstern?, ich schrieb von, von mir geöffneten Fenstern auf PulicScreens. Von in Fremden Fenstern zeichnen war nie die Rede

Gruß Thomas

--
Email: thomas-rapp@web.de
Home: home.t-online.de/home/thomas-rapp/
[/quote]



[ - Answer - Quote - Direct link - ]
2004-06-15, 14:11 h

thomas
Posts: 7718
User
Zitat:
hier ist aber das Problem, dass du davon ausgehst, dass dem so ist, wenn es auch Natürlich so sein wird, dass alle 32Bit gesaved werden, steht nirgends, dass das so gemacht wird. Es könnte ja sein, dass wenn man trotz RGBA PixelFormats auch die Anzahl der Farben extra eingestellt werden könnte/kann, bei eingestellter einer Farbe auch nur "eine Plane" zum sichern des Hintergrundes benutzt wird. Aber das wird sicherlich nicht so gemacht.

Das Retten und Wiederherstellen von verdeckten Stellen wird von der layers.library gemacht und die arbeitet mit Bitmaps. Sie weiß nichts von Pens oder ColorMaps. Eine 32bit Bitmap hat 32 Bits pro Pixel. Wenn man einen Bereich dieser Bitmap kopiert, macht es keinen Sinn, nur 8 oder weniger Bits zu kopieren, denn dann würde man ja nur den Blauanteil oder Teile des Blauanteils kopieren. Und du wirst zugeben, daß *das* nicht so ist.

Gruß Thomas

--
Email: thomas-rapp@web.de
Home: home.t-online.de/home/thomas-rapp/

[ - Answer - Quote - Direct link - ]
2004-06-15, 17:31 h

Holger
Posts: 8116
User
Zitat:
Original von DariusBrewka:
Wenn ich in TurboText 32Bit einstelle, kann ich dennoch keinen Pen mehr allokieren, das bedeutet für mich, dass man nicht unbedingt von irgendetwas ausgehen soll, was vernünftig erscheint.
Ähm TurboText?
Ist das so alt, wie der Name vermuten läßt?
Damit auf einem Screen freie Pens zur Verfügung stehen, muß der Erzeuger des Screens auch Pen-Sharing aktiviert haben. Wenn das Programm so alt ist, daß es noch nie von Pen-Sharing gehört hat, gibt's auch keine freien Pens.
Man kann zwar OpenScreen patchen, um alten Programmen zu freien Pens zu verhelfen, hat dann aber immer noch das Problem, daß das Programm sich nicht darum schert, ob Pens belegt oder frei sind.

mfg


--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Answer - Quote - Direct link - ]
2004-06-15, 17:33 h

Holger
Posts: 8116
User 		Nebenbei gesagt: wenn Du eh P96 benutzt und weißt, dass es sich um einen Truecolor-Screen handelt, wozu Pens belegen?
Du kannst sowieso jede Farbe benutzen und color-cycling funktioniert nicht, also wozu brauchst Du noch Pens?

mfg
--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Answer - Quote - Direct link - ]
2004-06-15, 17:44 h

Holger
Posts: 8116
User
Zitat:
Original von thomas:
Das Retten und Wiederherstellen von verdeckten Stellen wird von der layers.library gemacht und die arbeitet mit Bitmaps. Sie weiß nichts von Pens oder ColorMaps. Eine 32bit Bitmap hat 32 Bits pro Pixel. Wenn man einen Bereich dieser Bitmap kopiert, macht es keinen Sinn, nur 8 oder weniger Bits zu kopieren, denn dann würde man ja nur den Blauanteil oder Teile des Blauanteils kopieren. Und du wirst zugeben, daß *das* nicht so ist.
Jein.
Wenn ein ziemlich altes Programm vom System verlangt, zwischen Screen und planar strukturiertem Puffer zu transferieren, greift der Emulationscode, der durchaus versucht zu erraten, was das Programm eigentlich will, und dabei die Anzahl der Bitplanes und die gesetzte Bitmask berücksichtigt.
Deshalb ist es Aufgabe der anderen Programme, aufzuräumen wenn sie dar&uum;ber hinausgehende Eigenschaften benutzen.

mfg
--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Answer - Quote - Direct link - ]
2004-06-16, 00:31 h

DariusBrewka
Posts: 899
[Banned user] 		@Holger

Ja TurboText ist sehr alt, sollte aber dennoch mit Pens klarkommen, da ich dort unter 3.1 nur 4?? Farben für den Screen einstellen kann (Trotz 32Bit Format), dennoch kann ich dort keinen einzigen weiteren Pen mehr allokieren.

Pens braucht man Beispielweise weil man ja nicht nur WritePixelArray() benutzt sondern auch so Sachen wie Text(), Draw() etc. letzteres habe ich ja schon zu ändern versucht, leider hat da WinUAE so seine Macken.

[ - Answer - Quote - Direct link - ]
2004-06-16, 08:33 h

thomas
Posts: 7718
User
Ich habe doch schon geschrieben, daß du nur so viele Pens bekommst, wie du im Requester einstellst. Und wenn du nur vier Farben einstellen kannst, kannst du auch nur vier Pens benutzen.

Da aber TurboText nur die ersten vier benutzt, kannst du doch nach belieben die restliche Palette verändern, ohne Pens zu allokieren.

Oder du benutzt ModePro, um die Bildschirmtiefe zu erzwingen.

Oder du schmeißt ReqTools raus, das ist ja offensichtlich nicht an RTG angepaßt.

Ich verstehe nicht, warum du es dir so kompliziert machst.

Gruß Thomas

--
Email: thomas-rapp@web.de
Home: home.t-online.de/home/thomas-rapp/

[ - Answer - Quote - Direct link - ]
2004-06-16, 15:33 h

DariusBrewka
Posts: 899
[Banned user]
Zitat:
Ich habe doch schon geschrieben, daß du nur so viele Pens bekommst, wie du im Requester einstellst. Und wenn du nur vier Farben einstellen kannst, kannst du auch nur vier Pens benutzen.

genau, so ist es! aber wenn ich einen Screen mit RGBA Format habe, wo es scheinbar geht mittels ReqTools auch 4 Farben zu allokieren, so möchte ich das wissen das dem so ist, da wie schon gesagt, zumindestens hier Fehler auftreten falls ich auf diesen Screens einige, nicht allzu komplizierte Operationen ausführe.

Zitat:
Da aber TurboText nur die ersten vier benutzt, kannst du doch nach belieben die restliche Palette verändern, ohne Pens zu allokieren.

Na gut, gebe mir ein Beispiel, wie ich intuition/Text() benutze, ohne einen Pen zu haben. Oder soll ich etwa SetRGB32(VP, 4, red, green, blue) benutzen?. Nebenbei gesagt ist TurboText hier wirklich nicht Grundlage für diese Diskussion, da es nur als Beispiel gedacht war und wenn mein Programm bei irgendwem Müll produziert, weil sich etwas daneben verhält, so bekomme ich eines auf die Birne, auch wenn mein Programm vieleicht garnichts dafür kann. Um dem aus dem Wege zu gehen, will ich garnicht erst möglich machen, dass sich mein Programm auf solchen Screens öffnet.

Anderes Beispiel, cybergraphics/WriteRGBPixel() ist auf WinUAE Fehlerhaft, soll ich es benutzen? weil es überall läuft nur nicht auf WinUAE, was denkst du wer bekommt etwas auf die Birne?, mein Programm oder WinUAE, da ja jede andere Software korrekt läuft!
Das heisst wenn man weiss das etwas nicht Funktioniert, so muss man es nach Möglichkeiten nicht benutzen oder Alternativen nutzen.

Zitat:
Oder du benutzt ModePro, um die Bildschirmtiefe zu erzwingen.

Oder du schmeißt ReqTools raus, das ist ja offensichtlich nicht an RTG angepaßt.

ich habe sicherlich schon einige Male erwähnt, dass ich keinen eigenen Screen nutze, sondern einen PubLic Screen, mein Programm öffnet keinen eigenen Screen!

Sicherlich werde ich nicht schreiben, "Leider hat mein Programm Probleme damit, benutzen Sie also lieber nicht ModePro, und gar keine Tools die ReqTools nutzen"

Zitat:
Ich verstehe nicht, warum du es dir so kompliziert machst.


kompliziert ist es nur, wenn man es nicht versucht zu verstehen, was ich will.

gruss

[ Dieser Beitrag wurde von DariusBrewka am 16.06.2004 editiert. ]

[ - Answer - Quote - Direct link - ]
2004-06-16, 15:44 h

thomas
Posts: 7718
User
Du schreibst ja nicht, was du möchtest.

Bis jetzt habe ich nur verstanden, daß dein Programm auf einem fremden Screen ein Fenster öffnet und Probleme bekommt, wenn keine Pens mehr da sind.

Du solltest die Pens mit ObtainBestPen(...,OBP_FailIfBad,FALSE) allokieren, dann bekommst du immer einen. Den darfst du natürlich nicht verändern, aber auf einem fremden Screen mußt du davon ausgehen, daß du nichts ändern darfst.

Gruß Thomas
--
Email: thomas-rapp@web.de
Home: home.t-online.de/home/thomas-rapp/

[ - Answer - Quote - Direct link - ]
2004-06-16, 18:36 h

Holger
Posts: 8116
User
Zitat:
Original von DariusBrewka:
Ja TurboText ist sehr alt, sollte aber dennoch mit Pens klarkommen, da ich dort unter 3.1 nur 4?? Farben für den Screen einstellen kann (Trotz 32Bit Format), dennoch kann ich dort keinen einzigen weiteren Pen mehr allokieren.
Du hast offenbar nicht vollständig verstanden. Egal, ob TurboText zwei, drei oder vier Farben benutzt, wenn es beim Öffnen nicht selbst Pen-Sharing aktiviert, gibt es keine freien Pens. Die restlichen Pens sind war unbenutzt aber nicht frei.
Zitat:
Pens braucht man Beispielweise weil man ja nicht nur WritePixelArray() benutzt sondern auch so Sachen wie Text(), Draw() etc. letzteres habe ich ja schon zu ändern versucht, leider hat da WinUAE so seine Macken.
Das leidige Problem mit der Mixtur aus TrueColor oder altem graphics API. Die kompatible Lösung sieht so aus, daß Du einen unsichtbaren Screen anlegst, auf dem Dir alle Farben zur Verfügung stehen, darin zeichnest und dann das Bild per Truecolor-API auf den anderen Screen überträgst. Wenn Dir die Vorstellung eines kompletten zusätzlichen Screens nicht gefällt, kannst Du natürlich auch alle nötigen Resourcen (BitMap, RastPort etc.) von Hand anlegen.

mfg

--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Answer - Quote - Direct link - ]
2004-06-16, 21:25 h

DariusBrewka
Posts: 899
[Banned user] 		@thomas

Doch schreibe ich und es stimmt was du zuletzt schriebst. Leider kommt man manchmal nicht umhin exklusiv Pens zu benutzen, wenn keine da sind kann ich natürlich immer SetAPen(rp, 1) benutzen was nicht allzu Problematisch sein dürfte, wenn man nicht die Farben an sich ändert.

der Rest ist jetzt ehe Egal, da das Problem mit den übrigbleibenden Blöcken wohl irgendwo anders zu suchen ist.

@Holger

Ich kenne das nicht, dass man ein Flag "ALLOWPENSHARING" setzen kann, dass man bei PUBLICSCREENS ObtainBestPenXYZ() benutzen kann ist mir schon klar und habe ich bisher auch immer benutzt, was auch immer soweit so gut Funktioniert wie niemand auch diese Farben mit SetRGB() ändert. Ich hielt mich daran, leider gibt es andere Programme die das nicht tun und dann bekomme nur Ich immer die Meldungen "dein Programm macht die Farben Kaputt bzw. warum Stimmen die Farben nicht".

Da mein Programm izwischen nur noch einen Pen benutzt, und diesen Exclusiv, d.h. ein SetRGBColor() benutzt, welches sowohl SetAPen(myPen) sowohl als auch SetRGB32(vp, myPen, r, g, b) benutzt, bzw. wenn myPen nicht allokiert werden konne nur SetAPen(rp, 1), was keine Probleme darstellen dürfte ist es ehe Egal.

Es ging ja auch nicht unbedingt um das mit den Pens(), sondern darum, dass man bei Programmen mit ReqTools() wohl trotz RGBA Formates auch weniger als 16m Farben einstellen kann und dieses zumindestens hier manchmal so merkwürdige Blocke beim schliessen von Fenstern hinterliess. Dieses wollte ich wissen, ob man rausfinden kann, ob weniger Farben als das PixelFormat angegeben wurden, damit mein Programm auf solchen Screens garnicht erst geöffnet wird. Da dieses wohl eher eine Merkwürdigkeit von ReqTools ist bleibt wohl nur die Wahl zwischen Augen zu und durch, oder es zu verbieten. Da ich aber noch mehr Probleme mit WinUAE habe, könnte das auch ein weiterer sein.

Das Problem mit der API, alternativ benutze ich ttengine für Text, wo man auch ohne Pens auskommen kann, für Draw() habe ich die cgx API benutzt und mittels Berseham??? Algorithmus Linien Pixel für Pixel gezeichnet nur kommt bei letzterem wieder ein weiterer Bug?? in WinUAE dazwischen.

gruss

[ Dieser Beitrag wurde von DariusBrewka am 16.06.2004 editiert. ]

[ Dieser Beitrag wurde von DariusBrewka am 16.06.2004 editiert. ]

[ - Answer - Quote - Direct link - ]

-1- [ - Post reply - ]


amiga-news.de Forum > Programmierung > Anzahl der Farben unter Hi/True Color [ - Search - New posts - Register - Login - ]


.
Masthead | Privacy policy | Netiquette | Advertising | Contact
Copyright © 1998-2024 by amiga-news.de - all rights reserved.
.