I'd like a system similar to how we subscribe to topics, but for users.

There are a few people whose opinions I value, and I'd like to be notified every time they make a comment.

Is such a thing possible? I tried the "friends" system but that's not what I want apparently.

The problem is, if I'm getting 5fps in a mobile, that means the device is doing a ton of work.

True, the user probably doesn't care, but his battery will notice for sure. Especially since this is a visual novel, so it's supposed to be experienced in long stretches.

Also, just throwing this out there, if the most frequent bottleneck on mobiles is fill rate, why not limit the redrawing to only the parts that change? Yes it's impossible in some types of games, and yes you get a bigger hit on the CPU, but on the other hand the GPU will have less work to do.

But surely there are scenarios where a big image has to be used, and you cannot compose, right?

Visual novels, for instance, are full of huge backgrounds, and even the characters can be huge. I mean look at this thing:

It's immediately obvious that the background cannot be "composed".

Surely as long as we only have one big background per scene, we're fine?

Keep in mind performance isn't all that critical in that sort of game, the developer would be much more concerned with battery drain, music smoothness and text drawing.

So my guess is that since construct 2 doesn't redraw when nothing on the screen has changed, the framerate would be kept high. The only problem is that people like to implement that "typewriter effect" on the text, so it might count as constant redrawing - Ashley would c2 be smart enough to only redraw the bottom half of the screen?

you can make game like rayman with construct 2 ? "you can not"

Since you made the statement, the burden of proof is on you.

Prove me that it's impossible to "make game like rayman with construct 2". Otherwise your statement is invalid.

> If you like math go ingeneer, because you can use all that math for the games.

> If you go doctor is going to steal all your time and dont have all that math / data base / etc the ingeneer have

>

So I have decided from an early time that I want to be a computer engineer, so could then it possible to have time for making games as a hobby?

Sounds good. Besides, if the whole games thing doesn't work out for you, you'll still be in a profitable industry.

Now, keep in mind "computer engineer" doesn't really exist. There's front-end programmer, back-end programmer, web developer, project manager, systems architect, business analyst, database analyst, database administrator, hardware engineer, computer scientist, graphics designer, interface designer, end-user support, and many many other careers.

You can't post URLs yet. Either post screenshots as attachments or get 20 more rep (should be easy).

Also it's not that construct 2 is restrictive, it's just that the engine I provided for you was for a different concept than the one you want - it's no surprise that it doesn't work. If you had coded it in C++ it wouldn't be any different.

Looking at the videos, I can see that it will be impossible to fix the engine I gave you. You need a new one.

So if we want to use big images, don't care about slight pauses, but care about memory usage (say, if we're making a hidden object game, point and click or RPG), we either use a separate layout or "load image from URL"?

Ughhhh, not another one of these...

Try this:

[attachment=0:3fhkr9uy][/attachment:3fhkr9uy]

Problem Description

When moving an object "up" (270º) using the "move at angle" action, the final X position is not consistent. Sometimes you get a rounding error and some times not. The error is related to the initial X position of the object and the distance moved.

For some reason, moving the object "down" (90º), left (0º) or right (180º) doesn't seem to trigger the bug.

Steps to Reproduce Bug

• Run the project in the debugger
• See that the sprite's X position (after it has been moved 20 pixels) is 63.99999999999999. This is unexpected.
• Change the sprite's initial X position in the layout editor to 128
• Run the project in the debugger
• See that the sprite's X position (after it has been moved 20 pixels) is 128. This is correct.
• Change the sprite's initial X position in the layout editor back to 64
• Disable the second line and enable the first
• Run the project in the debugger
• See that the sprite's X position (after it has been moved 19 pixels) is 64. This is correct.

Observed Result

The final X position has a rounding error depending on distance moved and initial X position. The exact values that trigger the bug are somewhat arbitrary.

Expected Result

Since we're moving the sprite exactly 270º (that is, on the vertical axis), the X position should be unaffected.

Affected Browsers

• Chrome: YES
• FireFox: YES

Operating System and Service Pack

Windows 7 x64

Construct 2 Version ID

Construct 2 r166 64-bit

It's almost same to Firefox OS

I wish FirefoxOS would overtake Android. Alas, it will probably never happen...

Well I was somewhat wrong and somewhat right. Yes the downward motion is to be expected if you do it like that (like I said), but it's also what you want. The downward motion is desirable.

It stems from the fact that once the engine places the first platform, it starts connecting them front-to-back, and since you're always correcting the newest platform (pushing it down), the newer platforms will accumulate the effect.

How do you fix it? By making the platforms go "up" to offset the motion: Like the comments say, the engine is lacking scrolling. You need to add logic to keep the platforms (or the player) centered on the screen, and you cannot rely on the automatic centering provided by Construct 2 because your game is an infinite scroller, not a predefined level.

There are many problems with using "tiles" in the way you're describing:

• The player has a cyan "detector" sprite below him, and it relies on thin, rectangular platforms to work, otherwise it might detect two platforms simultaneously and not know which angle to pick. The thinner the platforms, the less this problem happens.
• With fixed tile platforms, you can only bend the pipes in 90º increments.
• With tile platforms, you can no longer use the platformer behavior to handle player movement, you'll have to come up with custom movement logic.
• setting addY to 24 does not make the platforms align. 34 works better, but makes the tiles overlap. Also this only works for the initial angle, all other angles break. That's because addY depends on the angle, it can't be a fixed value.
• Having isometric tiles make the whole connecting logic collapse, since when the engine tries to figure out where to attach the new platforms to the old ones, the maths give it the wrong answer, and things look jumbled.

This is not to say that isometric tiles are impossible, it's just that they're very very hard to work with this engine, which is designed to support a platformer.

If you do want to stick with tiles, I can help you a bit, but it involves starting over from scratch.