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

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

Erste << 20 21 22 23 24 -25- 26 27 28 29 30 Ergebnisse der Suche: 899 Treffer (30 pro Seite)
DariusBrewka   [Benutzer gesperrt]

23.07.2004, 15:02 Uhr

[ - Direktlink - ]
Thema: Ein Paar MOS Fragen
Brett: Programmierung

Ein Testschnipsel aus meinem Code, die Funktion pushIcon() soll ein BeispielBild in einen RastPort zeichnen, tut es aber nur, falls ich statt DrawAlphaImageToRP() DrawImageToRP() benutze, welches den Alphakanal ignoriert.

das geladenen Bild " images.pointer " ist ein png icon, welchem die Erweiterung beraubt wurde, sonst lädt NewDTObject() das ding nicht.

Wie gesagt das ist nur ein Testcode

code:
void DisposeImageContainer(struct NewImage *ni) {
	if (ni) {
		if (ni->data) {
			FreePooled(pool, ni->data, ni->w*ni->h*4);
		}
		FreePooled(pool, ni, sizeof(struct NewImage));
	}
}


void DrawAlphaImageToRP(struct RastPort *rp, struct NewImage *ni, UWORD x, UWORD y) {
	struct	Icons i;
	if (ni) {
		if (ni->data) {
			i.w = ni->w;
			i.h = ni->h;
			i.map0 = ni->data;
			DrawRGBAImage(rp, &i, x, y, FALSE, 0, 0);
		}
	}
}

void DrawImageToRP(struct RastPort *rp, struct NewImage *ni, UWORD x, UWORD y) {
	if (ni) {
		if (ni->data) WritePixelArray(ni->data, 0, 0, ni->w*4, rp, x, y, ni->w, ni->h, RECTFMT_ARGB);
	}
}

struct NewImage *NewImageContainer(UWORD w, UWORD h) {
	struct	NewImage *ni;
	ni = AllocPooled(pool, sizeof(struct NewImage));
	if (ni) {
		ni->w = w;
		ni->h = h;
		ni->data = AllocPooled(pool, w*h*4);
		if (ni->data == NULL) {
			FreePooled(pool, ni, sizeof(struct NewImage));
			ni = NULL;
		}
	}
	return ni;
}

void pushIcon(struct RastPort *rp) {
	struct	BitMapHeader   *bmhd = NULL;
	struct	FrameInfo 	   fri = {NULL};
	struct	NewImage	   *ni;
	struct	pdtBlitPixelArray pa;
            Object		   *icon;
	UWORD		   w, h;

	icon = NewDTObject("images:pointer",   DTA_SourceType,   DTST_FILE,
		DTA_GroupID,      GID_PICTURE,
		PDTA_Remap,	FALSE,
		PDTA_DestMode,    PMODE_V43,
		TAG_DONE);

	if (icon) {
		get(icon, PDTA_BitMapHeader, &bmhd);
		if(bmhd) {
			w = bmhd->bmh_Width;
			h = bmhd->bmh_Height;
			ni = NewImageContainer(w, h);
			if (ni) {
				pa.MethodID = PDTM_READPIXELARRAY;
				pa.pbpa_PixelData = (APTR) ni->data;
				pa.pbpa_PixelFormat = PBPAFMT_RGBA;
				pa.pbpa_PixelArrayMod = w*4;
				pa.pbpa_Left = 0;
				pa.pbpa_Top = 0;
				pa.pbpa_Width = w;
				pa.pbpa_Height = h;
				DoMethodA(icon, (Msg) &pa);
				DrawAlphaImageToRP(rp, ni, 0, 0);
			}
		}
		DisposeDTObject(icon);
	}
}

 
DariusBrewka   [Benutzer gesperrt]

23.07.2004, 14:45 Uhr

[ - Direktlink - ]
Thema: Ein Paar MOS Fragen
Brett: Programmierung

Nuja, hätte ich mir mal wieder denken können, dass das mit den AlphaKanal nicht klappt. Wozu gibt es dann das Format wenn AOS damit nichts anfangen kann?

Vieleicht geht's ja mit einer anderen picture.datatypes Version, oder auf MOS, aber hier mit V45.7 geht's scheinbar nicht.

Und auch wenn, wie lese ich damit icons ein?, mit ".info" als Erweiterung wird gibt "NewDTObject()" NULL zurück, wie erhalte ich die ToolTypes?, bzw. ich habe keine Lust mit NewDTObject() das Image zu laden und mit OpenDiskObject() etc. die ToolTypes. Oder was ist mit alternativen (=selected) Images?

Es ist doch Alles extrem nervig!

Werde wohl eher bei Scalos nachfragn, warum es auf MOS nicht klappt (wie gesagt die Umrisse sind vorhanden, nur der Background ist völlig schwarz)
 
DariusBrewka   [Benutzer gesperrt]

23.07.2004, 13:15 Uhr

[ - Direktlink - ]
Thema: Ein Paar MOS Fragen
Brett: Programmierung

Zitat:
Wenn es auf 3.1 problemlos funktioniert, warum benutzt du dann 3.9-Erweiterungen ?

Beispielweise, warum soll ich die wbstart.library benutzen, wenn es auch mit workbench/OpenWokbenchObject() funktioniert?.

Man kann ja auch mit 3.5/9 zusätzliche Features anbieten.

Ich bin gerade am versuchn die icons über die Dataypes einzulesen, aber so oft habe ich mit der datatypes.library nicht gearbeitet. Im pictures DataType gibt's eine Methode PDTA_READPIXELARRAY, mit entsprechendn Format hoffe ich auch den AlphaKanal auslesen zu können, allerdings funktioniert DoMethod() hier nicht so wie ich will, bzw es liefert nichts! Muss mal suchen wie man das richtig macht ;-)


 
DariusBrewka   [Benutzer gesperrt]

23.07.2004, 12:01 Uhr

[ - Direktlink - ]
Thema: Ein Paar MOS Fragen
Brett: Programmierung

@Hammer

wird wohl so sein, allerdings ist es für mich fraglich so zu handeln.

@thomas

zum letzterem, naja auch ich habe kein MOS Projekt erstellt!, sondern ein einfaches ASO3.1 mit Extensions für 3.5/9, somit sehe ich nicht, dass ich einfach drauf los programmiert habe. Auf OS3.1 funktioniert alles ganz hervorragend, nur auf MOS nicht. Wenn MOS höhere VNummern hat, ewartet man auch das das dann geht, da brauche ich nicht raten und da ich weder MOS noch einen PPC Rechner besitze schon garnicht sondern nur das glauben was ich lese.

BZW.wenn ich ein 3.1/5/9 Project starte brauche ich nicht zuerst die MOS Docs zu lesen. OK hab's vergessen zu erwähnen das es kein Nativ-MOS Project ist.

Ich will einfach simpel, dass mein 68K Programm auch auf MOS läuft, was es auch sollte, wenn MOS mit 3.1 Kompatibel ist, mein Tool ist es einfach!.

zu 2:

kann man über die DataTypes auch die Masken, bzw im Falle von PNG-Icons auch den Alphakanal erhalten?, bei AOS habe ich das nicht können.
 
DariusBrewka   [Benutzer gesperrt]

22.07.2004, 21:36 Uhr

[ - Direktlink - ]
Thema: Ein Paar MOS Fragen
Brett: Programmierung

Hi an Alle, auch wenn das hier vieleicht nicht das 100% Richtige Forum ist, aber auf mdc.morphos.net habe ich bisher nicht Alle Antworten erhalten. Oder dort ist nicht viel los!

1. Ist das Richtig, das die icon.library von MOS keine ColorIcons(=OS3.5/9) icons handeln kann, genauso wie NewIcons, d.h. für letztere braucht man den NewIcons Patch). Ich frage, weil ich mir die includes dafür vom MDC geladen habe und dort sind die Funktionen alle beschrieben, auch wenn die Versionsnummen nicht stimmen.

2. Hat jemand mit den scalos libs&datatypes schon icons geladen und dargestellt?. Wie ich das gemacht habe, funktioniert das überall nur scheinbar nicht bei MOS! (Ich muss in einen OffScreen Buffer malen, ncht auf einen Screen/Window), jedenfalls kommt bei mir bei MOS der Iconumriss, aber nicht das icon selbst!

3. Warum haben MOS libs eine weitaus höhere Versionsnummer, als OS3.5/9 libs? Funktionen die man aber braucht existieren nicht! (OpenWorkbenchObject(), z.B.)

Warum macht scheinbar nur mein Prog auf MOS Probleme, überall sonst aber kaum (nuja vieleicht)?
 
DariusBrewka   [Benutzer gesperrt]

18.07.2004, 13:34 Uhr

[ - Direktlink - ]
Thema: 32 Bit pro Farbkomponente?
Brett: Programmierung

Ich denke mal benutzt werden soviele wie es das untergebene System erlaubt, d.h. AGA -> 24 Bit, ECS -> 12 Bit.

Man hat seitens Commodore damals aber wirklich weit in die Zukunft gedacht, denn auf eine Auflösung von 65536*65536 können wir noch eine weile warten. Denke 16 Bit pro Kanal hätten genügt, 8 Bit sind eigentlich zu wenig, wenn ich manchmal einige DVD's schaue sieht man in Horizont öfters harte Übergänge.
 
DariusBrewka   [Benutzer gesperrt]

14.07.2004, 23:10 Uhr

[ - Direktlink - ]
Thema: CreateNewProcTags & MOS
Brett: Programmierung

Zitat:
Muß der neue Prozess eine größere Priorität als Main haben?

Da der Prozess eigentlich ehe nur schläft, sollte das nicht schaden, nur sollte er wenn er aufwacht schnell reagieren. Daran dürfte es also nicht liegen.

Zitat:
Das sich Intuition-Fenster einen MsgPort teilen können, weißt Du? Eventuell kann Dir auch SIGB_SINGLE helfen.

mache ich auch, wenn du z.B. aber für die Fenster auch AppWindow Fähigkeiten brauchst kommt noch eines hinzu, dann gibt's noch MUI (die Applikation selber benötigt kein MUI, aber der eingebaute Voreinsteller, dafür auch noch AppWindow Fähigkeiten -> insgesamt 3 Signale, wenn da noch Filerequester aufgehen in den Einstellern kommt noch eines hinzu, bzw. wenn ich keines mehr frei hatte waren die Requester tot, AREXX, ScreenNotify, DOSNotify, Commodities, Ports, um mit externen Modulen zu kommunizieren, etc. Es kommt schon so einiges zusammen.

 
DariusBrewka   [Benutzer gesperrt]

14.07.2004, 12:55 Uhr

[ - Direktlink - ]
Thema: CreateNewProcTags & MOS
Brett: Programmierung

@gni

Habe mich verschrieben, CreateNewProcTags() kehrt nicht zurück, somit kann CreateMSGPoster() auch auf keine Signale empfangen. Ich benutze kein MOS, sodass ich das auch sehr schwer testen kann, allerdings würde das doch schon einiges erleichtern.

Das ganze Problem existiert auch nur, weil ich diesen MSGPoster einbauen musste, da mir die Signale ausgegangen sind, bzw. vieleicht könnte ich einen Port für verschiedene Sachen nutzen, d.h. für DosNotify, Arexx, ScreenNotify, etc. für AREXX gäbe es ja IsRexxMsg (oder so ähnlich), für die anderen Msgs kenne ich Entsprechendes nicht und kann folglich nicht annehmen, bzw. mutmaßen ob ich die an einen CommonMSG Port senden lassen kann.
Bitte nicht fragen, warum 16 Signale nicht reichen, aber es ist so und mein MSGPoster, nimmt einige der MSGs dem HauptProgramm ab, und sendet Nachrichten an das HauptProgramm, welches dafür nur einen Port braucht, womit man sich Probleme (Siehe DeadLock Problem Thread) einfängt aber auch Vorteile hat.

gruss

Darius
 
DariusBrewka   [Benutzer gesperrt]

13.07.2004, 23:35 Uhr

[ - Direktlink - ]
Thema: CreateNewProcTags & MOS
Brett: Programmierung

@Holger

Es ist schon stdio (CON: oder FileSystem) und ich weiss nicht ob das daran liegen kann, da es ja sonst damit auch überall läuft. Und ob mit oder ohne die Ausgabe, bleibt es hier hängen, zumindestens kehrt CreateMsgPoster auch nicht zurück, wenn ich in PostFunction() alle DEBUG_OUT aufrufe entferne.

@Georg

Denke ich nicht, da es ja keine PPC Application ist, nichtmal eine für MOS, somit denke ich das es auch laufen müsste, tut's aber auf MOS kaum. Ich habe ein Stack Problem gehabt (zuwenig eingestellt), aber die Erhöhung auf 65536 hatte des Problem auch nicht behoben. Nunja, ich dachte MOS wäre OS3.1 Kompatibel und da ich keine Hacks im Programm habe, verstehe ich die Probleme mit MOS nicht.
 
DariusBrewka   [Benutzer gesperrt]

13.07.2004, 11:26 Uhr

[ - Direktlink - ]
Thema: CreateNewProcTags & MOS
Brett: Programmierung

Findet hier jemand einen Fehler, der CreateMsgPoster() hindern würde zurückzukehren?, die letzte Ausgabe die Kommt lautet "CMP: MainTask", folglich kehrt CreateNewProcTags() nicht zurück, der Stack ist Sicherheits halber sehr hoch.

Wenn der SubProzess gestartet worden wäre würde, müsste wenigstens noch die Ausgabe "PF: Start" kommen, welche aber nicht kommt.

Nunja, dieser Fehler kommt bei 68K Systemen nicht vor, scheinbar nur bei MOS, aber auch nicht überall.

in der PostFunction() wurde alles überflüssige entfernet, d.h. u.a. die Definitionen, nur die ersten zwei Code Zeilen, also nicht wundern.

code:
__saveds void PostFunction() {

    ...
    ...
    ...
   DEBUG_OUT_STRING("        PF: Start"); LF();
   TimePort = CreateMsgPort();
    ...
    ...
    ...
    ...
}


void RemoveMsgPoster() {
   if(PostTask && PosterCreated) SendSetupMsg(SETUP_EXIT, 0);

   while(FindTask(PostName)) Delay(10);

   if (SetupReplyPort) DeleteMsgPort(SetupReplyPort);
   if (PostPort) DeleteMsgPort(PostPort);
   PostTask = NULL;
   SetupReplyPort = NULL;
   PostPort = NULL;
   PosterCreated = FALSE;
}

BOOL CreateMsgPoster() {

   BOOL  ok;

   PostSignal = -1;
   PostStart =- -1;
   PostPort = NULL;
   SetupReplyPort = NULL;
   PosterCreated  =	 FALSE;
   ok = FALSE;
   SetupReplyPort = CreateMsgPort();
   if (SetupReplyPort) {
      DEBUG_OUT_STRING("CMP: SetupReplyPort created"); LF();
      PostStart = SetupReplyPort->mp_SigBit;
   	  PostPort = CreateMsgPort();
          if (PostPort) {
            DEBUG_OUT_STRING("CMP: PostPort"); LF();
      	    PostSignal = PostPort->mp_SigBit;
   	    MainTask = FindTask(NULL);
            DEBUG_OUT_STRING("CMP: MainTask"); LF();
            PostTask = (struct Task *) CreateNewProcTags(NP_Entry, (ULONG) PostFunction, NP_StackSize, 65536, NP_Name, (ULONG) PostName, NP_Priority, 1, TAG_DONE);
         if (PostTask) {
            DEBUG_OUT_STRING("CMP: PostTask"); LF();
            //DEBUG_OUT_STRING("CMP: wait until MP is launched"); LF();
            Wait(1 << PostStart);
            DEBUG_OUT_STRING("CMP: wait"); LF();
         	ok = PosterCreated;
         } else {
            DEBUG_OUT_STRING("CMP: PostTask failed"); LF();
         }
      }
   }
   return	ok;
}

 
DariusBrewka   [Benutzer gesperrt]

09.07.2004, 20:20 Uhr

[ - Direktlink - ]
Thema: MOS & AmiStart
Brett: MorphOS

Nachtrag:

Bezahlen muss man mir das sicherlich nicht!

Wenn jemand Testen will, ob die 0.65 auf MOS läuft, so reicht eine Mail an mich.

gruss
 
DariusBrewka   [Benutzer gesperrt]

09.07.2004, 20:14 Uhr

[ - Direktlink - ]
Thema: MOS & AmiStart
Brett: MorphOS

AS ist eine Taskleiste, welche in erster hinsicht optisch gefallen soll d.h. wenn jemand auf Purität setzt ist er bei AS fehl am Platze.

Eine Auswahl an Features der letzten Version aus dem AmiNet

code:
- displays unselected and selected images,
        - drag & drop
        - displays filesystems
        - small arexx port
        - keyboard support (since 0.52)
        - texture support (since 0.56)
        - transparent backgrounds (since 0.58)
        - direct commodities support (since 0.57)
        - iconobject.library support (since 0.59)
        - popupmenu support (since 0.59)
        - added filesystem action commands (copy/move/delete).
        - added external module support (since 0.59)
        - added a LaunchBar (TaskBar) (in 0.60)
        - display actions on the Taskbar (since 0.60)
        - antialiased TrueType font support
        - hotkey support (since 0.62)
        - support for irregular docks (Shapes)


das sind aber nicht alle, da die 0.65 bald rauskommen soll. Hoffentlich mit MOS Lauffähigkeit

Kurz AS ist ein Tool zum starten von Programmen etc., oder zum Verwalten von Commodities etc.

Richard Kapp hatte damals für mich die Homepage übernommen, leider macht er auf dem Amiga kaum noch was, sodass ich nicht weiss ob ich ihm die 0.65 auch anvertrauen muss.

Ein paar ScreenShots der über ein Jahr alten 0.64

http://home.pages.at/narr/hosted_sites/amistart/screens.html


gruss
 
DariusBrewka   [Benutzer gesperrt]

09.07.2004, 15:22 Uhr

[ - Direktlink - ]
Thema: MOS & AmiStart
Brett: MorphOS

Hi, wollte mal fragen ob jemand mal AS auf MOS benutzt hat?

Ich weiss das die ersten Versionen mal gingen, aber die neuerennicht. Ich will das natürlich korrigieren, aber leider scheinen die MOSler (auch die normalen User) nichts davon zu halten auch mal zu schreiben, ob das alles so funktioniert.

Ich jedenfalls will demnächst die 0.65 rausbringen, mit oder MOS Lauffähigkeit, besser mit aber ich werde nicht wieder mehrere Wochen warten.

Also, möchte jemand ausprobieren, ob's geht oder nicht

ANMERKUNG: AS ist eine reine 68k Applikation, d.h. kein MOS recompile

gruss

Darius
 
DariusBrewka   [Benutzer gesperrt]

09.07.2004, 15:17 Uhr

[ - Direktlink - ]
Thema: Deadlock Problem
Brett: Programmierung

Danke an alle, werde mal schauen welche Vorgehensweise die Beste ist, bzw. eigentlich gibt's nur eine Lösung.

Darius
 
DariusBrewka   [Benutzer gesperrt]

09.07.2004, 00:22 Uhr

[ - Direktlink - ]
Thema: Deadlock Problem
Brett: Programmierung

Hi, ich habe ein Programm, welches einen zweiten Thread erzeugt was auch Wunderbar funktioniert nur muss dieser Thread dem Hauptprogramm Nachrichten schicken und das Hauptprogramm kann wiederrum dem Thread Nachrichten schicken. Leider kommt es wie es kommen muss, dass beide auf einmal Nachrichten schicken wollen und dann beide Tasks auf Antwort warten, die Natürlich nicht kommt und das ganze endet in einem Deadlock.

Hat jemand Ahnung, wie das Problem beseitigt werden kann

gruss
 
DariusBrewka   [Benutzer gesperrt]

16.06.2004, 21:25 Uhr

[ - Direktlink - ]
Thema: Anzahl der Farben unter Hi/True Color
Brett: Programmierung

@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. ]
 
DariusBrewka   [Benutzer gesperrt]

16.06.2004, 15:33 Uhr

[ - Direktlink - ]
Thema: Anzahl der Farben unter Hi/True Color
Brett: Programmierung

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. ]
 
DariusBrewka   [Benutzer gesperrt]

16.06.2004, 00:31 Uhr

[ - Direktlink - ]
Thema: Anzahl der Farben unter Hi/True Color
Brett: Programmierung

@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.
 
DariusBrewka   [Benutzer gesperrt]

15.06.2004, 12:29 Uhr

[ - Direktlink - ]
Thema: Anzahl der Farben unter Hi/True Color
Brett: Programmierung

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]


 
DariusBrewka   [Benutzer gesperrt]

15.06.2004, 00:27 Uhr

[ - Direktlink - ]
Thema: Anzahl der Farben unter Hi/True Color
Brett: Programmierung

@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. ]
 
DariusBrewka   [Benutzer gesperrt]

14.06.2004, 14:00 Uhr

[ - Direktlink - ]
Thema: Anzahl der Farben unter Hi/True Color
Brett: Programmierung

@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
 
DariusBrewka   [Benutzer gesperrt]

14.06.2004, 11:22 Uhr

[ - Direktlink - ]
Thema: Anzahl der Farben unter Hi/True Color
Brett: Programmierung

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
 
DariusBrewka   [Benutzer gesperrt]

13.06.2004, 23:29 Uhr

[ - Direktlink - ]
Thema: Anzahl der Farben unter Hi/True Color
Brett: Programmierung

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
 
DariusBrewka   [Benutzer gesperrt]

13.06.2004, 15:55 Uhr

[ - Direktlink - ]
Thema: Anzahl der Farben unter Hi/True Color
Brett: Programmierung

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?
 
DariusBrewka   [Benutzer gesperrt]

10.06.2004, 23:28 Uhr

[ - Direktlink - ]
Thema: Schneller dank neuer rtg.library?
Brett: AROS und Amiga-Emulatoren

Die neue rtg Library beschleunigt nur die 32Bit modis, wie schon oben gesagt nur die Read/WritePixelArray() Funktionen. Damit ist jetzt z.B. die ttengine.library in 32Bit wesentlich schneller (in 32Bit) etc. Als Nebeneffekt kann man nun endlich die Wb in 32Bit laufen lassen, ohne das man einschläft.
 
DariusBrewka   [Benutzer gesperrt]

04.06.2004, 12:52 Uhr

[ - Direktlink - ]
Thema: AOS4-pre ist da!
Brett: Amiga, AmigaOS 4

Wegen der BootZeit, ich finde schon das es auf dem Amiga mehr Relevanz hat als auf dem PC, man mag gegen Windows sagen was man will, und auch ich arbeite auf dem Amiga wesentlich lieber (auch wenn's WinUAE ist), aber wenn ich den PC einschalte brauche ich ihn in der Regel nicht neu zu starten, beim Amiga muss ich dieses sehr oft (ok, ich habe viele Patches und mein eigenes Tool macht auch noch so seine Zicken). Nunja, dafür hat ja Windows auch so seine Vorteile :-(,

gruss
 
DariusBrewka   [Benutzer gesperrt]

26.05.2004, 23:59 Uhr

[ - Direktlink - ]
Thema: BltBitMapRastPort() / BltMaskBitMapRastPort()
Brett: Programmierung

Das gleiche hast du auch unter P96/CGFX, d.h. beide Funtionen benötigen auch hier eine 1 Plane Maske. Etwas anderes als antweder Pixel an oder Pixel aus bekommst du weder mit BltMaskBitMapRastPort() noch mit irgendwelcher nativer P96/CGX Funktion, glaube mir, ich würde selber gerne etwas anderes brauchen.

Ansonsten kommt es drauf an, wie du deine Bitplane anforderst?, d.h. wenn du sicherstellst das die Bitmap ein "AGA" Kompatibles Format hat, so wirst du auch unter P96/CGX keine Probleme haben, da die ensprechend von P96/CGX gepatchte Funktion dieses entsprechend behandeln, schwieriger wird wenn du eine ScreenFriendly Bitmap hast, da kannst du nicht einfach "die erste Plane" nehmen, denn die gibt es unter umständen garnicht, da musst du dir die Maske selber zusammenbauen.

Ich würde dir empfehlen zu überlegen, ob du wirklich Support für weniger als HiColor brauchst, wenn nicht ist alles um einiges einfacher.

[ Dieser Beitrag wurde von DariusBrewka am 27.05.2004 editiert. ]
 
DariusBrewka   [Benutzer gesperrt]

13.05.2004, 12:09 Uhr

[ - Direktlink - ]
Thema: Powericons Probl.
Brett: Amiga, AmigaOS 4

So etwas lässt sich relativ leicht mit dem List Befehl bewerkstelligen, einfach die richtigen LFORMAT Argumente angeben und damit ein Skript erzeugen.

code:
list >skript ALL pat="#?.png" LFORMAT "rename *"%p%n*" to *"%p%m.info*""


einfach in das Verzeichnis gehen, wo sich die Ikons befinden und obigen Befehl ausführen. Wenn er fertig ist, einfach /"execute skript/" starten
 
DariusBrewka   [Benutzer gesperrt]

10.05.2004, 22:57 Uhr

[ - Direktlink - ]
Thema: Iconify Gadget
Brett: Programmierung

Ein Iconify Gadget gibt es auch nicht in OS3.5/9, du kannst aber z.B. MUI benutzen das unterstützt Iconify (ob Reaction&Co dieses auch tun kann ich nicht sagen, da mir diese Alternativen zu hässlich sind).

Das AmigaOS (bis 3.9) unterstützt kein Iconify, du musst dafür in deinem Programm schon selber sorgen.
 
DariusBrewka   [Benutzer gesperrt]

27.04.2004, 20:41 Uhr

[ - Direktlink - ]
Thema: Welche Patches sind eigentlich sinnvoll ?
Brett: Amiga, AmigaOS 4

Ist MagicMenu eigentlich wirklich ein Patch, nach dem was in der Anleitung steht doch nicht oder irre ich mich da. Naja vieleicht habe ich es ja auch wieder vergessen.
 
 
Erste << 20 21 22 23 24 -25- 26 27 28 29 30 Ergebnisse der Suche: 899 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-2024 by amiga-news.de - alle Rechte vorbehalten.
.