BlitzMax x86 OSX Bank problems
BlitzMax Forums/BlitzMax Programming/BlitzMax x86 OSX Bank problems
| ||
| Ok the first problem I've run into besides not being able to Build All Modules (see my bug reports thread) is this: My program has a map loader which uses a TBank, and is getting odd values with PeekInt(). Could this be a problem with endian-ness? I have tried both endian switches on the bank load line, and though my game seems to run fine under Rosetta (the PPC version of it), the Intel version seems to only be able to Peekbyte successfully, not PeekInt... Hmmm... Any ideas? |
| ||
| If PeekByte works but not PeekInt it could be an endianess issue. If you know the value, you could look at the bytes of the integer to see if they are switched. |
| ||
| Any chance that you haven't converted your map from PPC to X86 before trying to load it? Doing so, when I'm not completely wrong can be done by reading it as a PPC endian stream and save it X86 endian. TBank is endian independent and works differently, at least I think someone from BRL mentioned something like that, unlike TStream. |
| ||
| Hi Dreamora, going to resurrect this thread cos I want to do some work on my game on my old PPC laptop while away. So how would I convert the endianness of the map files I'm using then? |
| ||
| Load them and save them with the appropiate flags and headers. I'll suggest you to take a look to the LoadText and SaveText functions of the TTextStream module, to see very easily how to do this kind of stuff. |
| ||
| Thanks I've had a look but I'm none the wiser..! So I should load the bank as text and save as text to convert? |
| ||
| Sorry Ziggy could you elaborate a little? |
| ||
OK, I've recently ran into this problem as well. It is an endianess problem related to how PPC and x86 processors store values greater than a byte. Basically, PPC processor store their values hi-byte to lo-byte, while x86 store them lo-byte to hi-byte. You have to take this into account when using the Peek and Poke commands, as the endian settings are used for streams only. You could use a bank stream, but I chose to simply account for the processor in use when doing my Peek/Poking, thus..?x86 lev.timeLimit=PeekShort(bank,offset+ldLimit) ?PPC lev.timeLimit=PeekByte(bank,offset+ldLimit)+256*PeekByte(bank,offset+ldLimit+1) ? As you can see, there are compiler directives to check which processor is being used. As the original file was created on a PC (x86) I simply checked if the program was being compiled on a PPC Mac and simply calculated the correct value using PeekByte instead. Naturally, this is a little slower, but all my data is transported into an array before the game starts, so speed here is not an issue. You would do something similar for ints (4 bytes). Hope that points you in the right direction. |
| ||
| Excellent, thanks for the tip, this should solve the problem. |
| ||
| You need to SAVE your data using the same endianness that you load it with. That should take care of all issues. If not, you can just read in an Int from the bank and then do byte masking and swapping to turn it into the right format. |
   |