Jo hab ich gemerkt.
Ich habe noch was entdeckt bei Transparenten PNG´s wird nicht richtig gezeichnet
Hier ist mal ein Photo davon
Und hier mal die beiden Grafiken
Jo hab ich gemerkt.
Ich habe noch was entdeckt bei Transparenten PNG´s wird nicht richtig gezeichnet
Hier ist mal ein Photo davon
Und hier mal die beiden Grafiken
Jop. QuickDraw verwendet den Alphachannel genau verkehrt herum. Das ist mir schon bei den Bitmaps aufgefallen. Ich hab ein PNG in Bitmap + Alphabitmap umgewandelt und musste dazu die Alphabitmap invertieren.
PS: Ich habe den vorherigen Post noch erweitert ![]()
oke sekunde;-)
Also muss ich den Alpha Kanal umdrehen. Hm. How do with Gimp ?
update 9 -> Fehler mit Alpha Channel hoffentlich behoben
Sehr schön, Funzt. ![]()
So. Ich habe jetzt uach eine Funktion, um Schriften aus einem Binärstring zu laden:
; #FUNCTION# ====================================================================================================================
; Name...........: _QuickDraw_InstallFont
; Description ...: Installs a font for the current process
; Syntax.........: _QuickDraw_InstallFont($sFontFile)
; Parameters ....: $sFontFile - Path of fontfile
; Return values .: Success - 1
; Failure - 0 and set @error
; |0 - generic error
; |1 - DLLCall error
; Author ........: ProgAndy
; Modified.......:
; Remarks .......:
; Related .......:
; Link ..........:
; Example .......:
; ===============================================================================================================================
Func _QuickDraw_InstallFont($sFontFile)
; Author: ProgAndy
Local $aResult = DllCall('gdi32.dll', 'int', 'AddFontResourceExW', 'wstr', $sFontFile, 'dword', 0x10, 'ptr', 0)
If @error Then Return SetError(1,0,0)
Return $aResult[0]
EndFunc
; #FUNCTION# ====================================================================================================================
; Name...........: _QuickDraw_InstallFontMem
; Description ...: Installs a font from binary data for the current process
; Syntax.........: _QuickDraw_InstallFontMem(ByRef Const $bBinary, $iFontsInImage = 1)
; Parameters ....: $bBinary - binary representation of the fontfile
; Return values .: Success - 1
; Failure - 0 and set @error
; |0 - font not loaded, gengeric error
; |1 - Could not create DLLStruct of required length
; |2 - DLLCall failed
; Author ........: ProgAndy
; Modified.......:
; Remarks .......:
; Related .......:
; Link ..........:
; Example .......:
; ===============================================================================================================================
Func _QuickDraw_InstallFontMem(ByRef Const $bFontBinary)
; Author: ProgAndy
Local $tData = DllStructCreate("byte[" & BinaryLen($bFontBinary) & ']')
If @error Then Return SetError(1,0,0)
DllStructSetData($tData, 1, $bFontBinary)
Local $aResult = DllCall('gdi32.dll', 'handle', 'AddFontMemResourceEx', 'ptr', DllStructGetPtr($tData), 'dword', DllStructGetSize($tData), 'ptr', 0, 'DWORD*', 0)
If @error Then Return SetError(2,0,0)
Return SetExtended($aResult[4], $aResult[0]<>0)
EndFunc
Sehr schön werde den src code mal in den ersten post machen
super projekt
hat aber noch ein paar Macken,
Das ist der Text mit "$Draw_Line" im Beispiel, bei schwarzem Hintergrund und Schriftgröße 40:
Hier mal 2 Beispiele erstellt mit QuickDraw:
Tramp of Particles:
Twister:
Als Vergleich auch die GDI+ und WinAPI Version ![]()
Danke an Andy für die WinAPI Version! ![]()
Isometric Level-3 Cube:
Gruß,
UEZ
Ich hab das Projekt erst heute endeckt, muss sagen es ist einfach abgefahren geil. Auf meinem XP x32 läuft das wie geschmiert. Was mich wie immer ein wenig aufregt ist, das es ein wenig viel CPU-Leistung schluckt. Wie läuft das eigentlich bei den 2D-Spielen, die haben ja keine so großen Anforderungen um sogar ganze Maps zu rendern. Wieso läuft das dann bei QuickDraw solangsam? Liegt das an den ständigen Dll-Calls?
Was mich wie immer ein wenig aufregt ist, das es ein wenig viel CPU-Leistung schluckt.
Das is ja egal solage es nicht 100 % auf einem Core arbeitet
ZitatWie läuft das eigentlich bei den 2D-Spielen, die haben ja keine so großen Anforderungen um sogar ganze Maps zu rendern. Wieso läuft das dann bei QuickDraw solangsam? Liegt das an den ständigen Dll-Calls?
Die sind meißtens is Sprachen geschrieben die Multi Threadring unterstützen. Das bei AutoIt nicht der Fall ist. Mit multithreadring geht das nämlich so gehn: 1 Thread rendert und ein anderer würde den Rest verarbeiten Usereigaben und Kollision zum Beispiel.
ähh ich weis nich ob es schon erwähnt wurde (zu faul den thread zu lesen
)
aba bei _QuickDraw_GetMouseLeft( ) wird immer ne nummer zurückgegeben
ansonst
super arbeit
ich bin begeistert ![]()
yxyx wir lassen uns auch mal blicken ?
wd
ja sicher
doodle wirds ja bald in qd geben ![]()
und da muss ich mir das natürlich ansehn ![]()
so ich bin jetz hier grad so n bissel am "basteln" ![]()
und ja jetz hab ich ein problem
ich hab ein bild (Anhang 1)
und jetz will ich das zeichnen
und dan sieht das aus wie in anhang 2
hier mal der codeteil der das bild zeichnet
Global $Bombepic = _QuickDraw_LoadTexture( "Bombe.png" )
_QuickDraw_Rect( 0, 0, 25, 25, $Bombepic, 0xffffffff)
weis jmd was ich da machen soll?
Die fehlerhafte Darstellung liegt warscheilich an einem Komprimierungsfehler.
Der Fehler wird schwächer, wenn man die Bilddatei vergrößert.
Bei 100x100 ist nichts mehr zu erkennen.
Gibt es nicht Möglichkeiten ihrgentwie Bitmaps von einem GraphicHandle zu zeichnen, sodass man einfach ne Verbindung zwischen GDI+ und QuickDraw hat? Das wäre meiner Meinung nach sehr nützlich! ![]()
Da kann man sich doch glatt Fragen wieso die GDI+ so schlecht Programmiert ist^^
So wies aussieht kommt AutoIt doch noch auf Hochtouren mit den Richtigen UDF´s und Dll´s ![]()
Wird das Projekt immer Beta bleiben oder irgendwann abgeschlossen sein ?
//:. Edit.: Kann eventuell ein x64 Compiler verwendet werden um alternativ das ganze auf x64Systemen zum Laufen zu bringen ? :.//
mfg
Mars(i)
Marsi, wahrscheinlich erst fertig sein wenn GDI+ 1 zu 1 übernommen wurde.