Colludium's Forum Posts

  • You need to add inverted commas so the command looks like ViewportRight ("HUD") - otherwise it looks for a value of HUD variable, which will probably return zero and so give you coordinates for layer zero instead.

  • I think this should do it. Please excuse the sprites...

    This does not use the on collision check because I'm not sure that it would work all the time (I could be wrong). Here you go for my solution:

  • Imagine that the Viewport returns the coordinates of the left/right/top/bottom of the visible screen area for the layer that you specify. Subtracting the top coordinate from the bottom coordinate will give you the height of the viewable area in pixels... Have a look at Tutorial: Supporting Multiple Screen Sizes.

    If all of that still seems difficult to grasp I suggest that you press on to looking at other areas of C2 and then come back to it - some of the concepts can be difficult to grasp at first but exposure and practice will help you get used to them. You can always manually make your sprites bigger than the likely screen height/width - if they are transparent then it won't matter that they are distorted.

  • Ah OK - you want the object to fill the screen:

    Set object.Width to ViewportRight("HUD") - ViewportLeft("HUD") and do similar to the object's height, assuming it's on the HUD layer and depending on whether it's width or height you're interested in.

    Hope that's what you're after?

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • I suppose I didn't answer your question exactly! Looking at my list above, if you want to achieve option 1 then you need to obtain the canvas size and scale your sprites so that they will appear at 1:1 resolution on screen, which means they will need to be scaled in the layout at run time according to the screen resolution - because C2 will try and then scale them so they appear in true proportion to the layout on screen.

    For example, let's say you have a 64x64 sprite that you want to have rendered as 64 pixels on screen. If your original layout is 640x640 then C2 will try and draw the sprite so it appears to be 1/10 the width/height of the screen. If the screen resolution is 1280x1280 then you would need to scale the sprite to 1/2 its width/height at run time so C2 would then draw it to appear 1/20 the screen size - which would still be 64x64. Add in the complication of different aspect ratios and you'll begin to see that this is not a good place to go - because you haven't even started you game mechanics yet!

    I would advise steering clear of this to begin with and I can't think of many game options where this would be an attractive proposition (there are some, though...).

  • vitorfgd, that is a very complicated subject and you need to be sure of exactly what it is that you want to achieve.

    1. Do you want the sprite to take up exactly the number of pixels on the screen irrespective of screen resolution? For example, a 128x128 sprite will look ok on an 800x480 screen but it would look really small on a full HD 1920x1080 screen - and the apparent difference in size would be very striking if the screen dimensions were about the same.

    2. Do you want the sprite to take up the same proportion of the viewable screen length/width irrespective of screen resolution or aspect ratio? C2 handles this option very well with its Scale Outer scaling option (and the others, but they are less on mobile usable IMO).

    The common advice is to draw your game for the largest aspect ratio you can expect (16:9 or 16:10) and then ensure that your background fits smaller aspect ratios to good effect. There are some great tutorials and threads on this, so do a quick search and have a look through. It's not a decision you can just glibly ignore at the start and then hope to fix later in your development. It also depends on your export target - I understand that C2 does scaling very well so, providing the sprites have the detail, you could draw all of your sprites and layout for 800x480 for example, with each sprite drawn at 1/2 scale, so that if there is any upscaling to be done (full HD / retina screen) then the upscale of your sprites can be done by adding that detail rather than by interpolating pixels. Again, plenty of tutorials ect will cover this better than I can. Personally I have scaled my last few apps to a middle of the road aspect ratio that is better suited for iOS - something like 960x640 or 1136x640 - both are ok for android and iOS and the scale outer can make some exports look longer and some look wider, but I'm personally happy with the average appearance. Whatever works for you...

  • Always happy to help! I found these forums extremely helpful when I first started (I'm hardly an expert now!) so it only seems fair. Feel free to ask away when you get stuck.

  • My best advice is to roll your sleeves up and experiment with some of the tutorial examples - reading will only give you 50% understanding at best, IMO. At some point you've got to start learning to take control of C2 and understand what it's doing for you and what you have to ask it to do for you - because it is very flexible and powerful but it's not able to read your mind.

    Regarding the white bars - just make your background bigger so all aspect ratios are covered - I normally use a tiled background that is sized way bigger than the planned screen size so that, when the aspect ratio is changed, none of the background's edges are visible.

  • Exactly. Just keep an eye on those threads, I'm sure there'll be a breakthrough and that's where it'll be announced first. When is a different question....

  • The anchor behavior only keeps an object in its position relative to the borders of the screen - it does not move it to the edge of the screen.

    Have a look in the manual for "viewport". You can place the object using that system expression. For example, if you want to place an object touching the left edge of the viewable screen:

    set Sprite.X to ViewportLeft("HUD" + Sprite.Width * 0.5) .... where "HUD" is the layer name of you HUD.

    Have a look at this demo I put together for an example of this.

  • That 'tutorial' was rather brief but ok as an introduction. Try searching for "scale my game" in the tutorials section of this website instead. There are loads of tutorials there that will help - but reading is only part of the process, get in there and play around with various settings and see what they do and how they do it. Also search the manual for "scale" and see what comes up...

    White edges implies that your background does not fill for the scale mode and aspect ratio you have selected.

  • I suggest you follow this thread and this thread. There's no way to access google leaderboards at the moment and cocoonjs offers the best short term solution now that the plugin has gone open source. Crosswalk should offer the option as well but I don't know the timing for that one either.

  • Same here. Just having the new plugin in the project causes it to fail to run.

  • You have to figure a way for a second touch function to not be acted upon by your events. Remember, the events run every tick, so the only way to ignore a touch event is to add a condition to the touch trigger so that your code can identify when the trigger has been actioned before. You can't simply disable touch on an object, it doesn't work like that. There really are a lot of ways you could do this.

    One simple way is to add an object boolean to your sprite - something like object.Touched. Check that the boolean is false during your touch trigger and then set it to true during the subsequent commands so that the touch event trigger cannot fire again.

    Also remember that if you have mouse input set to yes on the touch object then that can also trigger two touch events on some iOS and Android devices.

  • Just to clarify, because I think that my point about the manual may not have been clear. I read the manual within a couple of weeks of starting to use C2, however my comprehension of C2 was still lacking because I had very limited experience at using it. I had programmed before and used other game engines but that experience was only useful up to a point. A few months ago I had to completely re-write the engine for an app I have because I wanted to make a small adjustment and my original event system was so - frustrating - that I couldn't stand working around the inefficiencies I had coded into it. I had learned a lot in 6 months and was a little taken aback by how little I knew at the start. C2 looks easy to use (that's the big selling point) but is in fact a very powerful alternative to coding - and that power is its strength and weakness. The user has total freedom to do what they want but that means that they cannot cookie-cutter a game in 20 minutes because they need to create their own unique control features. That is why I like it so much above MMF and the other alternatives - I can do exactly what I want and not what scirra thinks I want.

    WRT to the layout option - this would satisfy so few people and would only serve to complicate the interface. How would C2 know which layout precedes the one that's being played when you might have 50 layouts for the main game and another 20 for interstitial screens / settings / options etc? What about a game like angry birds where the user can select the next layout to attempt? Any changes to encompass your desire to 'goto next layout' would have to not make any of those alternative game constructs harder to create. I would rather Ashley and the team worked on one of the numerous other areas where C2 could be improved before they start adding complicating features that are already easily worked using the current event system. I guess that it could be a nice feature if I wanted to make a linear game like flappy bird but there is a reason why so many on this forum will oppose these sorts of suggestions.

    There are areas where improvements could be made, but a good first port of call is the help forum. There you will be helped to learn how to take advantage of C2 and its strengths and, if there is something that could be made better (like sprite-font) then it will only be accepted if there is no easy and workable way to do it already.