Results 1 to 19 of 19
  1. wicketr's Avatar
    Posts
    232 Posts
    Global Posts
    249 Global Posts
       #1  
    Considering the two phones have different resolutions, I don't see how this will not split the app catalog. While some applications will be compatible for both, some are full screen.

    This will cause some of the apps to only work/look decent on one of the phones while the other is left out of the loop, unless the publish/write two versions. Considering this type of "full screen" look is meant for games, I'm concerned that developers will either write for the more popular phone (will that be Pixie in the long run?), or just not write for the phones since neither phone on its own will have THAT high of an adoption rate.

    I wish they had made the Pixie the same resolution so that the experience would be the same and would be the same for the developers. That would encourage more apps instead of splitting the community somewhat.
  2. #2  
    How does blackberry handle this for the storm and tour/bold?
  3. #3  
    I believe there is a property that can accessed which identifies the device which is running the program. This can allow you to create different settings, resolutions, behavior(s?) for differing palm devices.
  4. #4  
    I'm sure someone will chime in with a technical explanation, or correct me if I'm wrong, but I think WebOS is designed with this in mind. I believe that from a programming perspective it works similarly to how websites work on a variety of screen sizes and resolutions. Maybe the Engadget or PreCentral review discussed this.
  5. Gompers's Avatar
    Posts
    124 Posts
    Global Posts
    128 Global Posts
    #5  
    It is insanely simple to do with CSS.

    It's handled just like it would be on any web page. Now there are probably some layout things and style guidelines that need to be addressed, but it's nothing that is insurmountable by any stretch.

    Part of the reason that palm has been so slow exposing hardware to programmers through the standard APIs is for this particular reason, though. WebOS apps "hard-coded" for a particular device (i.e. the Pre or Pixie) would indeed cause a rift in the app catalog.
  6. #6  
    Think about it this way. How many different screen sizes/resolutions are there for computer monitors? How many of those monitors have problems viewing websites? HTML/CSS/Javascript are meant to be moldable to the hardware they are displayed on. That basically means with very minor code tweaks that the Pixi would display the same info, just smaller. That's the beauty of it.
  7. wicketr's Avatar
    Posts
    232 Posts
    Global Posts
    249 Global Posts
       #7  
    I'm sorry, but I'm just trying to imagine how a game like Bubble Pop or Breakout would be easily changed. Since the resolution is different, the game would have to be redesigned for the smaller vertical screen. The balls would have to be transformed into eliptical eggs for bubble pop? The whole screen squashed for for Breakout?

    Styling is easy for pages that already scroll, but for full screen applications, it seems quite a bit trickier.

    I couldn't imagine them just having you scroll games up and down while you are trying to play them.
  8. #8  
    There should be no worries regarding this. You must pass Palm QA before your application hits the App Catalog and they do all their testing in emulators for both phones. Trust me, I've had images of lower resolutions come back before the Pixie was announced. Quite confused I was... but I fixed the couple of items.

    It's not too bad to handle resolution issues and it's best to make your app as fluid as possible.

    Any applications that hit before the big push for QA on lower resolutions (not sure when that would have been), I would imagine, must be updated by the time the Pixie comes out.
  9. Gompers's Avatar
    Posts
    124 Posts
    Global Posts
    128 Global Posts
    #9  
    Quote Originally Posted by wicketr View Post
    I'm sorry, but I'm just trying to imagine how a game like Bubble Pop or Breakout would be easily changed. Since the resolution is different, the game would have to be redesigned for the smaller vertical screen. The balls would have to be transformed into eliptical eggs for bubble pop? The whole screen squashed for for Breakout?

    Styling is easy for pages that already scroll, but for full screen applications, it seems quite a bit trickier.

    I couldn't imagine them just having you scroll games up and down while you are trying to play them.
    "redesigned" is a very trivial thing in HTML. Seriously. You redesign a webpage every time you change the size of your browser.

    Yes, there are probably some applications that will need to be tweaked, and some of them might not work so well on the smaller pixie screen, but there is no reason that 99.9% of apps shouldn't work on both seamlessly.

    It's one of the major benefits of using CSS, HTML and javascript.
  10. #11  
    It's not as easy as that to make it behave like the Pixie. I'm sure Palm will have an emulator out that will allow us to do so, however.
  11. s219's Avatar
    Posts
    498 Posts
    Global Posts
    1,008 Global Posts
    #12  
    http://forums.precentral.net/palm-pi...ml#post1883265

    It will be a major hassle for full screen apps and games. Palm would have been smart to standardize screen resolution across the line like Apple has done. Instead, they are going down the path of WinMo and Android.
  12. #13  
    Quote Originally Posted by s219 View Post
    http://forums.precentral.net/palm-pi...ml#post1883265

    It will be a major hassle for full screen apps and games. Palm would have been smart to standardize screen resolution across the line like Apple has done. Instead, they are going down the path of WinMo and Android.
    It's not a hassle unless you don't do web development. It's very easy to get very scalable applications via this technique. The only issues you have are when you're doing very specific development for games but you don't write a game to work on only one resolution, do you? No and there are many development techniques to avoid issues in this space as well.

    The post you linked to is very ill-informed regarding how web development is done today and how the webOS SDK works.

    You're not adapting.
  13. s219's Avatar
    Posts
    498 Posts
    Global Posts
    1,008 Global Posts
    #14  
    I was linking to Marco's post and my followup. If you look at his app:

    http://www.precentral.net/homebrew-a...rpn-calculator

    which has obviously been constructed with painstaking effort, and uses a lot of raster images and touch targets, I think it explains his point.

    Me, I am speaking directly about games and full screen apps, with artwork and physics that are based on a very specific layout. In terms of coding for general sizing, it leads to a reduction in one or more of: performance, aesthetics, usability. I'll just give an example from a game I am working on now -- if I had to allow for generalized screen size and/or aspect ratio, it would add a significant amount of math operations throughout the code, and this is the same code that has painstakingly been hand tuned to reduce as many operations as possible. It's easy to do, but it wouldn't make sense.

    Unfortunately, the types of scaling that are feasible for game performance will diminish quality to some extent. You can't have it all, and it's naive to think it's a simple fix. We'd be better off with a single screen size and (more importantly) aspect ratio.
  14. #15  
    s219, I thought you said you weren't interested in working on webOS, and that the pre couldn't handle your awesome games. Like 200 times/day for the last three months. So why are you weighing in on this?

    If you can't handle different resolutions, you're really not getting this whole concept and you should stick to iphone.
  15. s219's Avatar
    Posts
    498 Posts
    Global Posts
    1,008 Global Posts
    #16  
    Quote Originally Posted by Cobraextreme View Post
    s219, I thought you said you weren't interested in working on webOS, and that the pre couldn't handle your awesome games. Like 200 times/day for the last three months. So why are you weighing in on this?

    If you can't handle different resolutions, you're really not getting this whole concept and you should stick to iphone.
    I'm just here for the brilliant conversation. And the free donuts.
  16. #17  
    Quote Originally Posted by s219 View Post
    I was linking to Marco's post and my followup. If you look at his app:

    http://www.precentral.net/homebrew-a...rpn-calculator

    which has obviously been constructed with painstaking effort, and uses a lot of raster images and touch targets, I think it explains his point.
    I fail to see how he couldn't use a set of background images to, dynamically, construct the buttons. Then use separate images for the items on the buttons.

    This would allow it to scale to any size, make it easier to add more buttons in the future and even change colors / themes if desired. It would still be usable on a Pixie but it would be ideal on the Pre and could even work, perfectly, if Palm's Pre 2 decides to come with 600X800 or any other, becoming popular, resolution for mobile phones.

    Sure, I agree that it would become a little more cramped on the Pixie, but he is using a ridiculous amount of buttons; you can't expect that to scale down beyond a certain threshold without destroying its usability anyway. I know everyone loves on-screen keyboards / number pads but using the keyboard would have been a great space saver.
    Quote Originally Posted by s219 View Post
    Me, I am speaking directly about games and full screen apps, with artwork and physics that are based on a very specific layout. In terms of coding for general sizing, it leads to a reduction in one or more of: performance, aesthetics, usability. I'll just give an example from a game I am working on now -- if I had to allow for generalized screen size and/or aspect ratio, it would add a significant amount of math operations throughout the code, and this is the same code that has painstakingly been hand tuned to reduce as many operations as possible. It's easy to do, but it wouldn't make sense.

    Unfortunately, the types of scaling that are feasible for game performance will diminish quality to some extent.
    This is what doesn't make sense to me.

    In game development, you need to take many factors into consideration including possible resolutions. You should work with specific ratios for individual items and size scale appropriately.

    What it sounds like to me is that you developed game X, then adjusted sprites to very specific points on the screen. This is a bad idea for game development no matter what platform you're developing for. You should always generate positions relative to screen dimensions while conforming to specific aspect ratios on certain objects.

    So, I really don't understand the problem here. It's not much more difficult to base your calculations off of window.screen.width and window.screen.height when you should be doing that anyway otherwise you're not future proofing your game at all.

    Would you be angry if Palm comes out with a new phone next spring that uses 640X960 or 600X800? You game would break there as well, even though the OS would look very nice and sharp.

    If you're using DirectX, OpenGL, SDL, XNA or any other kind of wrapper for the graphics sub-system, you always base your development on screen size. This is how console and PC gaming industries have done it for years so I don't really understand why anyone thought the mobile space should be different.
    Quote Originally Posted by s219 View Post
    You can't have it all, and it's naive to think it's a simple fix. We'd be better off with a single screen size and (more importantly) aspect ratio.
    I never said it was simple. I've done many years at the University working on simulations and games and it's a very difficult process especially if you're working in the 3D space. So, I agree that it's not simple but it's the way it should be done.

    Do you really think one screen size should last over multiple devices? That's very limiting. You would really rather stifle hardware development to make software development easier? Sorry, but I'd rather adapt then always be stuck with the same aspect ratio, screen size and resolution.

    The iPhone will have a higher resolution one day. The Pre will have a higher resolution.
  17. s219's Avatar
    Posts
    498 Posts
    Global Posts
    1,008 Global Posts
    #18  
    With a game, I set the main screen transformation once, when initializing the view. There are variables for screen size and aspect ratio, but they are in the form of compiler directives (#define in C) that are taken care of at compile time and basically hard-coded into the executable. This avoids having scale factors or additional transforms sprinkled throughout the code that need to be handled as repetitive math operations at runtime. In other words, the compiler will do the math and bake it into the executable. You wouldn't want to do it at runtime, since it would inflate the number of operations quite a bit. I even try to minimize OpenGL transformation matrices at runtime if I can help it. Every little bit matters on a mobile device.

    It might be irrelevant with webOS, though, since we don't have quite that capability with javascript (everything happens at runtime). So from that standpoint, my points might be moot.

    I predict iPhone will stick to 320x480 for a long enough time that devs can optimize for it with some longevity. At least that's the message we're seeing from Apple.
  18. #19  
    I agree that the same aspect ratio would have been nice and made everything must easier, though I'm curious as to how you would use compiler constants. The screen resolution is determined after compilation, so why would you do math in compiler constants? Seems like it wouldn't be useful once it executed on a machine with different resolutions.

    Processors are very good at Math and adding a few more items shouldn't hurt it unless your game is doing some insane calculations.

    Though, I would really love an alternative to web development for games. I'm pretty confident it'll never happen, however .

Posting Permissions