Tree[d]
Community Forums/Developer Stations/Tree[d]
| ||
| Hi, I'm just curious as to the use of tree[d]. Judging by the fact that it is available to all, would I be allowed to use the resource about the .gls file type in order to make a .b3d convertor for exports from tree[d]? I just thought I should ask, because I may do this if I ever need to do trees. |
| ||
| or, better yet, if it's allowed, has anyone done this? |
| ||
| http://www.blitzbasic.com/Community/posts.php?topic=34416 |
| ||
| Well, I guess I'll ask fredborg... He's been a bit unclear in that thread. Oh, no email specified... I'll jsut wait. Fred, is this a No no, or just an I'm not doing it no? |
| ||
| I like [d] by the way a bit like the [g] in giles! |
| ||
| *insane moan* Arrrghh! Cryptic computer language-like file format that seems to waste more space than needed, you have got to be kidding me! If anyone has a few pointers on reading symbolic writing that looks like it's from A Million BC that would be great :D If not, I'll either turn up in a straight-jacket at an insane assylum or just give up... OOOH, that's why noone's done it! |
| ||
| By the way, the page about the gile[s] file format tells me nothing!! absolutely nothing!!! nothing at all!!!11 Oh no, I think I'm going insane.... |
| ||
| gls isn't a hard format ... compared to the full obj and stuff like that it is small kiddies level ... |
| ||
| http://www.frecle.net/giles/glsspecs.htm That looks very simple actually.
GLS_HEADER
GLS_LIGHTMAPS
GLS_LMAP
GLS_TEXTURES
GLS_TEX
GLS_TEX
GLS_MATERIALS
GLS_MAT
GLS_MAT
GLS_MODELS
GLS_MODEL
GLS_MESH
GLS_MESH_SURFACES
GLS_MESH_SURF
GLS_MESH_SURF
GLS_MODEL
GLS_PIVOT
GLS_MODEL
GLS_LIGHT
GLS_RENDER
If you read that from top to bottom, the chunks will all be stored in the file in that order. In other words, you read two bytes that that tells you what is in a chunk. The chunk ID. What follows is the data in it. The data itself tells you how big that data will be. Some chunks might be 5 bytes long always. Others might be a string with an integer at the start that tells you the string is 100 characters long. But all you need to do is read that data in until you know there's no more data to read. Then you are at the next chunk ID! In actuality, this file format doesn't seem to waste any space at all. There are no chunks stored that are not needed, and chunks are not a fixed size that must be filled with zeroes if all the space is not used. Compare this with Microsoft Word which actually stores data from your ram in the word files, and saves old data from the document in there too even after you thought you deleted it from the document. Much simpler and more svelte than HTML too. Kinda reminds me of the B3D format, but easier to understand. But that may just be because the documentation is better. |
| ||
| By the way, the page about the gile[s] file format tells me nothing!! absolutely nothing!!! nothing at all!!!11 On the contrary it tells you everything. Oh no, I think I'm going insane.... Possibly :) |
| ||
| lol, I was tired out from just getting back from a trip. I have found where the model info is stored however... I think I'll just have to look at what changes when I alter the mesh slightly to find out how it works. Oh, by the way, I do think this is a good format. Very smart and to the point. The bit that made me say that the online material is useless, is where I should ask for help: What does the chunk ID stuff have to do with the saved file? |
| ||
| Swifty pretty much hit it on the head dillpickle... Maybe you should do some background reading into reading/writing file formats... Then you will understand what it all means and what you have to do to write a loader |
| ||
| good idea marc! Any ideas where I could find one? (A link to that tutorial site everyone likes perhaps... I forgot the url) |
| ||
| The first two bytes in the file are the first chunk id. That would be the ID of this chunk: GLS_HEADER The chunk follows those two bytes, and if you look at how the chunk says it's data is set up, it should be obvious how big the chunk is. The chunk may vary in size, but there will be bytes within the chunk that tell you how big each part of the chunk is. Once you read all the bytes in the chunk you are at the next chunk ID. Read those two bytes in and then read in the chunk data as that particular style of chunk specifies. |
| ||
| ahh, I think the main problem was that I was on lucida console font for some reason in notepad. I'm viewing in a proper one now, and I can see a lot more I think I still could use some help on reading the symbols :D |
| ||
| you dont read the symbols.. You read it into blitz using the readbyte/readbytes functions. |
| ||
| EDIT: It just occurred to me that my post fits better in a different thread, in the Blitz3D section. Off I go! |
| ||
| oh gah! Stupid me, I'll look into that shortly. |
| ||
| You were reading the file in NOTEPAD?! Ooooh jeez... :-) Yeah... the file is a binary format, not text format. I would _never_ have guessed you were having problems figuring out the format because you were trying to examine the file in notepad. That document linked to above tells you what order the bytes need to be read in. You'd never make sense of it trying to examine it directly, even if you used a hex editor, which is what you really need to use if you want to examine a binary file. Notepad won't even load half the data in if you try to look at a binary file, because it stops every time it sees a byte with the number 13 in it, which stands for enter. It thinks that's the end of a line. Among other problems. |
| ||
| LOL! I can see why the documentation didn't make any sense to you :) |
| ||
| oh cool, 13 stands for enter? and it stops there?? That's a weird coincidence because 13 is an unlucky number. Heh, I'm losing it. Good thing I mentioned notepad there, I almost didn't until I realised "They might think I'm using Word or something..." Okay, it's making some more snse now, but how do I find the labels? as a test I have the following:
Load = readfile("file_format_test_2_4.gls")
repeat
value = readint( Load )
print "Byte: " + value
if value = $2001 then runtimeerror "Yay"
if eof(Load) = true then runtimeerror "All done. If it says this, then you suck."
forever
According to the resource page, chunk ID's are ints, so I'm trying to find the chunk ID's. However, they aren't turning up... Correction: The chunk ID's work for the header stuff, just not the model stuff. Edit: Oh, and I protect my dignity by saying that I was mislead because the writeLine function just writes plain text, so I thought that thus every one of the file commands does that. The scary thing is, I was starting to understand a very small amount of that stuff in notepad... |
| ||
| Ints in blitz are longints. You want to read shorts. Shorts are two bytes. Longints are 4. |
| ||
| Yay it says Yay! Thanks. I'm on the road now :D Umm... Heh, in a ditch already! I can get the mesh data at $2000, but I can't find the model data at $1000. Is this unneaded perhaps? |
| ||
| Your problem is you are not reading the file the right way. Let's say you read the int that is the header chunk id. That chunk then has data in it. Maybe that data is 3 bytes long. Now if you don't need that data, you can skip over those 3 bytes. But you MUST skip ahead 3 bytes. If you try to just look through the file for $1000, you might find DATA that just happens to have that number. Or, as you found, you might find nothing at all... even if there is a chunk with $1000 for it's id, because you are offset one byte, so you read the value as $FF10 and $00AE. See the $1000 in the middle? You didn't find that cause you read two integers instead of reading the data correctly and reading bytes when you need to read a byte and shorts when you need to read a short. |
| ||
| Let's start with the header: GLS_HEADER $FFFF String + Float + Sub Chunks The document says: Byte 1 byte When used as a flag, a byte should be 0 for off and 1 for on. Short 2 bytes Integer 4 bytes Float 4 bytes String X bytes Strings in the gls file format are zero terminated. Sooo... GLS_HEADER $FFFF String + Float + Sub Chunks Start at the beginning of the file. Read a short. That is the chunk ID. That will be $FFFF. Now read the string. It is a C style string, not a Blitz style string, so read one byte at a time and place it in your string... until you reach a 0. Don't put the 0 in the string. That is jsut a marker sating the string has ended. Now read a "float". Float here is 4 bytes. The same size and format as a Blitz float. So read a blitz float in. You are now done reading the first chunk. The "Sub chunks" it refers to just means that there may be chunks after the chunk. So continue in this way. Read the next chunk id, a short, and then use that id to figure out what data you need to read in. And remember, if you don't need certain data, if possible, you can skip ahead by that many bytes instead of reading it. Unfortunately null terminated strings don't allow you to skip ahead because they don't tell you how long they are. So you have to read all of it until you get to a 0. Skipping ahead doesn't access the disk which is why you might want to do that. It'll be faster. |
| ||
| okay, I just came across where that problem gets more evident... So I guess the best way to avoid this is to squeeze out every bit of data in the file until I get to where I can stop? Lol, same time writing on both ends. Feels a bit odd :D I follow you, but how do I skip ahead bites? |
| ||
| FilePos(filehandle) tells you which byte you are at in the file. SeekFile(filehandle, offset) tells blitz which byte to read the next peice of data at. So if you want to skip the next 3 bytes: SeekFile(filehandle, FilePos(filehandle)+3) |
| ||
| okay, sounds simple enough. Thanks for the help so far, I'm learning a lot! |
| ||
| how do I read in a string with bytes? Is there a way to change the numbers to a string or something? (this is for the author) I know there's the Str function, but I can't get it working.. |
| ||
| Chr$(X) will return the character that a particular byte represents. |
| ||
I just realised something: I can skip strings easily! In the docs for .gls it says:Size Integer The size (excluding the chunk header) of the chunk This comes right after a chunk header. Just one thing, do you have any idea what this size is measured in? |
| ||
| I'm sure it is measured in bytes, because it would have to be for chunks which are an odd number of bytes long. |
| ||
| okay, thanks! |
   |