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

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

-1- 2 3 4 Ergebnisse der Suche: 107 Treffer (30 pro Seite)
Georg   Nutzer

03.05.2013, 22:01 Uhr

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

Zitat:
Original von jolo:

Bei mir ist es immer ein RGB24-PixelArray (malloc()), um welches ich eine Bitmap- und Rastport-Struktur herum baue.


Wie machst du das genau?

Normalerweise würde man ja AllocBitMap() mit flags = BMF_SPECIALFMT | SHIFT_PIXFMT(PIXFMT_RGB24) verwenden.

Oder - wenn man nicht mit graphics/cgfx Funktionen in das PixelArray rendern will - überhaupt keine BitMap sondern WritePixelArray(RECTFMT_RGB).
 
Georg   Nutzer

03.05.2013, 21:54 Uhr

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

Zitat:
Original von jolo:

Im Moment, nein. Ich verwende selber für AROS x86 den 'gcc' Compiler, weiß aber, dass Frank Wille einen 'vbcc'-AROS x86 Compiler in petto hat, welcher aber noch experimentell ist. Ich habe diesen zwar auch installiert, bei mir harmoniert dieser aber nicht mit dem AROS-SDK. Ich habe zwar etliche Header-Dateien aus dem AROS-SDK für den 'vbcc'-Compiler gefixt (auch auf Assembler-Ebene), aber es ist ein unendliches Unterfangen, so dass ich irgendwann das Handtuch geworfen habe.


Welche Header müssen gefixt werden und welche Art von Fixes? Viele Header sind ja auto-generiert, und da müßte man ja nur die Skripte fixen, die diese erzeugen.

 
Georg   Nutzer

02.05.2013, 18:55 Uhr

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

Zitat:
Original von wawa:

entweder weiss ich dass ein program mit dem zugewisenen stack auskommt, oder erhohe ich das und zwar nicht zu knapp, oder aber wenn was abkratzt gehe ich immer zuerst davon dass stack zu niedrig war.


Ich glaub' nicht daß man so einfach (ohne Tools oder so) wissen kann ob ein Programm mit dem Stack auskommt oder nicht. Mit dem Stack ist das so ne Sache ... ein Programm könnte nen (evtl. viel) zu kleinen Stack haben und dennoch überhaupt nicht instabil sein. Es kann aber zufällige andere Programme/Tasks instabil machen.



 
Georg   Nutzer

02.05.2013, 16:37 Uhr

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

Stabilität von aros-68k: ich hab' das vorhier nie benutzt, gestern aber mal ne Nightly Build mit FS-UAE unter Linux probiert. Mir ist aufgefallen, daß das "screenmode" Prefs Programm recht absturzfreudig war. Ich hab' dann gesehen, daß der Stack in der Shell nur 16 KByte groß war. Das könnte zu wenig sein. Ich hab' dann unter AROS x86 hosted gesehen (AROS mit "debug=stacksnoop" starten und dann in ner AROS Shell C:StackSnoop aufrufen), daß das wohl zu wenig sein könnte. Nach dem Start von "screenmode" war der Stack Usage etwa 14 KByte, und nach dem Selektieren einiger Screenmodes etwa 19 KByte. Unter aros-68k wird es vermutlich so ählich sein (ich' glaub' die stacksnoop Geschichte funktioniert dort wohl noch nicht).

Versucht deshalb vielleicht mal "StackAttack" (mit minstack so um die 40 KByte) vom Aminet früh in der Startup-Sequence zu starten. Das müßte eigentlich auch unter AROS funktionieren.

 
Georg   Nutzer

02.05.2013, 09:00 Uhr

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

Zitat:
Original von wawa:

system gestern in die knie zu bekommen


Hast du mal versucht (davor oder danach) sys:tools/debug/sashimi nebenher laufen zu lassen. Wenn da irgendwas einen Haufen Debug Output warum auch immer macht und es hängt nichts am seriellen Port (oder es läuft kein Tool wie Sashmi das den Output abfängt) könnte das evtl. das System stark ausbremsen.


 
Georg   Nutzer

30.04.2013, 10:13 Uhr

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

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

 
Georg   Nutzer

30.04.2013, 10:09 Uhr

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

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

 
Georg   Nutzer

29.04.2013, 20:54 Uhr

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

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

 
Georg   Nutzer

29.04.2013, 17:07 Uhr

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

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?
 
Georg   Nutzer

12.06.2012, 09:00 Uhr

[ - Direktlink - ]
Thema: geometrischer "Wahnsinn"
Brett: Get a Life

Bild

Bild: http://www.freeimagehosting.net/itnzt

Die Schrägen vom roten, gelben, blauen Dreieck ergeben ein Dreieck mit rot/gelb/blauen Linien. Wänn man zuerst die Längen davon errechnet, kann man danach die Winkel rausfinden.

Für den Würfel kann man eine Große von 1 x 1 x 1 annehmen.

Schräge Rot = 1 / cos(winkel1)
Höhe Rot = tan(winkel1)

Schräge Gelb = 1 / cos(winkel2)
Höhe Gelb = tan(winkel2)

Höhe Blau = Höhe Gelb + Höhe Rot
Länge Blau = wurzel(1^2 + 1^2) = 1.41421356237
Schräge Blau = wurzel(Länge Blau ^ 2 + Höhe Blau ^ 2)

2D Dreieck = Schräge Rot -> Schräge Gelb -> Schräge Blau

Für die Winkelberechnung aus den 3 Längen gibts Apps ...


 
Georg   Nutzer

11.06.2012, 19:38 Uhr

[ - Direktlink - ]
Thema: geometrischer "Wahnsinn"
Brett: Get a Life

@Holger:

Irgendwo ne 90 Grad Innenecke suchen. Dort von irgend einem Punkt P in der Ecke weg eine Line mit 33 Grad auf Wand A (links vom Eck) zeichnen. Und vom selben Punkt P weg eine Linie mit 56 Grad auf Wand B (rechts vom Eck) zeichnen.

Dann nen Winkelmesser so (schief) ranhalten, daß der eine Schenkel des Winkelmesser auf der Linie auf Wand A anliegt, und der andere auf der Line auf Wand B?

 
Georg   Nutzer

11.06.2012, 18:24 Uhr

[ - Direktlink - ]
Thema: geometrischer "Wahnsinn"
Brett: Get a Life

@Ralf27:

Ist es nicht eigentlich doch nur ein 2D Problem? Wenn ich zwei Bleistifte nehme und sie in beliebigem (3D) Winkel zusammen halte, so sind sie doch immer innerhalb einer Ebene, man kann sie also flach auf nen Tisch legen und da sieht man dann den 2D Winkel und rechnet dann mit dem so als ob alles 2D wäre.

 
Georg   Nutzer

18.03.2012, 10:46 Uhr

[ - Direktlink - ]
Thema: Bounding Box eines Layers
Brett: Programmierung

@Der_Wanderer:

Gibts da irgendwelche Refreshes oder Ähnliches von Intuition Gadgets (evtl. indirekt über RefreshWindowFrame()). Das darf man innerhalb BeginRefresh/EndRefresh auch nicht machen.

 
Georg   Nutzer

17.03.2012, 19:30 Uhr

[ - Direktlink - ]
Thema: Bounding Box eines Layers
Brett: Programmierung

[quote]
Original von Der_Wanderer:

code:
...
if (win->Flags&WFLG_WINDOWREFRESH) {
  EndRefresh(win, FALSE);
}

oldRegion = InstallClipRegion(newRegion);

if (win->Flags&WFLG_WINDOWREFRESH) {
  BeginRefresh(win);
}
...
// Draw widget //
...
// restore oldRegion and dispose newRegion


Hier hast du ein Problem mit dem 2. "if" Check, weil WFLG_WINDOWREFRESH wegen dem "EndRefresh(win, FALSE)" nach dem 1. Check nicht mehr gesetzt sein wird. Du mußt das cachen, also z. B. "BOOL in_refresh = (win->Flags&WFLG_WINDOWREFRESH) ? TRUE : FALSE" und dann bei den "if"s in_refresh abfragen.


 
Georg   Nutzer

17.03.2012, 11:59 Uhr

[ - Direktlink - ]
Thema: Bounding Box eines Layers
Brett: Programmierung

@Der_Wanderer:

MUI setzt ein Flag MUIMRI_REFRESHMODE innerhalb BeginRefresh/EndRefresh.

Theoretisch wäre es wegen dem installclipregion-geht-nicht-wenn-in-refresh-state Problem übrigens ne Optimierung, wenn man das so macht, daß man gar nicht rendert innerhalb BeginRefresh/EndRefresh, sondern sich nur ne Kopie von der DamageListe macht, und dann immer beim ClipRegion setzen diese dazu ANDet:
C code:
myinstallclipregion(region)
{
 struct Region *clipregion = region;

 if (region)
 {
   if (damageregion) AndRegionRegion(damageregion,region);
 }
 else
 {
   if (damageregion) clipregion = damageregion;
 }

 InstallClipRegion(clipregion);
}

 
Georg   Nutzer

17.03.2012, 09:58 Uhr

[ - Direktlink - ]
Thema: Bounding Box eines Layers
Brett: Programmierung

Zitat:
Original von Der_Wanderer:

Was ich jetzt auch nicht verstehe ist, warum es sich aufhängt wenn ich innerhalb Begin/EndRefresh neuzeichne. Scheinbar mache ich da irgendwas, was AmigaOS nicht passt. Ich dachte es wäre die Manipulation der ClipRegion.


Die AOS layers.library verträgt es nicht, wenn man InstallClipRegion() innerhalb Begin/EndRefresh aufruft. Deshalb muß man in so einem Fall kurz wieder aus dem Refresh State rausgehen, die Clip Region installieren, und dann wieder in den Refresh State rein:

Folgender Code ist z. B. aus der reqtools.library:
C code:
static struct Region *MyInstallRegion (struct Window *win, struct Region *reg, int refresh)
{
    struct Region *oldregion;

    LockLayerInfo(&win->WScreen->LayerInfo);
    
    if (refresh) GT_EndRefresh (win, FALSE);
    
    oldregion = InstallClipRegion (win->WLayer, reg);
    if (refresh) GT_BeginRefresh (win);

    UnlockLayerInfo(&win->WScreen->LayerInfo);
    
    return (oldregion);
}


 
Georg   Nutzer

09.02.2009, 12:11 Uhr

[ - Direktlink - ]
Thema: prop to pixel?
Brett: Programmierung

@AGSzabo:

Intuition (steht z. B. im Falle von C im <intuition/intuition.h> Header) benutzt für MAXPOT und MAXBODY 65535 (0xFFFF).
 
Georg   Nutzer

07.02.2009, 14:45 Uhr

[ - Direktlink - ]
Thema: prop to pixel?
Brett: Programmierung

Wenn man als Ausgang POT und BODY hat (bzw. diese aus top/total/visible errechnet hat), dann kann man sich diese ähnlich wie Prozentwerte vorstellen. Nur dass nicht 100 die "Basis" ist, sondern MAXPOT, MAXBODY. Also dividiert man durch MAXPOT bzw. MAXBODY anstatt 100.

BODY gibt anteilmässig die Größe des Knobs an. POT anteilmässig die Position.

code:
knobsize = propgadgetsize * body / MAXBODY;
if (knobsize < MINKNOBSIZE) knobsize = MINKNOBSIZE;


code:
knobposition = propgadgetpos + (propgadgetsize - knobsize) * pot / MAXPOT;


"size" == Breite oder Höhe je nachdem ob es horizontales oder veritkales Prop Gadget ist.

"pos" == x1 bzw. y1 je nachdem ob es horizontales oder vertikales Prop Gadget ist.

propgadgetsize == Gesamtgröße (Breite bzw. Höhe) des Propgadgets worin sich der Knob bewegt.

Wenn man sich denkt MAXBODY bzw. MAXPOT wären 100 - und body und pot ein Wert zwischen 0 und 100 - dann ist es noch einfacher zu verstehen.
 
Georg   Nutzer

26.10.2008, 15:30 Uhr

[ - Direktlink - ]
Thema: Keine Fenster Aktivierung bei Klick
Brett: Programmierung

Interessante Idee, das mit dem layer->Window verbiegen. Könnte schon funktionieren auch wenn's hacky ist. Was den Refresh betrifft, so macht Intuition schon auch einen Teil davon, weil z. B. layers bestimmte Dinge nicht wissen kann, wie z. B. den Fensterrahmen. Deshalb macht Intuition beim Layer/Window Vergrößern manuell "Ergänzungen" an der DamageListe des Layers. Aber bei Popup Menus wird man wohl eh rahmenlose Fenster nehmen und wenn man dann auch noch nen Smart Refresh Typ nimmt (solange alles sichtbar bleibt, braucht das nicht mehr Speicher als Simple Refresh) kann man wahrscheinlich das Refresh Problem vergessen.

Eine andere Möglichkeit ist, einen InputHandler (bzw. CxCustom commodities Objekt) anzulegen das bei linkem Mausklick überprüft (WhichLayer()) ob der Klick in das Popup Window geht. Wenn ja, dann den Event umändern in z. B. (recter Mausklick down).

Bei gesetztem WFLG_RMBTRAP bekommt die App dann ne IDMP_MOUSEBUTTONS - MENUDOWN Message. Die App kann das dann prüfen, ob das über dem Popup Fenster geschah. WFLG_RMBTRAP kann dynamisch gesetzt/gelöscht werden (sollte auch innerhalb des InputHandlers gehen), damit das nur über den Popup Fenstern geschieht und die normalen Menus nicht generell durch WLFG_RMBTRAP blockiert werden.


 
Georg   Nutzer

11.12.2007, 22:26 Uhr

[ - Direktlink - ]
Thema: PubScreenNode auswerten...
Brett: Programmierung

@Der_Wanderer:

Nein. Ein Node ist gültig (also ein "echter" Eintrag in der Liste) wenn ln_Succ (ist dann gleichzeitig auch für ln_Pred so) ungleich NULL ist. Wenn z. B. in ner Liste genau ein Item/Eintrag drin ist,
dann hat

- der erste Node beim Durchgehen der Liste ln_Succ ungleich NULL,
- der zweite Node ln_Succ = NULL, weil er kein echter Node ist sondern
Teil der List Struktur und kennzeichnend für das Ende der Liste.

Wenn die Liste genau zwei Items/Einträge hat, dann hat

- der erste Node beim Durchgehen der Liste ln_Succ ungleich NULL,
- der zweite Node beim Durchgehen der Liste ln_Succ ungleich NULL,
- der dritte Node ln_Succ = NULL, weil er kein echter Node ist sondern
Teil der List Struktur und kennzeichnend für das Ende der Liste.

Wenn die Liste leer ist (also keine Items/Einträge enthält) dann hat die Liste trotzdem immer noch ein lh_Head der nicht NULL ist, sondern auf nen Node zeigt. Dieser Node hat dann aber natürlich ein ln_Succ das NULL ist und somit bedeutet das es kein echter Eintrag ist, sondern das Ende der Liste bedeutet.

In C sieht geht man die Einträge einer Liste dann z. B. so durch:
C code:
node = list->lh_Head;
while (node->ln_Succ)
{
  [...]
  node = node->ln_Succ;
}


Bei pubscreens etwa so (google -> dopus4 source):
C code:
if((pubscreenlist = LockPubScreenList()))
	{
		pubscreen = (struct PubScreenNode *)pubscreenlist->lh_Head;
		while(pubscreen->psn_Node.ln_Succ)
		{
			if(Stricmp(pubscreen->psn_Node.ln_Name, "Workbench") != 0 && Strnicmp(pubscreen->psn_Node.ln_Name, "DOPUS.", 6) != 0 && pubscreen->psn_Screen->Width >= 640 && pubscreen->psn_Screen->Height >= 480 && pubscreen->psn_Screen->RastPort.BitMap->Depth > 1)
			{

				sprintf(namebuf, "%s:%s", pubscreen->psn_Node.ln_Name, cfg_string[STR_SCREEN_MODE_USE]);
				count += addscreenmode(namebuf, 640, 480, pubscreen->psn_Screen->Width, pubscreen->psn_Screen->Height, pubscreen->psn_Screen->Width, pubscreen->psn_Screen->Height, pubscreen->psn_Screen->RastPort.BitMap->Depth, MODE_PUBLICSCREENUSE);

			}
			pubscreen = (struct PubScreenNode *)pubscreen->psn_Node.ln_Succ;
		}
		UnlockPubScreenList();
	}


Man kann sich die Sache auch durch Makros erleichtern z. B.:
C code:
#define ForeachNode(list, node)                        
  for                                                    
  	(                                                      
 	    node = (void *)(((struct List *)(list))->lh_Head); 
 	    ((struct Node *)(node))->ln_Succ;                  
 	    node = (void *)(((struct Node *)(node))->ln_Succ)  
 	)

  [...]

  ForeachNode(list, node)
  {
     printf("%sn", node->ln_Name);
  }

 
Georg   Nutzer

02.03.2007, 18:47 Uhr

[ - Direktlink - ]
Thema: Anfängerfrage: Wie linke ich eine .a Datei ?
Brett: Programmierung

@Der_Wanderer:

Was malloc + co. betrifft, am besten diese in einem .c file reimplementieren, dann werden beim Linken diese genommen und nicht jene von der clib. Und du brauchst im orig. Source nicht überall malloc + co. durch anderen Code ersetzen.

Z. B.:

code:
void *malloc(size_t size)
{
    return AllocVec(size, MEMF_ANY);
}

void free(void *memory)
{
    FreeVec(memory);
}

usw.


 
Georg   Nutzer

21.02.2007, 12:08 Uhr

[ - Direktlink - ]
Thema: Swappen von Bitmaps
Brett: Programmierung

Daß LockBitMap() auf normalen Grafikarten (A1 #? Peg #? PC #? normale Amiga Classic Grafikkarten wie Cybervision, PicassoIV) Daten vom VRAM ins RAM kopiert is 99,999999% unwahrscheinlich. Das würde überhaupt keinen Sinn machen. Z. B. weil über AGP nur ein paar Megabyte pro Sekunde Lesegeschwindigkeit möglich ist. LockBitMap() friert nur die aktuelle Position der Grafikdaten der BitMap ein. Was entweder im RAM oder im VRAM sein kein. Das Umlagern zwischen RAM und VRAM (was getan wird wenn VRAM ausgeht aber z. B. ne neue Screen BitMap sichtbar werden muß) wird zwischen LockBitMap() und UnlockBitMap() verhindert.

Es mag nen 0,00000001% Ausnahmefall geben aber der Normalfall ist sicher nicht, daß LockBitMap() BitMap Daten vom VRAM ins Fastram
swappt. So ein Ausnahmefall wäre z. B. unter AROS der X11/hosted Gfx Treiber, wo Screen BitMaps/Friend BitMaps von Screen BitMaps X11 Pixmaps / X11 windows sind wo kein direkter Zugriff möglich ist. Zur Zeit schlägt hier dann direkter Zugriff auf BitMap Daten per LockBitMap() einfach fehl, was laut CGFX Autodocs Apps erwarten müssen (und dann halt ne alternative Methode benützen sollten wie ReadPixelArray() ... Ändern ... WritePixelArray()). Die meisten AOS Apps ignorieren das (wie nicht anders zu erwarten) und gehen davon aus daß LockBitMap immer klappt. Theoretisch könnte der Treiber so geändert werden, daß er direkten Zugriff emuliert, also nen Buffer anlegt, die BitMap Pixel mit ReadPixelArray einliest. Die App würde dann nen Pointer of diesen Buffer bekommen, ihn Ändern, und UnLockBitMap() würde ihn dann zurückschreiben. Das ist aber sehr unoptimal, weil LockBitMap() nicht weiß welche Teile der BitMap von der App geändert werden. Es müßte also immer die ganze BitMap einlesen, was wie gesagt (AGP) sehr langsam sein kann. Bei UnLockBitMap() gibts zwar dieses UBMI_UPDATERECTS Tag was vieleicht dazu da ist der Funktion zu sagen was geändert wurde, aber das ist dann auch schon zu spät. Man müßte es zur LockBitMap() Zeit wissen.




 
Georg   Nutzer

12.02.2007, 19:29 Uhr

[ - Direktlink - ]
Thema: DeleteLayer
Brett: Programmierung

Zitat:
Original von Der_Wanderer:

aber der Layer mag es beim Löschen wohl nicht, wenn die Bitmap schon weg ist.


Ich würd' sagen es ist der LayerInfo BackFill Hook, der das nicht mag. Wenn durch Layer Operationen (Verschieben, Schließen, ...) Teile der BitMap sichtbar werden in denen kein anderer Layer ist, werden diese mit dem LayerInfo BackFill Hook gefüllt. Wenn die BitMap dann nicht mehr existiert, geht das natürlich schief, außer es wurde LAYERS_NOBACKFILL als Hook installiert.




 
Georg   Nutzer

03.02.2007, 18:57 Uhr

[ - Direktlink - ]
Thema: Beispiel zu Datenübertragung via Netzwerk
Brett: Programmierung

@geit:

Google mal nach "netcat".





 
Georg   Nutzer

04.01.2007, 12:42 Uhr

[ - Direktlink - ]
Thema: Datatypes: Farben festlegen lassen
Brett: Programmierung

Zitat:
Original von Ralf27:
Genau so hab ich das auch gemacht, aber leider geht das nicht. Die Stifte werden nicht reserviert. ObtainPen verlangt wohl noch die RGB-Farben.


Wenn du den Screen selbst öffnest {SA_SharePens, TRUE} angeben (außer du nutzt eh {SA_LikeWorkbench, TRUE}, da sind pens automatisch shared).

Wenn wir das in AROS Intuition nicht falsch gemacht haben, dann ist es so, daß beim Screen Öffnen die DrawInfo pens (was man im Palette Prefs Programm einstellt) als Shared gelocked werden und falls SharedPens == FALSE alle restlichen Pens als exclusive.

 
Georg   Nutzer

03.01.2007, 18:52 Uhr

[ - Direktlink - ]
Thema: Datatypes: Farben festlegen lassen
Brett: Programmierung

@Ralf27:

Müßte so gehen:

PDTA_NumAlloc = Anzahl allozierter Pens
PDTA_ColorTable = Array allozierter Pens (ein UBYTE pro Pen)

mein_colortable = speicher für mindestens numalloc UBYTEs

Schleife pen = 0 bis numalloc-1
{
mein_colortable[pen] =
ObtainPen(cm, colortable[pen], 0, 0, 0, PEN_NO_SETCOLOR)
}

Später zum Freigeben:

Schleife pen = 0 bis numalloc-1
{
ReleasePen(cm, mein_colortable[pen])
}

Müßte auch ohne PEN_NO_SETCOLOR gehen. Es wird angenommen, daß ObtainPen keinen Fehler zurückgibt. Wenn das zu Unsicher ist mein_colortable als WORD Array (statt UBYTE Array) auslegen und beim Freigeben checken ob mein_colortable[pen] ungleich -1 ist.

 
Georg   Nutzer

17.10.2006, 22:59 Uhr

[ - Direktlink - ]
Thema: Amiga-ähnliches OS mit Linux-Kernel?
Brett: Andere Systeme

Zitat:
Original von DrZarkov:

Da wäre einmal AROS, welches gehostet auch unter Linux läut, und dort einen Fenstermanager voraussetzt.


Es sollte auch ohne Fenstermanager funktionieren (btw mit "export AROS_X11_FULLSCREEN=1" vor dem Start läufts im Vollbild Modus).

Außerdem is es möglich (mit ein paar Problemen/Einschränkungen) AROS/hosted unter Linux auch ohne X11 zu benutzen. Dann wird die Tastatur über /dev/console, die Maus über /dev/psaux und die Grafikkarte über den Linux framebuffer (/dev/fb0) angesteuert.

Andere Linux/X11 apps innerhalb AROS/hosted/X11 laufen zu lassen dürfte auch nicht ganz so schwierig sein, wie es sich vielleicht anhört. AROS/X11 könnte dazu selbst als X11 Fenstermanager agieren, und die X Fenster anderer Programme in das AROS/X11 Fenster re-parenten und windowmanagermäßig handeln (Verschieben usw.). Beim Mix zwischhen AROS nativen Fenstern und fremden X11 Fenstern gibts dann natürlich Situationen wo ein fremdes X11 Fenster teilweise von AROS nativen Fesntern überlagert werden soll. Das sollte aber machbar sein, indem man die Shapes der fremden X11 Fenster dynamisch neu berechnet.




 
Georg   Nutzer

16.10.2006, 22:54 Uhr

[ - Direktlink - ]
Thema: LAYERS_CLIPRECTS_LOST bei InstallClipRegion()
Brett: Programmierung

Ich würde es auch ignorieren. Bin mir nicht ganz sicher aber ich glaub' uralte Programme hatten teilweise "Refresh" Menus, die das Fenster (GUI usw.) komplett neu zeichneten. Für den Fall, wo irgendwelche Speicherplatzmängel wie in InstallClipRegion dazu führten das es Gfx Müll gab.

 
Georg   Nutzer

10.10.2006, 22:28 Uhr

[ - Direktlink - ]
Thema: MUI List, InsertSingle Problem
Brett: Programmierung

Zitat:
Original von Kaesebroetchen:
.
Zunächst funktioniert alles wie erhofft und es wird jedesmal ein neuer string eingetragen und die alten strings dabei nicht überschrieben.
Wenn ich jetzt aber auf einen der Einträge klicke dann wird der angewählte string mit dem Text des letzten Strings überschrieben !
Das kann ich sooft wiederholen bis die List nur noch Einträge mit dem Text des zuletzt hinzugefügten Strings enthält.


Das sieht auch nach beschriebenem "Strings nicht kopiert, sondern nur Zeiger gespeichert" Ding an. Genau wie bei Zune List Klasse. Nur das eben NList optimierter ist und und bei best. Aktionen (Einträge dazufügen) alte Einträge nicht neu rendert, wenn nicht notwendig. Deshalb bemerkst du das Zeiger-statt-Stringkopie Problem erst wenn du draufklickst, was zum Neurendern des Eintrags führt.



 
Georg   Nutzer

10.10.2006, 22:21 Uhr

[ - Direktlink - ]
Thema: MUI List, InsertSingle Problem
Brett: Programmierung

Hab' nochmal in Sourcse und MUI docs reingeschaut. Es gibt da MUIV_List_ConstructHook_String das man bei MUIA_List_ConstructHook und MUIA_List_DestructHook als Param angeben kann. Damit werden Strings kopiert und später wieder freigegeben. Also nicht nur Zeiger gespeichert.

Müßte auch mit Zune List Klasse gehen, nicht nur mit MUI List, oder NList.


 
 
-1- 2 3 4 Ergebnisse der Suche: 107 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.
.