| |
|
|
| Hallo zusammen,
Version 1.7 der ProSpeedDll ist jetzt verfügbar! Diesmal mit Schwerpunkt Bildschirm-Manipulationen. Diese Funktionen sind hinzugekommen und hier könnt ihr die neuste Version runterladen:
Meine Homepage
FindBytes (B,O,A,S,L) Eine Kopie der Profan-Funktion MemPos, aber schneller und sicherer. Mit FindBytes() kann eine beliebige Zeichenfolge in einem Bereich gesucht werden.
WaitWatch (M) Wartet, bis M Millisekundenn seit dem letzten Aufruf von StartWatch() vergangen sind.
InitExtFX (H) Erzeugung eines Bytes-Arrays aus einer externen Bitmap. Nötig für alle grafischen Effekte.
FreeExtFX (B) Freigabe von Speicher, der mit InitExtFX() erzeugt wurde.
Darken (F,X,Y,B,S) Abdunklung des Bildschirms (oder Teilen davon) bis hin zu einer schwarzen Fläche.
Lighten (F,X,Y,B,S) Aufhellung des Bildschirms (oder Teilen davon) bis hin zu einer weißen Fläche.
Blur (F,X,Y,B) Verwischt die Grafik auf dem Bildschirm (oder Teile davon).
Rustle (F,X,Y,B) Erzeugt ein Rauschen auf dem Bildschirm (oder auf Teilen davon) ähnlich dem eines Fernsehers ohne Sendeempfang.
Grey (F,X,Y,B) Macht bunte Bildschirme (oder Teilen davon) grau. Tauscht also alle Farben in Grautöne um.
SemiTrans (F,X,Y,B1,B2,P) Semi-Transparente Einblendung. Mischt zwei verschiedene Bilder zu einem, hierbei wird durch eine Prozentangabe die Transparenz jedes Bildes berücksichtigt.
Sharpen (F,X,Y,B) Macht das Bild (oder Teile davon) schärfer. Quasi der Umkehr-Effekt von Blur().
BlackWhite (F,X,Y,B,P) Macht aus einer Grafik auf dem Bildschirm (oder Teilen davon) ein Schwarz-Weiß Bild.
CopyArray (F,X,Y,B) Manuelle Kopie eines Byte-Arrays auf den Bildschirm (oder Teilen davon).
Viel Spass, Frank. |
|
|
| |
|
|
|
| Ich hab im Magazin eine News darüber veröffentlicht: [...]
Ich hoffe das geht klar.
MfG, Eric Eggert www.yatil.de - Das Profan²-Magazin |
|
|
| |
|
|
|
| Hallo Eric,
Natürlich geht das klar. Dankeschön und weiter so...
Gruss, Frank |
|
|
| |
|
|
|
| Hallo Frank!
Großes Lob an Deine Arbeit!
Die Dll ist wirklich überaus nützlich, allerdings bin ich mir nicht ganz sicher, ob es sich bei folgender Sache um einen Bug handelt:
dll laden Deklarations-block
windowstyle 80 window 0,0-800,600 Loadsizedbmp ...,0,0-800,600;0
string bereich#,0=Picture.bmp ExternHDC&=LoadExtBmp(bereich#,%HDC)
CopyExtBmp(%hdc,200,100,400,400,ExternHDC&,0,0,0)
Whilenot ende% irgendwas waitinput case Equ(%mousepressed,1):messagebox(text,text,0) case Equ(%mousepressed,2):ende%=1 sleep 20 allerdings per Def, da Profan 6.6 Endwhile
Ist nicht original, aber sollte es erklären.
Problem: Das Bild wird mit LoadExtBmp geladen und dann mit CopyExtBmp ins Hauptfenster kopiert. Soweit kein Problem. Wenn ich jetzt aber die Messagebox über die kopierte Grafik bewege zerstöre ich sie damit. Ganz im Gegensatz dazu wird die zuvor mit Loadsizedbmp geladene Hintergrundgrafik immer wieder ordnungsgemäß rekonstruiert. Bei anderen Fenstern, die ich beispielsweise in den Vordergrund hole geschieht das gleiche. Woran liegt es? Mein Fehler?
..und noch was anderes Anregung wolltest Du, nicht wahr? Nun, die Prospeed.dll sollte ja, soweit ich Dich verstanden habe die Möglichkeiten des Spieleprogrammierens verbessern. Deswegen ist ja der Schwerpunkt wohl auch die Sprite-Geschichte. Bei den Spritefunktionen fehlt aber eine ganz entscheidene! Schlagwort Hierarchie: Bislang ist es so, daß der zuletzt erstellte Sprite auf der vordersten Ebene plaziert ist, vor den zuvor erstellten. Die Hierarchie baut sich also von Sprite1 - hinterste Ebene bis Sprite (zuletzt erstellt) - vorderste Ebene auf. Für einfache Ballerspiele mag das genügen. Was ist aber wenn im laufenden Spiel eine Figur zuerst hinter einem Baum und dann vor ihm herlaufen soll? Zur Zeit würde das ein Löschen und Neuaufbauen aller betroffenen Sprites erfordern. Das gibt dann aber selbst mit der Prospeed das große Flattern, wenn da mal eben 10,20,30.. und mehr Sprites gesetzt werden müssen. Aber selbst, wenn das optisch vertretbar wäre, ist es doch einfacher, wenn die Dll diesen Aufwand übernimmt und schneller wäre das ohnehin. Beispiel: SetSpriteLayer(Sprhandle&,-2) um den Sprite zwei Ebenen nach hinten zu schieben, oder so ähnlich!? Hm. Möglicherweise gibt es da ja eine Lösung.
Nun denn, Deine DLL ist aber so, oder so Sonderklasse Das was ich geschrieben habe ist also nicht als Kritik zu verstehen.
Mit den allerbesten Grüßen Mischa |
|
|
| |
|
|
|
| Hallo Mischa.
>Problem: Das Bild wird mit LoadExtBmp geladen und dann mit CopyExtBmp ins >Hauptfenster kopiert. Soweit kein Problem. >Wenn ich jetzt aber die Messagebox über die kopierte Grafik bewege zerstöre >ich sie damit. Ganz im Gegensatz dazu wird die zuvor mit Loadsizedbmp >geladene Hintergrundgrafik immer wieder ordnungsgemäß rekonstruiert. Bei anderen >Fenstern, die ich beispielsweise in den Vordergrund hole geschieht das gleiche. >Woran liegt es? Mein Fehler? Ist nicht dein Fehler, das liegt an Profan. Immer wenn Profan mit seinen beiden Bitmaps herumhantiert, macht es eine Sicherheitskopie in %HDC2, um im Falle einer Überlagerung seine Hauptbitmap wieder zu restaurieren. Darum kommt auch wieder die ursprüngliche Bitmap, wenn was verdeckt wurde. Behebung:
1) Du schaltest dieses Verhalten ab und restaurierst selber bei so einem Ereigniss die Bitmap 2) Du kopierst, nachdem dein Bildschirm fertig ist, alles nach %HDC2 und aktualisierst somit die Sicherheits-Bitmap
>..und noch was anderes >Anregung wolltest Du, nicht wahr? >Nun, die Prospeed.dll sollte ja, soweit ich Dich verstanden habe die >Möglichkeiten des Spieleprogrammierens verbessern. >Deswegen ist ja der Schwerpunkt wohl auch die Sprite-Geschichte. >Bei den Spritefunktionen fehlt aber eine ganz entscheidene! >Schlagwort Hierarchie: >Bislang ist es so, daß der zuletzt erstellte Sprite auf der vordersten Ebene >plaziert ist, vor den zuvor erstellten. Die Hierarchie baut sich also von >Sprite1 - hinterste Ebene bis Sprite (zuletzt erstellt) - vorderste Ebene auf. >Für einfache Ballerspiele mag das genügen. Was ist aber wenn im laufenden >Spiel eine Figur zuerst hinter einem Baum und dann vor ihm herlaufen soll? Zur >Zeit würde das ein Löschen und Neuaufbauen aller betroffenen Sprites >erfordern. Das gibt dann aber selbst mit der Prospeed das große Flattern, wenn da >mal eben 10,20,30.. und mehr Sprites gesetzt werden müssen. >Aber selbst, wenn das optisch vertretbar wäre, ist es doch einfacher, wenn >die Dll diesen Aufwand übernimmt und schneller wäre das ohnehin. Beispiel: >SetSpriteLayer(Sprhandle&,-2) um den Sprite zwei Ebenen nach hinten zu schieben, >oder so ähnlich!? Hm. >Möglicherweise gibt es da ja eine Lösung. Ja, du hast recht. Ich hab mir die letzten Wochen selber schon meine Gedanken gemacht. Eine Layerstruktur muß her. Der erste Grundstein ist auch schon gelegt: SwapSpriteLayers(sprite1&,sprite2&) ;die beiden Sprites tauschen ihrer Ebene
Andere Layer-Funktionen werden folgen. In Version 1.8, bzw. 2.0
> >Nun denn, Deine DLL ist aber so, oder so Sonderklasse >Das was ich geschrieben habe ist also nicht als Kritik zu verstehen. Wo du recht hast, hast du recht. Ich nehms nicht als Kritik, sondern als Anregung. > >Mit den allerbesten Grüßen >Mischa >
Gruß, Frank |
|
|
| |
|
|