amiga-virus nachprogrammieren ;-)
-
Nö, WebFritzi, da hast du leider unrecht. Das packt man normalerweise in WM_PAINT damit die Region so frisch wie möglich ist.
-
Original erstellt von <Hendrik>:
Nö, WebFritzi, da hast du leider unrecht. Das packt man normalerweise in WM_PAINT damit die Region so frisch wie möglich ist.Du meinst wohl meinen ersten Post von den letzten beiden. Aber da hast du leider unrecht, da es hierbei nicht um Regions, sondern um Bitmaps und DCs ging. Pass das nächte mal ein wenig besser auf.
-
Nein ich meinte schon deinen Beitrag an Hammer. Wenn man die Region mit deinem Programm erstellt, ist die doch total veraltet. Man sollte die immer frisch in WM_PAINT generieren.
-
Original erstellt von <Hendrik>:
Nein ich meinte schon deinen Beitrag an Hammer. Wenn man die Region mit deinem Programm erstellt, ist die doch total veraltet. Man sollte die immer frisch in WM_PAINT generieren.*LOL* Genau. Damit man immer schön warten muss, oder was? So ein Blödsinn! Zu Testzwecken ist sowas vielleicht geeignet, aber nicht für die Endversion. Da sollte die Region dann binär vorliegen. Dann kann man sie meinetwegen immer wieder neu generieren, denn das geht viel schneller als das Verfahren, das para hier anwendet (immer wieder das Bitmap in ein 24-Bit-Bitmap umwandeln und dann die Region Pixel für Pixel mit CombineRgn() erstellen).
-
@Webfritzie
Da du von Testzwecken redest, ist es natürlich auch sinnvoll dir Regions jedesmal neu zu erstellen (bei jedem Start). Sonst müsste man ja immer dein Programm, welches nicht von dir ist, sondern von der Skinningpage (wo ich auch die Funktionen her hab), nehmen und dass wäre sehr kompliziert. Hat man ein Programm mal fertig ist es mit sicherheit einfacher sie als Binary vorliegen zu haben.Das man das Bild nicht in WM_PAINT läd ist mir nomalerweise auch klar, aber es ging nicht, wenn ich es einmal am Anfang lade, auch nicht wenn das Bitmap static ist. Da es nur ein Testprogramm war und innerhalb von kürzester Zeit geschrieben wurde, hab ich es halt "falsch" gemacht. Es war jediglich zur Demonstration gedacht.
para
-
zum code von para nochmal:
vorweg:
also ich hab jetz mal begonnen mich mit der winapi auseinanderzusetzen...
jetz kann ich wenigstens mit den begriffen handles und den WM_MESSAGES was anfangen
naja was ich bisher aber nur kann, sind fenster erstellen und deren inhalt gestalten... naja und mit ressourcen hab ich mich etwas beschäftigt...womit ich aber noch gar nich klarkomm sind dialoges und regions...
was genau sind dialoges und regions im vergleich zu fenstern ??
und warum werden die hier verwendet im code ?ausserdem wundert mich noch, dass para keine getmessage-schleife in der WinMain verwendet ... ? wie funktioniert das da dann ? ich mein irgendwo müssen doch die messages eingefangen werden die das os zum programm sendet ...
wäre dankbar wenn einer den code vonn para etwas erklären könnte zum thema messages einfangen und regions und dialoges...
thx
mfg haMMer
-
Original erstellt von paranoiac.org:
Sonst müsste man ja immer dein Programm, welches nicht von dir ist, sondern von der Skinningpage (wo ich auch die Funktionen her hab), nehmen und dass wäre sehr kompliziert.Das ist ja wohl die Höhe!!! Mein Programm hat mit den Funktionen der Skinning Pages sehr wenig zu tun. Es benutzt einen besseren Algorithmus. Ich geb aber zu, dass es zuerst der gleiche war. Und: der neue Algorithmus ist von MIR! Und auch wenn alles nur abgekupfert wäre, dann wäre das Prog trotzdem sinnvoll!
Und was wäre nun kompliziert daran, mein Prog zu benutzen??? Du scheinst mein Prog garnicht zu kennen, mein Lieber! Du gibst dort ein Bitmap an, welches in eine Region "umgewandelt" wird. Das Gute daran ist, dass man die Region abspeichern kann als Datei. In deinem Proggi kannst du sie dann wieder als Resource laden... und das geht um einiges schneller als immer wieder die Region neu zu generieren.
-
Was meint ihr mit der Skinning Page gibt mal nen Link her
-
jetz hab ich schon gedacht, jemand hat sich mühe gegeben um auf meine fragen zu reagieren ...
lol naja... mal abwarten
vielleicht muss ich mir doch noch mehr tuts besorgen und durchlesen
-
Original erstellt von Hammer:
vielleicht muss ich mir doch noch mehr tuts besorgen und durchlesenWäre bestimmt nicht schlecht. Hatte gerade viel zu tun. Ich schau mir dein Prob gleich mal an. Tut mir leid, aber das MUSSTE einfach mal raus.
@Nitromaus: http://www.flipcode.com/articles/article_win32skins.shtml
-
Doch ich kenne dein Programm sehr wohl. Davon mal abgesehen weiss ich auch, dass auf der Skinning Page auch ein Beispiel ist, wie man aus einem Bitmap Regions im Binary Format erstellt! Ist mir aber auch völlig egal!
Ich meinte damit nur, das es Unsinn ist, ´wenn man doch nur testen will, extra ein Programm zu benutzen welches 5 min länger braucht um das Ding zu speichern aber dann bei der Anwendung ein paar Sekunden schneller läuft. Hat man eine Anwendung mal fertig die Skins verwendet ist es nat. sinnvoller es mit einem Binary zu machen!
Und jetzt reite nicht darauf rum, sondern freu dich einfach, dass heut schönes Wetter war :p :p
Danke!
cu para
-
....
....
ihr beiden scheint guten plan zu haben mit den winapi funktionen ..!kann mir von euch jemand seine icq nummer geben, oder sagen, in welchem irc channel er sich öfters aufhält, sofern vorhanden.. ?
wäre net echt net mich etwas mit einem erfahrenen zu unterhalten..
mir fehlt halt der überblick über die fktnen. , bzw. viele kenn ich noch gar net und ich weiss net wo ich nachschauen soll...ich weiss ich bin zu gierig :), hab erst vor 8 wochen mit c/c++ angefangen, und hab schon n winsocket-consolen chatprog erstellt...
jetz will ich mir winapi geben und unbedingt meinen traum erfüllen, den ich schon seit 3 jahren hatte... den desktop-roboter, der die maus verschluckt !danach steig ich um auf libSDLlets rock!
mfg haMMer
-
Original erstellt von Hammer:
**was genau sind dialoges und regions im vergleich zu fenstern ??
und warum werden die hier verwendet im code ?
**Also, erstmal heißt das "Dialoge". Ein Dialog ist ein Fenster. Mehr nicht. Man kann aber ein solches Fenster in einer Resource ganz einfach erstellen. Zum Beispiel:
//////////////////////////////////////////////// //// About Dialog //// //////////////////////////////////////////////// ID_DLG_ABOUT DIALOG 0, 0, 164, 94 STYLE DS_MODALFRAME | WS_POPUP | WS_VISIBLE | WS_CAPTION | WS_SYSMENU CAPTION "About Metronomania" LANGUAGE LANG_NEUTRAL, SUBLANG_NEUTRAL FONT 8, "MS Sans Serif" { CONTROL "" , ID_WND_STC_IMG , STATIC, WS_CHILD | WS_VISIBLE | SS_ICON , 10, 18, 21, 20 CONTROL "Metronomania" , ID_WND_STC_TITLE, STATIC, WS_CHILD | WS_VISIBLE | SS_LEFT , 46, 9, 129, 16 CONTROL "Böna Company 2000 - 2002", ID_WND_STC_BOENA, STATIC, WS_CHILD | WS_VISIBLE | SS_LEFT , 49, 32, 92, 10 CONTROL "FritzPhilipp@web.de" , ID_WND_STC_MAIL , STATIC, WS_CHILD | WS_VISIBLE | SS_LEFT | SS_NOTIFY, 49, 48, 69, 10 CONTROL "OK" , ID_WND_BUT_OK , BUTTON, WS_CHILD | WS_VISIBLE | BS_DEFPUSHBUTTON , 57, 67, 53, 16 }
Ebenso einfach kann man z.B. Menus erstellen. Wegen dieser Einfachheit benutzen viele Dialoge, anstatt CreateWindow() zu benutzen.
ausserdem wundert mich noch, dass para keine getmessage-schleife in der WinMain verwendet ... ? wie funktioniert das da dann ? ich mein irgendwo müssen doch die messages eingefangen werden die das os zum programm sendet ...
Recht hast du! Das ist auch eine Eigenheit von Dialogen. Man benutzt einfach DialogBox() und gibt dort im letzten Parameter die DLGPROC (entspricht der WINDOWPROC bei Fenstern) an. In der angegebenen DLGPROC werden dann die Messages verarbeitet, die an den Dialog gehen.
wäre dankbar wenn einer den code vonn para etwas erklären könnte zum thema messages einfangen und regions und dialoges...
Nö, hab ich jetzt keine Lust zu. Ich kann dir noch schnell was zu Regions sagen. Du kannst dir eine Region vorstellen wie einen Bereich, in dem einige Punkte enthalten sind und andere nicht. Also irgendeine beliebige Form. Eine solche Form kannst du jetzt per SetWindowRgn() deinem Fenster zuweisen. Die Form wird dann sozusagen über das Fenster "gestülpt", und nur da, wo die Form über dem Fenster liegt, wird das Fenster auch gezeichnet. Alles andere gehört dann nicht mehr zum Fenster. Ja, so ist das.
-
Original erstellt von paranoiac.org:
Ich meinte damit nur, das es Unsinn ist, wenn man doch nur testen will, extra ein Programm zu benutzen welches 5 min länger braucht um das Ding zu speichern aber dann bei der Anwendung ein paar Sekunden schneller läuft.5 Minuten???
Ich wähne, du kennst das Programm wirklich nicht. Naja - zumindest nicht gut. OK, wir gehen das ganze mal durch. Also, du willst plötzlich ein neues Bmp für dein Window haben - und damit auch eine neue Region. OK, du änderst also erstmal den Namen des Bmps in der Resource. Soweit, so gut. Wir gehen mal von einem komplizierten BMP aus. Wenn du jetzt immer wieder im Programm deine Funktionen darüber laufen lässt, dauert das superlange! Was spricht nun dagegen, einmal den RegionBuilder anzuschmeißen und die Routine (die schneller ist als die in deinem Proggi) darüber laufen zu lassen? Dann bist du fertig. Den Namen der RGNDATA-Resourcendatei hast du doch in deinem Resourcenscript. Die wurde vom RegionBuilder schnell geändert. Alles, was jetzt in der Vorbereitung länger dauert, sind ein paar Klicks - einmal RegionBuilder öffnen (am besten, du hast ihn bei sowas die ganze Zeit geöffnet), einmal die BMP-Datei öffnen, einmal Region generieren (wie gesagt - schneller als in deinem Code) und einmal speichern. Das war's. Höchstens ne halbe Minute! Und: du bist das Warten in deinem Programm los.
P.S.: Sorry, dass ich nochmal darauf rumreiten musste. Aber ich muss doch mein Programm verteidigen.
-
ich habe 1 minute und 8 sekunden gebraucht :o
-
Hmm. Dann lad dir mal die neue Version runter.
P.S.: Das Ganze wird bald NOCH schneller.
-
hmm und um die form und größe der region zu ermitteln, benutzt er die
ScanRegion() funktion...
jetz versteh ich ...wenn ich scanregion weglass, dann zeigt er nämlich noch die komplette dialoge an ... wenns dazukommt, dann sieht man nur die bitmap, und wenn ich weiss bei mir auf transparent setze, dann sehe ich nur meinen Roboter (sprite) ...
womit ich aber noch net so klar komm sind die 2 externe funktionen ScanRegion() und Get24BitPixels ... noch etwas zu hoch für mich..
hab die beiden funktionen deshalb 1zu1 kopiert
jetz fehlt mir noc der algorithmus für die bewegung... bei mir isses aber easy, da er sich gleichförmig bewegen soll ..
ich hab aber zusätzlich da prob, dass er je nach cursor position eine andere bitmap einladen soll... soll er nach links gehen, nach rechts, nach oben, oder unten...
könnt etwas größer werden das prog...kann man eigentlich auch gifs verwenden anstatt bitmaps ?
-
Original erstellt von Hammer:
kann man eigentlich auch gifs verwenden anstatt bitmaps ?Ja, steht in der FAQ.
-
ich habe 3 verschiedene bitmaps , die er nach einer bestimmten zeit immer nacheinander anzeigen soll und das immer von vorn
nur hab ich jetz da ein prob!
und zwar bräuchte ich einen befehl, den dialoge neu zu generieren, sodass die 3 verschiedenen regions pro bitmap wieder nach jedem durchlauf neu gesetzt werden... da es sonst zu überlappungen kommt und er immer die region der vorherigen bitmap weiterverendet und dort die nächste drübersetzt, was natürlich falsch ist, es soll sich ja immer auf die ganze dlg beziehen !
einen fortschritt hab ich gemacht indem ich in der WM_INITDIALOGE die Regions getrennt mit GetWindowsRgn() abgespeichert hab!
hat wunderbar funktioniert...
nur nach dem ersten durchlauf, fängt das gleich prob wieder von vorne an...hier der code:
BOOL CALLBACK DlgProc(HWND hDlg, UINT message, WPARAM wParam, LPARAM lParam)
{
static HBITMAP hBitmap, hBitmap2, hBitmap3, hBitmapAttack;
HDC hdc, hdcMem;
PAINTSTRUCT ps;
static int bmp_counter = 1;switch (message)
{
case WM_INITDIALOG:hBitmap = LoadBitmap(hPubInst, MAKEINTRESOURCE(BMP_ROBO));
hBitmap2 = LoadBitmap(hPubInst, MAKEINTRESOURCE(BMP_ROBO2));
hBitmap3 = LoadBitmap(hPubInst, MAKEINTRESOURCE(BMP_ROBO3));
if(hBitmap==NULL || hBitmap2==NULL || hBitmap3==NULL)
{
MessageBox(0, "Bitmap konnte nicht geladen werden", "ERROR", MB_OK);
PostQuitMessage(0);
}GetObject(hBitmap, sizeof (BITMAP), &bitmap);
GetObject(hBitmap2, sizeof (BITMAP), &bitmap2);
GetObject(hBitmap3, sizeof (BITMAP), &bitmap3);hRgn = ScanRegion(hBitmap, 255, 255, 255);
GetWindowRgn(hDlg, hRgn);
hRgn2 = ScanRegion(hBitmap2, 255, 255, 255);
GetWindowRgn(hDlg, hRgn2);
hRgn3 = ScanRegion(hBitmap3, 255, 255, 255);
GetWindowRgn(hDlg, hRgn3);SetWindowPos(hDlg, HWND_TOPMOST, 0, 0, 0, 0, SWP_NOSIZE);
SetTimer(hDlg, TIMER_MOVE, 20, NULL);
SetTimer(hDlg, TIMER_BMP, 1000, NULL);
SetTimer(hDlg, TIMER_ATTACK, 2000, NULL);
SetTimer(hDlg, TIMER_RUSH, 20, NULL);return TRUE;
case WM_PAINT:
hdc = BeginPaint (hDlg, &ps);
hdcMem = CreateCompatibleDC (hdc);
if (bmp_counter == 1)
{
SetWindowRgn(hDlg, hRgn, true);
SelectObject (hdcMem, hBitmap);
BitBlt (hdc, 0, 0, bitmap.bmWidth, bitmap.bmHeight, hdcMem, 0, 0, SRCCOPY);
}
if (bmp_counter == 2)
{
SetWindowRgn(hDlg, hRgn2, true);
SelectObject (hdcMem, hBitmap2);
BitBlt (hdc, 0, 0, bitmap2.bmWidth, bitmap2.bmHeight, hdcMem, 0, 0, SRCCOPY);
}
if (bmp_counter == 3)
{
SetWindowRgn(hDlg, hRgn3, true);
SelectObject (hdcMem, hBitmap3);
BitBlt (hdc, 0, 0, bitmap3.bmWidth, bitmap3.bmHeight, hdcMem, 0, 0, SRCCOPY);
}
if (bmp_counter == 4)
{
SetWindowRgn(hDlg, hRgn2, true);
SelectObject (hdcMem, hBitmap2);
BitBlt (hdc, 0, 0, bitmap2.bmWidth, bitmap2.bmHeight, hdcMem, 0, 0, SRCCOPY);
}
DeleteDC (hdcMem);EndPaint (hDlg, &ps);
return TRUE;case WM_TIMER:
if (wParam == TIMER_MOVE && RemoveCursor() == false)
{MoveRobo(hDlg);}if (wParam == TIMER_BMP)
{
bmp_counter++;if(bmp_counter == 5)
{bmp_counter = 1;}InvalidateRect(hDlg, NULL, false);
}if (wParam == TIMER_RUSH && RemoveCursor() == true)
{}if (wParam == TIMER_ATTACK && RemoveCursor() == true && Rush(hDlg) == true)
{}return TRUE;
...
vielleicht sieht jemand was...also ich möchte nach möglichkeit nicht zu arg von meiner variante abweichen...
d.h. das grundprinzip zur lösung möchte ich nach möglichkeit beibehaltenthx
mfg haMMer
[ Dieser Beitrag wurde am 26.02.2003 um 17:40 Uhr von Hammer editiert. ]
-
Du setzt bei jedem WM_PAINT eine neue WindowRgn. Das ist nicht gut! Mach das beim Eingang von WM_TIMER mit wParam TIMER_BMP. Aber bevor du SetWindowRgn() aufrufst, rufst du nocheinmal GetWindowRgn() auf mit der upzudatenden Region im 2. Parameter. Zum Beispiel:
if(bmp_counter == 3) { // Vorige "aktive" Region war hRgn2 GetWindowRegion(hDlg, hRgn2); // Neue Region setzen SetWindowRgn(hDlg, hRgn3, TRUE); }