HPI version 3 diagram - Page 3

HPI version 3 diagram

Discuss the source code and development of Spring Engine in general from a technical point of view. Patches go here too.

Moderator: Moderators

User avatar
PauloMorfeo
Posts: 2004
Joined: 15 Dec 2004, 20:53

Post by PauloMorfeo »

I'm not sure that i'm understanding properly what the HPI3 file is suposed to do but, couldn't code from OpenOffice.org be used?
After all, a units set seems to me like some form of spreadsheet (like in MsExcel). They are just fields like UnitName, UnitHP, etc and they're corresponding values.

OpenOffice.org is LGPL, is very solid, runs on many platforms, etc. We can add more than text into the spreadsheet's cells so, i don't think it would be hard to add the units textures, scripts, etc, fields into the spreadsheet file.
And it would be the OpenOffice.org's code to handle file access and storage.

And if the new file system for storing the units set was literally .scx (OpenOffice.org's spreadsheets format), it would be really easy to go edit stuff...
Like Subdino said, there is no need to not reuse code. Especially if it is code that is proven to be good.

What do you think?
jouninkomiko
Posts: 436
Joined: 26 Aug 2004, 08:11

Post by jouninkomiko »

wouldn't call OO's code proven to be good :)

-- yet still has it installed, and curses quite often at it
Subdino
Posts: 25
Joined: 15 May 2005, 08:44

Post by Subdino »

PauloMorfeo wrote:on my Fat32 file system, it takes 119MBs out of my HDD
That's a FAT32 (and a windows) weakness.
And because of that weakness, you, coders, have to build your own workarounds, and somewhat reinvent the wheel beter than those microsoft big brains thought they had. Sadly you can't add a new filesystem support under windows as easily as it can be under linux (there are about 30 filesystems supported under linux, some - maybe most - read-only like ntfs, each designed for a special purpose, from interoperability to technical reasons ).

(The discution might be somewhat ideological now... I'll try to refrain myself from making that forum a unix-vs-others discution :-) )

To stick with the subject, I would say that (multiple file) archives are filesystems too, so they could also circumvent that FAT32 problem. For example TAR can be seen as a tape filesystem (Tape ARchiver), and ZIP multivolumes as a JBOD (Just A Bunch Of Drives, a way to use many HDDs as if they were one) & compressed filesystem - but those two are read only, modifying one file requires rebuilding the whole archive.
User avatar
Buggi
Posts: 875
Joined: 29 Apr 2005, 07:46

Post by Buggi »

Oh, this thread is SOOO not going to become a windows vs. the world flame war.

Good god all I did was post the HPI3 format!!

YES a new format is needed. The old format was 7 years old, used horrid compression and wasteful encryption. So I stepped up and finalized a format and am well on the way to completing the format.

Who gives a rats ass about what this compression does over that one. Everything is compressed. A 3do file is nothing but a series of vertices and faces in one file, you could store all those as separate files, just single one byte files for each vertex. But they're combined into a file format and compressed.

As for PNG and PCX. I thought I made it known I hate PCX. And, for the record, PNG uses LZ compression (Read: zlib). If we had more dev's on the project I'd request they work on including PNG support into Spring right now so when HPI3 is done the transition will be smooth.

-Buggi
User avatar
SeaEagle1
Posts: 17
Joined: 27 Apr 2005, 00:00

Post by SeaEagle1 »

Just a stupid question of mine, but what's the advantage of the new HPI 3 header structure over just adding a LZMA (7zip's compression) (or other)compression flag and removing the encryption? IMHO that would make both conversion and 'upgrading' of current tools possible or a lot easier.
User avatar
Buggi
Posts: 875
Joined: 29 Apr 2005, 07:46

Post by Buggi »

The more I've thought and worked at it the more I think it would be a good idea to wrap a plain zip file (7z or zip, whatever) up as HPI3. Building and maintaining the "directory" has turned out to be a total nightmare. With the structures already built in opensource I see no benefit to re-inventing the wheel.

I thought back to Doom 3 files. All you needed to do was rename the extension to .zip and unzip them. So I figure, lets go for it.

The first two characters in the file tell you what format it is. "PK" for zip and "7z" for a 7zip etc. So all the loader would need to do is look at the first two letters and determine the type of archive it's looking at and treat it that way.

Half the battle was getting the existing HPI format to load, and I've already got that done. Saving it out as a single zip or 7zip shouldn't be too tough.

-Buggi
User avatar
SeaEagle1
Posts: 17
Joined: 27 Apr 2005, 00:00

Post by SeaEagle1 »

That's also a good solution, would be nice if you could make it so that you indeed can just rename it and load it into your favorite zip / 7zip program.
coryrc
Posts: 81
Joined: 01 May 2005, 23:09

Post by coryrc »

What about:
http://icculus.org/physfs/
?
(ps I am for zip files too)
User avatar
Buggi
Posts: 875
Joined: 29 Apr 2005, 07:46

Post by Buggi »

ICSharpCode and sourceforge provide all we need to access zip and seven zip archives.

Now it's time I write up the classes to support FBI, TDF, and Weapon files.

I want to change the extensions of the files to be more accurate to what they represent, I know they're all text files, but yikes, lets use file extensions.

Units before was FBI... anyone know what this stood for? IMHO it should be .unit

Weapons, download, features, and gamedata all use TDF... horrible!!
.wep
.menu
.feat
.gdata
respectivly

All text files could have an XML equivalant for further integration with new technology and those files can exist next to their old format with "x" appended onto the extension.

So for example, ARMFARK.unit and ARMFARK.unitx

Scripts can stay BOS and COB... Unitpicts should be PNG files, period. Gui's are fine, as are models. And since Spring doesn't support GAF files, we don't have to worry about them :D thank god!

For those people in outrage about XML, settle, text takes up about 2% of the actual HPI file, the rest goes to sound, models, and textures.

:-)

-Buggi
User avatar
Dragon45
Posts: 2883
Joined: 16 Aug 2004, 04:36

Post by Dragon45 »

We're not worried about the size of the XML files in terms of HD space, we are worried about its literal utility. Try having made units for the past six years, then have someone tell you that their way is better just because they said so, even though they have no experience actually using the format and such. Its somewhat aggravating to see you consistently misrepresent our position to yourself and others.

In short: Please no XML. And if you do make it XML, please be fully aware that either myself or someone will modify the source code or add some sort of additional layer to make units creatable in the old style, with the program handling the conversion to your XML format.
User avatar
Buggi
Posts: 875
Joined: 29 Apr 2005, 07:46

Post by Buggi »

You think I'm new to unit design? No way. I've been knee deep in TA since it was released. I've never taken the public face I've taken with Spring though.

The XML will be transparent to the user. It's just for the ability to transfer and combine information in the core program. The old format will still be supported. And I in no way intended for it to sound like the "better" way, just different and new.

And you never know, you may like it once your used to it. ;)

Then again, maybe not... :shock:

-Buggi
User avatar
Dragon45
Posts: 2883
Joined: 16 Aug 2004, 04:36

Post by Dragon45 »

Well, if its backwards compatible, that's cool.

And like i said, i have tried it... that DTD i made was quite thorough. When i sat down to actually write a new unit .fbi in that format, i quickly realized what a monumental waste of time that was... it was simply a timewasting, inefficient method.
User avatar
AF
AI Developer
Posts: 20687
Joined: 14 Sep 2004, 11:32

Post by AF »

I think that if xml is supported then why should a units data be spread across numerous files? Have a single file ending with something like .unt and then inside there'll be the unit data build menu stuff weapons etc.
cranphin
Posts: 136
Joined: 13 Jun 2005, 16:37

Post by cranphin »

Zip file with plain file structure inside, and xml files, it's the Java(tm) way! :)
That's exactly how Java .jar files work, and it's show to be a good idea ;)

I approve ^_^

The one thing I wonder (I don't know, and too lazy to check ;) ) is if there's any good (L)GPL libraries to read/write zip files, and if there is any patent/copyright/etc. on zip files.

Besides that, this really is a very practical and simple format, easy to work with (just use your favorite zip/unzip tool).

An advantage is it becomes a lot easier to make the game so it can easily switch between running directly from the filesystem (the contents of a zip, but unzipped, ideal for when you're creating a mod etc.), or running from a compressed data file.

my 5ct :)

Cheers.
coryrc
Posts: 81
Joined: 01 May 2005, 23:09

Post by coryrc »

cranphin wrote:any good (L)GPL libraries to read/write zip files
Yes.
User avatar
Buggi
Posts: 875
Joined: 29 Apr 2005, 07:46

Post by Buggi »

Alantai Firestar wrote:I think that if xml is supported then why should a units data be spread across numerous files? Have a single file ending with something like .unt and then inside there'll be the unit data build menu stuff weapons etc.
Wow, I actually agree with you on something @_@;;
User avatar
AF
AI Developer
Posts: 20687
Joined: 14 Sep 2004, 11:32

Post by AF »

=?

of course you could always try putting an entire mod in a file.

I wonder would it be possibl to add formulae as such to such a file as values so that newly built unit stats changed in different conditions as time goes on or depending on the map? Might be useful for some instances.Or the use of inheritance or deriving units from other unit definitions to save space
Post Reply

Return to “Engine”