| |
|
|
![: 20.04.2004](.././../../i/a/noavatar.gif) | Hallo, mir ist aufgefallen, daß der FindBytes-Befehl keine Bytes mit den Werten 01-15 finden kann (oder Bytefolgen in denen solche Werte vorkommen). Gibts dafür einen Grund oder habe ich da etwas falsch gemacht? Ich möchte mit der Routine die Position bestimmter Punkte oder Pixel-Areale innerhalb einer Bitmap suchen, dabei kommen obige Werte wahrscheinlich auch vor. Ich hab die Routine mit einem Profan-Bereich# und mit einem InitExtFX()-Array ausprobiert und ausserdem die Parameter- übergabe via Chr$(x) oder einem zweiten Array, mit gleichem Ergebnis. MfG Dieter |
|
|
| |
|
|
|
![: 20.04.2004](.././../../i/a/noavatar.gif) | Hallo,
Frank ist im Moment im Urlaub (der glückliche !) deswegen musst du vorerst mit mir vorlieb nehmen ;) oder du wartest bis Frank wieder da ist.
Von einem Fehler in FindBytes ist mir bis jetzt nichts bewusst ! Poste doch mal am besten das Codestück, ich guck mal ob ich da was finden kann.
Moritz |
|
|
| |
|
|
|
![: 20.04.2004](.././../../i/a/noavatar.gif) | Hallo Moritz, nur keine falsche Bescheidenheit, du kannst dich gerne damit beschäftigen .Hier der Code, die auskommentierten Zeilen am Ende hab ich auch probiert. Wenn du das Dispose memory# am Anfang weglässt kannst du die Routine auch mal auf den Profan- Bereich testen. Der Teil-Hexdump ist eine kleine Bitmap, mit Paint erstellt. Ich habe einfach mit dem Hexeditor Bytefolgen reingeflickt und suchen lassen. Die Bytefolge 128 7 128 sollte an Adresse $5D gefunden werden, funktioniert bei mir aber nicht. Wenn man statt der 7 an Adresse $5E aber eine 8 setzt und nach 128 8 128 sucht, dann klappts wieder. Oder versuch mal z.B. an Adresse $37 statt der $10 etwas kleineres (ausser 8) zu setzen und z.B. nach 16 5 32 zu suchen. Bei Einzelbytes ist es genauso. Falls etwas unklar sein sollte, melde dich. Dieter KompilierenMarkierenSeparierenDeclare neu&,text$,such$,lenght&,breite&,höhe&,grösse&
Declare hdc1&,array1&,arrayadr1&
Declare memory#,bereich2#,pixpos&
Dim bereich2#,3
$I Prospeed_Funktionen.inc
*** Profan Hauptprogramm
SetTrueColor 1
neu&=usedll("ProSpeed.dll")
rem
Window (%maxx/2-400),(%maxy/2-300)-800,600
Cls 0
*** Daten und Bitmaps laden und initieren
text$="12_17pixel.bmp"
rem
lenght&=@FileSize(text$)
If lenght&>0
Dim memory#,lenght&
ReadFileFast(addr(text$),memory#,0,lenght&)
hdc1&=LoadExtMemory(memory#,lenght&)
Dispose memory# Profan-Bereich
EndIf
array1&=InitExtFX(hdc1&)
rem Header auslesen
arrayadr1& = Long(array1&,40)
breite& = Long(array1&,4)
höhe& = Long(array1&,8)
grösse& = Long(array1&,20)
rem Suchparameter setzen + suchen
such$ = @Chr$(128)+@Chr$(7)+@Chr$(128)
pixpos& = FindBytes(arrayadr1&,0,grösse&,Addr(such$),3)
rem Ausgabe
Print lenght&,arrayadr1&,breite&,höhe&,grösse&
Print "Pos>";pixpos&
waitkey
pixpos& = @MemPos(memory#,0,such$)
string bereich2#,0= @Chr$(128)+@Chr$(0)+@Chr$(128)
byte bereich2#,0= 128
byte bereich2#,1= 1
byte bereich2#,2= 128
pixpos&=FindBytes(arrayadr1&,0,grösse&,Addr(such$),1)
pixpos&=FindBytes(arrayadr1&,0,grösse&,bereich2#,3)
00000000 42 4D 9A 02 00 00 00 00 00 00 36 00 00 00 28 00
00000010 00 00 0C 00 00 00 11 00 00 00 01 00 18 00 00 00
00000020 00 00 64 02 00 00 C4 0E 00 00 C4 0E 00 00 00 00
00000030 00 00 00 00 00 00 10 10 20 30 10 00 FF FF FF FF
00000040 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
00000050 FF FF FF FF FF FF FF 00 00 00 10 02 10 80 07 80
00000060 FF FF FF
|
|
|
| |
|
|
|
![: 20.04.2004](.././../../i/a/noavatar.gif) | So wie ich das jetzt verstanden hab, suchst du in dem Array nach einen Pixel der den Farbwert @rgb(128,7,128) hat, oder ?
Dann versteh ich allerdings die benutzung von @chr() zum zusammen setzen des Suchstrings nicht, diese Funktion liefert dir doch Buchstaben zurück. In deinen Suchstring steht dann €|€ ! Kann man überhaupt mit einem String nach Bytefolgen suchen ? Hab bis jetzt kaum mit FindBytes gearbeitet, aber das währ mir neu. Scheint aber wohl doch irgendwie zu klappen, wie du geschrieben hast ![](.././../../i/s/__upl_ext_1111498557.gif)
Moritz |
|
|
| |
|
|
|
![: 20.04.2004](.././../../i/a/noavatar.gif) | Moritz, es scheint nicht irgendwie zu klappen, es ist völlig normal einen Suchstring auf diese Weise zu generieren, anders könnte man ja bestimmte Steuerzeichencodes nicht eintragen. Die Suchroutine wandelt den String ja wieder in die ANSI-Codezahlen um und sucht nach diesen Zahlenwerten und nicht nach Buchstaben. Was die Werte letztendlich aussagen ist irrelevant. Das Suchbeispiel Frank aus der prospeed-Hilfe könnte man so oder so eingeben: such$ = Frank oder such$ = @Chr$(70)+@Chr$(114)+@Chr$(97)+@Chr$(110)+@Chr$(107). Ist beides dasselbe. Übrigens habe ich ja am Ende des Listings die Suchcodes auch mit dem byte bereich2#,x=y -Befehl an einen 2.Bereich übergeben und damit (ergebnislos) gesucht. Ich habe deinen Einwand aber trotzdem überprüft und dabei herausgefunden daß ich auch etwas schieflag. Die FindBytes-Routine kann nicht nur Werte<15 nicht finden sondern stolpert über Suchwerte die nicht glatt durch 8 teilbar sind (und noch einige andere, z.B. den Wert 88). Dies scheint eher auf ein Problem innerhalb der Suchroutine hinzudeuten. Das obige Suchbeispiel z.B. funktioniert bei mir nicht.
MfG Dieter |
|
|
| |
|
|
|
![: 20.04.2004](.././../../i/a/noavatar.gif) | Hallo,
>>Die Suchroutine wandelt den String ja wieder in die ANSI Codezahlen um und sucht nach diesen Zahlenwerten und nicht nach Buchstaben<<
Ahh, ok, das wusst ich nicht, dann ergibts natürlich wieder Sinn ! Aber warum manche Werte nicht erkannt werden weiß ich auch nicht, solange sie unter 256 liegen dürft es ja auch keine Probleme geben. Muss irgendwie eine Inkompabilität zwischen den Ansi Zeichen und den Zahlen sein oder sowas, werds auch mal testen, hab im Moment aber wenig Zeit, deswegen wohl eher morgen.
Moritz |
|
|
| |
|
|
|
![: 20.04.2004](.././../../i/a/noavatar.gif) | Hi,
kurz mal aus meinem Urlaub... ) FindBytes() funktioniert korrekt, wie das untenstehende Beispiel beweist. Als Ergebnis wird 801 ausgegeben. Wenn du andere Zahlen in das Beispiel übernimmst, wirst du auch schnell merken, das deine Theorie mit den niedrigen Zahlen und Zahlen, die durch acht teilbar sind, falsch ist. KompilierenMarkierenSeparierenDeclare neu&,x&,y&,z&,text$,bereich#,eingabe#
Dim bereich#,20001
Dim eingabe#,1024
*** Alle Dll-Funktionen einbinden
$I Prospeed_Funktionen.inc
*** Profan Hauptprogramm
SetTrueColor 1
neu&=usedll("ProSpeed.dll")
WindowStyle 80
Window 0,0-800,600
Cls 0
Clear Eingabe#
String Eingabe#,0="120,128,7,128,124,125,126"
SetBytes(Bereich#,800,eingabe#)
text$=Chr$(128)+Chr$(7)+chr$(128)
x&=FindBytes(bereich#,0,20000,Addr(text$),3)
Print x&
WaitInput
freedll neu&
Dispose bereich#
Dispose eingabe#
END
Wie hast du das untere Hex-Array in deinem Beispielcode denn überhaupt erzeugt ? Sind das Werte der originalen Bitmap ? Oder ein abgespeichertes Byte-Array ? Du mußt wissen, das Windows die Bitmaps als Bytes in einem Byte-Array mit leichten Variationen einsetzt, aus 128,7,128 wird also leicht 127,7,128, außerdem geht die Pixel-Reihenfolge in einem Bytes-Array von unten links unten nach recht oben ! Das gilt es zu beachten... Wenn ich aus meinem Urlaub wieder zuhause bin (Samstag), werde ich dein Beispiel mal genauer testen.
Moritz: Ich hab super Wetter und jede Menge Spaß...
Gruß, Frank |
|
|
| |
|
|
|
![: 20.04.2004](.././../../i/a/noavatar.gif) | >>Du mußt wissen, das Windows die Bitmaps als Bytes in einem Byte-Array mit leichten Variationen einsetzt, aus 128,7,128 wird also leicht 127,7,128, außerdem geht die Pixel-Reihenfolge in einem Bytes-Array von unten links unten nach recht oben !<<
Das wird das Problem sein ! Ha, olle Bill Gates hat mal wieder schuld ![](.././../../i/s/__upl_ext_1111498557.gif)
Moritz |
|
|
| |
|
|
|
![: 20.04.2004](.././../../i/a/noavatar.gif) | Hallo Frank, du hast völlig recht, das hat mir gedämmert als ich später das Beispiel aus der prospeed-Hilfe 1:1 übernommen habe und auch mal mit Getpixel() vom Screen gelesene Daten mit einem gespeicherten File verglichen habe. Also das war mir ja völlig neu. Ich dachte immer Farbwert ist Farbwert. Die Unterschiede sind ja teilweise noch viel stärker als in deinem Beispiel. Bleibt eine Frage, lassen sich die Unterschiede mathematisch nachvollziehen, d.h. kann man sich darauf verlassen dass die Abweichungen immer gleich ausfallen oder werden die Werte vom System sozusagen kreativ über den digitalen Daumen gepeilt? Danke übrigens für deine schnelle Antwort, sogar aus dem Urlaub. MfG Dieter |
|
|
| |
|
|
|
![: 20.04.2004](.././../../i/a/noavatar.gif) | hi,
byte-arrays verwaltet prospeed intern immer in 24 bit, windows übrigens auch. bei der umrechnung von 32 auf 24 bit passieren halt diese kleiner fehler... soweit ich weiß, kann dieses verhalten im system irgendwo eingestellt werden, weiß aber nicht genau, wo...
frank, der aus dem urlaub wieder da ist, aber leider mit einer schultereckgelenkssprengung, bänderriss in der schulter ... nächste woche hab ich meine op..... muß jetzt mit links schreiben und maus lenken... |
|
|
| |
|
|