Blinx123's Forum Posts

  • Probably a quite simple thing to do, but I can't quite figure out how.

    My current event sheet basically looks like this.

    Global number "Scale" = 0.1

    ___________________________

    Every 0.01 seconds -> Sprite -> Rotate 1 degree clockwise

    Every 0.01 seconds -> System -> Add 0.001 to "Scale"

                                 -> Set scale to "Scale"

    This, of course, keeps rotating and scaling the sprite indefinitely. Now what I'd like to do is stop scaling it the second it hits the 1.0 mark and stop rotating it the moment it's correctly aligned to the screen once again.

    Is there any quick way to do this? Preferably, I'd like to do all this in a while loop, though I have yet to figure out how while loops work inside Construct 2 (some things are just harder to do inside an FSM than they're in clear cut, C like code).

  • Better look somewhere else then, as HTML is absolutely not made for this kind of stuff.

    What you're looking for is a solid back-end like PHP or Python.

    Once you're done with that, you can look into doing the front-end (the graphical layers and the clicky stuff) in HTML

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads

    You mean you're running your exported project from disk? That's never been supported. You have to upload projects before they work.

    It has always worked (and still does), actually. Just not under Chrome or IE.

    Firefox doesn't prohibit the use of offline cookies, so HTML exports work fine locally.

    The one thing that's still puzzling me is why manual Node-Webkit exports stopped working for me with R130. My build script is pretty simple and doesn't really do anything esoteric.

    #MakeNode.ps1
    $date = Get-date -format "dddd-dd-MMMM-yyyy_HH.mm~ms"
    
    CMD /C Sevenzip a -t7z -r "C:\users\$env:username\downloads\node-webkit-v0.5.1-win-ia32\node-webkit-v0.5.1-win-ia32\Package.7z" "C:\users\$env:username\desktop\Powershell Pr?sentation1\*.*" > C:\Log.log
    
    mkdir -p C:\users\$env:username\downloads\node-webkit-v0.5.1-win-ia32\node-webkit-v0.5.1-win-ia32\$date
    
    CMD /C Copy /b C:\users\$env:username\downloads\node-webkit-v0.5.1-win-ia32\node-webkit-v0.5.1-win-ia32\nw.exe+package.7z C:\users\$env:username\downloads\node-webkit-v0.5.1-win-ia32\node-webkit-v0.5.1-win-ia32\$date\package.exe
    

    Never mind that I still need to add a few lines, copying the rest of the Node-Webkit to the output folder. I currently do that manually (blame lazyness). Still, the script should (and, in fact, did) work properly.

  • The PlayBook browser ought to support WebGL. All demos except the ones from Playcanvas and Construct 2 work rather well.

    What does the console says when you check for errors in the browser ?

    Edit: Investing a bit more, this only happens when you try to execute the project in offline mode (locally on the computer if you will), which isn't an expected way to do.

    Host the project online and execute it, that's the intended way of executing HTML5 projects.

    Here's the output:

    Viewport target-densitydpi is not supported. | index.html:9

    Uncaught Error: SecurityError: DOM Exception 18 | c2runtime.js:1740

    The first one is pretty normal though, since it got deprecated a few months ago.

    I do need to get this working offline, since that's what the jury asks for.

    Lastly, I see no reason why such a project wouldn't run offline on it's own (aside of Google Chrome not being able to access the appcache or something like that, which I haven't yet checked). All my manually coded HTML projects do.

    EDIT: Never mind. Found out that this is due to Google Chrome's own security policies. Can't really fix it without stripping my demo off the pathfinding Webworker. The only solution I could find is to run Google Chrome with the "--allow-file-access-from-file" Chromium flag.

    Still weird that the same would also happen with manual Node Webkit builds. The only obvious thing that has changed since the version I used previously is the inclusion of jquery 2.0 and the fact that, by default, Index.html no longer looks for Jquery on it's official website.

    I just exported a small project for a demo coder competition and ran into a pretty weird issue.

    The exported index.html works just the way it should on Firefox but on Chrome, I'm merely greeted by a black background.

    This is true for all my exports and I'm wondering why that is.

    The app works just as it should inside preview mode (even when choosing Google Chrome) and as a Node-Webkit export.

    Manually packaging Node-Webkit apps (i. e. outside of Construct 2) stopped working with Construct 1.30 HTML exports, as well. Now all that happens whenever I execute such a self-packed app is a message window popping up, telling me that I can't use the HTML offline while also retaining the black background with nothing on it.

  • 1. Sure thing. You can even have a game utilizing both, vertical and horizontal layouts.

    2. Yes. I'm not sure which exporters are excluded from the free version, but you can always fall back on exporting your game as an HTML and then manually build it outside of Construct 2 (Phonegap Build will do that for you in less than 5 minutes) or upload it to some place and directly display it in the browser.

    3. You mean virtual keys? Simply add some button sprites and equip them with an "on touch" action.

  • Joannesalfa

    Yea. .Bat/.VBS are Windows exclusive scripting technologies. However, Linux and MacOSX feature similar batch scripting engines.

    At least on MacOSX, it will be pretty easy to create an update script that will keep your old files. Node-Webkit for MacOSX simply copies and replaces existing files inside the .App container, while Node-Webkit for Linux and Windows concatenates two or more binary files.

    As for multiplatform installer builders, you might want to take a look here.

    en.wikipedia.org/wiki/List_of_installation_software

    Ashley

    Isn't the cross-domain issue still persistent with your Ajax implementation? Wouldn't be worth much if it didn't allow for cross-domain actions.

  • I was trying out some WebGL demos on one of my two new Blackberry Playbooks (still not exactly sure whether it was wise to invest into two, but I digress) and found that none of the Playcanvas nor the Construct 2 ones were working.

    I haven't yet checked out the sources of either demo but was wondering whether this was done on purpose.

    Do those demos specifically check for a desktop browser (as can be done in an event sheet, I seem to recall) or is the whole WebGL implementation inside Construct 2 incompatible with mobile browsers?

    EDIT: Another question: Since Blackberry 10 and Blackberry Playbook OS 2.1 are both using Webworks SDK for their HTML5 content, would it be possible to deploy an app to the Blackberry Playbook using the Blackberry 10 export option?

  • Granted, it's still missing some automation. But the easiest thing you could do is create a batch script of some sorts, name it "updater.bat" and tell it to download and repack the content each time someone is launching that "updater.bat".

  • Meh. Totally forgot about Ubuntu Phone for ARM.

    You'd have to look into compiling Node Webkit yourself for this, I guess.

    Since Node Webkit's Github account lacks any concrete instructions on how to do this, you might want to take a look at Chromium for Linux ARM build instructions (Node Webkit and Chromium are, essentially, both using the same build process).

    code.google.com/p/chromium/wiki/LinuxChromiumArm

  • Yea. The only way to get this possibly working would be with the help of some symlinks (or perhaps simply hidding the files would suffice?).

    Anyways. Of all the files you listed, nw.pak and icudt.dll are the only absolutely manadatory ones (well. nw.pak is. I haven't yet tried without icudt.dll, but since it's a networking library, one might even exclude that one as well).

    dxwebsetup.exe can be placed into a different folder (most studios place them into a folder called setup or install or extras or something to that avail).

    ffmpegsumo.dll is used for <audio> and <video> tags, so you only need them for apps using the audio/video capabilities of the browser (to be fair, most games probably need the audio tag, at the very least)

    libEGL.dll and libGLESv2.dll are used for WebGL and GPU acceleration

    D3DCompiler_43.dll and d3dx9_43.dll are used for the compatibility layer (to make sure that WebGL games run on non-WebGL compliant hardware).

  • If you plan on getting rid of that extra blue box next to your image, Open your image in Image Editor, and simply press the Crop button... It's that simple.

    It actually wasn't "that" simple.

    The extra blue box wasn't physically there, you see.

    It was rather a graphical glitch that manifested itself in this weird blue box and, some times, extremely off coordinates.

    Anyways. I got rid of this ages ago, hacking some AMD drivers.

  • Having tested the PS Vita browser myself, I can only say that it sucks. It's just as bad as the Nintendo Wii U browser (it's really just the bare basic Webkit with only a few extensions, if any).

    I honestly don't even know why anyone would want to develop an HTML5 game on PS Mobile though.

    Monodevelop is a great IDE and Sony put some serious work into the documentation of their libraries. The included examples basically make your game for you.

    The only downside to C# is the fact that doing Functional (Reactive) Programming is tough as nail*. But then, that's not something HTML5 developers would be used to anyways.

    *I'm still struggling to re-code any of the included examples to a purely functional approach, as I'm really opposed to the anti-modular/anti-parallel concept of classes

  • Ubuntu Phone is just a mobile flavour of Ubuntu Linux. Couldn't you simply write an app for Linux (Node-Webkit export will do just that) and run it on your Ubuntu Phone?