I would assume visual basic.

If that was the case, stuff would be even less of a hassle to port to *nix (Mono).

I'm quite sure it isn't, though. For several reasons.

1. It would be way too easy to steal all the source.

2. Performance

3. As far as I remember, Ashley is somewhat of a regular on Stackoverflow. In fact, I think I read a few C++ specific comments from him in the past.

Blinx123

I think its all coded in MS visual studio ....

If so, ... it would require a full re-write from the start.

If c++ is not ashley's forte, ... well .. lets just say it would take quite a bit of time before a next update/release.

What do you mean by MS Visual Studio? Visual Studio is just an IDE with some advanced features (version control, integrated build server, gamification, GUI designer, etc).

Of course, if Construct 2 makes heavy use of Windows specific APIs it would've to be rewritten a fair bit. But if an application in our day and age still makes heavy use of Microsoft specific stuff, it should probably be rewritten anyways.

Where I come from, we call this legacy software.

BTW: Even without a native port, Construct 2 already runs better under Ubuntu than Windows 7 for me. So the least Scirra could do is work with someone from Wine or Crossover, fix some of the quirks and deploy a fully wrapped application as a download.

It would be a monumental and incredibly expensive amount of work for a relatively small userbase.

People saying this are missing the point.

The only reason the userbase* is still smaller is that very few people dare to make a difference.

Do you really think consumers would willingly use Windows if their favourite software was available for an OS like Ubuntu or MacOSX (both way more user friendly than Windows)? An OS that seldom crashes and, when it does, prints concise messages rather than the Gobbledy-Gook Windows treats it's users to?

Heck. I think a company supporting a game development framework owes it to themselves and their userbase to publish their whole software to Linux. This way, users can grow and actually acquire some skills they might need later on (if they chose to pursue a professional, IT centric career).

I can't speak for MacOSX, but porting to Linux is blatantly easy and having a varying amount of distros isn't an issue, at all. Most users will choose a Debian based distro, which means you can use dpkg to pack Construct2 as a .deb. Debian also has an rpm packager available, so you can port your .deb to .rpm (used by RHEL, CentOS, etc) in a matter of minutes. Dependencies also won't be much of a problem. Especially if your download page lists certain distros that should be used.

michael

It looks to me as if most of these issues come down to a quite error prone Direct3D implementation (AFAIK, the editor view uses D3D rather then OGL). By porting it over to Unix, you'd have to convert all your rendering code to OpenGL, which should also allow you to iron out all the little flaws within the rendering code.

*That's homeusers, btw. In enterprise applications (especially the server space), Windows is slowly but steadily going the way of the Dodo.

Thanks a lot to everybody.... if i knew before these problems... i will not buy construct2....this is a very bloking development for me....but in any way i will try to work with it... hoping for an upgrade that fix all these problem...as soon as possible...

Best regards,

lestroso

http://www.fasasoftware.com

Those aren't even issues, at all.

1. Unlikely to change, as those wrappers tend to try and go for feature completeness (a browser with a simplified GUI/without the chrome, basically). I really don't see the problem though. It's not as if a 100MB game would be anything of particular specialty. It's rather common for games to require quite a bit of hard-disk space. Generally, space requirements will be more balanced the bigger the game gets, as most of the space will be taken by your own digital assets.

2. Publishing to mobile platforms is generally more involved, even for native apps. Using tools like Phonegap Build and CocoonJS is as easy as it could possibly get.

Anyways. If more optimized applications are what you're after, you should really look into C/C++ or, heck, even modern BASIC. HTML5 is, essentially, an interpreted language. Games programmed in HTML/Javascript need an interpreter, be it your browser or a modern wrapper. The only possible way to decrease the size of such an interpreter is to either refactor the whole code or remove features.

Thanks to the nature of open source and FOSS, you can do both.

https://github.com/rogerwang/node-webki ... master/src

PS: You might also want to take a look into compression. Before deploying any of my works (even the smallest application written in C ), I usually try to compress assets as far as I can without sacrificing quality. I also create installers for every OS. For Windows, I can recommend NSIS. It's free and quite a fun experience.

For some reason, I always had issues with Construct 2 on my laptop (Lenovo E535).

However, in the past I could fix most of them by modifying the config and using different drivers.

I now ran into an issue I cannot seem to fix myself.

I downloaded the following .capx off Scirra Arcade:

static1.scirra.net/arcade/games/1259/tetris.capx

While it would open fine on my PC at work, I get the following error on my laptop:

"Construct 2 game creator has stopped working"

Problem signature:

Problem Event Name:     APPCRASH

Application Name:     Construct2.exe

Application Version:     2.0.0.0

Application Timestamp:     53024bf5

Fault Module Name:     Construct2.exe

Fault Module Version:     2.0.0.0

Fault Module Timestamp:     53024bf5

Exception Code:     c000001d

Exception Offset:     00000000004c5f00

OS Version:     6.1.7600.2.0.0.256.1

Locale ID:     1031

Additional Information 1:     1c57

Additional Information 2:     1c5758b731396da5cb0c71a42fb6b26b

Additional Information 3:     25bb

Additional Information 4:     25bb63829f4e108377a72e0adc481658

Read our privacy statement online:

go.microsoft.com/fwlink

If the online privacy statement is not available, please read our privacy statement offline:

C:\Windows\system32\en-US\erofflps.txt

PS: I just recently re-installed my laptop, so the OS version is still referring to Windows 7 pre-SP1. About to fix this now.

I see.

So essentially, you use Construct 2 as a room editor and import all the data to your engine?

I just had a look at my room editor (which, currently, looks really horrible and misses most basic functionality) and, from the looks of it, that XML approach might work for me as well.

AFAIK, Construct 2 can exclude content from JSON/XML. Is that correct? If so, I could probably just exclude all the editor content (movable test character, file menu, etc), apply full transparency to all walk-paths and export the stuff to XML.

How did you define paths, btw? Did you use invisible blocks as well?

dinofun

Arcadier = More like the fast paced shooters I used to play in arcades. Personally, I'd prefer a game that offered faster pacing and instant

As for Firefox: Aside of the audio (which suffers from a horrible latency), it looks and plays exactly the same as in Google Chrome, albeit a tad slower (Firefox is almost notorious for being incapable of handling physics).

I also ran it inside my own browser (which is based on Mozilla's codebase, but features a simplified layout and a faster rendering engine). Runs almost the same as in Google Chrome (Linux), speedwise. Even a tad faster than Chrome (Windows). The audio issues still subsist though.

Audio is definitely screwed up on Firefox.

Graphics are flawed by the very nature of your graphics. The player looks like a cutout, whereas the coins are way too pixelated (which just doesn't go well with the ways you depicted the meteors).

The artificial input lag largely stems from the way you implemented physics. It's not as if the ship wouldn't react to my input right away (as can be seen from the ship's active back-burner), but it just takes a great amount of time to finally move upwards.

It might be just me, but I prefer slightly arcadier controls. Realism is way less fun.

As for Stiivais main criticism: Get yourself a pair of glasses, dude! The doge is right there, inside the player ship.

Aside of the flawed graphics and audio, I don't see what's the challenge here. I also don't understand the concept of making a game harder to play by introducing significant amounts of artificial latency.

Could be a great game though, provided you polish the graphics, audio, performance and game-play. I'm sure you can come up with something a tad more original than "Let's make a Flappy Bird clone in outer-space".

Heck. Why not goof around a bit, try a few physics effects, add bullets and/or enemies?

This thread inspired me to tackle the conversion of my old, abandoned project GOAE (Grand Old Adventure Engine) to HTML5 again.

OlivierC

How do you handle the tooling? Did you write your own, integrated Construct 2 plugins or are you using an external pipeline for stuff like the scene editor?

Personally, I consider combining XUL (my last build used pure Construct 2 HTML5, but that was before I found out about XUL) and Construct 2 generated HTML5 for my pipeline, so I'll be independent from Construct 2 for most of the work.

The one thing I'm struggling with is coming up with a script engine. I'd love to have something with C like syntax.

Looks great ^_^

I use a bit of an older version of jasc paintshop 7, only 30mb, but been my loyal assistent for over 10 years ... I'll take it any day over modern paintshops.

The only two tools I ever felt comfortable with were Twisted Brush (it has this awesome filling mechanic where you can actually decide the radius of the filling by holding the mousebutton) and Corel Draw 11.

Twisted Brush did, unfortunately, not work well with this image and I don't know where I left my Corel Draw serial.

Anyways. Just found my original image. Turns out, it was way bigger (the one on here was just a Twitter avatar, it seems) and I managed to keep the layers somewhat seperate.

When I opened the file in GIMP, it was masked pretty well and there were only a few parts (the snout, the tail and some of the a's and e's) I had to fill in manually.

The letters look weird when I carve them on a gray background, so I'll still have to manually add them.

Getting one's logo onto a credit card is a huge PITA, btw. The logo on here has just the right size but easily blurs out and the original one is sharp but way too big.

Nope. Still doesn't work. Looks all sorts of funny, but I can't get the right combination.

EDIT: Just saw your edit. Thanks for the help. Just adding it to my logo. In the future, I'll make sure to stick to one single graphics editing tool and to use layers at all times :)

EDIT2: Just pieced it all together

<img src="http://s28.postimg.org/ez06vmnvx/Logo_B.png" border="0" />

Good work lennaert :)

I think I'm going to try and scale this to credit card measures. Getting a new CC next month and still hadn't decided on the custom image. Until now, that is.