RE: [Gamedevlists-brew] Alternative to BREW Resource Editor GUI?
Brought to you by:
vexxed72
Menu
▾
▴
RE: [Gamedevlists-brew] Alternative to BREW Resource Editor GUI?
|
From: <jh...@lm...> - 2004-12-11 00:04:10
|
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
>
>
|
