[Gamedevlists-brew] Re: Gauging the vibe
Brought to you by:
vexxed72
Menu
▾
▴
[Gamedevlists-brew] Re: Gauging the vibe
|
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 |
