[21 Oct 2008] Packaging the game's resources

Contains all messages from the Hollywood mailing list between 01/2006 and 08/2012
Locked
Paolo Canonici
Posts: 14
Joined: Tue Feb 16, 2010 7:11 pm
Location: Rome
Contact:

[21 Oct 2008] Packaging the game's resources

Post by Paolo Canonici »

Note: This is an archived post that was originally sent to the Hollywood mailing list on Tue, 21 Oct 2008 15:54:56 +0200

Hello all,

as the title says, I would like to develop an application module able to package (and of course to unpack...) the resources into a single file, in the same way that Hollywood does, with the preprocessors commands, when it creates the executable file. This is almost an essential feature for my work.

The resource file should be like a small-compact-simplified file system, divided into two main areas:

- Index table
- Data segment

The most useful functions, for that purpose, seem to be the "memory block functions", specifically: WriteMem() and ReadMem(), but I did not understand if there is a way (maybe not) to convert these blocks of memory in other types of objects like brushes, samples or simply a text buffer. On the other hand could be equally helpful to have a loadBrush function able to read from any file (not only a graphics file) at any position for any amount of bytes. As a simple explanation this is what I would like to code for the resource-load side:

Code: Select all

function loadResource(resourceId, resourceName$)
    local    fileId   = 1

    openFile(fileId, "resource.wad", #MODE_READ)
    local indexElement = loadIndexElementByName(fileId, resourceName$)
    if (getType(indexElement) <> #NIL)
        seek(fileId, indexElement.entryPoint)
        switch (indexElement.type)
            case #BRUSH:
                loadBrush(resourceId, fileId, indexElement.bufferSize, {Transparency = $FF00FF})
             ...
             ...
        endswitch
    else
       ; Resource does not exists!
    endif
    closeFile(fileId)
endfunction
Or, in the case of memory blocks functions:

Code: Select all

        seek(fileId, indexElement.entryPoint)
        switch (indexElement.type)
            case #BRUSH:
                readMem(fileId, blockId, indexElement.bufferSize)
                createBrushFromMemory(resourceId, blockId, {Transparency = $FF00FF})
             ...
             ...
        endswitch
And now the questions! :-) Is already possible to do something like that? If not, you (great Andreas) might think to make this possible in a nearby minor version update? :-) I know it's a lot to ask!

Thanks! Paolo.
User avatar
Allanon
Posts: 732
Joined: Sun Feb 14, 2010 7:53 pm
Location: Italy
Contact:

[21 Oct 2008] Re: Packaging the game's resources

Post by Allanon »

Note: This is an archived post that was originally sent to the Hollywood mailing list on Tue, 21 Oct 2008 17:22:55 -0000

Hello Paolo, if think you could try to write the memory block rapresenting your data to the disk, read it back with the appropriate Hollywood command and finally remove it from the disk, using the ram disk should be quiet fast. This can solve your problem but will expose your resources to the users even if for few time...

Regards, Fabio
User avatar
airsoftsoftwair
Posts: 5433
Joined: Fri Feb 12, 2010 2:33 pm
Location: Germany
Contact:

[21 Oct 2008] Re: Packaging the game's resources

Post by airsoftsoftwair »

Note: This is an archived post that was originally sent to the Hollywood mailing list on Tue, 21 Oct 2008 23:09:57 +0200
Hello all, as the title says, I would like to develop an application module able to package (and of course to unpack...) the resources into a single file, in the same way that Hollywood does, with the preprocessors commands, when it creates the executable file. This is almost an essential feature for my work.

The resource file should be like a small-compact-simplified file system, divided into two main areas: - Index table - Data segment

The most useful functions, for that purpose, seem to be the "memory block functions", specifically: WriteMem() and ReadMem(), but I did not understand if there is a way (maybe not) to convert these blocks of memory in other types of objects like brushes, samples or simply a text buffer. On the other hand could be equally helpful to have a loadBrush function able to read from any file (not only a graphics file) at any position for any amount of bytes. As a simple explanation this is what I would like to code for the resource-load side:

[...]

And now the questions! :-) Is already possible to do something like that? If not, you (great Andreas) might think to make this possible in a nearby minor version update? :-) I know it's a lot to ask!
Well, actually, it is *almost* possible with Hollywood 3.1. I say "almost" because it's currently not possible to store the resources in a separate file unless you resort to the temporary file solution as suggested by Fabio.

What is possible is to link all resources right into your executable WITHOUT using the preprocessor commands which preload everything. If you use the -linkfiles argument, then Hollywood will only load the resources when they're required. Here's the description from the Hollywood doc:

Code: Select all

   -linkfiles <db>:

    * This argument is only handled when -compile is also specified. You can use
    this argument to link files into your applet or executable. Your script will
    then automatically load these files from your applet or executable. This
    is an alternative for using the preprocessor commands to link files into
    your applet or executable. If you do not want to use preprocessor commands
    to link files into your applet or executable, use -linkfiles for that. You
    need to pass a database file to -linkfiles in the <db> parameter. The
    database file is a simple text file which contains a list of files to link
    into the applet or executable that will be compiled by Hollywood. You must
    only specify one file per line in the database file. The file specification
    must be identical to the specification you use in your script. For example,
    if there is a command 'LoadBrush(1, "data/menu.iff")' in your script and you
    want the file "data/menu.iff" to be linked into your applet or executable,
    you need to put it into the database you pass to -linkfiles. But you must
    use the same specification, i.e. you need to use "data/menu.iff"! Specifying
    "DH0:MyScripts/CoolGame/data/menu.iff" in the database will not work! The
    specification used in the link files database and in the script must be
    the same because otherwise Hollywood cannot know which file it must load.
Using the -linkfiles argument, Hollywood will link all the files specified in the database file to your executable but - in contrast to the preprocessor commands - will NOT load them automatically on startup but only when they're required. So you can have 100 megabytes of resources appended to your executable and it doesn't matter to Hollywood because it only loads a specific resource when needed.

The drawback is that the same data will be appended to the executable for each platform, so it can get pretty redundant if you have versions for 5 different platforms on each CD-ROM :) I'll try if I can improve this to allow resource loading from other files, too. But the concept is already there, at least.
User avatar
airsoftsoftwair
Posts: 5433
Joined: Fri Feb 12, 2010 2:33 pm
Location: Germany
Contact:

[26 Oct 2008] Re: Packaging the game's resources

Post by airsoftsoftwair »

Note: This is an archived post that was originally sent to the Hollywood mailing list on Sun, 26 Oct 2008 23:46:02 +0100

In the next Hollywood version there will be very cool new function which can do all that for you. And - in true Hollywood style - it's extremely easy to use. It's called DefineVirtualFile() and it can be used to define a virtual file inside another file. The return value from DefineVirtualFile() can be passed to all Hollywood functions which take a file name.

Have a look at my example:

Code: Select all

LoadBrush(1, DefineVirtualFile("dh0:huge_resource_file.dat", 300000, 100000, "sprite.png"))
This call will define a new virtual file that is located inside "dh0:huge_resource_file.dat". The virtual file will start at offset 300000 in huge_resource_file.dat and it will be of size 100000 bytes, i.e. the virtual file is located from 300000 to 399999 in huge_resource_file.dat. The 4th argument to DefineVirtualFile() defines the original name of the virtual file. This is an optional argument but it should be used so that Hollywood knows the file extension which is important for some badly designed file formats like mp3 which can't be easily identified without the file extension.

Well, that's about it. DefineVirtualFile() definitely opens up cool new possibilities because you can use it everywhere in Hollywood. You could also do something like:

Code: Select all

OpenFile(1, DefineVirtualFile("dh0:huge_resource_file.dat", 500000, 1234, "textfile.txt"))
DebugPrint(FileLength(1))   ; ---> prints 1234!!!
Paolo Canonici
Posts: 14
Joined: Tue Feb 16, 2010 7:11 pm
Location: Rome
Contact:

[27 Oct 2008] Re: Packaging the game's resources

Post by Paolo Canonici »

Note: This is an archived post that was originally sent to the Hollywood mailing list on Mon, 27 Oct 2008 10:51:22 +0100

This is an amazing news for me!!

I was just thinking about using a pair of executable files according to what you and Fabio had suggested: one for the game application and the other for the resource packaging, in order to have them all in a single resource file, BUT you have done everything that I need!! :-)

Now I look with fervour the next major Hollywood version, wich should give me a lot of essential features and bug-fixes! Is there a planned release date? When? :-)

Thank you!!!

Greets, Paolo.
User avatar
Clyde
Posts: 348
Joined: Sun Feb 14, 2010 12:38 pm
Location: Dresden / Germany

[27 Oct 2008] Re: Packaging the game's resources

Post by Clyde »

Note: This is an archived post that was originally sent to the Hollywood mailing list on Mon, 27 Oct 2008 13:58:08 +0100

Definitely cool feature! Great support, Andreas!

Another interesting question concerning release date: Will there also be a (free) update for the 3.x branch, or will the next update be Hollywood 4?

Greetings Micha
Currently using: Hollywood 9 with Windows IDE and Hollywood 9 with Visual Studio Code and hw4vsc
User avatar
airsoftsoftwair
Posts: 5433
Joined: Fri Feb 12, 2010 2:33 pm
Location: Germany
Contact:

[27 Oct 2008] Re: Packaging the game's resources

Post by airsoftsoftwair »

Note: This is an archived post that was originally sent to the Hollywood mailing list on Mon, 27 Oct 2008 23:26:51 +0100
Definitely cool feature! Great support, Andreas!

Another interesting question concerning release date: Will there also be a (free) update for the 3.x branch, or will the next update be Hollywood 4?
No, the next update will be Hollywood 4.
User avatar
airsoftsoftwair
Posts: 5433
Joined: Fri Feb 12, 2010 2:33 pm
Location: Germany
Contact:

[27 Oct 2008] Re: Packaging the game's resources

Post by airsoftsoftwair »

Note: This is an archived post that was originally sent to the Hollywood mailing list on Mon, 27 Oct 2008 23:30:31 +0100
This is an amazing news for me!! I was just thinking about using a pair of executable files according to what you and Fabio had suggested: one for the game application and the other for the resource packaging, in order to have them all in a single resource file, BUT you have done everything that I need!! :-) Now I look with fervour the next major Hollywood version, wich should give me a lot of essential features and bug-fixes! Is there a planned release date? When? :-)
When it's done :-)

But it shouldn't be so far away.
Locked