Themabewertung:
  • 0 Bewertung(en) - 0 im Durchschnitt
  • 1
  • 2
  • 3
  • 4
  • 5
Ntui: Iconproblem
#1
Habe mir das Testprogramm runtergeladen, und wie man im AIDE Projectthread lesen sehen kann funktioniert dort
das anzeigen der Icons nicht richtig unter OS4 (MOS kann ich erst nächste Woche testen wenn mein PEG1 den Netzteilcrash überlebt hat).

mal ne frage zum Source, das da:
[ab3]; blit icon to bitmaps
DrawIconStateA_ *rpB,*icon,#NULL,xoff,yoff,state,tag5
DrawIconStateA_ *rpW,*icon,#NULL,xoff,yoff,state,tag5
DrawIconStateA_ *rpW,*icon,#NULL,xoff,yoff,state,tag5[/ab3]

ist doch sicherlich nicht gewollt und ein Schreibfehler beim dritten Eintrag, das soll doch sicherlich nicht nochmal
in den Rastport mit Weisem HG (*rpW), sondern in den Alpha (*rpA) oder ?

Habs mal geändert, aber das ändert auch nix...
Das Icon wird im letzten Example nicht eingeblittet.
Zitieren
#2
nochwas, das steht im Cybergraphics.guide

evtl. liegt da der Hase im Pfeffer unter OS4 weil du LockBitmapTagList_ verwendest, könnte Wetten das es unter MOS funktioniert.

INPUTS
bitmap - pointer to a CyberGraphX bitmap pointer. please check if it is
a cybermap by calling GetCyberMapAttr() first.
Zitieren
#3
Also wenn ich den AlphaBlit weglasse, dann gehts...

Nur, was sagt uns das ?
Wird Alpha falsch erzeugt ?

[ATTACHMENT NOT FOUND]

hier nochmal mit dem Alphablit als Vergleich:
[ATTACHMENT NOT FOUND]
Zitieren
#4
@Blackbird

Setze mal bei AllocBitMap_ die Tiefe von 24 auf 32 ob das einen unterschied macht.
Zitieren
#5
Siehe der vorherige Thread. Ich vermute die Bitmap wird ins VRAM verschoben zum blitten, und ist deshalb nicht mehr für die Farb manipulation erreichbar. Ich versuche ein "wasserdichtes" Testprogramm zu machen.
Icon laden bzw. Bitmap Handling unter AmigaOS ist FURCHTRBAR. Man muss so wahnsinnig viele Sachen beachten, ich hoffe es gibt überhaupt eine Methode die auf allen Systemen funktioniert.
Zitieren
#6
@tomsmart1

jo, das hatte ich natürlich auch probiert, hat aber keine Änderung gebracht..

@Der Wanderer
Öha, klar, wenn die Daten plötzlich woanders liegen, dann können keine Farben mehr extrahiert werden, leuchtet ein...
hab den AIDE Thread erst später gelesen als den hier...

Aber zumindest hab ich den Ansatz des "nichtblittens" auch so erraten,obwohl dann die falsche Schlußfolgerung kam Big Grin
Zitieren
#7
Die Tests unter MOS3.4 sind nicht sehr positiv.
AIDE oder Copacabana starten erst gar nicht.
abe die TBImages (wobei bei der normalen installation heisen die toolbarimages) in Mos installiert.
Seit dem kann ich Copacabana nicht mehr starten, es bricht genauso wie AIDE mit der Fehlermeldung ab "Illegal Instruction"
Habe schon mit dem debugger geschaut, passiert beim einladen eines Pngimages in einer z_irgendwasfunction

Mach ich aber heute nicht mehr, kommt demnächst....

Allen schonmal eine frohes neues Jahr und einen guten Rutsch !
Zitieren
#8
Hm, vermutlich ist die z.library buggy.
Mir reicht das langsam, auf 3rd party Sachen angewiesen zu sein die nicht richtig funktionieren und ich muss dann wackelige Workarounds schreiben.

Hat jemand ein Problem damit, wenn AB3 Programme ab demnächst die "ab3support.library" vorraussetzen? Zumindest wenn man Includes benutzt wie z.B. die image.include?
Das würde vieles einfacher machen. Das ist eine Library die diverse Algorithmen enthält, wie z.B. zlib, FFT, prefixtree etc.
Die Library kann man relativ einfach für die verschiedenen Systeme nativ kompilieren, was einen deutlichen Speedgewinn bringen würde.
Momentan gibt es nur einen 68K port, aber es ist trivial einen PPC und x86 port zu machen.
Das würde z.B. das Laden von PNGs um den Faktor 2-20 beschleunigen.
Zitieren
#9
Ich glaube ich bin nicht der einzigste der nichts dagegen hätte wenn ich bei Programmen die ich dann (sollten sie irgendwann fertig werden) veröffentliche auf zusätzliche Librarys verzichten will/kann. Und gegen Nativ hat sicherlich keiner was Big Grin

also immer her mit der ab3supportlibrary Big Grin

ich kann mich noch gut daran erinnern als PfP das erste mal die image.include inne hatte und somit die zlib.library vorraussetzte. Viele user haben dann die z.library installiert und sich gewundert warum das trotzdem nicht funktioniert (z.lib ist eben nicht zlib.lib)
Zitieren
#10
Hab noch etwas Zeit rausschlagen können bis Sylvester hier losgeht, und was macht man da wenn man artig ist ?
Richtig, schmeist MOS nochmal an und schaut im Debugger wo es hakt.

Also in der Function ntui_DecodePNG bei z_Uncompress bei z_OpenLib bin mir nicht sicher ob beim Macro oder danach...
Zitieren


Gehe zu:


Benutzer, die gerade dieses Thema anschauen: 3 Gast/Gäste