You've already been told to stop begging for money here. Next time you do it you're getting a temporary ban. Knock it off.

I've been working on RPGs in construct for a while and I can't even imagine trying to make something so complex with clickteam fusion.

I use a 'branching tree' Structure for the most part.

Example:

If gameMode="action"

• Controls code
• Enemy AI
• Etc

If gameMode="cinema"

• If scene="intro"

If gameMode="menu"

Coding this way makes it easy to find what I'm looking for, as the base events are like categories and each subevent becomes more specific.

Are you running XP or Vista? I started getting a similar error and it turned out be that nw.js's main branch doesn't support XP or Vista anymore.

LaDestitute - Er... whoops. I read the post and responded without checking who the poster was, thinking it was you. Apologies for participating in the derail!

MPPlantOfficial as LaDestitute said, please create your own thread.

Here's how I do it. The method I use might be more complex than you need, but it's also very flexible:

All player characters, enemies and such are in a family called units.

I create an invisible object called base and put it in a family called bases.

All variables given to those objects are done by giving the families variables instead of directly to the sprites. This makes it easier to compare the values of two of the same object interacting with each other.

At the start of the layout, I create an invisible base object at each of their locations. I store the UIDs of the units/bases they're paired with as family variables.

I also create a shadow sprite. It's separate from the base for positioning purposes.

The base objects are the real controlling objects where most of the code happens. Because all the player characters, enemies and NPCs are controlled by the same type of object, it's easy to control them however I want by just changing their variables, like if variable mode = wandering, etc.

The part you're probably most interested in --> The base objects have the variables z and zModifier. The zMod variable is the speed of movement on the z axis (jumping in the air, visually it's the same as the y axis, the z variable is really just the distance between the base location on the ground and the unit in the air), and it is added to the z variable. When in the air, the gravity rate is always subtracted from zMod. When z is lower or equal to 0, the object is on the ground, and depending on the velocity in can be set to bounce.

Every tick, unit locations are set to base.x, base.y-base.z. Because of how construct works, as long as there are the same number of bases and units (destroy any in the layout before creating them for each unit) no for each is needed, and the units are all at the location of the correct base. I place the shadows at unit.BBoxLeft, base.y and set the shadow width to the unit width (the shadow hotspot is on the left).

Another benefit to this method is collision can be checked in 3D by first checking for collisions or distances between bases, then checking if their units are overlapping.

The main downside to this method is it requires a lot of for each loops in situations where construct's auto-picking doesn't work, but I consider the ease of use while coding and versatility to be worth it. If only C2 had containers that could be modified at runtime like CC had with the picker plugin... maybe C3 will have that feature.

I haven't checked your code, so apologies if I just explained most of what you're already doing, I just thought I should make it clear. Even if you don't want to use my method, perhaps the part about the variables will be helpful.

You can see this method in action in the gif in my sig. There are more including some of a flying enemy in the first post of Loot Pursuit's devlog.

The problem with that method is it's inconsistent based upon the speed of the mouse and where it happens to be when the measurements of its position are checked - if the mouse moves quickly, it's a large gap.

I'm having difficulty finding a way to do this. I want the screen to scroll when the mouse is near the edge of the window, but stop if it goes past the edge of the window (the rendering area, technically). In all the tests I've done, it just keeps scrolling.

Anyone know of a way to accomplish this? I've tried checking the mouse values but they stop updating outside the window. Checking if the mouse is over a fullscreen sprite doesn't work either for the same reason.

Tinimations - Glad it helped!

newt - Bitrate and pixel fill rates really don't have anything to do with each other though. Bitrate is all about compressed video and the resulting accuracy of the compressed image in comparison to the original, and game engines don't compress their rendered frames when they're sent to the screen. Even having thousands of small sprites like the snow or confetti he showed might slam the draw calls, but the resulting number of pixels drawn would still probably be quite small compared to what the gpu can manage because of the empty space between them. With that many sprites on screen it's probably going to be a cpu bottleneck calculating their positions or telling the gpu to draw them instead of the actual process of drawing them, which is what we're talking about here. If you meant developers should avoid tons of objects to optimize though, that's correct but for different reasons than the pixel fill rate alone.

Whiteclaws - A draw call is made for each on screen object, not once for the entire screen, so if you have 100 instances that's a hundred draw calls each frame, or 6000 per second.

That's not exactly right about RAM/VRAM being cleared each frame - it would be a huge bottleneck to do so, as the process is so slow most games have to show you a loading screen. I suspect you meant the framebuffer is cleared (the RAM/VRAM allocated to the drawn image). Even if that is what you meant I thought I should clarify for anyone else reading. If you have 'clear background' set to yes it clears the framebuffer (which also takes more work, so disabling it can help performance if the background is covered anyway), but you can turn that off and watch objects smear around.

As mentioned, the framebuffer is stored in memory, so the higher the resolution the more memory it uses.

saiyadjin - At that resolution with no overdraw it's 124,416,000 drawn pixels per second. The Tegra 3 - which is an older chip - could draw 1.04 billion pixels per second, the Tegra 4 can draw 2.68 billion, and there are two generations of chips that have come out since then that are even faster. Mobile gpus have had the power to draw the entire screen multiple times per frame for quite a while.

Also, C2 does not only draw moved pixels. I've never heard of the technique used anywhere except compressed video and even then it's not exactly the same thing as it's encoding the movement of pixels rather than just drawing the moved pixels, as far as I know. If anyone's using it for rendering it's unusual (aside from frame warping in VR to coverup missed frames, but that doesn't work properly for rendering new material). If there's any difference between the current frame and the previous one, C2 redraws everything (with the exception of any pixels that are not covered by an object if you tell it not to with the clear background setting). If everything is the same, it skips drawing completely.

Whiteclaws - it's not as simple as that. With C2's back to front renderer, if two objects overlap, those pixels are drawn twice.

newt That's bitrate, pixel fill rate is the number of pixels a gpu can draw per second.

Tinimations - I'm not sure how much knowing the exact number of pixels drawn each frame would help. There's such a wide variety of hardware out there any number that's fine for one device will be too much for another, unless you're targeting the Xbox one?

There's also the issue that not all pixels require the same amount of work to draw. Even ignoring webGL effects which obviously add a varying amount of work, a transparent pixel requires more work from the gpu than a fully opaque one. Fully transparent ones still require work from the gpu as well, though only if an object is visible. So if you have an image with a lot of completely transparent pixels, that's work the gpu is doing for no effect. Rotated objects require more work, too.

For any recent gpu though, those aren't really something to be concerned about as graphics cards are getting ridiculously powerful. Ashley tested his new 1070, and if I recall correctly from his tweet he was able to render a quarter million sprites at 30 fps, though I don't know how large they were.

However, on a device like the iphone 4s, having UI panels be opaque instead of transparent makes a considerable difference. On some of those older devices the total pixel fill rate is only about three times the resolution of the screen - so if you have a single background image the size of the screen, that's a third of the pixel budget right there.

I suppose you could calculate the size of the bounding boxes and crop them to the screen to determine a vague estimate of the number of pixels they contain, but again pixels alone aren't the only benchmark for performance because of various things like how it's more work for the gpu to use a larger texture than a smaller one and how it takes extra work to switch from one texture to another (so if you have a hundred of the same image to draw, sticking them all on the same layer can help).

There are more performance tips in the manual, in case you haven't seen them already: https://www.scirra.com/manual/134/performance-tips