HPI version 3 diagram

Buggi · Post by **Buggi** » 07 May 2005, 21:05

Version 1 versus version 3

Version 3 will just be a plain zip file. Whether it's ZLib or 7z, other? Simplest and most docuemented formats out there are the best to impliment. So why not use them instead?

This also eliminates ALL encryption. Oy, what a waste.

This doesn't get into any specifics on the FBI information or the revamping of the files in the directories, just the HPI format itself. File extensions (while a sort of moot point) will have to change. Tooooo many .TDF files.

-Buggi

sp2danny72 · Post by **sp2danny72** » 07 May 2005, 22:50

Why create yet another archive format?
I thought the community agreed on 7z?

AF · Post by AF » 07 May 2005, 22:56

You do nto udnerstand, re-read what eh said and you wills ee the flexibility eh ahs incorporated and some fo the advantages of why.

Also be aware that ti was he and SJ who amde the 7z idea popular and dwardens thread on comrpession

Buggi · Post by **Buggi** » 07 May 2005, 23:16

I'm creating something that has massive flexibility and isn't tied into ONE compression format, hence the Type 2 entry.

This way, if someone prefers Tar over 7zip, so be it, all will work.

I should include a CompressionMethod of "NONE"

*runs and does just that*

Cheesecan · Post by **Cheesecan** » 08 May 2005, 11:42

It's good to see that not everyone has forgotten about compression in this broadband-era.

Dwarden · Post by **Dwarden** » 08 May 2005, 21:12

interesting .... btw buggi check your PM box ...

jouninkomiko · Post by **jouninkomiko** » 09 May 2005, 06:06

hmm i was thinking along the lines of the same thing, but why bother over complicating this with encryption flags etc? essentially, all you really need is an option to use the current hpi format, which allows for no compression as well, or just loading a 7z archive with the appropriate directory structure. in addition, 7z wins for text against the other forms of encryption as well, so i'm still kind of worried that making a new format really won't be that helpful

... though i have to admit, sweet ass layout. what did you make that in?

Buggi · Post by **Buggi** » 09 May 2005, 06:30

jouninkomiko wrote:hmm i was thinking along the lines of the same thing, but why bother over complicating this with encryption flags etc?

I took all encryption out.

jouninkomiko wrote: essentially, all you really need is an option to use the current hpi format, which allows for no compression as well, or just loading a 7z archive with the appropriate directory structure.

Not really, I wanted to allow people to try multiple compression formats, the general consensus was to allow for variety and not lock someone into one format. Although I am axing the LZ77 format in version 3. :)

jouninkomiko wrote: ... though i have to admit, sweet ass layout. what did you make that in?

Visio 2003. I do all my flowcharting with it. Glad you like it. ^_^

-Buggi

Buggi · Post by **Buggi** » 11 May 2005, 06:08

Okay, I've made significant progress on the back-end of the new system. I have the objects all created for V3 files and am creating the routines to load and manipulate them now.

Don't worry, there will be static routines to convert from V1 to V3 and I'll try to make it as painless as possible :)

However, after some thought, I've decided that if you have a V3 file down the road with a Type 2 entry, converting to to V1 should prove to be difficult as it's really an embedded zip file inside the structure.

Heck the entire thing could be just one huge zip file.

So V3 -> V1 conversion will be limited at best down the road. But the software will be able to manipulate V1 files naturally.

The tough part? Getting the Spring source to use V3 files

-Buggi

jouninkomiko · Post by **jouninkomiko** » 12 May 2005, 19:31

how did you get visio to make your layouts look like that?

Buggi · Post by **Buggi** » 12 May 2005, 20:16

Visio?

Took me about 10-20 minutes to lay those out.

And right now, I'm battling with the conversion of LZ77 compression to C#...

That and PCX files, what a freaking waste!

How soon can Spring support PNG?

Post by SJ » 12 May 2005, 20:23

About as soon as someone write an PNG reader and integrate into CBitmap.

coryrc · Post by **coryrc** » 13 May 2005, 00:28

Buggi wrote:And right now, I'm battling with the conversion of LZ77 compression to C#...

Is this for the in-game conversion or V1 -> V3 external helper?

Buggi · Post by **Buggi** » 13 May 2005, 01:06

I got that to work. :D

It's always the little things you miss.

Now my next task is simply going to be to save out a V1 file to make sure I have the logic correct.

Saving it out without encryption :D

I'll be posting a MAJOR update later today on our progress. The structure classes for V3 files are done, now I'm working on V1 Legacy support in the classes.

I have a friend helping me with a C# PCX wrapper class because those file formats are FUBAR and not even .NET has support for them.

-Buggi

jouninkomiko · Post by **jouninkomiko** » 13 May 2005, 02:29

question: why are you doing it in c#? i thought the community was aiming for platform independance?

Buggi · Post by **Buggi** » 13 May 2005, 02:40

jouninkomiko wrote:question: why are you doing it in c#? i thought the community was aiming for platform independance?

Uh... to my knowledge Spring is done in C++ 7

And the Battleroom App is C#

Not sure where the platform independance comes in.

coryrc · Post by **coryrc** » 13 May 2005, 02:51

Buggi wrote:
jouninkomiko wrote:question: why are you doing it in c#? i thought the community was aiming for platform independance?
Uh... to my knowledge Spring is done in C++ 7

And the Battleroom App is C#

Not sure where the platform independance comes in.

Aren't you writing the HPI v3 parser... that would end up in Spring?
And, check out https://opensvn.csie.org/traccgi/taspri ... ringClient, which is the rewrite of SpringClient (in C++).

renrutal · Post by **renrutal** » 13 May 2005, 05:00

The idea of a format that supports multiple compressions is just beautiful.

This way we can reach the maximum lossless compressability and the best speed/compression rate from multiple file formats while maintaining it transparent to the users. It just takes a bit more of coding but it will pay off.
Really useful if you want to pack everything to decrease the ammount of space it takes[for archiving and distribution] or pack to load the game faster.

Another utility could handle that management.

Congrats Buggi. Now the C++ version would give a lot less work to the other developers :)

jouninkomiko · Post by **jouninkomiko** » 13 May 2005, 05:31

there is a c++ version of the lobby being rewritten. what im saying is you can't plugin the v3 of the hpi into spring unless the user has .net (since c# compiles only to MIL). this really should be done in c/c++, imo.

... also, can you send me your visio file please? im learning how to use it right now, and i'd like to see what made up your document and how you got it to look all cool and snazzy like that. mine are just black and white

Buggi · Post by **Buggi** » 14 May 2005, 09:36

Sure Jounin, just drop me a PM with your email and I'll send it to you.

As for the project, the main construction set will remain in C# and until I'm 100% happy with the code it'll stay that way.

Downgrading the IO library to C++ shouldn't be to much of an issue when the time comes to port it for Spring. I'm not porting the front-end to C++, just the V3 read IO implimentation.

I posted the entire spec, no reason another dev out there can't start on a C++ version of a dll library for Spring to absorb. It'll save me the work and expedite the usage of V3 for Spring.

V3 IS the file format for Spring. V1 for TA, V2 was for TA:K, V3?... Spring. Not backwards compatible like the versions before it. The goal is to move forward

-Buggi

Spring RTS Engine

HPI version 3 diagram

HPI version 3 diagram

reinventing the wheel