Hi there! You are currently browsing as a guest. Why not create an account? Then you get less ads, can thank creators, post feedback, keep a list of your favourites, and more!
Lab Assistant
#76 Old 15th Aug 2011 at 11:08 PM
Quote: Originally posted by SandrineD
Well you can definitely move them...
Circled in red and another circle where it came from.
#1 has moved north to join three others.
it didn't involve the four slots that appear to define the corners but there is more because it renders wrong and disappears if you zoom in too close. So the other numbers must relate to render "windows".
It's cool that there's progress on this! So let me ask - seeing as I don't speak hex so I have no idea what you did! - what did you edit to move the water plane? Also, do you think that the rendering "window" you mentioned might be defined in the other resource simsample discovered - 0x90624C1B?

(Incidentally, when I created a new world to test something out, I discovered that the 0x90624C1B resource was already in the world; I hadn't needed to add it with s3pe, so perhaps it's not specific to the water planes but more of a general resource.)

If the rendering issue can be solved, I might just have to go back and tweak my world-in-progress by raising the rivers (fortunately, I won't have to do any more terrain painting!)...
Advertisement
Lab Assistant
#77 Old 15th Aug 2011 at 11:46 PM
I used a very nice program called HxD it makes cut and paste very easy and I do all kind of non-std things with programs that were never designed to do that.

the 906 doesn't determine position. I experimented using Bridgeport 906 and twinbridge 707's and vice versa. I feel sure all positioning is from 707's.

also the 906 clearly is related as it says how many 707's are used. Even with six 707's in the world file, if you change that byte to 05 it will only show 5 water planes.

what I've found definitely renders the texture of the WP and does it in parts somehow 48 in the case of the smallest one eg WP#1 or WP#3. Other variable obviously effect view windows or whatever you want to call them. eg - the 4 bytes near the start that set the two corners. Also many other unknowns. Also haven't worked out the precise measurements used, so I move it but without the precision I demand.

ps in that 906 in your new world what was the value of byte 12?
Lab Assistant
#78 Old 17th Aug 2011 at 2:32 AM
Quote: Originally posted by SandrineD
I used a very nice program called HxD it makes cut and paste very easy and I do all kind of non-std things with programs that were never designed to do that.
Thanks for getting back to me. Something like that'll come in handy eventually, but for right now, I'm completely lost when it comes to reading hex.

Quote: Originally posted by SandrineD
the 906 doesn't determine position. I experimented using Bridgeport 906 and twinbridge 707's and vice versa. I feel sure all positioning is from 707's.

also the 906 clearly is related as it says how many 707's are used. Even with six 707's in the world file, if you change that byte to 05 it will only show 5 water planes.
That's interesting. So maybe the 906 is just an index resource that says "here's how many water plane resources there should be" and the 707's give the specifics for the positions of the planes and their view windows. In theory, then, that should allow us to specify any number of water planes that we want.

Quote: Originally posted by SandrineD
what I've found definitely renders the texture of the WP and does it in parts somehow 48 in the case of the smallest one eg WP#1 or WP#3. Other variable obviously effect view windows or whatever you want to call them. eg - the 4 bytes near the start that set the two corners. Also many other unknowns. Also haven't worked out the precise measurements used, so I move it but without the precision I demand.
Hmm, I wonder if when simsample edited the corner coordinates, it only moved the view window but left the actual water plane in the original spot - hence the hole in the terrain since the view window and the water plane didn't match.

As for the textures - maybe they're multi-tile textures instead of single tile textures, so the 48 parts of the two small water planes could represent a rectangle that's six texture units deep by eight texture units wide. So if the water texture is an 8 tile x 8 tile unit, then the water plane would be 48 tiles deep by 64 tiles wide. (Just a thought off the top of my head - probably not correct, but who knows!)

Quote: Originally posted by SandrineD
ps in that 906 in your new world what was the value of byte 12?
I haven't a clue, alas! All I know is that when I went in with S3PE to add the 906 it was already there. I replaced it anyway just to be safe, so I don't know what the original value was. I also don't have a hex editor - yet - so I wouldn't be able to find byte 12 if my life depended on it!
Lab Assistant
#79 Old 17th Aug 2011 at 8:45 AM
Don't worry I checked myself. The 906 also specifies map size so it has to be there. On a default the 12th byte is 00 as there are no additional Water Planes.
e3 d3 Ne2 Nd2 Nb3 Ng3
retired moderator
Original Poster
#80 Old 17th Aug 2011 at 1:14 PM
Quote: Originally posted by buxcosim
Hmm, I wonder if when simsample edited the corner coordinates, it only moved the view window but left the actual water plane in the original spot - hence the hole in the terrain since the view window and the water plane didn't match.

Yes, that sounds likely. I didn't play with it for very long, so didn't get as far as SandrineD! :D

Quote: Originally posted by SandrineD
Don't worry I checked myself. The 906 also specifies map size so it has to be there. On a default the 12th byte is 00 as there are no additional Water Planes.

That's not all that there is to map size though, as unfortunately importing UNKN 0x90624C1B from a large world into a small world does not change its size!

Great progress, SandrineD! Thanks all for contributing to this thread, it is most interesting!
Lab Assistant
#81 Old 17th Aug 2011 at 9:49 PM
Spending way too much time on these sidetracks really
I should be focused on my real projects.
However, I have an insatiable curiosity and it has been piqued!

sifted through a few files and earmarked the ones that look like possibilities mostly based upon having 08 in large and 01 in tiny worlds and other things that appear similar.

These texture things are definitely tiled.

See below the final result after loading around 7 files including the 906 thing from before.
This started as a tiny map and the four small pyramids were placed at the corners. Now we see the possible ground extends 8 times more in both directions, far off the view edges.

Just not sure yet, which of the 7 are compulsory!?

e3 d3 Ne2 Nd2 Nb3 Ng3
retired moderator
Original Poster
#82 Old 17th Aug 2011 at 11:53 PM
Excellent! You made a small world large! :D

You could find out which resources are compulsory by removing them one by one, and testing each time.
Lab Assistant
#83 Old 18th Aug 2011 at 12:53 AM
Quote: Originally posted by SandrineD
Don't worry I checked myself. The 906 also specifies map size so it has to be there. On a default the 12th byte is 00 as there are no additional Water Planes.
That makes sense. So by editing byte 12, we might be able to create as many water planes as we need - assuming of course that the map size matches. That would open up a lot of possibilities if the rendering issues could be resolved.

Quote: Originally posted by SandrineD
sifted through a few files and earmarked the ones that look like possibilities mostly based upon having 08 in large and 01 in tiny worlds and other things that appear similar.
I don't know if this means anything, but 2048 (the size of the largest map) is 8 x 256 (the size of a terrain chunk). Perhaps the number 08 in that byte refers to the number of terrain chunks, so a value of 08 means a square world that's 8 chunks by 8 chunks = 2048 x 2048. Maybe by altering the value we could create custom map sizes, for example a value of 6 might create a map thats 1536 x 1536, while a value of 16 might create a monster map at 4096 x 4096 - and probably crash most computers that try to play it!

Quote: Originally posted by SandrineD
These texture things are definitely tiled.
If the number above represents the number of chunks in the world, then maybe the texture tiles for the terrain are related to the size of the chunks. If CAW creates the final terrain image in 256 x 256 tiles, then that could explain why we're not supposed to use more than 8 terrain paints per chunk - CAW simply has problems creating a tile that's too complex.

Looking at simsample's size data, the sizes of all but one of Bridgeport's water planes are multiples of 8, so maybe the tile size for the water plane is 8 squares x 8 squares. (If the corner coordinates represent the viewing window and not the water plane itself, then the one plane that isn't a whole number multiple of 8 could just mean that its viewing window is smaller than the plane.)

Again, just some thoughts, probably off base, but who knows!

Great progress on this! I just wish I spoke hex, so I could help test some of these things myself. (Sometimes I think that people use hex just to be difficult...)
Lab Assistant
#84 Old 18th Aug 2011 at 1:11 AM
people use hex because computers like it.Well really they like binary but thats worse. Besides thats why 8 bits make a byte and 2PWR8=256 which is also 16sqrd. Thats why you get all those pairs ranging from 00 to FF.

Now back to the matter... my wish is also to make a bigger map.
Maybe its possible, but even if it worked just by changing these files it would be a lot of work bec of how they are structured. Plus the program appears to have a trap in it that stops you loading a height file greater than 2048x2048. For me that would render the point moot if I can't fix it... but then, thats an assumption!

Maybe I'll look into it!?
e3 d3 Ne2 Nd2 Nb3 Ng3
retired moderator
Original Poster
#85 Old 18th Aug 2011 at 8:54 AM
buxcosim, I think you have it exactly right, as if you look at the resources in a world file you'll see many of them are addressing a single chunk.

SandrineD, perhaps you could let us know which resources you imported to change the world size and what you edited to move the water levels? That way, others could test for you and we could make a little tutorial. Great work, although I think you're being very ambitious to attempt to change the maximum world size, I don't think that will be possible. Worth looking at, though!
Lab Assistant
#86 Old 18th Aug 2011 at 9:27 AM
Agreed, we will probably not be able to change the max size, but definitely worth looking. I'm trying to get my friend to look into it if he ever has time since he has in the past done things like that, finding things people said would never be found.

The files:
As well the one we were looking at before... S3_90624C1B_00000000_0000000000000001%%+UNKN.bnry which frankly only seems to change the 'first viewing position' when you open a world in CAW.

These files all looked like they had the right 'patterns'
S3_2AD195F2_00000000_0000000000000001%%+UNKN.bnry
S3_3D8632D0_00000000_0000000000000001%%+UNKN.bnry
S3_05CD4BB3_00000000_0000000000000001%%+UNKN.bnry
S3_06DC847E_00000000_0000000000000001%%+UNKN.bnry
S3_044735DD_00000000_0000000000000001%%+UNKN.bnry
S3_9063660D_00000000_0000000000000001%%+WTXT.wrldtxtrmap

Files like the BB3 one will be really annoying as it lays out the 64 tiles [256x256] needed for the 2048x2048 world and a section for each [256bytes].
So if you wanted a 4096x4096, you'd have to generate 256 tiles.
It might come down to a case of being able to make it but it still wont load in CAW!?
Who knows.
Lab Assistant
#87 Old 19th Aug 2011 at 3:24 AM
Quote: Originally posted by SandrineD
people use hex because computers like it.Well really they like binary but thats worse. Besides thats why 8 bits make a byte and 2PWR8=256 which is also 16sqrd. Thats why you get all those pairs ranging from 00 to FF.
I'm just old-fashioned - I prefer decimal! That way, if I want a value of 256, I can just say 256 and not get confused!

Quote: Originally posted by SandrineD
Now back to the matter... my wish is also to make a bigger map.
Maybe its possible, but even if it worked just by changing these files it would be a lot of work bec of how they are structured. Plus the program appears to have a trap in it that stops you loading a height file greater than 2048x2048. For me that would render the point moot if I can't fix it... but then, thats an assumption!
Well, this being EA, chances are the files are structured in ways that make simple changes a nightmare to implement, and the world size limit does makes sense since larger maps can strain lower-end computer systems; they probably put that in just to keep people from trying to make maps that would crash their systems!

Quote: Originally posted by simsample
buxcosim, I think you have it exactly right, as if you look at the resources in a world file you'll see many of them are addressing a single chunk.
It just struck me that in the file SandrineD mentioned, the value was 8, and in the large map there are 64 (8 x 8) chunks, so I thought that perhaps the terrain textures would be handled on a chunk by chunk basis as well. Just a hunch, but who knows? Maybe it'll lead to a breakthrough if it pans out!

Quote: Originally posted by SandrineD
Files like the BB3 one will be really annoying as it lays out the 64 tiles [256x256] needed for the 2048x2048 world and a section for each [256bytes].
So if you wanted a 4096x4096, you'd have to generate 256 tiles.
It might come down to a case of being able to make it but it still wont load in CAW!?
Just out of curiosity, when you changed the world size value in the other resource from 01 to 08, did it automatically update the BB3 resource? The original world had a size value of 01 and only 1 texture tile, but when you changed the value to 08 to get a large world, did the BB3 resource automatically convert from a 1 x 1 tile world to an 8 x 8 tile world? If it was automatic, that could make it easier to generate custom map sizes; if it's not automatic, then it would really be a pain to have to do it manually!
Lab Assistant
#88 Old 19th Aug 2011 at 7:10 AM
I suppose programs for general release have to have safeguards or EA would be even more swamped with complaints.
Its like the people who say they want to have realistic moving hair but expect to run it on a standard computer
ps - I think you'd need a render farm for that!

That's not a maybe, its definitely in tiles or chunks [as you say].
Its even noted in one of the EA documents that tiling takes place and the size is 256x256.

In my last experiment I didn't edit all the files, the ones like BB3 I copied over from a base world of a larger size.
This was just to prove that it worked and to identify which files did it!

If you can use S3PE [not at all hard] you can do some experiments.
.. and don't forget to report back here!

C'est la vie, they say, because they can't change their world, but, we can! That's why we have CAW! :rolleyes:
Lab Assistant
#89 Old 19th Aug 2011 at 9:09 AM
I'm working a world that I would love to have more then one plane of water in it. So I used a hex editer to try and figure out the 707 files and this is what I have came up with:
https://docs.google.com/a/zaidesthi...d=1&output=html
It's not much but maybe it will help someone.
The files have 2 parts that repeat a number of times depending on the DWORD before them. Can't figure out what they are storing maybe someone else can. There is also what looks like a random number of DWORDs with low values at the end of each file that I haven't even tried figuring out.
Lab Assistant
#90 Old 19th Aug 2011 at 11:13 AM
Yeah that pretty much agrees with what I've found so far except to note what I've said above.
Y? - you can remove the ? its definitely the altitude of the plane.
The indexes as you call them indicate the number of blocks following of 11 and 39 bytes respectively.
The number of blocks in the first group appear to be the render chunks and are proportional to the size of the water plane area.
The second group appears similar, perhaps render at a diff LOD???
Did you notice the 2nd index is always 1/12 of the first index?
The random data, as you put it, at the end is something like a list of indexes.
The interesting thing is that the size of the range of values is equal to index2 or the number of data sets in the 2nd data block.
eg - #1 the values range from 0-3 and the 2nd index is 4.

It appears that these files are more about rendering than positioning although the alt is determined in here. But, then, from a certain perspective you could think of that as part of the rendering issue.

C'est la vie, they say, because they can't change their world, but, we can! That's why we have CAW! :rolleyes:
Lab Assistant
#91 Old 20th Aug 2011 at 2:52 AM
Quote: Originally posted by SandrineD
I suppose programs for general release have to have safeguards or EA would be even more swamped with complaints.
Yeah, and with CAW having all of the memory management problems that it does, it's a wonder that even the 2048 x 2048 worlds work sometimes!

Quote: Originally posted by SandrineD
That's not a maybe, its definitely in tiles or chunks [as you say].
Its even noted in one of the EA documents that tiling takes place and the size is 256x256.
I remember reading that the worlds were divided into 256 x 256 chunks, but I wasn't sure how (or if) that applied to the texture mapping; I just assumed that it probably did. When you mentioned that you found a byte that controls world size, it just struck me that the value of the byte could be refering to the number of tiles/chunks since multiplying the tile size by the value of the byte gave the world size.

Quote: Originally posted by SandrineD
In my last experiment I didn't edit all the files, the ones like BB3 I copied over from a base world of a larger size.
This was just to prove that it worked and to identify which files did it!
Ah, okay. That'll have to be another thing to try then to see if changing one file automatically updates the other.

Quote: Originally posted by SandrineD
If you can use S3PE [not at all hard] you can do some experiments.
.. and don't forget to report back here!
I'm finding S3PE easy to use for basic functions - importing/exporting resources and so on. My problem is that I don't have any clue what to do with the resources after I get them extracted since I don't read hex. To me, it's all a bunch of 00 05 F3 and so on. So basically, I just use S3PE to extract a resource I know I need (because someone else figured it out), and then I paste it into another world. And I only just started using it because of this thread - I knew I needed it in order to get raised water in my world! I still have a ton of stuff to learn before I can get into anything more complicated.

Quote: Originally posted by SandrineD
It appears that these files are more about rendering than positioning although the alt is determined in here. But, then, from a certain perspective you could think of that as part of the rendering issue.
Which bytes specifically did you edit to move the water plane? (For example, byte 12 in the 906 resource controls the number of water planes, so which bytes did you change in the 707's to control the x, y, and z positions?) I know which ones simsample changed that didn't work (the ones for the apparent corner positions), so knowing which bytes do work would save some time and give me (and everyone!) a good place to start experimenting - after I learn to read hex!

On second thought, maybe a hex-to-decimal converter might be a better option for me...
Lab Assistant
#92 Old 20th Aug 2011 at 7:31 AM Last edited by zaide_chris : 20th Aug 2011 at 11:31 AM.
OK the number of blocks in the first group is FLOOR(X/32)*FLOOR(Z/32)*12
and number of blocks in the second group is FLOOR(X/32)*FLOOR(Z/32)

For the blocks in the first group
WORD: BLOCK1X divide by 4 to get cord in the same units as X1,X2
WORD: BLOCK1Z divide by 4 to get cord in the same units as Z1,Z2
DWORD: i think this is a floating point number = to 0? have no clue for all the bp files it is allways bc7f0400 but in tb it's 9e430400 or bc7f0400- note tb's water plane is much larger
BYTEs 9-11: Allways 80ff80

Going to start looking at the second group now.

Edit:
For the blocks in second group
DWORD: BLOCK2X1 floating point number in the same units as X1,X2
DWORD: BLOCK2Z1 floating point number in the same units as Z1,Z2
DWORD: BLOCK2X2 floating point number in the same units as X1,X2
DWORD: BLOCK2Z2 floating point number in the same units as Z1,Z2
BYTEs 17-39: Allways 01010000000000ffffffffffff

Edit:
and heres the top part
WORD: Allways 0500
DWORD: Y floating point number
DWORD: X1
DWORD: Z1
DWORD: X2
DWORD: Z2
DWORD: XA floating point number
DWORD: ZA floating point number
DWORD: Allways 03000000

it's all together at
https://docs.google.com/a/zaidesthi...ut=html&ndplr=1
Lab Assistant
#93 Old 20th Aug 2011 at 8:10 PM
Similar idea re the triangles, screenprint from excel chart with 16 data series...
no time right now, have to do some work on friend's project to return the favours


C'est la vie, they say, because they can't change their world, but, we can! That's why we have CAW! :rolleyes:
e3 d3 Ne2 Nd2 Nb3 Ng3
retired moderator
Original Poster
#94 Old 20th Aug 2011 at 8:27 PM
Thanks everyone, lots of great information, please keep the ideas coming!
Lab Assistant
#95 Old 20th Aug 2011 at 9:41 PM
Briefly here's the one for the second set of data, I think you can see what's happening now.
nb - if using excel it can convert 4digit hex using =HEX2DEC but doesn't do 8digit fps so you need to add a fn or two.


C'est la vie, they say, because they can't change their world, but, we can! That's why we have CAW! :rolleyes:
Lab Assistant
#96 Old 20th Aug 2011 at 9:55 PM
=HEX2DEC(RIGHT(E20,2)&MID(E20,5,2)&MID(E20,3,2)&LEFT(E20,2)) should work if your viewing the files as 8bit and you remove the spaces most hex editors add

=IF(LEFT(RIGHT("000000000"&HEX2BIN(MID(E19,7,2)),8))=1,-1,1)*(BIN2DEC("1"&RIGHT("000000000"&HEX2BIN(MID(E19,5,2)),7))/128+BIN2DEC(RIGHT("000000000"&HEX2BIN(MID(E19,3,2)),8))/32768+BIN2DEC(RIGHT("000000000"&HEX2BIN(MID(E19,1,2)),8))/8388608)*POWER(2,BIN2DEC(RIGHT("000000000"&HEX2BIN(MID(E19,7,2)),7)&LEFT(RIGHT("000000000"&HEX2BIN(MID(E19,5,2)),8),1))-127) and that should work for floating point numbers
Lab Assistant
#97 Old 20th Aug 2011 at 10:33 PM
by the way the tile size is 32x32.
so #1 which is 64x64 has 2x2 tiles and therefore 4 sets of data in the second set.
I presume also why the word after the x,z averages is always 3 to indicate 3 sets of data perhaps!?
the last set then refers to tiles by order number which is why the range of these values is always equal to the # entries in dataset2

Already had a set of functions like this...

Option Explicit

Quote:
' shg 2008-0919, 2009-0517 (minor changes)

' Routine Input Output WF/VBA
' -------- -------------------- -------------------------- ------
' Byte2Sng ab(0 To 3) Single VBA
' Sng2Byte Single 4-byte array Variant Both
' Sng2Hex Single Hex String Both
' Hex2Sng Hex string Single Both
' Var2Sng 4-byte array Variant Single Both

' Routine Input Output WF/VBA
' -------- -------------------- -------------------------- ------
' Byte2Dbl ab(0 To 7) Double VBA
' Dbl2Byte Double 8-byte array Variant Both
' Dbl2Hex Double Hex string Both
' Hex2Dbl Hex string Double Both
' Var2Dbl 8-byte array Variant Double Both

' Routine Input Output WF/VBA
' -------- -------------------- -------------------------- ------
' Flt2Byte Single or Double 4- or 8-byte array Variant VBA
' Byte2Hex Byte array Hex string VBA

'===============================================================================
' User-defined data types
' (Necessary because that's the only way LSET works)
'===============================================================================
Type uab4: ab(0 To 3) As Byte: End Type
Type uab8: ab(0 To 7) As Byte: End Type

Type uFlt: f As Single: End Type
Type uDbl: d As Double: End Type

'===============================================================================
' Functions for Singles (church dances)
'===============================================================================
Function Byte2Sng(ab() As Byte) As Single
' Returns the conversion of
' the Big-Endian, 0-based, 4-byte array ab to a Single

' SNaN will cause overflow (as it should)

' VBA function only

Dim ub As uab4
Dim uf As uFlt

' put the bytes in Little-Endian order
ub.ab(3) = ab(0)
ub.ab(2) = ab(1)
ub.ab(1) = ab(2)
ub.ab(0) = ab(3)

' copy the bytes into the float
LSet uf = ub
Byte2Sng = uf.f
End Function

Function Sng2Byte(f As Single) As Variant
' Returns the conversion of Single f to
' a Big-Endian, 0-based, 4-byte array in the variant

' Worksheet function or VBA

Dim ab(0 To 3) As Byte
Dim ub As uab4
Dim uf As uFlt
Dim i As Long

uf.f = f

' copy the single into the byte array
LSet ub = uf

' put the bytes in Big-Endian order
For i = 0 To 3
ab(i) = ub.ab(3 - i)
Next i

Sng2Byte = ab
End Function

Function Var2Sng(v As Variant) As Single
' Returns the conversion of
' the Big-Endian, 1-based, 4-byte array in v to a Single

' Worksheet function or VBA

Dim ub As uab4
Dim uf As uFlt
Dim i As Long

' put the bytes in Little-Endian order
For i = 0 To 3
ub.ab(i) = v(4 - i)
Next i

' copy the bytes into the float
LSet uf = ub
Var2Sng = CSng(uf.f)
End Function

Function Sng2Hex(f As Single) As String
' Returns the conversion of float f to a hex string

' Worksheet function or VBA

Const sPad As String = "0"
Dim uf As uFlt
Dim ub As uab4
Dim i As Long

uf.f = f
LSet ub = uf

For i = 0 To 3
Sng2Hex = Right(sPad & Hex(ub.ab(i)), 2) & " " & Sng2Hex
Next i

Sng2Hex = Left(Sng2Hex, Len(Sng2Hex) - 1)
End Function

Function Hex2Sng(ByVal s As String) As Single
' Converts hex string s to a Single

' Worksheet function or VBA

Const sPad As String = "00000000"
Dim i As Long
Dim ub As uab4
Dim ab(0 To 3) As Byte

s = Replace(s, " ", "")
If Len(s) > 8 Then Exit Function
If Len(s) < 8 Then s = Right(sPad & s, 8)

For i = 0 To 3
ab(i) = CByte("&H" & Mid(s, 2 * i + 1, 2))
Next i

Hex2Sng = Byte2Sng(ab)
End Function

'===============================================================================
' Functions for Doubles (swap meets)
'===============================================================================
Function Byte2Dbl(ab() As Byte) As Double
' Returns the conversion of
' the Big-Endian, 0-based, 8-byte array ab to a Double

' VBA function only

Dim ub As uab8
Dim ud As uDbl
Dim i As Long

' put the bytes in Little-Endian order
For i = 0 To 7
ub.ab(7 - i) = ab(i)
Next i

' copy the bytes into the double
LSet ud = ub
Byte2Dbl = ud.d
End Function

Function Var2Dbl(v As Variant) As Double
' Returns the conversion of
' the Big-Endian, 1-based, 8-byte array in v to a Double

' Worksheet function or VBA

Dim ub As uab8
Dim ud As uDbl
Dim i As Long

' put the bytes in Little-Endian order
For i = 1 To 8
ub.ab(8 - i) = v(i)
Next i

' copy the bytes into the double
LSet ud = ub
Var2Dbl = ud.d
End Function

Function Dbl2Byte(d As Double) As Variant
' Returns the conversion of Double d to
' a Big-Endian, 0-based, 8-byte array in the variant

' Worksheet function or VBA

Dim ab(0 To 7) As Byte
Dim ub As uab8
Dim ud As uDbl
Dim i As Long

ud.d = d
LSet ub = ud

' output the bytes in Big-Endian order
For i = 0 To 7
ab(i) = ub.ab(7 - i)
Next i
Dbl2Byte = ab
End Function

Function Dbl2Hex(d As Double) As String
' Returns the conversion of Double d to a hex string

' Worksheet function or VBA

Const sPad As String = "0"
Dim ud As uDbl
Dim ub As uab8
Dim i As Long

ud.d = d
LSet ub = ud

For i = 0 To 7
Dbl2Hex = Right(sPad & Hex(ub.ab(i)), 2) & " " & Dbl2Hex
Next i

Dbl2Hex = Left(Dbl2Hex, Len(Dbl2Hex) - 1)
End Function

Function Hex2Dbl(ByVal sInp As String) As Double
' Converts hex string sInp to a Double
' Worksheet function or VBA

Const sPad As String = "0000000000000000"
Dim i As Long
Dim ub As uab8
Dim ab(0 To 7) As Byte

sInp = Replace(sInp, " ", "")
If Len(sInp) > 16 Then Exit Function
If Len(sInp) < 16 Then sInp = Right(sPad & sInp, 16)

For i = 0 To 7
ab(i) = CByte("&H" & Mid(sInp, 2 * i + 1, 2))
Next i

Hex2Dbl = Byte2Dbl(ab)
End Function

'===============================================================================
' Functions for Either (metrosexuals)
'===============================================================================
Function Flt2Byte(flt As Variant) As Variant
' Returns the conversion of flt to
' a Big-Endian, 0-based, 4- or 8-byte array Variant

' VBA function only

Dim ab8(0 To 7) As Byte
Dim ub8 As uab8
Dim ud As uDbl

Dim ab4(0 To 3) As Byte
Dim ub4 As uab4
Dim uf As uFlt

Dim i As Long

Select Case VarType(flt)
Case vbSingle
uf.f = flt

' copy the single into the byte array
LSet ub4 = uf

' put the bytes in Big-Endian order
For i = 0 To 3
ab4(i) = ub4.ab(3 - i)
Next i
Flt2Byte = ab4

Case vbDouble
ud.d = flt

' copy the single into the byte array
LSet ub8 = ud

' put the bytes in Big-Endian order
For i = 0 To 7
ab8(i) = ub8.ab(7 - i)
Next i
Flt2Byte = ab8
Case Else
Flt2Byte = CVErr(xlErrValue)
End Select
End Function

Function Byte2Hex(ab() As Byte) As String
' Converts ab to a hex string
' VBA function only

Dim i As Long

For i = LBound(ab) To UBound(ab)
Byte2Hex = Byte2Hex & Hex(ab(i)) & " "
Next i
Byte2Hex = Left(Byte2Hex, Len(Byte2Hex) - 1)
End Function

C'est la vie, they say, because they can't change their world, but, we can! That's why we have CAW! :rolleyes:
Lab Assistant
#98 Old 20th Aug 2011 at 11:03 PM
hmmm, I think I just realized what the last set is but let me check the theory first, it might also mean the 03 isn't sets of data but LODs.... maybe

C'est la vie, they say, because they can't change their world, but, we can! That's why we have CAW! :rolleyes:
Lab Assistant
#99 Old 20th Aug 2011 at 11:41 PM
a slight revision... there isn't a specific tile size
its all determined by the co-ords of the vertices

C'est la vie, they say, because they can't change their world, but, we can! That's why we have CAW! :rolleyes:
Lab Assistant
#100 Old 21st Aug 2011 at 12:07 AM
for a start, forget the LOD thing... more likely the 03 is to indicate the number of vertices in each set.
Looking at #0 #1 #3 the third dataset becomes clear.
Look at the number of tiles in x and z dir, call them xt and zt
the # words in D3 is = xt*(zt+1)+1
D3 solved!
Look...

#1 7 words
02 00 00 00

02 00 00 00
00 00 00 00
01 00 00 00

02 00 00 00
02 00 00 00
03 00 00 00

#0 37 words
06 00 00 00

05 00 00 00
00 00 00 00
01 00 00 00
02 00 00 00
03 00 00 00
04 00 00 00

05 00 00 00
05 00 00 00
06 00 00 00
07 00 00 00
08 00 00 00
09 00 00 00

05 00 00 00
0A 00 00 00
0B 00 00 00
0C 00 00 00
0D 00 00 00
0E 00 00 00

05 00 00 00
0F 00 00 00
10 00 00 00
11 00 00 00
12 00 00 00
13 00 00 00

05 00 00 00
14 00 00 00
15 00 00 00
16 00 00 00
17 00 00 00
18 00 00 00

05 00 00 00
19 00 00 00
1A 00 00 00
1B 00 00 00
1C 00 00 00
1D 00 00 00

C'est la vie, they say, because they can't change their world, but, we can! That's why we have CAW! :rolleyes:
Page 4 of 9
Back to top