gamedevlists-brew

[Gamedevlists-brew] Alternative to BREW Resource Editor GUI?

[Bill K. <bi...@pe...>]

The BREW Resource editor has always irritated me.  The new version includes 
some features I had always wanted (like the ability to sort the collection of 
resources based on their label or contents... before it didn't even seem to 
properly sort them by ID, which was insanely ridiculous!)

However, the new version is still irritating to use, and just now I took over 
a project from someone else, and had to go in and change about 50 hard-coded 
paths in the BRI file to be relative paths (e.g., "..\bitmaps\" instead of 
"C:\blah\blah\blah\blah\bitmaps\")

Is there an easier way to do this?  I come from the world of Unix and Linux 
development, where the Makefile rules.  If I were to design something like the 
BREW Resource editor, my first step would be to make a command-line tool that 
takes a set of inputs (BRI, which would be editable in a text editor, as well 
as the various resources: BMP, MID, etc.), and then spit out the output (BAR 
binary archive and BRH C header file).

I know some of the BREW tools have command-line options, but was wondering if 
the new BREW 3.x resource editor can be used in this way, or if anyone here 
has any examples of how they've simplified this process.

-bill!
(whose wrist now hurts from all the tedious mousing... >:^P )

Re: [Gamedevlists-brew] Alternative to BREW Resource Editor GUI?

[Guido H. <gh...@g3...>]

> Is there an easier way to do this?  I come from the world of Unix and 
> Linux
> development, where the Makefile rules.  If I were to design something like 
> the


I am using John Szeder's "ReszTool." John is on the list too, so I expect 
him to speak up as well on this and maybe get a demo version of it in your 
hands. His resource editor is XML based, meaning you write an XML file 
listing the resources you want in the BAR file and the toll builds it based 
on that. It allows to create different builds in a single XML file, so you 
can have dedicated builds for each handset if you need to and so forth. 
Becasue it's command line based you can directly include it in your make 
file or VS project builds as well.

I have worked in the tool a bit and also implemented the ability to compress 
files as they are included into the BAR file, which is very important to me 
to avoid intermediate files etc. I made a few other changes that I needed 
and I'm very happy with the tool overall, so I can only recommend it highly.

Guido

RE: [Gamedevlists-brew] Alternative to BREW Resource Editor GUI?

[Tom H. <to...@am...>]

> I am using John Szeder's "ReszTool." John is on the list too, so I expect
> him to speak up as well on this and maybe get a demo version of
> it in your
> hands. His resource editor is XML based, meaning you write an XML file
> listing the resources you want in the BAR file and the toll
> builds it based
> on that. It allows to create different builds in a single XML
> file, so you
> can have dedicated builds for each handset if you need to and so forth.
> Becasue it's command line based you can directly include it in your make
> file or VS project builds as well.
>
> I have worked in the tool a bit and also implemented the ability
> to compress
> files as they are included into the BAR file, which is very
> important to me
> to avoid intermediate files etc. I made a few other changes that I needed
> and I'm very happy with the tool overall, so I can only recommend
> it highly.

I'm using a vastly modified version of John's tool as well. At this stage
the tool is heavily tied to my framework but I've modified it to do things
like image format conversions (we use GIF for BREW and PNG for J2ME), easily
handle multiple languages, emit J2ME classes and BREW headers, etc. It's one
of the pieces of our tools that lets us do BREW and J2ME essentially
simultaneously and target assloads of handsets during development (instead
of porting after).

>From what I hear there's now an XML based BAR compiler as part of the BREW
tools, but I haven't used it and don't know how to get it.

Tom

Re: [Gamedevlists-brew] Alternative to BREW Resource Editor GUI?

[John S. <jo...@se...>]

Hey all...

Anyone who wants to know about the resource tool can email me, it is used at
sorrent, dchoc, and by both Tom and Guido.

Essentially it lets you specific groups of strings and files, and you can
create multiple bar files in different directories with one resource file.

I tried pitching it to qualcomm, but they werent super interested about
adding it to the brew toolkit.

The other thing it does is exports all the strings to a J2ME class file, so
you port from brew to j2me with relative ease.

RE: [Gamedevlists-brew] Alternative to BREW Resource Editor GUI?

[Matt S. <ma...@en...>]

Hi Bill,

Recent versions of the BREW Resource Editor support an XML format (.BRX
instead of .BRI), and can generate BAR files from the command line. You can
convert your existing BRI files to the new XML format by doing a "Save as"
from the resource editor.

Our makefiles have something along the lines of:

$(BREWBIN)\brewrc -o $(APPNAME).bar $(BUILD).brx

Matt. 

RE: [Gamedevlists-brew] Alternative to BREW Resource Editor GUI?

[Aaron I. <ais...@ap...>]

Here was my solution to the BRI/BAR problem:

As with almost all the BREW builtins (text drawing, file reading/writing,
etc), I found it very helpful to write my own.  I don't use BAR files at
all.  It uses zlib compression, which is pretty good for a small ARM
footprint (I got the decompressor down to about 6K).  The resource tool,
written in python which also has built-in zlib support, reads in specially
formatted .h file that defines all the IDs and filenames.  This way my .h
file can't ever get out of sync.  My makefiles also know how to read the
header file, so they can rebuild the resource file once any of the required
files are changed.

-Aaron


> -----Original Message-----
> From: gam...@li... 
> [mailto:gam...@li...] On 
> Behalf Of Bill Kendrick
> Sent: Friday, December 10, 2004 4:02 PM
> To: gam...@li...
> Subject: [Gamedevlists-brew] Alternative to BREW Resource Editor GUI?
> 
> The BREW Resource editor has always irritated me.  The new 
> version includes some features I had always wanted (like the 
> ability to sort the collection of resources based on their 
> label or contents... before it didn't even seem to properly 
> sort them by ID, which was insanely ridiculous!)
> 
> However, the new version is still irritating to use, and just 
> now I took over a project from someone else, and had to go in 
> and change about 50 hard-coded paths in the BRI file to be 
> relative paths (e.g., "..\bitmaps\" instead of
> "C:\blah\blah\blah\blah\bitmaps\")
> 
> Is there an easier way to do this?  I come from the world of 
> Unix and Linux development, where the Makefile rules.  If I 
> were to design something like the BREW Resource editor, my 
> first step would be to make a command-line tool that takes a 
> set of inputs (BRI, which would be editable in a text editor, 
> as well as the various resources: BMP, MID, etc.), and then 
> spit out the output (BAR binary archive and BRH C header file).
> 
> I know some of the BREW tools have command-line options, but 
> was wondering if the new BREW 3.x resource editor can be used 
> in this way, or if anyone here has any examples of how 
> they've simplified this process.
> 
> -bill!
> (whose wrist now hurts from all the tedious mousing... >:^P )
> 
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide Read honest & 
> candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now. 
> http://productguide.itmanagersjournal.com/
> _______________________________________________
> Gamedevlists-brew mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-brew
> 

RE: [Gamedevlists-brew] Alternative to BREW Resource Editor GUI?

[<jh...@lm...>]

My solution is similar; I have long since abandoned QUALCOMM's file format.  I
rolled my own command-line tool that reads a simple line-oriented text file. 
(Aaron, my ZLIB decompressor is about the same size :).  I also support a
simple RLE compression, and when I have an application which is memory bound
but not asset bound, or a low-asset app on a slow device, I cut out the ZLIB
decompressor and just go with RLE (which has a 300 byte stateless
decompressor).

I had three major complaints with QUALCOMM's tools.  The first was the lack of
command-line invocation which I understand they have now fixed.

The second problem I had was the need to maintain multiple .bri/.brx files when
I've got more than one build of the same app.  I wanted something that better
supported the Single Point Of Truth design rule; I wanted a single "bar
template" file which served *all* the builds for each app.  My solution is to
support a *very* simple template format, but then I pass the template through
the C preprocessor before building.  This lets me do things like:

  #ifdef BUILD_BIG_PHONES
  asset.bmp  bigAssets/asset.bmp  ZLIB
  #else
  asset.bmp  smallAssets/asset.bmp RLE
  #endif

or even:

  asset.bmp  BUILD_DIR/asset.bmp  BUILD_BMP_COMPRESSION

Though I despise preprocessor use in code, I have been very happy with this
simple trick, and it only took me five minutes to implement it in my Makefiles,
and the dependencies for the entire process were easily integrated and
expressed with a few short pattern rules.  I don't believe that the XML-ization
of the .bri files helps much on this score, though human-inspectability is a
*huge* improvement.

The final, damning problem I had was the .brh file.  While it's "efficient" to
refer to each asset as a simple integer, I think it's bad practice to generate
code which requires a recompile each time you tweak the assets.  Strict
dependency checking would require you to recompile the .bar each time you
edited a single pixel of a single asset, and this in turn would require you to
recompile and relink your project.  Sloppy dependency checking would lead to
mistakes with .brh version skew as assets are added or rearranged.

My soution to this final problem was to use symbolic names; the "asset.bmp" in
the first column of the above examples.  My resource file comes with a symbol
table which contains the offsets, sizes, dimensions, and transparency-use of
all the art.  In this I'm following the same pattern we have in the J2ME world,
where your resource file is file-system-like.  In fact, I support exactly this
syntax:

   Image img = Image::createImage("asset.bmp"); 

Since stuff like image height and width live in the symbol table, this allows me
to delay loading (and uncompressing, and converting to native format) all of my
assets until draw-time.  I can happily do calculations on img.getWidth(), etc.,
but the actual data isn't loaded until (unless) I draw it.

-JHW

Quoting Aaron Isaksen <ais...@ap...>:

> Here was my solution to the BRI/BAR problem:
> 
> As with almost all the BREW builtins (text drawing, file reading/writing,
> etc), I found it very helpful to write my own.  I don't use BAR files at
> all.  It uses zlib compression, which is pretty good for a small ARM
> footprint (I got the decompressor down to about 6K).  The resource tool,
> written in python which also has built-in zlib support, reads in specially
> formatted .h file that defines all the IDs and filenames.  This way my .h
> file can't ever get out of sync.  My makefiles also know how to read the
> header file, so they can rebuild the resource file once any of the required
> files are changed.
> 
> -Aaron
> 
> 
> > -----Original Message-----
> > From: gam...@li... 
> > [mailto:gam...@li...] On 
> > Behalf Of Bill Kendrick
> > Sent: Friday, December 10, 2004 4:02 PM
> > To: gam...@li...
> > Subject: [Gamedevlists-brew] Alternative to BREW Resource Editor GUI?
> > 
> > The BREW Resource editor has always irritated me.  The new 
> > version includes some features I had always wanted (like the 
> > ability to sort the collection of resources based on their 
> > label or contents... before it didn't even seem to properly 
> > sort them by ID, which was insanely ridiculous!)
> > 
> > However, the new version is still irritating to use, and just 
> > now I took over a project from someone else, and had to go in 
> > and change about 50 hard-coded paths in the BRI file to be 
> > relative paths (e.g., "..\bitmaps\" instead of
> > "C:\blah\blah\blah\blah\bitmaps\")
> > 
> > Is there an easier way to do this?  I come from the world of 
> > Unix and Linux development, where the Makefile rules.  If I 
> > were to design something like the BREW Resource editor, my 
> > first step would be to make a command-line tool that takes a 
> > set of inputs (BRI, which would be editable in a text editor, 
> > as well as the various resources: BMP, MID, etc.), and then 
> > spit out the output (BAR binary archive and BRH C header file).
> > 
> > I know some of the BREW tools have command-line options, but 
> > was wondering if the new BREW 3.x resource editor can be used 
> > in this way, or if anyone here has any examples of how 
> > they've simplified this process.
> > 
> > -bill!
> > (whose wrist now hurts from all the tedious mousing... >:^P )
> > 
> > 
> > -------------------------------------------------------
> > SF email is sponsored by - The IT Product Guide Read honest & 
> > candid reviews on hundreds of IT Products from real users.
> > Discover which products truly live up to the hype. Start reading now. 
> > http://productguide.itmanagersjournal.com/
> > _______________________________________________
> > Gamedevlists-brew mailing list
> > Gam...@li...
> > https://lists.sourceforge.net/lists/listinfo/gamedevlists-brew
> > 
> 
> 
> 
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now. 
> http://productguide.itmanagersjournal.com/
> _______________________________________________
> Gamedevlists-brew mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-brew
> 
> 

Re: [Gamedevlists-brew] Alternative to BREW Resource Editor GUI?

[Charlie W. <ch...@fi...>]

barc also does command line compilation as well as do some things some of 
the brew resource
editors cannot., its also a text format so you can use a preprocessor, you 
can use real dependancy
checking via a makefile just in the same way as you do for a .c/cpp file.

its been available for a while, in the browser toolkit

charlie



> My solution is similar; I have long since abandoned QUALCOMM's file 
> format.  I

Re: [Gamedevlists-brew] Alternative to BREW Resource Editor GUI?

[Bill K. <bi...@pe...>]

jh...@lm... wrote:
> My solution is similar; I have long since abandoned QUALCOMM's file format.

Isn't there a potential issue with taking up extra space when users disable 
your app?  (Here I'm assuming this is something that users actually do in the 
real world.  I don't have my own BREW phone, so I don't play with other 
people's BREW apps much.  I can't imagine myself liking an app enough to keep 
it, but /still/ having some need to disable it.)

e.g., when one "disables" an app on their phone, it kills the MOD and BAR 
files, but that's about it.  (Then it re-downloads everything when it's 
reactivated)

I guess it can't be too much of an issue, since I have seen so many people 
mention that they've stopped using BAR files. ;^)

-bill!

RE: [Gamedevlists-brew] Alternative to BREW Resource Editor GUI?

[Tom H. <to...@am...>]

> I guess it can't be too much of an issue, since I have seen so
> many people
> mention that they've stopped using BAR files. ;^)

It kills any files (regardless of type) that were part of the original
installation. Any files that are created later are left behind. In other
words, it isn't a problem ;)

Tom

Re: [Gamedevlists-brew] Alternative to BREW Resource Editor GUI?

[<jh...@lm...>]

Quoting Bill Kendrick <bi...@pe...>:

> 
> jh...@lm... wrote:
> > My solution is similar; I have long since abandoned QUALCOMM's file
> format.
> 
> Isn't there a potential issue with taking up extra space when users disable 
> your app?  (Here I'm assuming this is something that users actually do in the
> 
> real world.  I don't have my own BREW phone, so I don't play with other 
> people's BREW apps much.  I can't imagine myself liking an app enough to keep
> 
> it, but /still/ having some need to disable it.)
> 
> e.g., when one "disables" an app on their phone, it kills the MOD and BAR 
> files, but that's about it.  (Then it re-downloads everything when it's 
> reactivated)
> 
> I guess it can't be too much of an issue, since I have seen so many people 
> mention that they've stopped using BAR files. ;^)
> 
> -bill!

Well, I still call it a ".bar" file, even though it's a different format.  This
might be a bit of an abuse, but since the AppLoader and Get It Now's disable
features give files with these extensions special treatment, I just piggy
back.

-JHW

Re: [Gamedevlists-brew] Alternative to BREW Resource Editor GUI?

[Guido H. <gh...@g3...>]

>>since the AppLoader and Get It Now's disable
> features give files with these extensions special treatment

What special treament may that be? That's the first itme I hear that, 
really. Anything exciting that can be put to actual use?

Guido 

Re: [Gamedevlists-brew] Alternative to BREW Resource Editor GUI?

[Tom P. <bre...@ac...>]

> >>since the AppLoader and Get It Now's disable
> > features give files with these extensions special treatment
> 
> What special treament may that be? That's the first itme I hear that, 
> really. Anything exciting that can be put to actual use?

I think Jesse means that AppLoader won't allow you to
copy a .bar from the phone. At least any version of
AppLoader that came out in the past 20 months or so.
--t

Re: [Gamedevlists-brew] Alternative to BREW Resource Editor GUI?

[<jh...@lm...>]

Well, there was a mistake on my initial post: Get It Now doesn't give any
special treatment.  Whether or nor a file is preserved when the user disables
an app depends on how it was signed, as Bill Kendrick pointed out.

The AppLoader, however, offers special treatment for certain file extensions. 
The "copy file from device" option is disabled for .mif, .mod, .sig, and .bar
files.  If there's anything else up there (i.e. a .dat, .cfg, .txt, .foo) file,
then you can copy it from the device to your desktop.  I'm sure many of us have
exploited this to generate and recover a logfile on the Nokia devices which
don't support the Logger, or the VX4400 which corrupts the log stream.

Anyhow, this is why I give my custom asset files the .bar extension: even if
it's just a small hurdle to a dedicated ripper, I didn't think it was right to
deny my clients' assets this extra protection.

-JHW


Quoting Guido Henkel <gh...@g3...>:

> >>since the AppLoader and Get It Now's disable
> > features give files with these extensions special treatment
> 
> What special treament may that be? That's the first itme I hear that, 
> really. Anything exciting that can be put to actual use?
> 
> Guido 
> 
> 
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now. 
> http://productguide.itmanagersjournal.com/
> _______________________________________________
> Gamedevlists-brew mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-brew
> 
>