Sigmag's Forum Posts

  • Thanks for reading through and providing feedback!

    — We had made the same mistake as well with BGs taking up waaay too much space, and by the time we realized, it was too late. We elected to reduce BG size rather than recreate them all using different techniques. It wasn't funny for us either

    I'm still expanding my knowledge on the whole RAM thing, and am curious about the different image compression in RAM techniques that I didn't know existed at the time of writing the post. If C2 could leverage PVRTC and like methods on a broader scale, it could drastically improve the performance of all games. C2 does some RAM magic on export, but from what I've read the criteria the image has to meet is narrow, so most are rendered 32-bit, and from what I remember I think it doesn't go lower than 16-bit. I'd be interested in being able to get images from 32bpp to 2bpp, taking up 1/16 the space in RAM, especially since most of our artwork is cartoony and would not suffer from lossy compression methods like a photo would.

    That said, I know there isn't a standard compression method across platforms, and those images would have to meet a narrow criteria across the board to be utilized in RAM that way, so it wouldn't be an easy implementation. Fun idea to entertain though.

  • There are a multitude of concepts that people miss when jumping into programming, especially with a streamlined engine like Construct 2!

    Ashley and everyone else on this site really come together to help explain these concepts, but sometimes we don't realize we've missed something until it's too late.

    In the case of our team, we missed the concept of image RAM and how it affects stability of your app. We designed our first app for the iPad only to realize 90% into the project, our game crashed nonstop. This was because our images took up over 300MB in RAM! It's a miracle it even ran at all.

    So what we had to do then was audit and cut back where we could to get our app down to a reasonable size. We were able to cut it down to just under 100MB, but at the cost of image quality reductions, and the end stability still wasn't where we had wanted it.

    What I aim to do with this blog post is set people on the right path from the get go with how image RAM works and to provide you the system I used to audit my image RAM. This should help you to get a good visual overview of which of your images are wasting the most RAM and where you can cut the fat.

    You can plug in the image asset list from your exported project and the sheet will give you some nice color coded information that isn't too hard on the eyes.

    Just click the banner above or, you can click this link too: http://pangolingames.com/how-to-audit-image-ram/

    There is a RAM vs Storage overview before it gets to the utility itself, that should hopefully help explain how image download size and image size in RAM are not the same thing.

    In any case, I hope you find it an enjoyable and enlightening read!

  • A0Nasser Of course! And that is a good idea, I had not thought to do a post about the scrolling background technique, it is actual quite simple code and so I will do a blog post about it as well during June.

    I am very interested in the graphic side of things and enjoy making special effects, so I will be sure to share what I can about my techniques with the forums to help those who do not understand.

    I have always been very picky about graphic technologies in video games I have played, and it seems to be paying off now as I make my own!

    — I know that many people struggle with aspect ratios and resolution problems, I decided to tackle the problem once and for all when I realized that games would display differently not only on different devices, but they will also display differently on the same device depending on if there is address bars, and other software bars.

    I think the approach I have used is one of the most viable ways of handling this issue as once you implement the base code it is pretty straight forward to be able to place elements on the screen - you must do it by code however - I am not sure if that is how most people do it, but I rarely position objects using the layout editor. The only other limitation I can think of the system is that you cannot use "Is on Layout" behavior, because the layout is always on the left and does not change from it's initial pixel value.

    Here is what I mean in case it isn't clear. The red outline represents where the actual layout is at a layout size of 320x480, and the window is stretched to something larger (I think 976x558 px). This is using scale outer for the project setting "Fullscreen in browser" for reference.

    And in the meantime until I am able to write up the blog post on the technique, you can try ResUtil. I am not sure if it will help or not for your specific situation, but I built this utility earlier this month to help to visualize which aspect ratios and resolutions to target based on whatever device you load it on, and seeing how your game will scale. Just go to the URL on any device you want to test and it can show you some useful information.

    You can test any size on PC by resizing your browser and setting custom sizes.

    I hope you find it useful! I also hope that I am not annoying anyone by posting these links in many topics, I want to offer help where I can.

  • A0Nasser Alright, if I can help even one person, I will put in the time!

    I don't have a time frame for it just yet, as I'm not too sure how involved I'll need to make it. Hopefully sometime within June as I have some catching up to do on code first!

  • DatapawWolf Glad you like it! I just updated it to include the original file I used, so you can compare your work or work off of that file while you go through it.

    I'll be writing similar, graphic-based blog posts in the future and actually have intentions to write one about how to fit your game to any size screen/aspect ratio coming up here within a month or so - so stay tuned!

  • UPDATED: 7/28/14

    Now that I am for certain going to be doing a write up on the technical aspects, I've decided to update my progress in the OP.

    I know that trying to target any specific resolution or aspect ratio can be infuriating, which is why I designed this object positioning/scaling technique in the first place. Now that I've had a few months to iron out problems, I want to get it in your hands so you can stop worrying about it too!

    Here's a demo showing what the dynamic scaling technique does. You can test scaling by stretching the window to any width and height you want and the filler will spawn as necessary, both above/below and to the left/right depending on if the aspect ratio is taller than 3:2 or wider than 3:2.

    In anticipation of the dynamic scaling technique write up, you can read some preliminary info about how images scale so that you'll have a better grasp as to what to expect using dynamic scaling.

    This blog post was written as an intro to the dynamic scaling post and got out of hand, so it became its own post. If you want a relatively easy to digest run down on what happens when your images are scaled (dynamically or not) then start here!

    The next post will describe the actual techniques used in the Dragonfly Zero scaling demo and how to replicate them. That should be ready here sooner rather than later, I hope to have it done within the next month. Sadly it keeps getting postponed due to development projects, school, and my internet being down for a good part of July.

    However, the development project keeping me from writing up the dynamic scaling post is also heavily focused on the expansion of the dynamic scaling technique so that it will be able to rotate orientation and reposition objects on the fly. So while I hate to delay it further, by the time I get to the write-up, the technique will be well rounded.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Hey guys!

    I've been working on animations for our upcoming game, Dragonfly Zero, and wanted to share the process I used to create the weapon firing animations.

    Wasn't sure which subforum to put this in, as it pertains heavily to art. However, it does include a good deal of technical aspects of making the art, so this subforum should work as well as any!

    The write-up ended up being pretty long, but I added in pictures and humor where I could to make it more accessible. This post should be useful for artists and non-artists alike!

    You can either click the banner at the top, or click this URL: How To: Animate and Light Weapons

    Let me know what you guys think!

    A few of the animations:

  • Jayjay Ah, thanks for the example!

  • If there is anything you guys would like to see it modified to do, I can take a swing at it as well. It's an ongoing project

  • Ok, thanks for the follow up. I think we found an easier way of doing it in the end, but this will be good for reference in the future.

  • Here's a screenshot of an upcoming title from us at Pangolin, I think it looks good so far

    The girlfriend and I have been working on the visuals for a few months!

  • Problem Description

    Line of sight seems only to take object origin into consideration and not object bounding box. Therefore line of sight checks do not work very well with a narrow scope.

    I'm trying to build a laser with a very narrow scope for a schmup and LOS would work great if not for lack of bounding box checks.

    If this is the intended behavior, it's somewhat counter-intuitive.

    Attach a Capx

    Here's the .capx

    Description of Capx

    The capx has test boxes for which the laser should size according to the wall it has hit, otherwise reach the top of the screen. You can control the player position with arrow keys.

    The origin point for these walls is in the bottom right corner of each instance.

    Steps to Reproduce Bug

    • Use arrow keys to move the laser about
    • Notice how the laser only reacts when in line of sight of the origin point (shooting the bottom right corner of any given wall)

    Observed Result

    The laser shoots through walls even though they are blocking line of sight, unless shooting directly at the origin point.

    Expected Result

    The walls should block the laser at any point of the wall.

    Affected Browsers

    ALL

    Operating System and Service Pack

    Window 8.1 Pro, 64-bit

    Construct 2 Version ID

    beta r169

  • BUMP FOR UPDATE

    I've updated the first post of the thread, I've made modifications to the utility so that it provides more detailed information and allows for custom game screen resolution!

    Let me know if it sucks! I haven't tested it very thoroughly, but it should work on any device.

    HTML5 ResUtil 2.0

  • This is awesome, I don't have a macbook to test this on right away but a breakthrough all the same!

  • slanw

    Sorry for the late reply.

    LONG, ARDUOUS ANSWER:

    What is best for mobile is also what is best for PC - that is to target all aspect ratios that can appear on any device. 99% of all monitors are one of these 3 aspect ratios - 4:3, 16:9, or 16:10. Keep in mind 16:9 is the defacto standard going forward and monitors are rarely made in 4:3 or 16:10 any more due to the standard set by 1080p (1920x1080 - 16:9).

    That said, there are still plenty of 4:3 and 16:10 monitors in the wild, and it's never a smart thing to target one specific aspect ratio.

    All normal aspect ratios fall between 4:3 and 16:9, there are a few outliers but for the most part you only need to target 4:3 to 16:9.

    What this means is your UI will need to scale to make use of extra space, with the low end limit at 4:3 and the high end limit at 16:9. How you handle that is up to you but requires a different type of fullscreen scaling than the default letterbox (I personally like Scale Outer). I handle most of the issue by spawning elements at certain %s of screen height/width rather than focus on absolute values like X: 100, Y:200. This way when the window size stretches past the layout size it won't break your game.

    You can see some of this in action on my current project, working title: Dragonfly Zero. The crucial part of the screen where all the gameplay happens is 3:2, anything outside of the 3:2 aspect ratio is filled with filler art that extends the UI graphics, but not the UI functionality. All crucial functionality must fit within the core 3:2 area.

    Click the banner below to launch the Dragonfly Zero main menu scaling demo and stretch your window to any size you want and watch what happens.

    The game will start stretching upwards if taller than 3:2 and stretch outwards to the sides if wider than 3:2. You can use the utility from the first post to get a better idea of how this works.

    Keep in mind I chose 3:2 in portrait because I'm targeting mobile and 3:2 is a good middle of the road between 4:3 and 16:9. Since you are on PC you should be targeting landscape, and if you are targeting browser with no intentions of fullscreen you may want to offset your aspect ratio range towards 16:9, because the browser address bars and things like the task bar in windows will squish the available height for your game, meaning your game will be making use of an area with a wider aspect ratio, easily passing beyond 16:9 on widescreen monitors, while not dropping down to 4:3. However, this all assumes a fullscreen browser on a 16:9 monitor, when someone could be playing in a scaled down browser window not taking up the entire screen.

    I highly suggest using this window resizer plugin for chrome, not only for testing this, but for testing all of your games in the future. It's an invaluable tool.

    SHORT ANSWER:

    This answer only really applies if you are thinking about making a lower res html game like a flash game you might see on kongregate, which stays at a fixed smaller size that fits fully in the browser window even when the browser isn't fullscreen.

    In that case you might aim for a smaller res like 480x320 (3:2), or 480x360 (4:3), where the aspect ratio doesn't matter so much because you aren't making use of the whole screen anyways.