gamedevlists-brew Mailing List for gamedev (Page 2)
Brought to you by:
vexxed72
Menu
▾
▴
gamedevlists-brew — This list is for discussing game creation on the BREW mobile platform.
You can subscribe to this list here.
| 2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(75) |
|---|
|
From: Bill K. <bi...@pe...> - 2004-12-13 18:27:56
|
So I asked this on the BREW Forums lately, but thought I'd ask here. How about an IRC channel? :) Though I admittedly only use the technical ones for my personal (hobby?) Open Source development (e.g., I hang out in the #sdl and #zaurus channels on FreeNode.net), I think it might be a useful addition to the forums and this list for discussing BREW issues. Or, am I the only one who'd be into that? ;) -bill! |
|
From: Guido H. <gh...@g3...> - 2004-12-13 18:20:30
|
Back on the subject, here's my plan... I will close the list off and not allow public subscription. As a general rule I will only allow new members by invitation only, which means they will need to be sponsored by an exisiting list member. However, before inviting people to the list, please check with the list if anyone has a reason against the addition of a particular invitee. In addition to that I will allow people to send me uninvited subscription requests so we can also bring in valuable people even if they are not well connected. New subscribers will have to send me an email complete with an outline as to why they wish to be added to the list. I will look ovoer the outline and if it is someone of potential interest and value to the list I will also ask to see if anyone has reason to reject the candidate. I hope this is okay with everyone, as I do think a closed list makes more sense than a completely open one and will help us keep the noise to a minimum, and the friendliness at a maximum. As for privacy I am currently looking into additional software solutions that may allow me to take the list entirely private so that the posts and archives cannot be viewed by non-subscribers. Evidently this will mean that we may have to move the list again in the next days or so since Sourceforge doesn't offer that, but I hope that's all right, especially since I will automatically re-subscribe everyone if that's going to be the case. Guido |
|
From: Tom P. <bre...@ac...> - 2004-12-12 02:04:21
|
> Is there sneaky way to use the built-in zip decompressor that is required
> for decompressing the jar and png files? I was thinking of putting the data
> in a fake PNG 24-bit image, but I don't see a way to read it. It would be a
> shame to have to bring along a ZIP decompressor in my jar, just because they
> didn't expose it in the MIDP API.
Oh, have you not tried this method?
InputConnection conn = Connector.open("jar:/dictionary.jar", Connector.READ);
DataInputStream dis = conn.openDataInputStream();
Just kidding. It's annoying that they didn't expose an
inflate in MIDP2. They did add Image.getRGB, but that
still doesn't help because the values can be altered
to phone-safe colors.
You said you already have a decompressor, but you might
be interested in looking at this one:
http://www.java4ever.com/index.php?section=j2me&project=apime&menu=download&lang=en
> Given that some phones decompress the application at install time, as Tom P
> explains, it seems that I can't rely on the zip compression in the jar file
> alone.
Well, you could make a separate version for iDEN phones.
--t
|
|
From: Rich C. <rc...@m-...> - 2004-12-12 01:25:07
|
Hey all, thanks for letting me in the secret club. I am sorta lying low until I figure I can contribute something useful, but just wanted to announce my lurkiness. I'm mCube over at Qualcomm's boards, btw. But I've had various other handles there too, over the past coupla years. RC -----Original Message----- From: gam...@li... [mailto:gam...@li...] On Behalf Of gam...@li... Sent: Saturday, December 11, 2004 4:39 PM To: gam...@li... Subject: Gamedevlists-brew digest, Vol 1 #4 - 9 msgs Send Gamedevlists-brew mailing list submissions to gam...@li... To subscribe or unsubscribe via the World Wide Web, visit https://lists.sourceforge.net/lists/listinfo/gamedevlists-brew or, via email, send a message with subject or body 'help' to gam...@li... You can reach the person managing the list at gam...@li... When replying, please edit your Subject line so it is more specific than "Re: Contents of Gamedevlists-brew digest..." Today's Topics: 1. Re: Gauging the vibe... (Tom Park) 2. RE: Gauging the vibe... (Aaron Isaksen) 3. RE: Power issues on phones (ruben Tech) 4. Re: Alternative to BREW Resource Editor GUI? (John Szeder) 5. Re: Gauging the vibe... (John Szeder) 6. Re: Gauging the vibe... (Guido Henkel) 7. porting a database file from BREW to J2ME (Aaron Isaksen) 8. RE: porting a database file from BREW to J2ME (Tom Hubina) 9. Re: Alternative to BREW Resource Editor GUI? (jh...@lm...) --__--__-- Message: 1 From: "Tom Park" <bre...@ac...> To: <gam...@li...> Subject: Re: [Gamedevlists-brew] Gauging the vibe... Date: Fri, 10 Dec 2004 20:21:54 -0800 Reply-To: gam...@li... > what kind of proprietary and sensitive matters would folks be > willing to discuss on a private list? One example: while particular device specs are discussed on the forum, there is no easy-to-query database that covers all the devices because Qualcomm isn't allowed to publish it. We could. It's simple enough to write and share a device profiler-benchmark applet. We could share the output. It would make our lives easier. It would give competitive advantage to the recipients. If you are not self-employed, would your employer allow you to share such data? Well, I doubt mine would, if it were entirely my own effort. However, as a collaborative effort, who would own such data? While the relative sales numbers for various handsets are pretty obvious, that's another sensitive area where people might share data. > For me personally, I like having a focused technical list that can be a > better resource than the BREW forums and I'm happy to keep the secret stuff > in IM or private emails. Part of the value in the list is that you get contribution from several people, not just a couple guys. >I was half tempted to suggest that this list be > opened up to J2ME as well as BREW, but that can always be a different list. Yeah, I was going to suggest the same thing, seeing how we all probably are doing J2ME work as well, and probably other wireless mobile APIs like Symbian and Smartphone. The occassional off-topic email probably won't hurt, especially if you're talking about porting btwn platforms. --t --__--__-- Message: 2 From: "Aaron Isaksen" <ais...@ap...> To: <gam...@li...> Subject: RE: [Gamedevlists-brew] Gauging the vibe... Date: Fri, 10 Dec 2004 23:17:48 -0500 Reply-To: gam...@li... RE private lists: There are some technical things that I've discovered over the past 2 years developing for BREW that I'd be happy to share with people that I knew would return the favor and share what they know. This detailed knowledge is what makes us valuable developers. Sharing that knowledge with our peers make us even better. However, giving away that advice for free to people who will only use it to compete with us and not expand what we are capable of, might not make sense. The biggest downside to having a secret list is that some very knowledgeable, but not well connected, people could be left out. RE J2ME: I would not mind if this list also focused on J2ME, unless the traffic and volume got too high. I have started porting our apps to J2ME, and I already have several questions that I couldn't find answers to. If not this list, then I would love to be part of a similar list focused on J2ME. -Aaron > -----Original Message----- > From: gam...@li... > [mailto:gam...@li...] On > Behalf Of Tom Hubina > Sent: Friday, December 10, 2004 10:52 PM > To: gam...@li... > Subject: RE: [Gamedevlists-brew] Gauging the vibe... > > The privacy stuff is limited because it is on SourceForge > and, well, they're all about "open" .. heh. > > I was under the impression that this was going to be a > technical list, but I'm curious, what kind of proprietary and > sensitive matters would folks be willing to discuss on a > private list? I'm on some myself already and while they start > off strong it seems like the sensitive stuff ends up getting > discussed in private messages anyway ;) > > Beyond that, if there's people we trust enough to discuss > sensitive stuff with, what's wrong with inviting them on to > the private lists already in existence? As Guido mentioned, > we're already on them so in theory we can do that if we want. > > For me personally, I like having a focused technical list > that can be a better resource than the BREW forums and I'm > happy to keep the secret stuff in IM or private emails. I was > half tempted to suggest that this list be opened up to J2ME > as well as BREW, but that can always be a different list. > > Tom > > > -----Original Message----- > > From: gam...@li... > > [mailto:gam...@li...]On Behalf Of > > Guido Henkel > > Sent: Friday, December 10, 2004 7:37 PM > > To: gam...@li... > > Subject: Re: [Gamedevlists-brew] Gauging the vibe... > > > > > > Yes, I am familiar with these lists and some of us are actually > > members of some of these lists as well. In actuality, I > would like to > > make this list completely private and allow new subscribers by > > invitation only but it seems that the sourceforge list > setup that we > > have here doesn't allow for tha - at least not that Tom Hubina or I > > are aware of. Otherwise I'd be all for closing off the list to > > outsiders so that we can also discuss proprietary and sensitive > > matters here. > > > > 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 > > > > > > ------------------------------------------------------- > 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 > --__--__-- Message: 3 Date: Fri, 10 Dec 2004 23:28:32 -0800 (PST) From: ruben Tech <rub...@ya...> Subject: RE: [Gamedevlists-brew] Power issues on phones To: gam...@li... Reply-To: gam...@li... --0-255098488-1102750112=:49387 Content-Type: text/plain; charset=us-ascii How are you shutting down the application? Do you shut down the application by pressing "END/pwr" key or by pressing "CLR" key (when the application at top level)? If you are observing power drain issue after shutting down the application by pressing "END/pwr" key, that's possibly a bug I have observe in LG phones (specifically LG7000 and pre-commercial LG8000 phones). At least in LG7000/8000 if you press END/pwr key to shut down the application, it wouldn't behave correctly. Your application willn't receive EVT_APP_STOP and then FreeAppData call, however it will be put into a very strange background state and it keeps running (one of my sample hello world app can reproduce this case). In my opinion that could be the possible cause of power drain. I have reported the problem to VZW, let you know any update I receive. Jon-Eric Simmons <jsi...@sh...> wrote: In every game we do, we return TRUE for the EVT_APP_NO_SLEEP to keep the phone from going into power saving mode (which yields unacceptable performance). I would think the correct implementation would be that the phone would attempt to go to sleep some time after my app has exited and that attempt would be successful since there is no app to stop it. Perhaps some phones incorrectly never sleep once an app has denied them that option. Commenting out the EVT_APP_NO_SLEEP handling on an offending handset would show if there is any connection. Just a thought. -Jon-Eric -----Original Message----- From: gam...@li... [mailto:gam...@li...] On Behalf Of Aaron Isaksen Sent: Friday, December 10, 2004 3:59 PM To: gam...@li... Subject: [Gamedevlists-brew] Power issues on phones Hello, Has anyone experienced any power problems AFTER your app has been run on a handset? A developer I work with is reporting some odd behavior, where his LG test phones burn down much quicker after we've run our app and its been exited normally. Our app doesn't do anything fancy with background behavior, its just a game. He reports that after running our game for 5 minutes and then quitting, the phone will be dead in 8 hours. Even if he puts the phone on the charger right after playing the game, waits for it to charge up, and then removes it from the charger, it will still burn down in 8 hours, so its not itself that burns too much power. He also reports this behavior with some games he downloaded (Tetris, Q-Bert) a while ago. We are running some tests to measure this, but I wanted to know if anyone experienced something similar. Thank you, Aaron Isaksen President/CEO, AppAbove Inc. ais...@ap... TEL: 646-613-0484 ------------------------------------------------------- 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 --------------------------------- Do you Yahoo!? Jazz up your holiday email with celebrity designs. Learn more. --0-255098488-1102750112=:49387 Content-Type: text/html; charset=us-ascii <DIV>How are you shutting down the application? Do you shut down the application by pressing "END/pwr" key or by pressing "CLR" key (when the application at top level)?</DIV> <DIV> </DIV> <DIV>If you are observing power drain issue after shutting down the application by pressing "END/pwr" key, that's possibly a bug I have observe in LG phones (specifically LG7000 and pre-commercial LG8000 phones). At least in LG7000/8000 if you press END/pwr key to shut down the application, it wouldn't behave correctly. Your application willn't receive EVT_APP_STOP and then FreeAppData call, however it will be put into a very strange background state and it keeps running (one of my sample hello world app can reproduce this case). In my opinion that could be the possible cause of power drain. I have reported the problem to VZW, let you know any update I receive.<BR><BR><B><I>Jon-Eric Simmons <jsi...@sh...></I></B> wrote:</DIV> <BLOCKQUOTE class=replbq style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #1010ff 2px solid">In every game we do, we return TRUE for the EVT_APP_NO_SLEEP to keep the<BR>phone from going into power saving mode (which yields unacceptable<BR>performance).<BR><BR>I would think the correct implementation would be that the phone would<BR>attempt to go to sleep some time after my app has exited and that attempt<BR>would be successful since there is no app to stop it.<BR><BR>Perhaps some phones incorrectly never sleep once an app has denied them that<BR>option.<BR><BR>Commenting out the EVT_APP_NO_SLEEP handling on an offending handset would<BR>show if there is any connection.<BR><BR>Just a thought.<BR><BR>-Jon-Eric<BR><BR>-----Original Message-----<BR>From: gam...@li...<BR>[mailto:gamedevlists-brew-a dm...@li...] On Behalf Of Aaron<BR>Isaksen<BR>Sent: Friday, December 10, 2004 3:59 PM<BR>To: gam...@li...<BR>Subject: [Gamedevlists-brew] Power issues on phones<BR><BR>Hello,<BR><BR>Has anyone experienced any power problems AFTER your app has been run on a<BR>handset? A developer I work with is reporting some odd behavior, where his<BR>LG test phones burn down much quicker after we've run our app and its been<BR>exited normally. Our app doesn't do anything fancy with background<BR>behavior, its just a game. He reports that after running our game for 5<BR>minutes and then quitting, the phone will be dead in 8 hours. <BR><BR>Even if he puts the phone on the charger right after playing the game, waits<BR>for it to charge up, and then removes it from the charger, it will still<BR>burn down in 8 hours, so its not itself that burns too much power.<BR><BR>He also reports this behavior with some games he downloaded (Tetris, Q-Bert)<BR>a while ago.<BR><BR>We are running some tests to measure this, but I wanted to know if anyone<BR>experienced some! thing similar.<BR><BR>Thank you,<BR><BR>Aaron Isaksen<BR>President/CEO, AppAbove Inc.<BR>ais...@ap...<BR>TEL: 646-613-0484<BR><BR><BR><BR><BR>-------------------------------------------- -----------<BR>SF email is sponsored by - The IT Product Guide<BR>Read honest & candid reviews on hundreds of IT Products from real users.<BR>Discover which products truly live up to the hype. Start reading now. <BR>http://productguide.itmanagersjournal.com/<BR>__________________________ _____________________<BR>Gamedevlists-brew mailing list<BR>Gam...@li...<BR>https://lists.sourceforge .net/lists/listinfo/gamedevlists-brew<BR><BR><BR><BR>----------------------- --------------------------------<BR>SF email is sponsored by - The IT Product Guide<BR>Read honest & candid reviews on hundreds of IT Products from real users.<BR>Discover which products truly live up to the hype. Start reading now. <BR>http://productguide.itmanagersjournal.com/<BR>__________________________ _____________________<BR>Gamedevlists-brew mailing list<BR>Gam...@li...<BR>https://lists.sourceforge .net/lists/listinfo/gamedevlists-brew<BR></BLOCKQUOTE><p> <hr size=1>Do you Yahoo!?<br> Jazz up your holiday email with celebrity designs. <a href="http://us.rd.yahoo.com/evt=29910/*http://celebrity.mail.yahoo.com">Lea rn more.</a> --0-255098488-1102750112=:49387-- --__--__-- Message: 4 From: "John Szeder" <jo...@se...> To: <gam...@li...> Subject: Re: [Gamedevlists-brew] Alternative to BREW Resource Editor GUI? Date: Sat, 11 Dec 2004 00:57:25 -0800 Reply-To: gam...@li... 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. --__--__-- Message: 5 From: "John Szeder" <jo...@se...> To: <gam...@li...> Subject: Re: [Gamedevlists-brew] Gauging the vibe... Date: Sat, 11 Dec 2004 01:03:35 -0800 Reply-To: gam...@li... > RE private lists: There are some technical things that I've discovered over > the past 2 years developing for BREW that I'd be happy to share with people > that I knew would return the favor and share what they know. This detailed > knowledge is what makes us valuable developers. Sharing that knowledge with > our peers make us even better. However, giving away that advice for free to > people who will only use it to compete with us and not expand what we are > capable of, might not make sense. Agreed. Plus I like super sekret clubs. > RE J2ME: I would not mind if this list also focused on J2ME, unless the > traffic and volume got too high. I have started porting our apps to J2ME, > and I already have several questions that I couldn't find answers to. If > not this list, then I would love to be part of a similar list focused on > J2ME. What he said. How about that j2me, eh? --__--__-- Message: 6 From: "Guido Henkel" <gh...@g3...> To: <gam...@li...> Subject: Re: [Gamedevlists-brew] Gauging the vibe... Date: Sat, 11 Dec 2004 09:42:49 -0800 Reply-To: gam...@li... > How about that j2me, eh? Alright, sure, let's open this mailing list to J2ME or other mobile development related discussions as well. As Tom said, most of us are probably dabbling in these different areas as well anyway so we can just as well talk about it. Guido --__--__-- Message: 7 From: "Aaron Isaksen" <ais...@ap...> To: <gam...@li...> Date: Sat, 11 Dec 2004 14:54:52 -0500 Subject: [Gamedevlists-brew] porting a database file from BREW to J2ME Reply-To: gam...@li... Hello, Well I figure I might as well take advantage of our new freedoms... I'm doing a port of our Spanish/English dictionary and phrase book application from BREW to J2ME, and I'm a bit annoyed there is no file i/o functions in J2ME, just a stream reading function. The compressed database was designed to be very efficient in BREW, but I think it needs to be redesigned from the ground up to be efficient in J2ME. One small advantage is that I can rely on the built in zip/jar support to do some of the decompression work. The database is read-only, so I don't need to mess with RecordStores. 1) Has anyone noticed a phone that completely decompresses the JAR, including non-class files, into memory when the app is first loaded? That is, do all known J2ME phones keep the resources compressed until requested? 2) Do any phones degrade in performance when large numbers of small files are stored in the jar file? Thank you! -Aaron --__--__-- Message: 8 From: "Tom Hubina" <to...@am...> To: <gam...@li...> Subject: RE: [Gamedevlists-brew] porting a database file from BREW to J2ME Date: Sat, 11 Dec 2004 12:34:36 -0800 Reply-To: gam...@li... > -----Original Message----- > 1) Has anyone noticed a phone that completely decompresses the JAR, > including non-class files, into memory when the app is first loaded? That > is, do all known J2ME phones keep the resources compressed until > requested? Yes. A file is only loaded into memory when you open it. To be even more specific, if you're loading a 100k file and using the stream mechanism to get to a record 50k in, then 50k of the file will be loaded into memory. So far I haven't found a phone that would let you seek to the 50k mark without having the preceding 50k in your heap. As I figure it, this is due to the file you're loading being zipped inside the jar, so you need to decompress from the start to the point where you want ... you can't just jump to it. In case it isn't obvious, this also means you have significant performance issues if you're going to be seeking all over the place in a file. It might be interesting to just store the file in the jar, and not deflate it. Maybe it would allow you do seek with good performance and without hitting the heap if the file isn't compressed. You would need to create the it with a tool other than jar, or modify the jar with WinZip after or something. > 2) Do any phones degrade in performance when large numbers of small files > are stored in the jar file? I haven't run into any performance issues, but there's a pretty large overhead per file (~150 bytes) so if download size is a concern having lots of files is a very bad thing. Tom --__--__-- Message: 9 Date: Sat, 11 Dec 2004 13:38:28 -0800 From: jh...@lm... To: gam...@li... Subject: Re: [Gamedevlists-brew] Alternative to BREW Resource Editor GUI? Reply-To: gam...@li... 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 > > --__--__-- _______________________________________________ Gamedevlists-brew mailing list Gam...@li... https://lists.sourceforge.net/lists/listinfo/gamedevlists-brew End of Gamedevlists-brew Digest |
|
From: Aaron I. <ais...@ap...> - 2004-12-11 23:25:43
|
Thank you Tom P and Tom H for your insights. I imagine that I can speed up the seek process by breaking up the database into several smaller chunks, each stored as a separate file in the jar (but not too small, as Tom H points out). In addition, I had already planning on reworking the record search algorithm so it didn't have to do any reverse seeks, which I could tell would be inefficient from the stream API. Given that some phones decompress the application at install time, as Tom P explains, it seems that I can't rely on the zip compression in the jar file alone. Is there sneaky way to use the built-in zip decompressor that is required for decompressing the jar and png files? I was thinking of putting the data in a fake PNG 24-bit image, but I don't see a way to read it. It would be a shame to have to bring along a ZIP decompressor in my jar, just because they didn't expose it in the MIDP API. -Aaron > -----Original Message----- > From: gam...@li... > [mailto:gam...@li...] On > Behalf Of Tom Park > Sent: Saturday, December 11, 2004 5:32 PM > To: gam...@li... > Subject: Re: [Gamedevlists-brew] porting a database file from > BREW to J2ME > > > > 1) Has anyone noticed a phone that completely > decompresses the JAR, > > > including non-class files, into memory when the app is > first loaded? > > > That is, do all known J2ME phones keep the resources compressed > > > until requested? > > > > Yes. A file is only loaded into memory when you open it. To be even > > more > [...] > > It might be interesting to just store the file in the jar, and not > > deflate it. Maybe it would allow you do seek with good > performance and > > without > > No, I'm assuming that Aaron is already asking whether it's > okay to leave the file decompressed in the JAR, because he's > worried that if the phone decompressed the JAR then it'd be too big. > > Nextel iDEN phones definitely decompress the JAR upon install. > Install is a different step from download. The classes go > into a program space, and resources go into a data space. > There are iDEN-specific JAD properties for the decompressed > size, e.g.: > > iDEN-Data-Space-Requirement: 112 > iDEN-Program-Space-Requirement: 157 > > where the values are in KB. > > Offhand, I don't know of other phones that decompress the > JAR, but I wouldn't assume Motorola is not or will not be the > only one to use this optimization for J2ME performance. > --t > > > > ------------------------------------------------------- > 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 > |
|
From: Tom P. <bre...@ac...> - 2004-12-11 22:26:35
|
> > 1) Has anyone noticed a phone that completely decompresses the JAR, > > including non-class files, into memory when the app is first loaded? That > > is, do all known J2ME phones keep the resources compressed until > > requested? > > Yes. A file is only loaded into memory when you open it. To be even more [...] > It might be interesting to just store the file in the jar, and not deflate > it. Maybe it would allow you do seek with good performance and without No, I'm assuming that Aaron is already asking whether it's okay to leave the file decompressed in the JAR, because he's worried that if the phone decompressed the JAR then it'd be too big. Nextel iDEN phones definitely decompress the JAR upon install. Install is a different step from download. The classes go into a program space, and resources go into a data space. There are iDEN-specific JAD properties for the decompressed size, e.g.: iDEN-Data-Space-Requirement: 112 iDEN-Program-Space-Requirement: 157 where the values are in KB. Offhand, I don't know of other phones that decompress the JAR, but I wouldn't assume Motorola is not or will not be the only one to use this optimization for J2ME performance. --t |
|
From: <jh...@lm...> - 2004-12-11 21:38:29
|
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 > > |
|
From: Tom H. <to...@am...> - 2004-12-11 20:36:00
|
> -----Original Message----- > 1) Has anyone noticed a phone that completely decompresses the JAR, > including non-class files, into memory when the app is first loaded? That > is, do all known J2ME phones keep the resources compressed until > requested? Yes. A file is only loaded into memory when you open it. To be even more specific, if you're loading a 100k file and using the stream mechanism to get to a record 50k in, then 50k of the file will be loaded into memory. So far I haven't found a phone that would let you seek to the 50k mark without having the preceding 50k in your heap. As I figure it, this is due to the file you're loading being zipped inside the jar, so you need to decompress from the start to the point where you want ... you can't just jump to it. In case it isn't obvious, this also means you have significant performance issues if you're going to be seeking all over the place in a file. It might be interesting to just store the file in the jar, and not deflate it. Maybe it would allow you do seek with good performance and without hitting the heap if the file isn't compressed. You would need to create the it with a tool other than jar, or modify the jar with WinZip after or something. > 2) Do any phones degrade in performance when large numbers of small files > are stored in the jar file? I haven't run into any performance issues, but there's a pretty large overhead per file (~150 bytes) so if download size is a concern having lots of files is a very bad thing. Tom |
|
From: Aaron I. <ais...@ap...> - 2004-12-11 19:55:03
|
Hello, Well I figure I might as well take advantage of our new freedoms... I'm doing a port of our Spanish/English dictionary and phrase book application from BREW to J2ME, and I'm a bit annoyed there is no file i/o functions in J2ME, just a stream reading function. The compressed database was designed to be very efficient in BREW, but I think it needs to be redesigned from the ground up to be efficient in J2ME. One small advantage is that I can rely on the built in zip/jar support to do some of the decompression work. The database is read-only, so I don't need to mess with RecordStores. 1) Has anyone noticed a phone that completely decompresses the JAR, including non-class files, into memory when the app is first loaded? That is, do all known J2ME phones keep the resources compressed until requested? 2) Do any phones degrade in performance when large numbers of small files are stored in the jar file? Thank you! -Aaron |
|
From: Guido H. <gh...@g3...> - 2004-12-11 17:42:43
|
> How about that j2me, eh? Alright, sure, let's open this mailing list to J2ME or other mobile development related discussions as well. As Tom said, most of us are probably dabbling in these different areas as well anyway so we can just as well talk about it. Guido |
|
From: John S. <jo...@se...> - 2004-12-11 09:16:44
|
> RE private lists: There are some technical things that I've discovered over > the past 2 years developing for BREW that I'd be happy to share with people > that I knew would return the favor and share what they know. This detailed > knowledge is what makes us valuable developers. Sharing that knowledge with > our peers make us even better. However, giving away that advice for free to > people who will only use it to compete with us and not expand what we are > capable of, might not make sense. Agreed. Plus I like super sekret clubs. > RE J2ME: I would not mind if this list also focused on J2ME, unless the > traffic and volume got too high. I have started porting our apps to J2ME, > and I already have several questions that I couldn't find answers to. If > not this list, then I would love to be part of a similar list focused on > J2ME. What he said. How about that j2me, eh? |
|
From: John S. <jo...@se...> - 2004-12-11 09:10:35
|
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. |
|
From: ruben T. <rub...@ya...> - 2004-12-11 07:28:33
|
How are you shutting down the application? Do you shut down the application by pressing "END/pwr" key or by pressing "CLR" key (when the application at top level)? If you are observing power drain issue after shutting down the application by pressing "END/pwr" key, that's possibly a bug I have observe in LG phones (specifically LG7000 and pre-commercial LG8000 phones). At least in LG7000/8000 if you press END/pwr key to shut down the application, it wouldn't behave correctly. Your application willn't receive EVT_APP_STOP and then FreeAppData call, however it will be put into a very strange background state and it keeps running (one of my sample hello world app can reproduce this case). In my opinion that could be the possible cause of power drain. I have reported the problem to VZW, let you know any update I receive. Jon-Eric Simmons <jsi...@sh...> wrote: In every game we do, we return TRUE for the EVT_APP_NO_SLEEP to keep the phone from going into power saving mode (which yields unacceptable performance). I would think the correct implementation would be that the phone would attempt to go to sleep some time after my app has exited and that attempt would be successful since there is no app to stop it. Perhaps some phones incorrectly never sleep once an app has denied them that option. Commenting out the EVT_APP_NO_SLEEP handling on an offending handset would show if there is any connection. Just a thought. -Jon-Eric -----Original Message----- From: gam...@li... [mailto:gam...@li...] On Behalf Of Aaron Isaksen Sent: Friday, December 10, 2004 3:59 PM To: gam...@li... Subject: [Gamedevlists-brew] Power issues on phones Hello, Has anyone experienced any power problems AFTER your app has been run on a handset? A developer I work with is reporting some odd behavior, where his LG test phones burn down much quicker after we've run our app and its been exited normally. Our app doesn't do anything fancy with background behavior, its just a game. He reports that after running our game for 5 minutes and then quitting, the phone will be dead in 8 hours. Even if he puts the phone on the charger right after playing the game, waits for it to charge up, and then removes it from the charger, it will still burn down in 8 hours, so its not itself that burns too much power. He also reports this behavior with some games he downloaded (Tetris, Q-Bert) a while ago. We are running some tests to measure this, but I wanted to know if anyone experienced something similar. Thank you, Aaron Isaksen President/CEO, AppAbove Inc. ais...@ap... TEL: 646-613-0484 ------------------------------------------------------- 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 --------------------------------- Do you Yahoo!? Jazz up your holiday email with celebrity designs. Learn more. |
|
From: Aaron I. <ais...@ap...> - 2004-12-11 04:17:56
|
RE private lists: There are some technical things that I've discovered over the past 2 years developing for BREW that I'd be happy to share with people that I knew would return the favor and share what they know. This detailed knowledge is what makes us valuable developers. Sharing that knowledge with our peers make us even better. However, giving away that advice for free to people who will only use it to compete with us and not expand what we are capable of, might not make sense. The biggest downside to having a secret list is that some very knowledgeable, but not well connected, people could be left out. RE J2ME: I would not mind if this list also focused on J2ME, unless the traffic and volume got too high. I have started porting our apps to J2ME, and I already have several questions that I couldn't find answers to. If not this list, then I would love to be part of a similar list focused on J2ME. -Aaron > -----Original Message----- > From: gam...@li... > [mailto:gam...@li...] On > Behalf Of Tom Hubina > Sent: Friday, December 10, 2004 10:52 PM > To: gam...@li... > Subject: RE: [Gamedevlists-brew] Gauging the vibe... > > The privacy stuff is limited because it is on SourceForge > and, well, they're all about "open" .. heh. > > I was under the impression that this was going to be a > technical list, but I'm curious, what kind of proprietary and > sensitive matters would folks be willing to discuss on a > private list? I'm on some myself already and while they start > off strong it seems like the sensitive stuff ends up getting > discussed in private messages anyway ;) > > Beyond that, if there's people we trust enough to discuss > sensitive stuff with, what's wrong with inviting them on to > the private lists already in existence? As Guido mentioned, > we're already on them so in theory we can do that if we want. > > For me personally, I like having a focused technical list > that can be a better resource than the BREW forums and I'm > happy to keep the secret stuff in IM or private emails. I was > half tempted to suggest that this list be opened up to J2ME > as well as BREW, but that can always be a different list. > > Tom > > > -----Original Message----- > > From: gam...@li... > > [mailto:gam...@li...]On Behalf Of > > Guido Henkel > > Sent: Friday, December 10, 2004 7:37 PM > > To: gam...@li... > > Subject: Re: [Gamedevlists-brew] Gauging the vibe... > > > > > > Yes, I am familiar with these lists and some of us are actually > > members of some of these lists as well. In actuality, I > would like to > > make this list completely private and allow new subscribers by > > invitation only but it seems that the sourceforge list > setup that we > > have here doesn't allow for tha - at least not that Tom Hubina or I > > are aware of. Otherwise I'd be all for closing off the list to > > outsiders so that we can also discuss proprietary and sensitive > > matters here. > > > > 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 > > > > > > ------------------------------------------------------- > 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 > |
|
From: Tom P. <bre...@ac...> - 2004-12-11 04:16:28
|
> what kind of proprietary and sensitive matters would folks be > willing to discuss on a private list? One example: while particular device specs are discussed on the forum, there is no easy-to-query database that covers all the devices because Qualcomm isn't allowed to publish it. We could. It's simple enough to write and share a device profiler-benchmark applet. We could share the output. It would make our lives easier. It would give competitive advantage to the recipients. If you are not self-employed, would your employer allow you to share such data? Well, I doubt mine would, if it were entirely my own effort. However, as a collaborative effort, who would own such data? While the relative sales numbers for various handsets are pretty obvious, that's another sensitive area where people might share data. > For me personally, I like having a focused technical list that can be a > better resource than the BREW forums and I'm happy to keep the secret stuff > in IM or private emails. Part of the value in the list is that you get contribution from several people, not just a couple guys. >I was half tempted to suggest that this list be > opened up to J2ME as well as BREW, but that can always be a different list. Yeah, I was going to suggest the same thing, seeing how we all probably are doing J2ME work as well, and probably other wireless mobile APIs like Symbian and Smartphone. The occassional off-topic email probably won't hurt, especially if you're talking about porting btwn platforms. --t |
|
From: Tom H. <to...@am...> - 2004-12-11 03:52:25
|
The privacy stuff is limited because it is on SourceForge and, well, they're all about "open" .. heh. I was under the impression that this was going to be a technical list, but I'm curious, what kind of proprietary and sensitive matters would folks be willing to discuss on a private list? I'm on some myself already and while they start off strong it seems like the sensitive stuff ends up getting discussed in private messages anyway ;) Beyond that, if there's people we trust enough to discuss sensitive stuff with, what's wrong with inviting them on to the private lists already in existence? As Guido mentioned, we're already on them so in theory we can do that if we want. For me personally, I like having a focused technical list that can be a better resource than the BREW forums and I'm happy to keep the secret stuff in IM or private emails. I was half tempted to suggest that this list be opened up to J2ME as well as BREW, but that can always be a different list. Tom > -----Original Message----- > From: gam...@li... > [mailto:gam...@li...]On Behalf Of Guido > Henkel > Sent: Friday, December 10, 2004 7:37 PM > To: gam...@li... > Subject: Re: [Gamedevlists-brew] Gauging the vibe... > > > Yes, I am familiar with these lists and some of us are actually > members of > some of these lists as well. In actuality, I would like to make this list > completely private and allow new subscribers by invitation only > but it seems > that the sourceforge list setup that we have here doesn't allow > for tha - at > least not that Tom Hubina or I are aware of. Otherwise I'd be all for > closing off the list to outsiders so that we can also discuss proprietary > and sensitive matters here. > > 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 > |
|
From: Guido H. <gh...@g3...> - 2004-12-11 03:37:26
|
Yes, I am familiar with these lists and some of us are actually members of some of these lists as well. In actuality, I would like to make this list completely private and allow new subscribers by invitation only but it seems that the sourceforge list setup that we have here doesn't allow for tha - at least not that Tom Hubina or I are aware of. Otherwise I'd be all for closing off the list to outsiders so that we can also discuss proprietary and sensitive matters here. Guido |
|
From: Tom P. <bre...@ac...> - 2004-12-11 03:16:49
|
FWIW, there are already a few invite-only, closed lists. Chris Hecker started one. George Broussard started another. Not only to keep out newbies & trolls and unproductive flaming and oneupsmanship, but also in an industry where there's so much proprietary information, it is a way for indies to share info freely without worry. I've heard of private file-sharing groups where the members want to protect the network against attack by outsiders (e.g. RIAA). They use a "sponsor" model where every new invitee is sponsored by a member. If an invitee is banned from the network, then the sponsor is also expelled, in order to provide strong incentive -- not only on the sponsor's part, but the invitee also is liable for his sponsor. Obviously, we don't want or need such strong protection of the list against newbies (although you can look at the BREW forums as having been attacked by newbies, eh). I just bring it up to put the openness of this list in perspective. This list is not so closed. E.g. I was invited to Broussard's Game Illuminati list by a friend, and Broussard nixed the invite, saying that mobile game developers were not hardcore enough for that group. Members of that list are not even supposed to acknowledge its existence, i.e. 1st rule of fight club. --t |
|
From: Tom P. <bre...@ac...> - 2004-12-11 03:00:31
|
> >>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 |
|
From: Guido H. <gh...@g3...> - 2004-12-11 02:27:31
|
>>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 |
|
From: <jh...@lm...> - 2004-12-11 02:20:51
|
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 |
|
From: Paul Z. <pa...@bl...> - 2004-12-11 00:51:07
|
I've actually been working on a BREW port of InfoZIP. It's nicer than just GZIP since its an archive format, not just a compression format (allows multiple compressed files in one .zip file). I've still got a bug to fix, but once that's done I fully plan on moving all of my files into it and getting rid of the .bar file all together.=20 Once the bug is fixed, I'll be able to create the .zip archives for my games with common archiving tools (Winzip, IZArc, etc) which have a much nicer GUI than the BREW Res tool (currently, however, it only extracts from archives made with the InfoZip's Wiz.exe tool).=20 I miss integer resource names, because I can no longer load in an array of images by saying img[i]->loadFromRes( RES_ID_IMG_01 + i), and strings take more time to process, but it does make for more simplified and apparent code. (And I can always edit the filename sequentially: name[4] +=3D i; img[i]->loadFromZip( name) ) -Paul -----Original Message----- From: gam...@li... [mailto:gam...@li...] On Behalf Of Bill Kendrick Sent: Friday, December 10, 2004 4:38 PM To: gam...@li... Subject: Re: [Gamedevlists-brew] Alternative to BREW Resource Editor GUI? 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=20 your app? (Here I'm assuming this is something that users actually do in the=20 real world. I don't have my own BREW phone, so I don't play with other=20 people's BREW apps much. I can't imagine myself liking an app enough to keep=20 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=20 files, but that's about it. (Then it re-downloads everything when it's=20 reactivated) I guess it can't be too much of an issue, since I have seen so many people=20 mention that they've stopped using BAR files. ;^) -bill! ------------------------------------------------------- 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.=20 http://productguide.itmanagersjournal.com/ _______________________________________________ Gamedevlists-brew mailing list Gam...@li... https://lists.sourceforge.net/lists/listinfo/gamedevlists-brew |
|
From: Tom H. <to...@am...> - 2004-12-11 00:41:42
|
> 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 |
|
From: Bill K. <bi...@pe...> - 2004-12-11 00:38:18
|
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! |
|
From: Charlie W. <ch...@fi...> - 2004-12-11 00:15:24
|
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 |
