Sigmag's Forum Posts

  • ronval - Glad I could help! I recommend reading these 3 links by Ashley for further information, they can save you a good deal of frustration down the road.

    Supporting multiple screen sizes

    Remember not to waste your memory

    Performance Tips

    And one possible explanation without knowing any further information about your game, is that scale outer can and will render your game beyond the layout size whereas letterbox renders your game at layout size. So maybe extra GPU/CPU work relating to that?

    Ashley - Good to know! Thanks for the clarification.

  • ronval - This is my understanding of it, there could be misinformation.

    If you use the low quality scaling, it will decrease GPU load and increase overall performance to a comparable level to if you were using all the assets at that lower resolution, even if the assets have extra pixel information in the editor layout. But you will still have the RAM commitments for the original size of those assets.

    For example, if your layout is 320x480, you can still have assets in your game that are 512x512, bigger than the layout itself. These assets with higher resolutions see use when using the hi quality full screen scaling, but use the same RAM regardless of render mode.

    When you use hi quality scaling, it takes your 320x480 layout and scales it up to fit and render at a resolution of the device. So if you are running it on an iPad it will render at 768x1024 and on a 3GS it still renders at 320x480 because that's the native screen size. So while 512x512 is overkill for an asset on 320x480, that extra pixel information is used when scaled to fullscreen in hi quality.

    Since the aspect ratio of the game is the same scaling from 320x480 to 768x1024, what IS changing along with the resolution is the ppi (pixels per inch) or how close together the pixels are. Retina displays have very high DPI displays, meaning that even though the iPhone 5S isn't much larger of a phone than the iPhone 3GS(163ppi), it has a much higher resolution (1136 x 640 pixel (326ppi), higher than the iPad2 (132ppi)!) so a game rendered at 320x480 will look great on 3GS, and pixelated on the iPhone 5S. That said, the 3GS looks more pixelated overall than the iPhone 5S due to lower ppi, because the pixels are larger.

    However including higher resolution assets comes at the cost of RAM; each 256x256 square of pixels you have uses 0.25MB of RAM when loaded in the game. Meaning a 512x512 square uses 1MB by itself! This is what vtrix means when you should do both to save texture space, to modify the resolution of the original assets in the game to more closely match the intended resolution (ONLY IF USING LO QUALITY AND NOT GOING BACK) so you could potentially achieve the same effect with a 64x64 px sprite on lo quality as a 512x512 px sprite.

    If you run lo quality, your game always renders at 320x480 resolution and then scales those pixels existing at the 320x480 resolution to fit the device's resolution of 768x1024. So you aren't filling each pixel with it's own unique color information, you are kind of stretching one pixel's color into like 9 pixels of information, causing it to look artifacted and pixelated.

    I kind of got off a few tangents here, so if anything is unclear let me know and I'll try to explain further.

  • If anyone has another aspect ratio they are targeting let me know. I was going to include 17:10 and 16:10, but they just fall between 3:2 and 16:9 anyways, so it's a bit redundant.

    I'm really glad you guys are finding it useful. If I knew a way to pull the device name into a text object that would be neat.

    We could potentially screenshot the utility on our personal devices and post them here for reference, in order to get an exact look at the sizes/working resolutions for a bunch of different devices without having to own them.

  • ronval

    If your game runs ok right now on the iPad 1, then you might be ok - since iPad 1 is an old device. But if your clients want you to have a game that runs really well on old hardware, the smaller resolution is usually the way to go, ESPECIALLY if they want it primarily for phones. If they want it primarily for tablets, you have to weigh the pros and cons of each to fit your situation.

    I know I wouldn't want to redo all that work either! :X

    I'm glad I was able to help.

  • The bigger your native game resolution, the bigger the rendering/performance hit!

    320x480 is still a 1.33:1 (4:3) ratio, so it will fill the screen the same as your 768x1024 game would (with less pixel density/graphical fidelity), but due to the increased resolution, the draw calls are going to be much more intensive.

    That is because 320x480 is 153,600 pixels, and 768x1024 is 786,432 pixels! Over 5 times as many pixels!

    Thus, a game designed a 320x480 will run many times faster than the same game at 768x1024 at the cost of graphical fidelity.

    I actually just made a utility to help gauge this type of thing.

    Here's a link to my resolution utility

    What this utility does it show you based on layout size how much your game will scale up or down from it's native, intended resolution to fit the device it is running on.

    If you open the portrait version, the layout is actually already set to 768x1024 (4:3 - iPad res) so you can test with the portrait HTML5 link to get an accurate idea of how your game will scale.

  • matthewhxq Alrighty, landscape utility now available. I've got 3:2 included as a 3rd aspect ratio boundary in both portrait and landscape versions. Let me know how this works for you!

  • UPDATE (5/7/14)

    Alright guys, decided to upgrade this utility, now being designated as HTML5 ResUtil. It has a good deal more functionality and can help give measurement information for knowing how much filler UI you will need for different aspect ratios, as well as now allowing you to designate your game resolution for testing. Not to mention portrait and landscape are both working under one utility now for ease of testing!

    Click the banner below to launch.

    Let me guys know what you think!

    ORIGINAL POST

    [quote:2s2l14aa]Hey guys,

    We are in the first leg (week) of development on our new game, and I ran into the same problem we all do: Resolution and aspect ratio.

    Since we are programming for different devices and different platforms (native HTML5, iOS, android, etc) we need to be able to account for software bars as well device native screen resolutions.

    I've hobbled together some sort of basic utility to help me test how a game in different aspect ratios might scale (focus on DPI) and where I can expect black bars to show up, and I thought I'd post here in case anyone else can get use of it or use it as a foundation.

    Speaking of which, this is a modified version of some scaleRatio code I found on these forums about 12 months ago, so I don't remember the original author , but thank you mystery man.

    USAGE

    Just load the program via web browser onto your device, then make note of the information you get per device. I recommend screen capture on the device if you want to save for reference later.

    The utility works best if you stretch the window to allow empty space past 16:9 on the left and right in landscape mode, and on the top and bottom in portrait (may not work on most screens very well due to reduction of text size, but will work great if you have a flipped monitor! )

    If you notice anything busted or misconfigured, let me know and I'll try to fix it.

    HTML5 ResUtil

    NOTES

    • There may be minor discrepancies of 1-2px either visually, or represented in the information panel.
    • Each box includes it’s border as a representation of it’s aspect ratio. This means the game screen box will overlap the borders when matching aspect ratios.
    • The utility will automatically switch between portrait and landscape orientations (if height exceeds width in landscape, or width exceeds height in portrait).
    • The orientation label also works as a button.

    SCREENSHOTS

    Landscape - Google Chrome, PC (windows)

    Landscape - Safari, iPhone 5S (iOS)

    Portrait - Safari, iPhone 5S (iOS)

  • Sigmag here. Educational apps might not be a primary focal point of most C2 developers, but it goes to show how flexible the engine can be.

    Really happy to have our first product in the wild.

  • I'm working with clrammer on the same project, and we also have issues with sound delay on the tizen platform. Anyone else with a Tizen device having issues of this nature?

    As an addendum to the above post, is there anyway to interact with the Tizen virtual keyboard API through C2? I think right now we are leaning towards making our own in-app keyboard to circumvent this issue in time for the App Challenge.

  • ErekT

    It doesn't happen on all sprites, and it's not always consistent on the sprites it does happen to.

    So far it's done this with horizontal blur, set color and tint. I'm assuming it does it for every effect.

    I tried re-sizing the image to match a sprite that isn't having this problem (no change) and I just cut out half of the sprite in different parts of the image to change it to see if it made a change, and the line is the same.

    szymek

    Was ludei able to help you with your issue?

  • No such luck :

    It only appears when applying a webGL effect, the line doesn't show up on the sprite otherwise.

    How can I address the texture bleeding of a webGL effect?

    <img src="http://i.imgur.com/YEENUlx.png" border="0" />

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads

  • Hey guys,

    We are pulling our hair out trying to figure out what might cause the problem we are having.

    Essentially every time we apply any webGL effect to a sprite, we get a 1px line beneath the sprite, and in some cases to the left/top/right as well.

    It only happens when we export through CJS; this issue does not happen in chrome.

    I've attached a couple of screenshots, but I can't include a capx because we are about 90% done with development.

    Just trying to narrow down the possibilities, and since this doesn't happen with a new capx it's likely something in our logic. However, we have 2500 events and hundreds of variables, so if anyone knows a good place to start that'd be fantastic.

    <img src="http://i.imgur.com/lzrjuk2.jpg" border="0" />

    <img src="http://i.imgur.com/Y9RPzsv.png" border="0" />

    Couple of things we've tried:

    ? Putting a wait before enabling the effect (This helps alleviate the issue on SF, but not completely, does not work on other sprites)

    ? Turning on pixel rounding - no dice

  • R0J0hound

    So the memory leak fix in your latest update doesn't address canvas copying to webgl texture? I take it that a proper fix would require a code overhaul with a large time commitment on your part?

  • R0J0hound

    Let me preface by saying thank you for this plugin, it's a great asset!

    I'm working with clrammer on the same project, and we are both psyched to see an update to address the performance hit introduced with CJS 1.4.

    We haven't seen a difference in performance, but we are probably missing something since it works for others.

    2 Questions:

    1) Was just wondering if minifying the script is necessary for the performance fix? I don't see why it would, but worth asking.

    We haven't been using it (or able to use it) because of conflicts during export with 64-bit java, and due to our lack of understanding of the minifying process we just kind have been forgoing that aspect.

    2) What operating systems / devices do you personally test on? In what capacity have you tested iOS?

    I'm sure we are probably overlooking something at this point, just trying to identify what it is.

    SirSpunky

    What operating systems / devices are you testing on that you noticed the performance gain?

  • Notice any improvements otherwise? My android 1.4 right now works better than iOS 1.4 as far as layout loading and avoiding hang. Im kind of scared to update! Also how long can we expect for a 1.4.1 on iOS assuming theyve put the update in for apple to process? I hope it works better so we can keep on track with our release date!

    Also, anyone else having problems with android 1.4 crashing randomly and becoming unable to launch without app reinstall? Its annoying when it happens every time i launch :S. very time consuming