Merge all game files into ONE EXE

So, at last my first game is ready for release.

Now, for easy distribution i would like to create a SINGLE exe which contains
all te dll’s (SDL, SGE, MSVC…, etc.), the ttf files and the gif files.

Is this possible? And, if so: how?

Basically i want to merge all my game files:

plt.bmp
back.gif
sligris.gif
Sligris_bgr.gif
sligris_small_black.gif
crane_cabin.gif
crane_skel.gif
Intro_bottom.gif
fontFtr.ttf
fontHdr.ttf
fontOrders.ttf
libpng1.dll
msvcp60.dll
MSVCP60D.DLL
SDL.dll
SDL_image.dll
SGE.dll
zlib.dll
Sligris.exe

into:

Sligris.exe

How to do this? Any Ideas?

Bas van Dijk

So, at last my first game is ready for release.

Now, for easy distribution i would like to create a SINGLE exe which contains
all te dll’s (SDL, SGE, MSVC…, etc.), the ttf files and the gif files.

Is this possible? And, if so: how?

Basically i want to merge all my game files:

plt.bmp
back.gif
sligris.gif
Sligris_bgr.gif
sligris_small_black.gif
crane_cabin.gif
crane_skel.gif
Intro_bottom.gif
fontFtr.ttf
fontHdr.ttf
fontOrders.ttf
libpng1.dll
msvcp60.dll
MSVCP60D.DLL
SDL.dll
SDL_image.dll
SGE.dll
zlib.dll
Sligris.exe

into:

Sligris.exe

How to do this? Any Ideas?

Bas van Dijk

You can statically link all the libraries together. The resources can
all be converted to C code that you can compile and link into your
program and use RWops to read them from memory. Turns out all SDL
functions that read from files actually use a RWop to do the file IO and
there are RWops that let you treat a constant in memory as a file.

	Bob PendletonOn Sun, 2004-09-26 at 15:16, Bas van Dijk wrote:

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

±-------------------------------------+

What is this recent obsession on the SDL list with cramming more crap
into your application? WHAT FOR?On Sep 26, 2004, at 4:16 PM, Bas van Dijk wrote:

So, at last my first game is ready for release.

Now, for easy distribution i would like to create a SINGLE exe which
contains
all te dll’s (SDL, SGE, MSVC…, etc.), the ttf files and the gif files.

Is this possible? And, if so: how?

Basically i want to merge all my game files:

plt.bmp
back.gif
sligris.gif
Sligris_bgr.gif
sligris_small_black.gif
crane_cabin.gif
crane_skel.gif
Intro_bottom.gif
fontFtr.ttf
fontHdr.ttf
fontOrders.ttf
libpng1.dll
msvcp60.dll
MSVCP60D.DLL
SDL.dll
SDL_image.dll
SGE.dll
zlib.dll
Sligris.exe

into:

Sligris.exe

How to do this? Any Ideas?

Bas van Dijk


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

Donny Viszneki <smirk thebuicksix.com> writes:

What is this recent obsession on the SDL list with cramming more crap
into your application? WHAT FOR?

In my case it will be for several reasons…

1- distribution, updates, etc, one file does it all… is in fact a good point.

2- when dealing with artists (in my case students)… you never can make things
fool proof… because fool are so ingenius… so, files such as dll are on the
only if you need to know basis. so its better to hide them!

3- estetic… I think it all starts with a good naming convention and well
organised pipepline… files of all kinds such as dlls in your root folder ends
up to be a bunch of unnecessary files the artists who uses your product dont
care about… and plus, I hate scrolling in a folder to find a game.exe.

4- id software with doom3 is a great exemple… cleanyness is next to
godlyness! they know it… and I agree.

5- I do my bed every morning!

:wink:

Golgoth

some counter points (:

1- distribution, updates, etc, one file does it all… is in fact a good
point.

makes for larger updates than just giving the files that need to be updated
(you could have an auto-patcher for instance that compares files and
downloads the ones that are different)

2- when dealing with artists (in my case students)… you never can make
things
fool proof… because fool are so ingenius… so, files such as dll are on
the
only if you need to know basis. so its better to hide them!

The artists might get miffed that they cant update the graphics themselves
to be able to see how their art interacts with the other art

3- estetic… I think it all starts with a good naming convention and well
organised pipepline… files of all kinds such as dlls in your root folder
ends
up to be a bunch of unnecessary files the artists who uses your product
dont
care about… and plus, I hate scrolling in a folder to find a game.exe.

the dll’s would have to be in the same folder as the exe but nothing else
would you could put all those in subfolders

and my own:

  1. you make a HUGE exe which makes for alot of loading time at startup.
    when you have all resources in the exe, when you fire up that exe it loads
    ALL of those into ram which is a waste of memory since you dont need them
    all in ram at the same time im assuming.

  2. loading the resources from the exe while the exe in ram makes it so
    whatever resources you have currently loaded from the exe are stored TWICE
    in ram. once in the exe thats resident and once for your loading of the
    resources. pretty wasteful if you ask me :stuck_out_tongue:

  3. ID uses WAD files, they dont put everything in the exe. you may check
    out physicsfs (http://icculus.org/physfs/) or at least zlib to make your own
    wad type files (:

  4. to add art/resources to your game you are going to have to recompile
    every time, makes it difficult to make map editors work etc (assuming you
    have the kind of game that would want one) or to quickly change or add a
    graphic and see how it turns out.> ----- Original Message -----

From: neosettlers@sympatico.ca (Golgoth)
To:
Sent: Sunday, September 26, 2004 3:07 PM
Subject: [SDL] Re: Merge all game files into ONE EXE

Donny Viszneki <smirk thebuicksix.com> writes:

What is this recent obsession on the SDL list with cramming more crap
into your application? WHAT FOR?

In my case it will be for several reasons…

1- distribution, updates, etc, one file does it all… is in fact a good
point.

2- when dealing with artists (in my case students)… you never can make
things
fool proof… because fool are so ingenius… so, files such as dll are on
the
only if you need to know basis. so its better to hide them!

3- estetic… I think it all starts with a good naming convention and well
organised pipepline… files of all kinds such as dlls in your root folder
ends
up to be a bunch of unnecessary files the artists who uses your product
dont
care about… and plus, I hate scrolling in a folder to find a game.exe.

4- id software with doom3 is a great exemple… cleanyness is next to
godlyness! they know it… and I agree.

5- I do my bed every morning!

:wink:

Golgoth


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

Yes, I basicly agreed with all the points you ve mentioned… i m running in
two different thread… my mistake… in fact I m mainly talking about removing
the dlls from the root folder… but including small dlls such as sdl in the
exe… sounds like a good plan tho!

I ll be interested in doing so… but for now i cant even Delay load the sdl
dll… so theres some investigation to do on this first I believe.

Golgoth

Bas van Dijk wrote:

So, at last my first game is ready for release.

Now, for easy distribution i would like to create a SINGLE exe which contains
all te dll’s (SDL, SGE, MSVC…, etc.), the ttf files and the gif files.

Is this possible? And, if so: how?

Basically i want to merge all my game files:

[snip]

msvcp60.dll
MSVCP60D.DLL

I’m not sure you’re legally allowed to statically link some microsoft DLLs.

SDL.dll
SDL_image.dll
SGE.dll

These 3 are LGPL-licensed. According to their license, you must provide
a way to relink your binary with different versions of these library.

So in short, when packing everything into a single file, read the
licences carefully.
I know, this is not funny, but it might save you from some trouble.

Stephane

Ok for the person that originally started this thread:

Static linking is the way to do it, but if you do that you have to open
source it according to LGPL. Also if you want to roll everything ELSE
up into a single file (but not the EXE) there are libraries that allow
you to use zip files or other pack type files in that manner. I use
PHYSFS because someone made a static library that binds PHYSFS to SDL
RWOps. However that doesn’t work with fonts sometimes (random crashes).

-TomT64

Stephane Marchesin wrote:> Bas van Dijk wrote:

So, at last my first game is ready for release.

Now, for easy distribution i would like to create a SINGLE exe which
contains all te dll’s (SDL, SGE, MSVC…, etc.), the ttf files and the
gif files.

Is this possible? And, if so: how?

Basically i want to merge all my game files:

[snip]

msvcp60.dll
MSVCP60D.DLL

I’m not sure you’re legally allowed to statically link some microsoft
DLLs.

SDL.dll
SDL_image.dll
SGE.dll

These 3 are LGPL-licensed. According to their license, you must
provide a way to relink your binary with different versions of these
library.

So in short, when packing everything into a single file, read the
licences carefully.
I know, this is not funny, but it might save you from some trouble.

Stephane


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

What is this recent obsession on the SDL list with cramming more crap
into your application? WHAT FOR?

It makes things easier for the customer. That’s all. And, that is more
than enough! Game programming isn’t a primarily technical pursuit.
Therefore, not every decision is made for technical reasons. Many, if
not most, major decisions are made for human and business reasons. The
decision to lump everything together into one file is a business
decision arising from a human need.

There is also the slight benefit that it keeps the less technically
inclined from lifting your art and music resources. Some people do worry
about that.

And then there is the other point… The author wants to do it. It is
his decision to make. He believes there is value in doing it. And you
have 0 (zero) reason or right to object. The fact that you would not do
it that way is not relevant to the discussion.

	Bob PendletonOn Sun, 2004-09-26 at 16:11, Donny Viszneki wrote:

On Sep 26, 2004, at 4:16 PM, Bas van Dijk wrote:

So, at last my first game is ready for release.

Now, for easy distribution i would like to create a SINGLE exe which
contains
all te dll’s (SDL, SGE, MSVC…, etc.), the ttf files and the gif files.

Is this possible? And, if so: how?

Basically i want to merge all my game files:

plt.bmp
back.gif
sligris.gif
Sligris_bgr.gif
sligris_small_black.gif
crane_cabin.gif
crane_skel.gif
Intro_bottom.gif
fontFtr.ttf
fontHdr.ttf
fontOrders.ttf
libpng1.dll
msvcp60.dll
MSVCP60D.DLL
SDL.dll
SDL_image.dll
SGE.dll
zlib.dll
Sligris.exe

into:

Sligris.exe

How to do this? Any Ideas?

Bas van Dijk


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

±-------------------------------------+

Ok for the person that originally started this thread:

Static linking is the way to do it, but if you do that you have to open
source it according to LGPL.

That is not true, you do not have to open source it if you statically
link with LGPL libraries. You DO have to provide a way to relink the
file. That means you have to provide the object files on a website
somewhere along with instructions on how to relink it.

What you said is true about GPL code, not LGPL code.

	Bob PendltonOn Sun, 2004-09-26 at 19:21, TomT64 wrote:

Also if you want to roll everything ELSE
up into a single file (but not the EXE) there are libraries that allow
you to use zip files or other pack type files in that manner. I use
PHYSFS because someone made a static library that binds PHYSFS to SDL
RWOps. However that doesn’t work with fonts sometimes (random crashes).

-TomT64

Stephane Marchesin wrote:

Bas van Dijk wrote:

So, at last my first game is ready for release.

Now, for easy distribution i would like to create a SINGLE exe which
contains all te dll’s (SDL, SGE, MSVC…, etc.), the ttf files and the
gif files.

Is this possible? And, if so: how?

Basically i want to merge all my game files:

[snip]

msvcp60.dll
MSVCP60D.DLL

I’m not sure you’re legally allowed to statically link some microsoft
DLLs.

SDL.dll
SDL_image.dll
SGE.dll

These 3 are LGPL-licensed. According to their license, you must
provide a way to relink your binary with different versions of these
library.

So in short, when packing everything into a single file, read the
licences carefully.
I know, this is not funny, but it might save you from some trouble.

Stephane


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

±-------------------------------------+

Are you having any difficulty linking to SDL the NORMAL way? Is it
really worth the trouble to do it any other way? Besides, legally you
will have to provide a non-statically linked version anyhow. And as
Alan said, updating will take forever unless you use a binary patching
system.On Sep 26, 2004, at 7:02 PM, Golgoth wrote:

Yes, I basicly agreed with all the points you ve mentioned… i m
running in
two different thread… my mistake… in fact I m mainly talking about
removing
the dlls from the root folder… but including small dlls such as sdl
in the
exe… sounds like a good plan tho!

I ll be interested in doing so… but for now i cant even Delay load
the sdl
dll… so theres some investigation to do on this first I believe.

Golgoth


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

Bob Pendleton wrote:>On Sun, 2004-09-26 at 19:21, TomT64 wrote:

Ok for the person that originally started this thread:

Static linking is the way to do it, but if you do that you have to open
source it according to LGPL.

That is not true, you do not have to open source it if you statically
link with LGPL libraries. You DO have to provide a way to relink the
file. That means you have to provide the object files on a website
somewhere along with instructions on how to relink it.

What you said is true about GPL code, not LGPL code.

  Bob Pendlton

I didn’t see this particular angle of it. In any case, that is very
platform specific and compiler specific. Depending on your target user
this could be problematic. Static linking is the generally accepted and
easy-for-the-programmer way to compile the program with new versions of
the library (except dynamic linking, which is loads easier). So in
reality you have to do whichever you feel is best for both you and
whatever your target audience is, and also fits within the rules of
providing a way to relink the library. For example, does binary
patching count as relinking? Probably not since it depends on the
developer of the program to provide the patch, I guess.

-TomT64

What is this recent obsession on the SDL list with cramming more crap
into your application? WHAT FOR?

It makes things easier for the customer. That’s all. And, that is more
than enough! Game programming isn’t a primarily technical pursuit.
Therefore, not every decision is made for technical reasons. Many, if
not most, major decisions are made for human and business reasons. The
decision to lump everything together into one file is a business
decision arising from a human need.

Two arguments.

First, I will argue against whether or not this fact is even relevant.
Case and point: have you EVER seen a big name computer game that comes
as a single binary?

Second, I will argue against this philosophy. Considering ease of use
(a purely human aspect) OVER system performance (a purely technical
aspect) is what has led us to things Windows and automatic
transmissions!

When I was in highschool I made a lot of software. Instead of making it
easy to use - I made it educational. It TEACHES the user about the
underlying technology. Not more than is necessary, but not less either.
In my opinion this is one of multiple approaches to the ease-of-use
problem that is much better than sacrificing performance or
functionality.

There is also the slight benefit that it keeps the less technically
inclined from lifting your art and music resources. Some people do
worry
about that.

Technically inclined or not, if you know the name of the media you’re
looking for, you’ll find it on a file sharing network ten times faster
than you’ll rip it out of any sort of proprietary or otherwise
difficult to access archive.

Case and point - I am technically inclined, but if I wanted to get
megaman sprites (and at one point I did want just that) I didn’t
download the ROM and start the laborious process of extracting them - I
searched the internet and downloaded hundreds of them in minutes.

Personally, I think if someone is making money off of your media it
will be relatively easy to find them (or at least the ease of finding
out will be proportional to their ill-gotten success.) And if they’re
using them for personal purposes who gives a damn?

Very, very personally, I know a LOT of people disagree with this - but
even if they used them in an open source project I wouldn’t mind one
bit. Though I’d definitely come down on them for using it without my
permission if that was the case.

And another thing: if they aren’t technically inclined, WHAT are they
going to with your precious media that you wouldn’t want them to do?

And then there is the other point… The author wants to do it. It is
his decision to make. He believes there is value in doing it. And you
have 0 (zero) reason or right to object. The fact that you would not do
it that way is not relevant to the discussion.

Oh come on Bob, this is just silly. The nature of an argumentative
objection is not to steal another’s will power from them and force them
to do what you say! It’s totally my right to make this sort of
objection, I’m not forcing anybody to do anything!On Sep 26, 2004, at 8:36 PM, Bob Pendleton wrote:

On Sun, 2004-09-26 at 16:11, Donny Viszneki wrote:

Donny Viszneki wrote:

What is this recent obsession on the SDL list with cramming more crap
into your application? WHAT FOR?

It makes things easier for the customer. That’s all. And, that is more
than enough! Game programming isn’t a primarily technical pursuit.
Therefore, not every decision is made for technical reasons. Many, if
not most, major decisions are made for human and business reasons. The
decision to lump everything together into one file is a business
decision arising from a human need.

Two arguments.

First, I will argue against whether or not this fact is even relevant.
Case and point: have you EVER seen a big name computer game that comes
as a single binary?

Well big name nowadays? No. I know in the DOS days and Windows 3.1
days there were lots of games that were a single EXE, or an EXE and a
DLL that the made themselves. Solitaire is one of the latter. Stars!
is one of the former (I know, you’ve probably never heard of it).
However it doesn’t seem very logical to do this, especially if you’re
using multiple libraries AND especially if you are going for cross
platform compilability. For that, the best you can do is include all
the DLLs (for Windows) and pack all your graphics, media, and such into
a zip file or other pack file and use a library to access that (which is
what I have done), or make your own library and pack file format.

Second, I will argue against this philosophy. Considering ease of use
(a purely human aspect) OVER system performance (a purely technical
aspect) is what has led us to things Windows and automatic transmissions!

Hey I LIKE auto transmission! :slight_smile:

When I was in highschool I made a lot of software. Instead of making
it easy to use - I made it educational. It TEACHES the user about the
underlying technology. Not more than is necessary, but not less
either. In my opinion this is one of multiple approaches to the
ease-of-use problem that is much better than sacrificing performance
or functionality.

I should mention here that there is no logical reason not to have a
balance. In fact, it is quite possible, given enough time and effort, to
make it both easy to use AND have it perform and function well.
However, both sides of the coin are up to interpretation by whoever uses
it. No matter how easy it is to use, or how technically good it is,
someone can always complain.

Personally, I think if someone is making money off of your media it
will be relatively easy to find them (or at least the ease of finding
out will be proportional to their ill-gotten success.) And if they’re
using them for personal purposes who gives a damn?

Well therein lies a very legal and fundamental argument. Remember when
Paramount tried to shut down all the Star Trek websites? Ill-conceived
as the notion may have been, their goal was to prevent “Star Trek” from
becoming so commonly used anywhere that it became, under common law, a
common name. “Kleenex” almost had this problem too. They didn’t want
other tissue brands using their brand name to describe all tissues.
That’s where the paranoia about people ripping artwork and music and
other media comes from. In fact it can be very problematic. How many
button lights or pasta pans have you seen of different brands on TV
lately? Which one is original? You don’t know, because the rights
weren’t protected enough for one company to be prevented from getting
rich off someone else’s idea.

But I’m pretty sure all of this is beside the original point of trying
to roll up your files into an easily distributable or "clean looking"
form. As I have suggested, a library to deal with a pack file format
and distribution of DLLs OR static linking libraries (in my book no real
difference as far as distribution goes… it’ll still zip up to be about
the same size) should take care of the problem of files nicely.
Besides, Windows default behavior is to HIDE DLLs, so there’s no need to
worry about them getting in the way within the directory of an average user.

-TomT64> On Sep 26, 2004, at 8:36 PM, Bob Pendleton wrote:

On Sun, 2004-09-26 at 16:11, Donny Viszneki wrote:

Donny Viszneki wrote:

What is this recent obsession on the SDL list with cramming more
crap
into your application? WHAT FOR?

It makes things easier for the customer. That’s all. And, that is
more
than enough! Game programming isn’t a primarily technical pursuit.
Therefore, not every decision is made for technical reasons. Many, if
not most, major decisions are made for human and business reasons.
The
decision to lump everything together into one file is a business
decision arising from a human need.

Two arguments.

First, I will argue against whether or not this fact is even
relevant. Case and point: have you EVER seen a big name computer game
that comes as a single binary?

Well big name nowadays? No. I know in the DOS days and Windows 3.1
days there were lots of games that were a single EXE, or an EXE and a
DLL that the made themselves. Solitaire is one of the latter. Stars!
is one of the former (I know, you’ve probably never heard of it).
However it doesn’t seem very logical to do this, especially if you’re
using multiple libraries AND especially if you are going for cross
platform compilability. For that, the best you can do is include all
the DLLs (for Windows) and pack all your graphics, media, and such
into a zip file or other pack file and use a library to access that
(which is what I have done), or make your own library and pack file
format.

DOS and Windows 3.1 games: let’s face it, these games had a very tiny
amount of media, and were probably not subject to many updates.
Therefore, most of the disadvantages (besides personal inconvenience on
the part of the developers) are already eliminated.

I have no idea what Stars! is (besides a cable movie channel.)

Second, I will argue against this philosophy. Considering ease of use
(a purely human aspect) OVER system performance (a purely technical
aspect) is what has led us to things Windows and automatic
transmissions!

Hey I LIKE auto transmission! :slight_smile:

What are you, a woman? :stuck_out_tongue:

When I was in highschool I made a lot of software. Instead of making
it easy to use - I made it educational. It TEACHES the user about the
underlying technology. Not more than is necessary, but not less
either. In my opinion this is one of multiple approaches to the
ease-of-use problem that is much better than sacrificing performance
or functionality.

I should mention here that there is no logical reason not to have a
balance. In fact, it is quite possible, given enough time and effort,
to make it both easy to use AND have it perform and function well.
However, both sides of the coin are up to interpretation by whoever
uses it. No matter how easy it is to use, or how technically good it
is, someone can always complain.

I definitely agree.

Personally, I think if someone is making money off of your media it
will be relatively easy to find them (or at least the ease of finding
out will be proportional to their ill-gotten success.) And if they’re
using them for personal purposes who gives a damn?

Well therein lies a very legal and fundamental argument. Remember
when Paramount tried to shut down all the Star Trek websites?
Ill-conceived as the notion may have been, their goal was to prevent
"Star Trek" from becoming so commonly used anywhere that it became,
under common law, a common name. “Kleenex” almost had this problem
too. They didn’t want other tissue brands using their brand name to
describe all tissues. That’s where the paranoia about people ripping
artwork and music and other media comes from. In fact it can be very
problematic. How many button lights or pasta pans have you seen of
different brands on TV lately? Which one is original? You don’t
know, because the rights weren’t protected enough for one company to
be prevented from getting rich off someone else’s idea.

Star Trek and Kleenex: The laws that allow for common names to be used
freely by anyone do not apply to music, texture maps, sound effects,
fonts, or any other game media.

Ergo, that is not where the paranoia about ripping artwork and music
and other media from games comes from.

Button lights and pasta pans: A patent on a “button light” is adequate
protection - clearly no one has a patent - or they’re licensing the
patent to everyone under the sun - or they’re waiting for someone to
make a fortune on them and sue the pants off of them. Patents do not
prevent others from SEEING your idea, just from profiting from them.

But I’m pretty sure all of this is beside the original point of trying
to roll up your files into an easily distributable or "clean looking"
form. As I have suggested, a library to deal with a pack file format
and distribution of DLLs OR static linking libraries (in my book no
real difference as far as distribution goes… it’ll still zip up to
be about the same size) should take care of the problem of files
nicely.

Actually, the “original point” may have been lost. Bas van Dijk hasn’t
shown up to comment since his original post!

Besides, Windows default behavior is to HIDE DLLs, so there’s no need
to worry about them getting in the way within the directory of an
average user.

Only on the most recent windows versions.On Sep 26, 2004, at 10:10 PM, TomT64 wrote:

On Sep 26, 2004, at 8:36 PM, Bob Pendleton wrote:

On Sun, 2004-09-26 at 16:11, Donny Viszneki wrote:

It makes things easier for the customer. That’s all. And, that is more
than enough! Game programming isn’t a primarily technical pursuit.
Therefore, not every decision is made for technical reasons. Many, if
not most, major decisions are made for human and business reasons. The
decision to lump everything together into one file is a business
decision arising from a human need.

And then there is the other point… The author wants to do it. It is
his decision to make. He believes there is value in doing it. And you
have 0 (zero) reason or right to object. The fact that you would not do
it that way is not relevant to the discussion.

Well put, Bob. You have a firm grasp of the realities of life :wink:

JeffOn Sunday 26 September 2004 05:36 pm, Bob Pendleton wrote:

Bas van Dijk wrote:

So, at last my first game is ready for release.

Now, for easy distribution i would like to create a SINGLE exe which contains
all te dll’s (SDL, SGE, MSVC…, etc.), the ttf files and the gif files.

Is this possible? And, if so: how?

Basically i want to merge all my game files:

plt.bmp
back.gif
sligris.gif
Sligris_bgr.gif
sligris_small_black.gif
crane_cabin.gif
crane_skel.gif
Intro_bottom.gif
fontFtr.ttf
fontHdr.ttf
fontOrders.ttf
libpng1.dll
msvcp60.dll
MSVCP60D.DLL
SDL.dll
SDL_image.dll
SGE.dll
zlib.dll
Sligris.exe

into:

Sligris.exe

How to do this? Any Ideas?

Bas van Dijk

Sorry if i’m repeating whats already been said in this thread, I
haven’t read it all it seems to have gone off topic a bit.

You may want to try using “Tile Studio” which someone else mentioned on
here a while back on this thread:

http://twomix.devolution.com/pipermail/sdl/2004-July/063587.html

Tile studio is here: http://tilestudio.sourceforge.net/

It allows you to export the graphics as “C” code so they will become
static data in you EXE. Which I think is exactly what you want to do.
This method should work on any platform.

As far as the DLL is concerned, I would build a static version of Zlib
and link with that. You will however have to distribute your EXE with
the SDL dll files, statically linking here I think will break the licence.

Or, if your actually thinking of building an installer, then you might
like to check out the Nullsoft installer:

http://nsis.sourceforge.net/

HTH,

  • Tom

Hi

One solution is to do the following (I have used it before myself in several
different languages).

Say you have your exe, then you add data after it has been compiled by
opening it and writing to it. (This requires you to write your own program
to open the file and write in a format you see fit.

Let’s play with an example that I used when I first did this in VB a long
time ago.
Here is a description of the end of your file and the appended data.

EXE | “dneeht” | “?” | “image1.bmp” | “?” | “2400” | “?” | IMAGEDATA | “?”
|…

This is a format I used when I did this the first time. The “?” char can be
changed to anything you like, it’s just used as a breakpoint to tell the
program that new information is comming.
The function should know in wich order things come, i.e. name, size, data

Explination of the format================
EXE: This is the standard exe of your game compiled

“dneeht”: The function scans the exe for this tag and when it reaches this
it know that the exe has ended and that our data begins. This tag should be
something that cann’t be find anywhere in the original exe since that will
confuse the function that will extract the data.

“?”: Tells the function that we get data (the name of a file in this case)

“image1.bmp”: The name of the file

“?”: We change what data we read again and this time it’s te size of the
image file

“2400”: The size of the image file

“?”: Time to recive the imagedata

IMAGEDATA: The imagefile written into the exe in binary format. Now we
create a file named as the image name we got above and starts to read bytes
and writing them into that file. We stop when we have read as many bytes as
the imagessize tells us to read.

Now we have extracted an image. All that is required is to write the program
that reads the filesizes and names of the files and appends them and the
correct information to the end of the exe.
And then write the function to extract it all once the exe is run. And
prehaps delete all the files upon exit.
Once you have doen this, it can be used over and over again for all your
projects.

If you run across the problem that you can’t even run the exe beacuse it
needs one of the appended files to run. Then you can wrap it all up into
another exe that extracts all the images and dlls AND your original exe.
Then extracts them all and runs your original exe once that is done.

This might seem like alot of work, but since you only have to create the
program and function once, it’s not that hard.

Best regards
Daniel Liljeberg

----- Original Message -----
From: t.wilson@hazid.com (Tom Wilson)
To: "A list for developers using the SDL library. (includes SDL-announce)"

Sent: Monday, September 27, 2004 11:34 AM
Subject: Re: [SDL] Merge all game files into ONE EXE

Bas van Dijk wrote:

So, at last my first game is ready for release.

Now, for easy distribution i would like to create a SINGLE exe which
contains all te dll’s (SDL, SGE, MSVC…, etc.), the ttf files and the gif
files.

Is this possible? And, if so: how?

Basically i want to merge all my game files:

plt.bmp
back.gif
sligris.gif
Sligris_bgr.gif
sligris_small_black.gif
crane_cabin.gif
crane_skel.gif
Intro_bottom.gif
fontFtr.ttf
fontHdr.ttf
fontOrders.ttf
libpng1.dll
msvcp60.dll
MSVCP60D.DLL
SDL.dll
SDL_image.dll
SGE.dll
zlib.dll
Sligris.exe

into:

Sligris.exe

How to do this? Any Ideas?

Bas van Dijk

Sorry if i’m repeating whats already been said in this thread, I haven’t
read it all it seems to have gone off topic a bit.

You may want to try using “Tile Studio” which someone else mentioned on
here a while back on this thread:

http://twomix.devolution.com/pipermail/sdl/2004-July/063587.html

Tile studio is here: http://tilestudio.sourceforge.net/

It allows you to export the graphics as “C” code so they will become
static data in you EXE. Which I think is exactly what you want to do.
This method should work on any platform.

As far as the DLL is concerned, I would build a static version of Zlib and
link with that. You will however have to distribute your EXE with the SDL
dll files, statically linking here I think will break the licence.

Or, if your actually thinking of building an installer, then you might
like to check out the Nullsoft installer:
http://nsis.sourceforge.net/

HTH,

  • Tom

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

Bob Pendleton wrote:

Ok for the person that originally started this thread:

Static linking is the way to do it, but if you do that you have to open
source it according to LGPL.

That is not true, you do not have to open source it if you statically
link with LGPL libraries. You DO have to provide a way to relink the
file. That means you have to provide the object files on a website
somewhere along with instructions on how to relink it.

What you said is true about GPL code, not LGPL code.

Bob Pendlton

I didn’t see this particular angle of it. In any case, that is very
platform specific and compiler specific.

Yes, it is. The world has changed a lot since the last version of the
LGPL was written. The goal of the GPL and the LGPL is to force companies
to open there development platforms by making it cost less to use open
tools than closed tools. And, you know what? It is working. :slight_smile: But, it
does create problems for people working on new closed platforms.

Depending on your target user
this could be problematic.

IMHO, 99.999% or more of users have no interest in relinking. But, those
that do must have the ability to do so if you want to use LGPL code in
your project.

Static linking is the generally accepted and
easy-for-the-programmer way to compile the program with new versions of
the library (except dynamic linking, which is loads easier). So in
reality you have to do whichever you feel is best for both you and
whatever your target audience is, and also fits within the rules of
providing a way to relink the library.

Exactly, it is a business and human factors question, not a technical
question.

For example, does binary
patching count as relinking? Probably not since it depends on the
developer of the program to provide the patch, I guess.

I don’t think binary patching counts as relinking because the end user
can’t generate the patch. It is really not a big problem to provide the
object files on a web site so that anyone who wants to can get them and
relink.

	Bob PendletonOn Sun, 2004-09-26 at 20:38, TomT64 wrote:

On Sun, 2004-09-26 at 19:21, TomT64 wrote:

-TomT64


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

±-------------------------------------+

What is this recent obsession on the SDL list with cramming more crap
into your application? WHAT FOR?

It makes things easier for the customer. That’s all. And, that is more
than enough! Game programming isn’t a primarily technical pursuit.
Therefore, not every decision is made for technical reasons. Many, if
not most, major decisions are made for human and business reasons. The
decision to lump everything together into one file is a business
decision arising from a human need.

Two arguments.

First, I will argue against whether or not this fact is even relevant.
Case and point: have you EVER seen a big name computer game that comes
as a single binary?

Ahhh, a strawman argument. We are not talking about big name games, we
are talking about smaller games written by a single person or a small
group of people that are distributed over the Internet. Big name games
have big name budgets to support end users who have trouble installing
them. Small name games have to “just work”.

Second, I will argue against this philosophy. Considering ease of use
(a purely human aspect) OVER system performance (a purely technical
aspect) is what has led us to things Windows and automatic
transmissions!

Bull… The only thing that matters is the “purely human aspect”. If
people have to work too hard to use something they will find something
that is easier to use. That is reality. Putting system performance over
human convenience is so… '1960ish. Back then, and I remember back
then, a 1 MOP/1 MB computer cost millions of dollars so it was worth a
huge amount human discomfort to get the most out of the computer.

Now days computers with a hundred to a thousand times that performance
can be picked up in flea markets for less than $100. I spent a large
part of yesterday in a flea market and saw just that.

Putting the computer ahead of the person using the computer is just
plain wrong. It is what is wrong with the majority of developers I meet.
They somehow think the customer is less important than the computer.

Consider that if it takes you two years to develop a game, a reasonable
time for a complex game, by the time you are done computers will have
twice the performance and dropped in price by roughly 25%.

When I was in highschool I made a lot of software. Instead of making it
easy to use - I made it educational. It TEACHES the user about the
underlying technology. Not more than is necessary, but not less either.
In my opinion this is one of multiple approaches to the ease-of-use
problem that is much better than sacrificing performance or
functionality.

I have no idea what kind of programs you wrote in high school, nor do I
care. I am talking about writing games in a market where there are many
many game developers all trying to make a buck, or even get noticed.
Anything the developer can do to make the game more attractive to the
customer is a good thing to do.

There is also the slight benefit that it keeps the less technically
inclined from lifting your art and music resources. Some people do
worry
about that.

Technically inclined or not, if you know the name of the media you’re
looking for, you’ll find it on a file sharing network ten times faster
than you’ll rip it out of any sort of proprietary or otherwise
difficult to access archive.

Case and point - I am technically inclined, but if I wanted to get
megaman sprites (and at one point I did want just that) I didn’t
download the ROM and start the laborious process of extracting them - I
searched the internet and downloaded hundreds of them in minutes.

Personally, I think if someone is making money off of your media it
will be relatively easy to find them (or at least the ease of finding
out will be proportional to their ill-gotten success.) And if they’re
using them for personal purposes who gives a damn?

Very, very personally, I know a LOT of people disagree with this - but
even if they used them in an open source project I wouldn’t mind one
bit. Though I’d definitely come down on them for using it without my
permission if that was the case.

And another thing: if they aren’t technically inclined, WHAT are they
going to with your precious media that you wouldn’t want them to do?

Change them and post them to the Internet. Like I said, this is a minor
point. I notice you spent more time on it than on the rest of the
discussion combined.

And then there is the other point… The author wants to do it. It is
his decision to make. He believes there is value in doing it. And you
have 0 (zero) reason or right to object. The fact that you would not do
it that way is not relevant to the discussion.

Oh come on Bob, this is just silly. The nature of an argumentative
objection is not to steal another’s will power from them and force them
to do what you say! It’s totally my right to make this sort of
objection, I’m not forcing anybody to do anything!

As a matter of fact, that is exactly what an argumentative objection is
for. Its only purpose is to try to bully someone into your point of
view. Constructive criticism is always OK. Bullying is not.

You have posted some good stuff on the list, you have also posted a lot
of bullying and belittling stuff. If you want to be respected you need
to drop the bulling and belittling else you wind up in peoples kill
files.

	Bob PendletonOn Sun, 2004-09-26 at 20:40, Donny Viszneki wrote:

On Sep 26, 2004, at 8:36 PM, Bob Pendleton wrote:

On Sun, 2004-09-26 at 16:11, Donny Viszneki wrote:


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

±-------------------------------------+