Regardless of the ratio, the vertical resolution will be 480. Find out the ratio of the monitor to determine what to set the horizontal resolution to (I'm not sure of the math). After setting the resolution, put an extra layer above all the others. Put black bars on the left and right covering the area past 0 and 640.

Yeah, post a vid, man! There is a 'post videos of what you're working on' thread...

Good Advice:

Do not make an rpg. Not right now, It will only end in disappointment. I'm telling you, it's impossible at this level. I've been doing game development for years and I would still not dare tackle a big FF style rpg, even with a team. If you are making tiles like that, then please do yourself a favor and start with a small game idea to hone your skills. You will soon see that all the behind the scenes coding which goes into even a small game soon becomes a handful. An RPG is by far the most difficult game genre to develop, and even with a team it takes the utmost devotion and planning. I don't want to sound harsh, but I am 211% sure that this game will not get finished, or even to a point of near completion. Come up with a small original design with your team or on your own, and see how tough it is to finish just that.

There's some solid advice there, except that while it's not impossible, it is VERY VERY hard. My RPG is an 'RPG-lite' for the exact reason that I wanted to try something simple to actually complete a project. It's been 10 MONTHS and I'm barely past the first boss!!! There's the map, battles, saving, inventory, leveling up, equipment, cinemas, stats, menus, towns, npcs, shops, items, etc etc and that's for a 'simple' RPG!

I don't want to discourage you, but there's a reason most indie RPGs are made with RPG maker - all that stuff that comes built-in is a lot more complex than it seems!

Make something small, a one area/town/boss 'practice' RPG that has all the features of the other RPG you want to make (I'm using this technique even for a longer RPG - that's why I'm not much further than the first boss). Seriously, it will be way more work than you expect, not to mention that you'll probably have to rewrite portions of it repeatedly to get new features to work with the old ones. The benefits of doing it this way are by getting all the game's systems and features working one one area, it makes it much easier to test everything, and then if after completing it you feel like you'd like to continue, you have a whole engine ready for content, making the development of the next game/area much, much easier.

Also, development tip: when testing a concept (like your tile system), don't put a whole lot of work into something before making sure it'll work/be feasible. That way you won't have to redo a lot of work if the concept doesn't work.

And I have to also vote against using BOF screenrips. if you're going to put this much work into a project, I highly recommend making some actual tiles. It will be MUCH more rewarding to have (and easier to work with!) original graphics.

Try something like: always set angle to anglediff*0.9

The bigger the angle difference, the faster it will turn (there are various ways to cap the speed), and it won't overshoot when it gets to the right angle.

Also, what I typed won't work exactly because it doesn't have timedelta. It should look like: always set angle to anglediff*(somenumber*timedelta) but I can't remember what somenumber's supposed to be for that. Try experimenting with what number should be there.

A global variable is helpful to use because it will be unaffected by the picking process. It doesn't need to be a global variable - you could have a 'valuesprite' if the values are needed for only that layout. As it is, you're picking an object, then creating another instance of that object which forgets the previously selected instances of the created object, which makes it confusing. By setting the place to create from somewhere else, it makes it all work smoother.

There are two ways. I think the right command is lerp, but the easier way in construct would be this:

• Move at angle: angle(square.x, square.y, targetx, targety), pixels: speed*timedelta

Hmm, using lerp for that does seem to be a bit trickier than I thought.

What I think is happening is you're selecting a cloud via the conditions, but when you create a cloud in the actions, it forgets the selected cloud from the conditions, and the new cloud that was created becomes the only selected cloud, meaning that the new cloud spawns from it's own pivot point.

Also, since the objects with the bullet behavior are set to destroy themselves automatically when leaving a layout (in the properties), you don't need the sprite to clean them up when they go offscreen. A much easier computationally method, if the bullet behavior wasn't cleaning up after itself already, would be to check their x position. Much faster than checking for collisions.

I modified your .cap. I set a global variable for each cloud picked in the conditions so the x/y you wanted to spawn from wouldn't be forgotten when you created a new cloud and used those instead. Take a look at it and tell me if there's anything you don't understand.

For thread:

I believe the issue is construct changed how it picks objects after creating them. So if you had:

Create sprite

Create sprite

• Set angle of sprite

in 98.9 it would change the angle of both. In newer versions, the same event would result in the second sprite being rotated. This is because on creating an instance of an object, construct picks the object that has been created and forgets all other instances of the object. The new version of the event:

Create sprite

• Set angle of sprite

Create sprite

• Set angle of sprite

I haven't checked the .cap tho, so it might be something else.

I have a situation where I want the player to go back and forth between layouts very often. With the way construct is, I have two options - either load all the textures at start (not an option for this game, too many textures) or dump everything out of VRAM when switching layouts. This means I have to reload everything every time, resulting in a rather noticeable pause.

Is there any chance of a third method that loads all the textures as they're needed when going to a new layout, but doesn't dump the old ones?

Also, a 'unload all textures except those in use' command would be nice.

I prefer else forgetting the selected objects - if it didn't work that way, there's some stuff that I don't know how it would be possible to do. Else events run if the event preceding it does not run - so if you want it to run only once, a trigger once condition after the else should work. (I haven't checked the .cap)

Example:

value = 1

• action 1

else

• action 2

So if value does not equal 1, else will repeatedly fire until it does. IIRC, else events don't work properly if there's a subevent between them, like this:

value = 1

• action 1

subevent conditions

subevent actions

else

• action 2

I don't know if that's been fixed or not, but it sounds like it hasn't.

Why do everyone cares so much about "the best way"?! There is not a best way to do a thing!

Perhaps, but some ways are clearly better than others. And isn't your entire rant about doing something a better way?

I wonder why everyone is so against this kind of feature. Polygons with textures and collision checking. Is that so difficult? So difficult for you that MADE the entire CONSTRUCT?

The devs don't even have much time to work on bugfixes, which are of much, much higher priority. Maybe they could consider it for C2, but there's more important stuff to be done on C1.

This is not even the first time a user asks for this kind of feature. And noone helps those users. We are not all expert coders!!

They can't implement everything people want immediately. Construct is a free piece of software written in the dev's spare time. I think we all can agree that there are more important things to work on first, like bugfixes, and perhaps even online capabilities (not sure what the status is on that. Seems to be a lot of different info), etc.

I'm not against the feature - I just think that most of what could be achieved with it can already be done, and other stuff is more important.