HPI version 3 diagram
Moderator: Moderators
HPI version 3 diagram
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
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
Last edited by Buggi on 13 Jun 2005, 21:46, edited 2 times in total.
- sp2danny72
- Posts: 60
- Joined: 09 Jan 2005, 04:52
reinventing the wheel
Why create yet another archive format?
I thought the community agreed on 7z?
I thought the community agreed on 7z?
-
- Posts: 436
- Joined: 26 Aug 2004, 08:11
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?
... though i have to admit, sweet ass layout. what did you make that in?
I took all encryption out.jouninkomiko wrote:hmm i was thinking along the lines of the same thing, but why bother over complicating this with encryption flags etc?
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: 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.
Visio 2003. I do all my flowcharting with it. Glad you like it. ^_^jouninkomiko wrote: ... though i have to admit, sweet ass layout. what did you make that in?
-Buggi
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
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
-
- Posts: 436
- Joined: 26 Aug 2004, 08:11
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
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
-
- Posts: 436
- Joined: 26 Aug 2004, 08:11
Aren't you writing the HPI v3 parser... that would end up in Spring?Buggi wrote:Uh... to my knowledge Spring is done in C++ 7jouninkomiko wrote:question: why are you doing it in c#? i thought the community was aiming for platform independance?
And the Battleroom App is C#
Not sure where the platform independance comes in.
And, check out https://opensvn.csie.org/traccgi/taspri ... ringClient, which is the rewrite of SpringClient (in C++).
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 :)
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 :)
-
- Posts: 436
- Joined: 26 Aug 2004, 08:11
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
... 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
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
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