I've Been Learning C!

[MrQuetch]

Originally Posted by Lupin

It means it's an hexadecimal (base 16) number.

Ah, ok - makes more sense. I've also been looking at it more, now that I'm not working at the moment. I've noticed that it says that there are 2 vertex types. Is there a real difference between which to use or why to use it?

I've kind of broke down the majority myself so I can see easier where things are located and how they work with each other:

Vertex structure:
===========

(Vertex Type 1)
xx xx yy yy zz zz 00 00
s16 s16 s16 dummy

(Vertex Type 2)
xx xx yy yy zz zz 00 00
s16 s16 s16 dummy

Quad / Triangle Blocks:
===============
aa bb cc cc dd dd 00 00
u8 u8 u16 u16 dummy

Quad structure:
==========
aa aa bb bb cc cc dd dd + (4 or 16 or 24 bytes, probably uv mapping)
u16 u16 u16 u16

Triangle structure:
============
aa aa bb bb cc cc 00 00 + (4 or 16 or 24 bytes, probably uv mapping)
u16 u16 u16 dummy

[Lupin]

I'm not sure what vertex type 2 are for, 99% of what you can see in game are vertex type 1.

[MrQuetch]

Originally Posted by Lupin

I'm not sure what vertex type 2 are for, 99% of what you can see in game are vertex type 1.

That's strange that they even have the 2nd type then. Oh well. Hey, I managed to add onto the program that I've been making, and now I can place buildings anywhere I want in a zone!

The objects don't have collisions yet, but that shouldn't be too hard to figure out, I'm already coding for that part. I know the algorithm well enough, it's just a matter of implementation.

Edit: Just put this together real quick.



It works, but as I said - no collisions yet. The Y & Z are just switched for now. It's weird that Y is coming towards you from above, whereas in most programs I use (like 3ds Max for example) the Z is the one going upwards, not Y.

[MrQuetch]

Collisions are now in the house!

I overlooked one of the values in hex, so the collisions were working for all sides except one, which was a real pain.

Anyways, glad it really works now!

[MrQuetch]

Originally Posted by Lupin

I'm not sure what vertex type 2 are for, 99% of what you can see in game are vertex type 1.

Hey, Lupin, what if it just so happens that the vertex type 2 is accounted for all of the 'bones' of all of the animated models? I've been looking at that page that you linked me to (thanks again by the way), and I've noticed that Leslie did indeed make a mistake on one of the parts - rather an important one as well.

The part that she listed for '70h:' as vertex 1, only accounts for all models that don't have any 'bones' other than their 'pivot' position. That kind of sounds contradictory in itself, but every 'static' model (such as a building per say) will be listed as 1. I've checked other models via hexing again, and all non-animated models contain a 1 in that exact same spot.

To give even more proof, I looked at Twinsen's amount / hierarchy of bones, and even Joe the Elf's. If you look at row 3 position 1 for Twinsen in hex, it's listed as 18, which is 13 in hex. Therefore, he has 18 bones (you can see that by using the LBA Model Viewer). On the other hand, for Joe, it says that he's got 1D in hex, which turns out to be 29? The bones seem like (just like the same formula for the vertices) they increase their count by 1. That makes sense, because all static models just have 1 position to mark their origin. In the program, it even says the bones start from 0, but that's added by 1.

I'm photo shopping some more pictures, so hopefully I can get those up soon.

Something I forgot to mention, it looks like all of those vertex type 2's are listed before the 1st ones, which is weird. It looks like the 1st ones really are just the actual geometry whereas the 2nd ones are indeed just making the 'bone' structures.
I could be wrong, but I think this might actually be it.

[MrQuetch]

I've discovered more of the algorithm for the LBA2 models! I'm becoming more familiar with the structures now, so that's really good news!

I've been using Game Maker Studio for some of the other programs, but seeing as 3D is more of a difficult stretch to do in it, I'll be making the model creator in Unity.

I've decided Unity will be a good decision to choose for the program because Unity has a similar built-in mesh system that LBA2 has. Just like LBA2 in which the vertices have set positions, and then the triangles are drawn to those vertices' positions, Unity does this almost the exact same way. So, I'll make it that in my program, the user can create vertices anywhere he/she pleases, and then creating triangles, the user can set which indices of the triangles are set to what vertices.

Although I've been talking about modeling for the game, it looks like animation will actually not be very difficult - I might even implement that into my program. I've just taken a look at the animations for LBA2, and their hex code is nowhere near as complex as the models are. First part, is the number of frames +1, second comes the number of bones, and then the frame to loop after. I still have to look at the animations a bit more. The equation / formula for figuring out the file size of an animation is surprisingly easy, you just take the number of frames * the number of bones, and that's how large it will be. Of course, then you have to tell if a bone uses translation or rotation, and then it's X,Y, and Z, axes per frame, but that shouldn't be too hard once I get the modeling going. I'm pretty sure that somewhere in the animations are stored the sound effects, and the projectiles - but that could be somewhere else I presume. Possibly the File3D information for the models.

Just figured I'd let you guys know.

I'm not sure if it's me or not. But, it makes me wonder why we still don't have a model creator for LBA2. We already have viewers, and that'd make me think that LBA2 could be edited in that aspect already, but apparently not.

[MrQuetch]

As I said - finally understanding the model format some more! Just for proof that I've discovered more, I've posted the first (if not already done by someone else) the first hexed-edited model for LBA2 (with different rendering types)! I took a pole from the Desert Island raceway, and edited it. This wasn't done with an editor yet, it was all hex. But, after figuring out the structure for the vertices, colors, and render types, modifying models has become much easier.

[MrQuetch]

While I've still been trying to decipher more of the LBA2 model structure (which is becoming easier for that subject), in a matter of minutes I managed to solve the algorithm for the sprites in LBA2. I've now made a program (yet again) where you can input a number of pixels for the X and Y axes, and create an image in the exact format. I'll try to get an image up soon.

[Zink]

What a great progress you are making!

Nice to see some new tools will be coming. Good luck with this.

[MrQuetch]

Originally Posted by Zink

What a great progress you are making!

Nice to see some new tools will be coming. Good luck with this.

Hi, Zink!

Thank you very much! I must say though, if it weren't for you making the LBA Package Editor, none of this would have been possible for me - I have no idea how to uncompress data. The fact that you made that happen has allowed me to extract entries from the game and learn their structures - especially in hex.

I appreciate you very much! Yes, hopefully these programs / tools will be out soon.

In all honesty, the main reason I started doing this, was that I wanted more programs to alter / modify LBA2, but since not many people were doing anything about the game - I decided I could start and see if anything would happen. I'm surprised / amazed with how much I've learned / discovered already.

Ever since Freshman year in high school, I wanted to make a game using the LBA2 engine. But, I wondered if it could actually be done or not. Now that I've graduated with a diploma, looking at it now, computer science is all just memory - and if you know how memory is structured a specific way, it makes creating programs much more fun and easy. It's actually quite weird, I never had a programming class in high school - they simply did not have any (programming) classes. I had to learn on my own at home.

Again, thank you very much for the inspiration and motivation. I'll keep you guys in check.

P.S - It seems like Fred made the algorithm for the lm2 models difficult to understand. Fortunately, parts are becoming more understanding.

[Zink]

Glad to be of help

My story is quite similar. I wanted to translate both games into Polish, so I needed a text editor, and a way to make accented characters (ąćęśżłó). A text editor was there (written by El Muerte), but additional characters required a font modification. The font format wasn't known yet, so I decided I would give it a try. And I succeeded, and it was fun! That joy when I could write properly "Chodźcie za mną!" instead of "Chodzcie za mna!" ("Follow me!") was incredible .

Keep learning and don't give up

[MrQuetch]

Originally Posted by Zink

Glad to be of help

My story is quite similar. I wanted to translate both games into Polish, so I needed a text editor, and a way to make accented characters (ąćęśżłó). A text editor was there (written by El Muerte), but additional characters required a font modification. The font format wasn't known yet, so I decided I would give it a try. And I succeeded, and it was fun! That joy when I could write properly "Chodźcie za mną!" instead of "Chodzcie za mna!" ("Follow me!") was incredible .

Keep learning and don't give up

Awesome! Glad to hear that we both started something - and actually succeeded in pursuing our goals! I don't know any Polish, but I do know quite a bit of Spanish. My main language is English of course. Either way, nice job!

Something I wanted to know (I'm not sure if you know though), do you know how the models are stored for LBA2? I know enough that I should be able to make a program for the models now, but it seems as though I've come to a halt - one important part remains that I have trouble getting to work properly, and it's crucial for what I'm doing. Whenever I change the number of polygons in the header and try to add that near the bottom with the rest of the polygons, I can see the changes in the LBA Model Viewer - and it works, so that's good. But, I cannot get the models to run in the game - it crashes each time. The Viewer seems to not be as strict as LBA2 actually is. I'm wondering if something else needs to be switched in the headers for the models to function properly. If it helps, the headers have the number of parts (such as vertices, polygons, etc) and their offsets (which byte they begin at in the file).

I'll keep trying to see what the problem is. Perhaps I'm leaving something out, but I've checked my files over and over. I'm not giving up... yet. I'd like to make this happen with model creation.

[Zink]

I have only one idea: the offset block in LBA in some files ends with an additional offset, which is equal to the total size of the file in bytes. If that is so, the offset must be updated when you change the file size.

On the second thought: are you sure you're putting the file into HQR correctly? Compression flags, etc?

[Lupin]

I think it most probably has to do with section offsets in the main header, there are quite a few of them, and they're not all well documented.

[Zink]

The Shape file also contains different kinds of objects. Perhaps that would be similar to the models: http://lbafileinfo.kazekr.net/index....BA2:Shape_file

[MrQuetch]

Originally Posted by Zink

I have only one idea: the offset block in LBA in some files ends with an additional offset, which is equal to the total size of the file in bytes. If that is so, the offset must be updated when you change the file size.

On the second thought: are you sure you're putting the file into HQR correctly? Compression flags, etc?

Alright, I'll have to check into that. Thanks! Perhaps I'm missing one of the bytes in the very beginning of the lm2 files. It looks like that the ending of the files are either 00, or are FF representing the texture coordinates if the model has any - I'm not sure then if the total size would be at the end? Maybe... Wouldn't hurt to figure out.

Whenever I test a file in the game, I always replace an existing entry with one I've edited in hex, and then build the output file to the game's HQR that I have opened. When I'm done testing in the game, I clear the replaced entry back to it's default - in hopes of not messing up the HQR and having to back it up or re-installing the game. I've been doing this for the past few years already - and everything has worked, unless I really screwed up the file and had to re-extract it - which has happened on several occurrences.

I did not know that there was a 'correct' way to put a file in the HQR. It's always looked as simple as extracting, replacing, and clearing entries. I don't think I've ever used compression flags in the LBA Package Editor - I don't even know where they are.

Overall, I'm probably just overlooking something so easy to fix in the files. Hopefully that's the case, and if so, I can finally be relieved.

[MrQuetch]

Originally Posted by Lupin

I think it most probably has to do with section offsets in the main header, there are quite a few of them, and they're not all well documented.

Ahhh... That's probably it. I noticed (Even though I've been told several times already) that some parts are rather confusing, hence the lack of documentation. I understand pretty much everything in the top header, but what's a bit confusing (As I said before) is the first two lines in the header. Some of those numbers are the same for every file in the game, but the ones on the right are especially different.

Something I've noticed as well, is that some offsets in the header have an extra byte after them, and that value seems to range in various ways - I'm still not sure what that is. That might be another thing I've been overlooking.

I'll see what I can do. Thanks, Lupin!

[MrQuetch]

Originally Posted by Zink

The Shape file also contains different kinds of objects. Perhaps that would be similar to the models: http://lbafileinfo.kazekr.net/index....BA2:Shape_file

Hmmm... Seems similar, and for more simple - which is nice. It's equations don't look nearly as complex as the models are. I might check that out at some point. Thanks.

[Zink]

Originally Posted by MrQuetch

Alright, I'll have to check into that. Thanks! Perhaps I'm missing one of the bytes in the very beginning of the lm2 files. It looks like that the ending of the files are either 00, or are FF representing the texture coordinates if the model has any - I'm not sure then if the total size would be at the end? Maybe... Wouldn't hurt to figure out.

Some files (grids are the ones I know of) have additional data after the usual offset block and data block. This addition is not in the same format as the rest of the file. For grids it's an array of bytes that helps with memory management. The thing is that the addition for the grids is not taken into account in the last offset (file size) value.
You would have to figure out whether that's also the case for lm2 or not.

Originally Posted by MrQuetch

Whenever I test a file in the game, I always replace an existing entry with one I've edited in hex, and then build the output file to the game's HQR that I have opened. When I'm done testing in the game, I clear the replaced entry back to it's default - in hopes of not messing up the HQR and having to back it up or re-installing the game. I've been doing this for the past few years already - and everything has worked, unless I really screwed up the file and had to re-extract it - which has happened on several occurrences.

I did not know that there was a 'correct' way to put a file in the HQR. It's always looked as simple as extracting, replacing, and clearing entries. I don't think I've ever used compression flags in the LBA Package Editor - I don't even know where they are.

That's a correct way, and nothing should prevent the model files from working (other than their contents). I thought you might have been using some hex editing to put lm2 files back into hqr, or using a custom hqr editor that doesn't update compression flags.
Package Editor doesn't allow you to edit the compression flags. It updates them automatically when you compile the hqr.

[MrQuetch]

Originally Posted by Zink

Some files (grids are the ones I know of) have additional data after the usual offset block and data block. This addition is not in the same format as the rest of the file. For grids it's an array of bytes that helps with memory management. The thing is that the addition for the grids is not taken into account in the last offset (file size) value.
You would have to figure out whether that's also the case for lm2 or not.



That's a correct way, and nothing should prevent the model files from working (other than their contents). I thought you might have been using some hex editing to put lm2 files back into hqr, or using a custom hqr editor that doesn't update compression flags.
Package Editor doesn't allow you to edit the compression flags. It updates them automatically when you compile the hqr.

Actually, now that you mention it, I've noticed that after some of the offsets for the vertices, normals, polygons, etc., there are extra bytes. They seem to be very small, and are generally not too high. That just might be it - I'll have to check it out! The lm2's probably have that!

About data blocks, are those located after the number of parts, the offsets, or something else? I'm not sure about where this would be located - probably sounds like it'd be in the header with everything else.

Glad to hear I've been using the Package Editor in a way that it's meant to be used. Interesting you mention the hexing HQR part, I actually created a thread for Alone in the Dark hexing, and managed to find many entries for the existing models in the game - but since it was all compressed data, when I would hex, it would generally be a group of elements that shifted in some way. Most of the time it would just crash. I posted a couple screenshots there actually.

Once AITD has an uncompressed editor like the LBA games, I shall make tools for that as well.

The fact that you managed to make the files re-compress back into the HQR program that you made is rather amazing. Once again, thank you for the Package Editor.

I'm at work right now, but when I get home, I'll have to send you guys an image of pallet shifting - I managed to make the game look like it's being seen through infrared. That's another step to being able to make the game look different - pallet manipulation.

[MrQuetch]

Something that I noticed for the lm2s, if there is no lines, spheres, or textures being used on the model, their numbers are 0, which is correct, but - they still have an offset! What the heck!? That's really strange! What's even more strange is that they are usually the same offset, which looks like it starts from where the polygons are located, maybe even at the end of the polygons. I'd have to check that again.

[MrQuetch]

Alright, so I figured out a little more about the LBA2 file structure, specifically those offsets. It looks like that the number after the offset is just the amount of data, possibly for the space (just like you said, Zink). Thanks for helping a bit in the direction! Although the number after the offsets seems to vary, it looks like it's not necessarily the same for the other parts - which is weird. Perhaps posting this image will make more sense.

It's been quickly put together, once again. But, the number after the offset of the normals seems to hold the amount of bytes for each normal? I'm pretty sure - that might be the case, but there are 8 bytes for every normal until it goes onto the next normal... Hmm...

Anyways, here it is. I even listed the numbers, the higher - the more room, and the less - almost no room at all. I didn't bother putting 1 or 0, because they look just like 2, except look at the normals (light colors) on the left and ride sides of the jeans as if they were dark like the rest of the jeans.



Also, I kind of lied about the infrared - it contains red, yellow, green, blue and the sort. So, here it is, everything in just plain red.



It's not perfect as the shading on Twinsen and the tree (for example) do not have shading on their sides. That's just me though, I roughly coded an image to get something that looks like this, which is seen in the RESS.HQR for the 'shading palletes'.

They look like this:



Sure, it looks like cluttered garbage, but it's all important to get the right color values and hues. For my code (right now - still cruddy), all I did was write lines of colors by writing 8 colors +1 going down vertical. Hopefully that made sense. I'll still have to 'round' off the edges of some of the 'color boxes' to get that 'shade' on the other objects. For right now though, you can set a color, and the file will generate to that color for you. I haven't really tested it for other stuff yet, but I'm sure we could see the world in all other colors as well.

Slowly but steadily to success we come.

[MrQuetch]

I just looked at the 'LBA2 Making Of' on Youtube: https://www.youtube.com/watch?v=hDNVNImNI4s

I've already seen it a few times, but looking back at the scenery and animation programs - I got a few useful numbers out of the video. They say that they've got 100 - 400 polygons for scenery objects (pretty helpful, the objects could probably use a little more). And finally, the models (as shown from the animator) can have up to 530 polygons at most. This being said, the scenery objects could have up to 530 - but not all do.

This will give me more of a solid understanding of how my basis will be structured. In addition, I'm going to see where in the lm2 files those numbers are stored. I know that FF is 255, so another FF (255 +255 = 510), now I just need a 20, and in hex that's '14'.

[MrQuetch]

I may have found the problem, and I'm going to start testing it with other models just to ensure that it is what I think it is. It looks like all of the bytes for a model are located in the top of the header (and I mean the very top for that matter, specifically the first two lines of code).

I've come up with an equation for finding the amount of bytes in the whole file (might even be wrong). Basically, on the 10th column of the 1st line, there are generally three FF's (255). The beginning of very lm2 file has a 10 (16) and 3 columns later a 60 (96) Here is my equation:

TheNumbersIn3Columns - 96 + 16 = TotalNumberOfBytes.

Where 96 is the size of the header including everything (bones, vertices, normals, etc).
And hex (16) is the base of itself. That probably sounds wrong, but you get the idea.

I did this for a model from the game, and surprisingly, the calculation was correct. The missile model located in OBJFIX.HQR at the last entry (105) has 684 bytes. Those 3 columns contain 254, 255, and 255 - so that is FE, FF, and FF.

So, the equation for the missile model would look like this (as you can see, the 255 x 3 became 254 (FE) plus the other FF's:

(254 + 255 + 255) - 96 + 16 = 684. I counted the bytes in the file, and they are exactly 684 bytes. I'm glad I've found this, and hopefully it can help other people.

In the Package Editor, it says it's got 700 bytes in original size, but that's if you subtract the 16, then it becomes 684.

Edit: Looks like the other numbers around those ones somehow add up for bigger files. That could be wrong too. Just checking...

[MrQuetch]

I've now got loading working in general! Which is quite funny considering that I've been able to save for a few weeks. Now that I've got this settled, I just need to implement loading for everything I've done so far.