DiegoM's Recent Forum Activity

  • It makes sense that the problem is still present in Edge and Opera because much like Google's Chrome, they are based on the open source project, Chromium. So they pretty much have the same strengths and weaknesses.

    Firefox and Safari are both unique, so they have different strengths and weaknesses.

  • This seems to be related to this chromium issue. Where the maximum quality when resizing doesn't produce the expected result.

    bugs.chromium.org/p/chromium/issues/detail

    C3 is using a browser feature to produce resized images when it is available, if it is not available, it falls back to our own implementation of a resizing algorithm, which I have noticed produces better results, the problem is that it isn't as efficient as the browser and it is prone to run out of memory.

    For a while now the feature has been supported by browsers, so the custom resize logic isn't used. In any case, I prefer to not use that because the browser implementation will be way better, assuming it works. The problem is that there is no reasonable way to detect if the resizing is working properly or not to fallback to our resizing method.

    Is this a problem in other browsers? Namely Firefox and Safari.

  • After the tween starts, t.value will have the value the tween is currently in.

    In order to get the changing value over time you need to query that function multiple times during the lifetime of the tween. You can do that by listening for the "tick" event of the runtime.

    Try adding something like this to your main script. 

    let t = null;

async function OnBeforeProjectStart(runtime)
{
	// Set up a "tick" event listener
	runtime.addEventListener("tick", () => Tick(runtime));
	
	// Get the first Sprite instance
	// (assumes a Sprite instance already exists in the layout)
	const sprite = runtime.objects.Sprite.getAllInstances()[0];
	
	// Get the Tween behaviour from the sprite
	// (assumes the Tween behaviour has been added to the instance in the editor)
	const tween = sprite.behaviors.Tween;
	
	// Start the tween
	t = tween.startTween("value", 200, 3, "linear", {
		startValue: 100
	});
}

function Tick(runtime)
{	
	// Check every tick for the state of the tween,
	// Make sure it has been created and that is hasn't been released before trying to use it
	if (t)
	{
		if (t.isReleased)
		{
			// Null the reference to the tween once it has been completed
			t = null;
		}
		else
		{
			// Get the value of the tween
			console.log(t.value);
		}	
	}
}

    You can check what is being printed in the console by pressing F12 when the preview window shows up.

  • This is a small example showing how to load an animated SVG.

    dropbox.com/s/w66ch2oks77qzl1/Animated%20CSS.c3p

    The SVG is in it's own file and is loaded into the HTML element using the AJAX plugin. The animation is defined in a separate CSS file which is loaded automatically by setting it's purpose to "Stylesheet"

    I haven't tried it, but you could also choose to define the SVG and CSS directly in the Content property of the HTML element instance.

  • Yeah, that's it. That's the main thing the timer behaviour does under the hood.

  • I think the only non obvious thing you should take into account if you are just going to use a variable as a timer is delta time (There is a system expression to get the current delta time).

    If you just use a value by which the variable is incremented you could end up with the timer taking more or less time to complete on different devices running at different frame rates.

    Depending on your use case that might not be an issue though. For example the case of just wanting to produce extremely short delays, as in a few frames.

    I'm going to lock this thread now because the original problem has already been understood and for some reason people are using this thread to post their unrelated problems in.

    If anyone is having any issues please file a bug report following the guidelines, that is the best way to get help.

  • The fastest way to get help is to share your project, most likely there is a small, non obvious detail that you are missing.

    Sometime because we look at our projects all the time and already have a way in which we go about solving problems it can be easy to miss stuff that is falling out of our common think patterns.

    Someone else is likely to find this issues a lot quicker because they think different.

  • In 2D the only way to solve this is by having two different sets of animations for each side, no hidden tricks.

    Granted, most games (including high profile ones) don't even bother with it and just mirror the images.

    The most common example of this is 2D fighting games, at all levels of development, from the tiniest of studios to big budget AAA games, the graphics are just flipped and nobody seems to be bothered with it. Some of the newer fighting games that could easily do it because they are in 3D, still choose to flip the assets because it is more convenient for the players to see the same graphics no matter what side the character is facing.

    If you still want to do it, you will need to produce more graphics.

  • I didn't think about the possibility of loading the page in an iframe, but you will have a similar problem, if the page you want to show doesn't like being shown in a different origin, then it won't work.

  • An easy way to find out the requests a page is doing is by opening dev tools in your browser, usually by pressing F12, and then going into the network tab.

    You will see everything the page is doing, which usually is a lot more than you would think! It might take a while to go through everything but you will surely find it there.

    If you are lucky you will be able to hit the endpoint yourself, unless it is somehow protected by either some sort of pass key or maybe a cross origin access policy.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Just to clarify, headless browsers are libraries that let you write programs that behave like a normal internet browser. There should be at least one headless browser for the most popular server side languages, such as JavaScript (node.js) or Python.

    They have functionality such as waiting for a page to execute JavaScript after the initial request, before trying to query the content of a page, among other things.

    For the most part they are used for website testing, but they can have other uses like web scraping.

DiegoM's avatar

DiegoM

Member since 24 Apr, 2015

Twitter
DiegoM has 1,382,591 followers

Trophy Case

  • 9-Year Club
  • Jupiter Mission Supports Gordon's mission to Jupiter
  • Forum Contributor Made 100 posts in the forums
  • Forum Patron Made 500 posts in the forums
  • Regular Visitor Visited Construct.net 7 days in a row
  • RTFM Read the fabulous manual
  • Email Verified

Progress

15/44
How to earn trophies

Blogs