algorithmus um daten im "Big Endian Format" einles
Übersicht
BlitzBasic Allgemein
x_toBetreff: algorithmus um daten im "Big Endian Format" einles |
 Do, März 16, 2006 16:45Antworten mit Zitat 
|
|
|---|---|---|
|
da BB daten nur im Little Endian Format liest, ich die aber "Big Endisch" brauche hab ich mal diesen Algorithmus geschrieben. Er funktioniert erstmal nur mir Short werten. Kann man das irgendwie beschleunigen..??
Bei größeren dateien versagt das alles kläglich... 
Code: [AUSKLAPPEN] For i = 0 To (FileSize (datafile$)/2)-1 Step 2 byte1 = ReadByte (datafilehandle) byte2 = ReadByte (datafilehandle) PokeByte shortbank,i,byte2 PokeByte shortbank,i+1,byte1 Next |
||
Dreamora |
Do, März 16, 2006 17:02 Antworten mit Zitat
|
|
|---|---|---|
|
Dir ist hoffentlich schon klar, dass das falsch ist, oder?
Wenn dann wären es 4 oder gar 8 Byte, abhängig vom System wo es her kommt. |
||
| Ihr findet die aktuellen Projekte unter Gayasoft und könnt mich unter @gayasoft auf Twitter erreichen. | ||
x_to |
Do, März 16, 2006 18:25 Antworten mit Zitat
|
|
|---|---|---|
von einem 16 bit system...folglich 2 bytes..
|
||
Dreamora |
Do, März 16, 2006 18:44 Antworten mit Zitat
|
|
|---|---|---|
|
Dann bitte das anmerken
Zumal es heutzutage nur noch 32bit oder gar 64bits gibt (G5) |
||
| Ihr findet die aktuellen Projekte unter Gayasoft und könnt mich unter @gayasoft auf Twitter erreichen. | ||
x_to |
Do, März 16, 2006 21:03 Antworten mit Zitat
|
|
|---|---|---|
|
nun...vielleicht habe ich mich auch etwas falsch ausgedrückt.
selbstverständlich kann der MC68000 (Motorola) auch 32 bit hantieren, aber ich bräuchte wirklich maximal 16 bit... da kommt mir auch glatt die frage, warum es diese beiden unterschiedlichen format gibt... 
|
||
Dreamora |
Do, März 16, 2006 21:11 Antworten mit Zitat
|
|
|---|---|---|
|
Müssten eigentlich 3 sein, da der G5 64Bit ist und OSX .4 glaub auch 64bit ist auf solchen Systemen.
Das Format hängt dabei von der "Bitversion" des Betriebssystem ab. Wenn es 16bit ist, dann wird alles in 16Bit gespeichert etc. Ist bei Windows XP und Windows XP 64 nicht anderst. Ursache ist, dass eine Int auf einem 32Bit system 32bit lang ist, auf einem 64bit jedoch 64bit. Selbiges gilt für andere Datentypen. |
||
| Ihr findet die aktuellen Projekte unter Gayasoft und könnt mich unter @gayasoft auf Twitter erreichen. | ||
x_to |
Do, März 16, 2006 21:34 Antworten mit Zitat
|
|
|---|---|---|
|
da ergibt sich doch dann der vorteil von Big Endian.
pro bit wird eben ein wert an- oder vorangestellt. bei little endian muß ja dann alles nochmal "verdreht" werden.... komisch, aber an Little Endian werde ich mich wohl nie gewöhnen... 
|
||
Dreamora |
Do, März 16, 2006 21:57 Antworten mit Zitat
|
|
|---|---|---|
|
Es gibt keinen Vorteil oder Nachteil.
Die PPC haben eine umgedrehte Bitreihenfolge im Prozessor, geladen wird es dort genau gleich wie auf der X86 Seite. Wenn zb eine Zahl 0010 auf X86 ist, dann ist sie auf PPC 0100, deswegen wirds umgekehrt gespeichert. Sonst müssten PPC beim laden die Bit manuell umdrehen, was natürlich schwachsinn wäre 
|
||
| Ihr findet die aktuellen Projekte unter Gayasoft und könnt mich unter @gayasoft auf Twitter erreichen. | ||
x_to |
Sa, Jul 22, 2006 11:24 Antworten mit Zitat
|
|
|---|---|---|
|
ich stehe nun vor dem problem, daß ich irgendwie die daten nicht mehr richtig auslesen kann....irgendwie doof, obwohl ich sie auch in die speicherbank bekommen habe...
an einer stelle im programm will ich gern die aktuelle position auslesen, dann den wert an dieser stelle auslesen und mit den rest der bank vergleichen... allerdings funktioniert das irgendwie nicht...
Code: [AUSKLAPPEN] firstvalue = PeekShort(modbank,startoffset*2)
For i = 0 To BankSize - 1 secondvalue = PeekShort (modbank,i) If secondvalue = firstvalue secondvalue = secondvalue + framecount PokeByte modbank,i,secondvalue EndIf Next dabei ist "modbank" nur eine kopie von "shortbank" |
||
Übersicht
BlitzBasic Allgemein
Powered by phpBB © 2001 - 2006, phpBB Group