I've never had to use the image manipulator a lot before, certainly not for this purpose, so before I go spending an hour or two with trial and error, I thought I'd see if anyone has any thoughts/solutions first.

On this unexpected side-project I decided to work on this week, I want to be able to allow the game to be modded by simply replacing the bitmaps used.

I've seen plenty of discussions here on sprite-sheets, but I can't remember if anyone found a way of doing it.

What I want is to be able to read a 256x512 bitmap from disk and take the 32x32 tiles from this and place them into the angles of the sprite.

I'm probably going to have a crack at this later, before I go to bed, but any thoughts welcome.

Cheers,

Krush.

Is it fair for you to ask Ash to work part time on it, so you can avoid paying the price of the license?

I don't think the price of a license is an issue for the majority of people.

It's hardly going to break the bank is it.

But I'm not convinced that the old Construct method worked that well.

In my time here, there are major bugs that where never fixed, despite requests, many posts from people asking very relevant questions that went unanswered even though other posts around them were answered, devs disappearing for long periods of time, some forever, and then the project ending abruptly so that the new version can be worked on (if it wasn't for people like RojoHound, Lucid, and 1 or 2 others, Construct 0.x wouldn't have been anywhere near what it is now).

I've already made my opinion on the absence of an .exe exporter in Construct 2, so I won't go over old ground, but my main concern with Construct 2 is that for a paid product, the above behaviour wouldn't be acceptable.

Krush.

Has the "Set Always on Top" command from the Window object ever worked?

I haven't needed it before, so I've only just found out.

It's easy to do in VB or C++, so if it's not working, I imagine it's because it's hardly been used and hasn't been flagged as not working.

Or I could be missing something.

Krush.

monkeycoder.co.nz

It has quite bold claims.

Very interesting.

Thanks for the link.

Krush.

There is only issue with behaviors. Low FPS makes platform jumping higher and high FPS makes jump lower

As Mipey says, it should be time delta'd so that there's no difference whatever the frame rate.

But it does bring me back to my original comment.

If a behaviour does what you want, how you want, then there's no reason not to use it.

If it doesn't, down to the behaviour not working as it should or it's poorly written, then it should be avoided.

Bad code is bad code, whether it's written by you or someone else.

Krush.

Yeah, he's been working on that addon for months.

I've been watching it's progress for a while, and while some of it looks like it could be useful, a lot of it isn't needed.

The funniest thing for me was the price. lol

I'm sure some people will find it useful, and as I said in another thread, whatever it takes to get the end result, but it's certainly not worth the price asked.

Krush.

I think this train of thought is just another case of coding snobbery.

If a behaviour or plugin does everything you want it to, then coding it from the ground up is not only a waste of time, but goes against modern programming.

Code is meant to be reused as much as possible, and using behaviours and plugins is no different to using existing classes/functions and libraries, either as they stand or adding to them for your specific purpose.

At the end of the day, people are using programs like Construct to write games, and whether it's because it's faster to develop or because they don't know how to program at code level, there will be code snobs who will say that it's lesser than using something like C++, even though C++ programmers will be using built-in libraries and external libraries for most of their calls (which of course were written by someone else, lol)

If a game works well in both idea and performance, then it's irrelevant how it was coded.

Java used to be ridiculed years ago, but over the last few years it's been instrumental in the rise in mobile phone games, and it culminated (in my opinion) in a game like MineCraft showing just how irrelevant a specific language is.

Just remember, generally, if someone is saluting a specific language/tool to the degree that they ridicule any other method, then you can be sure that either:

a) It's the only language/tool they know how to use

or

b) They chose the hardest way to program something so that they could prove to themselves how great they were (which means they are lacking confidence in general).

As someone who started programming in 1982/3 (ish) and has used Z80 machine code through to C++/C# with everything in-between, and enjoy using software like Construct/Unity/Stencyl etc, I'd never judge a game by how it was written.

The final result is all that matters.

But then I'm not a snob in any aspect of life, and some people can't be anything else but a snob, lol.

Krush.

I don't think you should put a vote against the licensing model because you don't like the features - they're different things. If we did an EXE exporter, that would not change the proposed licensing model! So the question is, is it a good licensing model?

Well, that's a very patronising post, but I'll respond sensibly.

The licensing you propose mentions the amount of money for each license, and without an .exe exporter, I don't believe they are worth the money.

I'd say that was relevant.

BTW, I didn't vote at all in this thread, and voted for "mixed" in the other thread, so I never put a vote against either license proposal.

I'm sure there's a way you can check that.

We've been over the EXE exporter in other threads - we knew we'd disappoint many people with HTML5, but we took a risk and did it anyway, and we still want to eventually produce an EXE runtime. So hopefully everyone is happy in the end!

The problem is that you compare Construct 2 to other game creators (in other threads), but they have the advantage of being available now, and have support for exe already, with other exporters either already available or on their way.

While I agree that HTML5 is going to be important, I still think that neglecting exe export from the off is a mistake.

That's my opinion, and as you say, it's your decision.

Krush.

Just like the last proposal, I have no problem with what you've come up with.

But the lack of an .exe exporter means it's a no for me.

It also means it's not worth me taking up the early-adopter option, because without the guarantee of an .exe exporter, I'd be wasting my time.

I'm also not a fan of commercial non-official plugins/exporters.

Money's not a problem, in any amount, I just think that (a) you need to keep your revenue streams future-proof, and (b) people need to get value for money from their official purchase.

None of my questions were answered in the last thread, but here goes anyway:

How come you haven't come up with license upgrade prices?

It doesn't have to be complicated.

Just allow people to pay the difference.

We're not talking physical goods here, so there's no depreciation value to be factored in.

The "ALSO-" section could look like it only applies to the Pro license the way you've posted it (I assume it applies to all licenses), so you may want to point that out a bit more clearly.

Again, it's all pretty irrelevant to me while there's no .exe export.

The projects that I'm working on involve Unity, Construct 0.x, and Java, so maybe when I'm done with those, Construct 2 will be worth looking at (for the reason I've stated several times already).

The problem is, I may well be more than happy with the toolset that I've used to make those, and may not choose to add another.

I fear you may push away other Construct users without the inclusion of an .exe exporter early on too.

Just my opinion.

Krush.

Like InkBot says, avoid using MP3 and use Ogg instead.

I have several pieces of music that loop throughout my game, and there's no sign of any pauses, clicks or pops when looping (using Ogg).

Krush.

Well, I like your proposals, and I have no problem with any of them.

If you're a hobby programmer then �40 for 2 years is going to be well worth it, and if you're more serious about it, then both �40 and �150 for 2 years is still good value.

The only reason Construct 2 is still a No from me is the absence of a Windows exe exporter.

If it has a fully-featured exe exporter bundled with it upon release, then I'd have no problem paying either price.

If there isn't an official exe exporter created at some point down the line (i.e. free for those who have already paid), then I would be giving Construct 2 a miss.

And the possibility of an official exe exporter being released at a later date would not be enough for me to buy in advance of that.

So, in short, a very good license idea in my opinion, but the missing exe exporter is a deal-breaker for me.

Good luck with it anyway.

EDIT: I haven't read the whole thread, but what about upgrading from one license to another?

Is it just going to be a case of paying the difference (�110)?

Krush.

Woah, don't worry about it mate.

There's more important things.

Very sorry to hear that.

We'll be thinking of you and your fiance.

Hope it all goes well.

Best wishes,

Brian & Family.