Page 1 of 1

Open Halo Parser: Demo

Posted: Fri Jan 15, 2010 8:22 pm
by Modzy
Not having anything to do during my winter break, I started writing classes for RB on map parsing. I'll have a link to the source of some of the classes. A few still need work, such as "Linked Maps," the driving force of map decompiling, memory loading, and compiling.
This demo of sorts contains the roots of my little project. It's basically a class for loading maps and pulling information from them without having to go back to the file itself, once loaded, of course. It also has a few universal methods and such which could be useful in other, non-Halo applications. An example of this is my basic "string reader." Will read strings without a set length, like those in map files. I know many programs do the same thing, but they also seem to set the stream backwards to read a character, this doesn't, making it a little faster.

Well, not much more to say, so here's a few examples of using it:

Loading a map:

Code: Select all

//f will be our folderitem, already having a file assigned to it.
Dim New_map As New Halo_map
New_map.load(f)
Once we've got our map loaded, we can pull any info we'd like from the tags or header and whatnot:

Code: Select all

\\Displaying a message box stating the SCNR's, or first tag in the map's, length
Msgbox Str(New_map.tags(0).length)
It's pretty much that easy to pull anything you need.
Download

Re: Open Halo Parser: Demo

Posted: Sat Jan 16, 2010 12:09 pm
by Altimit01
Not bad. Some good improvements on the basic map loading code. I'd quibble on a few of the variable names picked, particularly the temp variable tag_offsets but it works alright. Not very OO but I'm not sure how important that is to you.

Re: Open Halo Parser: Demo

Posted: Sat Jan 16, 2010 4:10 pm
by Modzy
Yeah, I'll slim it down a bit more and remove as much of that stuff as I can before it's public. My main focus right now is the "Linked Maps." That should make advanced map editing like decompiling, adding tags and whatnot very easy, and early tests show it to be quite a bit faster than Eschaton's algorithms too. ;D

EDIT: Also, another thing I didn't include in this download are the mapped out tags classes. They work with Linked Maps to create new tags for maps. I'm not sure if I'll make those public anytime soon.

Re: Open Halo Parser: Demo

Posted: Sat Jan 16, 2010 6:31 pm
by Altimit01
I'm not sure I understand what you mean be linked maps. I see the same basic stuff where it's just a large collection of data all tied to one map. The only thing that seems like it might be faster is the tag length calculation. Unless you think there's some major speedups to be had in not having classes for the header and the like which might be true in RB I suppose. If you want really fast, you could just mass load everything for relevant sections and then lookup the data within memory blocks. One of the traditionally slowest parts of code are in the I/O.

Re: Open Halo Parser: Demo

Posted: Sat Jan 16, 2010 6:48 pm
by Modzy
Oh I know, that's where most of the speedups I'm adding are.

Re: Open Halo Parser: Demo

Posted: Sat Jan 16, 2010 6:54 pm
by Altimit01
The C/C++ stuff I wrote doesn't even bother with streams. It was really interesting watching it do full map loads of the BSP quickly. It uses the older block read method from C.

Re: Open Halo Parser: Demo

Posted: Mon Jan 18, 2010 7:12 am
by Dirk Gently
RB fail, needs more C/Objective-C noob.

Re: Open Halo Parser: Demo

Posted: Mon Jan 18, 2010 10:08 am
by Modzy
Dirk Gently wrote:RB fail, needs more C/Objective-C noob.
:tongue:

Re: Open Halo Parser: Demo

Posted: Mon Jan 18, 2010 10:46 am
by Altimit01
I blame cloud who first gave me a crappy bit of HMT code converted to RB.

Re: Open Halo Parser: Demo

Posted: Mon Jan 18, 2010 10:53 am
by Dirk Gently
then lets dump the hate wagon on him :P

Re: Open Halo Parser: Demo

Posted: Wed Jan 20, 2010 8:44 pm
by nil
Altimit01 wrote:If you want really fast, you could just mass load everything for relevant sections and then lookup the data within memory blocks. One of the traditionally slowest parts of code are in the I/O.
Hm. Yeah, now that I think about it, loading the map file (or whatever you need to) in memory makes sense. It's faster once loaded, and you can more easily or safely, implement features like saving and undo/redo.