Ashley's Recent Forum Activity

  • For the record, setting the text size to TextWidth/TextHeight isn't necessarily going to fit the complete text in. Text metrics are actually super complicated. You have all sorts of different baselines (e.g. hanging, middle, alphabetic, ideographic...), different languages extend different distances above and below the line, certain unicode combinations can extend indefinitely in an upwards or downwards direction (e.g. z̻̗͜a̦̥̱͖̝͓͉l̡̤͕̟̝̟̻g͎̹o̡̫̲ text), and so on and on.

    So when you say "how tall is the text?" it's not actually particular clear what you are measuring. Which baselines are you going from? Does it include all ascenders and descenders? Do you want it to keep extending with things like zalgo text? How do you make sure it never cuts off any of the text with any possible combination of text, font and languages?

    This is compounded by the fact the web platform currently doesn't expose all the text metrics we need to answer all of these questions (as noted in this old issue about vertical text alignment).

    This issue appears to refer to BBcode altering the text size not being taken in to account in the calculated text height, which is a different type of problem - but even if that's fixed, it still won't mean that setting the text size to TextWidth/TextHeight allows all the text to be visible, because of everything I just mentioned. Basically you just have to add some padding - but unfortunately at the moment there's no way to know how much padding is needed exactly, and it's different depending on the text/font/languages you want to cover. So, you'll just have to guess...

  • Measuring text immediately should work in the C3 runtime. The workaround where you had to wait a tick was something that only needed to be done in the old C2 runtime.

  • This should be possible with the Binary Data object and the AJAX object. Using AJAX you can make two requests:

    1. Firstly use the AJAX object 'Set response binary' action to save the next request in a Binary Data
    2. Then use AJAX to request the GameRecorder.RecordingURL - this will load the recording in to the Binary Data
    3. Once that completes, you can do another AJAX request with 'Post binary to URL'. Choose the same Binary Data object to send, and then enter your server URL to post to.

    In other words you first use AJAX to transfer the recording to a Binary Data object, and then you can use 'Post binary to URL' to send the contents of that Binary Data object to your server. You'll need to make sure the server can handle binary data coming in from the body of the POST request.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Construct 2 is being retired soon. All I can advise is either upgrade to Construct 3, or target higher versions of Android. There's very little usage of such old Android versions so it doesn't seem like that would be a problem.

  • I took a look at the project and as far as I can tell it doesn't use any images over 4096x4096.

    This doesn't make any sense: the originally reported error said it was creating an image over 16384px, but there aren't any such large images in the project.

    My best guess is it's a graphics driver issue. Linux often has poor quality graphics drivers that cause all sorts of problems. Maybe try updating the graphics drivers, or try installing alternate drivers if you can find any others available.

    The project also uses the Spriter plugin which is a third-party addon - it's possible it's causing the issue somehow, but that would be the responsibility of the addon developer.

  • There are absolutely loads of new features in C3 compared to C2 - see What's new in C3 for an overview - not least of which includes a completely rewritten runtime with far faster performance.

  • Note we don't make AdMob and can't fix any problems with it, so you may want to report this to AdMob directly instead.

  • Answer your own performance questions with measurements

    In terms of fill rate, both the source size and destination size count: the larger the source image, the more memory it takes up and the more memory bandwidth it needs to read from the image; and the larger the size it's drawn at, the more memory bandwidth it needs to write pixels to the screen.

  • The size of the layout should not cause this, since it does not have any direct impact on memory usage.

    I think we can only make wild guesses unless you share the actual project.

  • The diagnostic information says the maximum texture size on your system is 16384. The only way this can happen is if your project has an image larger than 16384x16384. Construct itself will never create a spritesheet larger than 4096x4096.

  • Move the cursor a little to the right to get it to indent.

  • Please note the earlier link is to old Construct 2 documentation - for up-to-date advice see the Performance Tips guide in the Construct 3 documentation instead.

Ashley's avatar

Ashley

Early Adopter

Member since 21 May, 2007

Twitter
Ashley has 1,827,608 followers

Connect with Ashley

Trophy Case

  • Jupiter Mission Supports Gordon's mission to Jupiter
  • Forum Contributor Made 100 posts in the forums
  • Forum Patron Made 500 posts in the forums
  • Forum Hero Made 1,000 posts in the forums
  • Forum Wizard Made 5,000 posts in the forums
  • Forum Unicorn Made 10,000 posts in the forums
  • Forum Mega Brain Made 20,000 posts in the forums
  • x126
    Coach One of your tutorials has over 1,000 readers
  • x74
    Educator One of your tutorials has over 10,000 readers
  • x5
    Teacher One of your tutorials has over 100,000 readers
  • Sensei One of your tutorials has over 1,000,000 readers
  • Regular Visitor Visited Construct.net 7 days in a row
  • Steady Visitor Visited Construct.net 30 days in a row
  • RTFM Read the fabulous manual
  • x44
    Great Comment One of your comments gets 3 upvotes
  • Email Verified

Progress

32/44
How to earn trophies

Blogs