naelian's Forum Posts

  • You can find a rebuild sample here => http://compan360.bitballoon.com/

  • Give me a few days to open dusty boxes ! ;p ... I'll put here a new link when i found a copy ;p

  • Click on the "xdk" icon on the top left part of the intel xdk window (the xdk icon become blue)

    Now locate "build settings (Android-Crosswalk)" and put "Orientation" to "Landscape"

  • SergioRM Windwalker happydigital

    Thanks guys !

    <img src="https://dl.dropboxusercontent.com/u/74282909/UC_news.png" border="0">

    Undersea challenge is not dead, i choose to not focus on smartphones market cause of poor perfs (perhaps in a year). I work on a full new and very fast engine (55-60 fps) and focus on node-webkit export to provide a way to use your own images to feed the game with new challenges ! the gameplay is now really different using 2 mouse buttons and parallax effects to play on several "planes/views", AquaItable has now 4 "magnets" to stick pieces and new shaking effects when you keep a piece in your hand in zoom view ... scoring management is also now based on the clay.io plugin.

    I'm also working on many others projects (C2/node-webkit screensavers, clocks) and a new "1-2" players game that should come on Scirra Arcade very quickly and called "The 10 Seconds Barrier" ...a first preview HERE use 1/2/3 keys to play (numeric pad for 1st player ... "hear" and "hit")

    So no new release of UC will come for weeks because this project is now really BIG and i choose to learn many more things to create the BEST game i could !

    Stay Tune ;phere

  • No support of key arrows make your game unplayable for all players without a xbox controller or a qwerty keyboard ... sad.

  • I've downloaded your final .exe version and get the same issue as you. I've also try to preview your project using firefox .... I get a error message at end of the loading system about "sprite_plugin.js" no more responding ... so nw do the same and probably lock without displaying this error. You're project use to many ressources.

  • The 0.7.0 node webkit use in the last C2 beta release (R142) is really fast but including a debugger system always create a huge dps drop. You can perhaps try to reduce fps drop "not using" some elements in debug mode. Testing system browser.querystring = "?debug" (verify syntax i'm not sure) is true if you are in debug mode and false in other case so you can probably not execute or hide many things that are just here to make your game more nice in debug mode as for example some webgl effects or background layers and keep the "engine" code unchanged. May be this can help you to make this debug mode more usable (i hope so).

  • andreyin imagine your code with so many textbox update every tick it will never be so fast ! ... obviously provide a way to disable temporary the debugger to make the game playable to test a specific case is perhaps something scirra could add in future. Actually at 20-30 fps some games stay really playable, consider that it's a good test to know if your game is still playable on very old computers !

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • Don't expect to get it, i want this record ! ;p

  • Yes it's really strange, using your "or" first and "is on screen" in sub-event seems working fine but i can't explain why it's different for C2.

  • I don't understand very well your problem with R142, the way the project view is rescale in the window is depending on your project's parameter "Fullscreen in browser" if this can help ... In C2 a node webkit window is always resizable and the debugger use is own way to resize windows as a user can do so i don't see where there is a "bug".

    You should link a capx and give full details about your pc os as explained in the bugs report section ... Bug report without these elements are closed quickly without answers of the Scirra team !

    Try also debugger mode using chrome and all common browsers (if you can) and see if the result is different.

  • naelian - Sounds interesting. Could you elaborate some more? I'm not sure I totally followed.

    Editing a parameter in the debugger view make this view becoming the focus/main view right ? ... so keyboard/touch event are no more understand by the project code unless putting the project view as main by clicking on it (is the most simple way). Obviously if your project code is doing specific things on mouse click/touch events such as exiting (ex : screensaver project) it's not very convenient. The idea is just to put button or a on top window on the debugger view to be able to focus quickly the Project view, doing so no action on the project view itself is needed to make it focus again so this simple way isn't creating some unwanted behaviour.

  • Could be nice to display a small area that can give focus to the project view to make it keyboard responsive after changing a parameter in debugger view. It's possible to click on it but many project as mine do specific things (as exiting !) when a mouse click is done so it could be useful.

  • It's very strange to see Scirra still using the 0.6.2 nw release and also still closing program using "window["nwgui"]["App"]["quit"]();" instead of "window.close();" because this last command seems to be more reliable. Actually the last nw release (0.7.1) try to solve some problems using nwgui.app.quit (issue 984) but it's still not fixed in 0.7.1. Using "window.close();" avoid this issue.

    so i edit C2runtime.js like this ...

    Acts.prototype.Close = function ()

         {

              if (this.runtime.isCocoonJs)

                  ?CocoonJS["App"]["forceToFinish"]();

              else if (this.runtime.isNodeWebkit)

                  ?//window["nwgui"]["App"]["quit"]();

                  ?window.close();

              else if (!this.is_arcade && !this.runtime.isDomFree)

                  ?window.close();

         };

    * R142 debugger problem update *

    Fullscreen mode still generating a error message in a node webkit debugger mode but Browser > Close is now working differently, the project itself is close but the debugger window need to be close in a second step ... so there is a real progress and no more issue using Browser.close.

    Thanks Scirra for updating nw to 0.7.0 in R142 release and use now window.close() to exit. App.quit will perhaps be reliable in 0.7.2 and better way in future but window.close seems now the only way to avoid major issues ... sure using "window.close()" will probably create other problems but seems actually the better choice !

    * R143 debugger problem update *

    Debugger now hangs using node webkit as debugger with this example.

  • Yes it's true there is a bug but you can avoid it before this will be fixed

    Create a constant text variable called quote and containing "

    so this will display quote = """

    And then use the run file command using

    quote & NodeWebkit.AppFolder & "/dxwebsetup.exe" & quote

    Doing so even with spaces in exe folder name or path (ex : "new project") the dxwebsetup program will be run, this is exactly the same way use by windows to manage spaces in path.

    Strangely some others node webkit plugin commands are running well if AppFolfer name or path use spaces such as "List Files" or "Copy Files"