gonzdevour's Forum Posts

  • OK, I got it.

    We shouldn't select minify when export.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • I used Tap's AppmobiDev Plugin, worked.

  • Same result on iPad3

    r117

    PhoneBrowser mode

    iPad3

    Initiate scanner?OK

    Complete scanning?OK

    Barcode data?Not recieved.

    Same capx as above.

  • Same here.

    r117

    PhoneBrowser mode

    Android Galaxy S2

    I can see the scanner and can complete the scan,

    but no data recieved.

    My capx:

    https://dl.dropbox.com/u/49730415/AppmobiBarcode.capx

    I'll try iOS tomorrow.

  • Thanks, I'll try r116 beta soon.

  • Hi, I have some trouble as below:

    <img src="http://i1220.photobucket.com/albums/dd443/gonzdevour/672A547D540D-1_zps9c4f71b2.jpg" border="0" />

    It's the example capx included in plugin folder:

    1. I added a text object to test if ?is windowsphone app? works, seems no.

    2. Vibrate 2 sec didn?t work, too.

    3. ?Back? still didn?t work. It turned back to app-list instead of HOME layout.

    I am not sure if it's:

    1. about device: HTC 8S

    2. about C2 release version: r117

    3. because of other reason.

    Thanks you for making this plugin.

    I am struggling with back-button support for weeks.

  • I got this if I tried to open DirectCanvas project.

    <img src="http://i1220.photobucket.com/albums/dd443/gonzdevour/2013-2-54E0A534812-20-10_zps7c32d3b1.jpg" border="0" />

    I've just successfully build a PhoneBrowser apk by XDK with same C2 template,

    maybe it's more likely a DirectCanvas problem?

  • Link to .capx file (required!):

    https://dl.dropbox.com/u/49730415/AppmobiNotSupported.capx

    Steps to reproduce:

    1. Create an Appmobi template

    2. Export it with DirectCanvas

    3. Test it on XDK or build it as an Android APK

    Observed result:

    Black Screen in APK, crash in XDK

    Expected result:

    Not Black Screen or crash

    Exporters affected:

    DirectCanvas: Yes

    Phonebrowser: No

    Operating system & service pack:

    XPsp3

    Construct 2 version:

    r117

  • Link to .capx file (required!):

    https://dl.dropbox.com/u/49730415/ForceOwnTextureInAppmobi.capx

    Steps to reproduce:

    1. Create a new project with Appmobi template

    2. Add a new layer and set its "Force own texture" to yes.

    3. Export the project to appmobi use directcanvas.

    Observed result:

    Black screen.

    Expected result:

    Not black screen.

    Platform affected:

    Chrome: no

    Firefox: no

    Internet Explorer: no

    Phonegap:no

    CocoonJS:no

    Appmobi:

    -Phone Browser:no

    -DirectCanvas:yes

    Operating system & service pack:

    WinXPsp3

    Construct 2 version:

    r116

  • Though there's family feature in C2,

    I always arrange all the enemies into only ONE SPRITE with different animation name and add behaviors which I need.

    If INITIAL ANIMATION PROPERTY is available, will be very helpful to make platform games with many kinds of enemies and animations previewable in C2 editor.

    Especially for enemies with physics behavior.

    If you want to set physics parameters separately to each kind of enemy, family+Physics won't help.

  • One last note, I pulled the failing BrickBreaker sample from supportforums.blackberry.com/t5/Web-and-WebWorks-Development/TEXT-object-cause-black-screen-after-OS-2-1-0-1032/td-p/1938303 and packaged/deployed to my PlayBook (2.1.0.1088) and definitely saw some issues (and some potential issues):

    * As I was playing, the rendered area kept growing larger. Not sure if that was intentional.

    * After playing for ~20 seconds, the screen went black.

    The timing of the screen going black appears related to the growing play area. I did not come across any large volume increase though (it was always around 50% volume.)

    That being said, I clicked through / failed a few times without any issues beyond the growing play area / eventual black screen.

    Are these the issues in question?

    By my test months ago,

    the text with webgl-on is sufficient to make screen black.

    It's great to hear that they'll be ok now.

    The story about growing paly area is here:

    When I was making Brick Breaker for testing if playbook's performance is good enough for ACT,

    I tried many ways to figure out why it always turned into black screen,

    then I found that when I choose "Letterbox Integer Scale" mode, it showed with smaller size and worked.

    (WebGL is On)

    Therefore, I made the growing-area to make sure if it's screen size problem.

    The result is, if the screen size just fit Playbooks's screen size, it crashed to black screen.

    At first, I thought it's screen size issue,

    after more tests, I found if I turned WebGL off, the growing area wouldn't crash anything.

    Moreover, if I removed text object, it worked with WebGL too.

    For study reason, I'd show you this:

    Monday Morning Escape

    http://appworld.blackberry.com/webstore/content/17842944/?lang=en

    It's my first playbook game after BrickBreaker testing.

    Actually speaking, I want this game published at first, but it turned into black screen too.

    I removed all text objects to fix the black screen issue,

    but it wouldn't be a game without hints and story-telling.

    After BrickBreaker testing, I simply turn WebGL Off in Monday Morning Escape project,

    then it amazingly worked.

    That's why I think it's not screen area issue and surely is WebGL problem.

    I don't know if something fixed or not in these months.

  • Perhaps that's why I haven't seen the symbols/space issue, I've been building with the BlackBerry 10 SDK. I'll double check on the latest PlayBook SDK, though I can't guarantee an update would be possible as essentially all development efforts are on BlackBerry 10 nowadays. If the fix is small, perhaps it could be added in.

    Thanks.

    I'll have to take a closer look at the WebGL issue; WebGL as a whole is definitely supported on the PlayBook platform, however if there is a component that is breaking WebGL, that's something that we'd need to escalate to our development teams to have fixed. Have you by chance already submitted a bug report on this to the development teams?

    Yes. I 've sent a zip not only to the development teams,

    but also to an Application Development Consultant Mr.Wong in RIM HK.

    However, maybe it's hard to discover what happened by the zip,

    I think the C2 exported files are not simple enough to debug.

    If you are trying C2, just put a text object and turn WebGL on/off to see what happened in .bar.

    I am not sure if this issue fixed. It's about a month ago and I found Playbook OS has updated.

    For Ripple, if you're still seeing issues, please fire me an email to eorosxmv@rim.com and we can work together to get it working properly. I can set up a phone call if you like too and we can talk it out. Are you using the standalone Ripple installation? The standalone was EOL'd a while back and isn't maintained anymore. The recommended Ripple currently is the Chrome Extension version 0.9.10. There are a few things we need to double-check to get the default localhost working, which I'd be happy to work with you on. Alternatively, a local web server is what I generally recommend.

    Thanks, you are kind.

    I am using command line to ensure all things worked and pop out the real reason if error,

    It's enough for me right now, but I think a much more friendly Ripple is necessary.

    While there are two separate SDKs for PlayBook and BlackBerry 10, this is because PlayBook applications exist within an AIR container, and BlackBerry 10 applications are HTML5 that hook directly into native (C/C++). There are some API changes, and some config.xml changes, but overall the process and structure should be very similar.

    Got it. If there're plugins and exporter to deal config and API integration,

    It will be a great inducement for C2ers to try RIM platform.

    I agree that screen resolutions can be a nightmare to manage, which is why we've standardized our touch-screen devices to 1280x720 and keyboard devices to 720x720 moving forward. There will still be some adaptation required, but you shouldn't need to make these adjustments with every new device launch as was the case in the past.

    While iPhone5 and Win8 makes their screen 16:9,

    I think 1280x720 is a nice idea. It helps the developers easier to make cross-platform plans.

    Any plugins created will target BlackBerry 10 first, with the potential for PlayBook. Since the PlayBook is going to be upgradable to BlackBerry 10 eventually anyways, the tradeoff between effort and importance comes into play.

    Playbook is an old guy........but I can understand that RIM has no superiority to join the Arm Race.

    As a game constructor, what we need is a platform with 60 fps for all the game genre.

    Hope BB10's software acceleration can make it with HTML5.

  • Thanks ronval told me here.

    On Playbook:

    1.As Ashley said, naming issue is annoying.

    Symbols/Space limitation make things harder from game making to packaging.

    2.WebGL not supported.

    http://supportforums.blackberry.com/t5/Web-and-WebWorks-Development/TEXT-object-cause-black-screen-after-OS-2-1-0-1032/td-p/1938303

    3.Blackberry Graphical Aid is not a reliable tool, same as Ripple.

    http://supportforums.blackberry.com/t5/Web-and-WebWorks-Development/Can-t-build-Bar-from-zip-by-Blackberry-Graphical-Aid/td-p/1861711

    4.By the webwork tutorial I've followed, I think BB10 and PlaybookOS are not the same structure of development. The SDK I have to download for Playbook is different to the SDK for BB10beta. When the resolution of BB10 and Playbook are very different, It's not easy to make a game once and publish to both BB10 and Playbook; and I am not sure WaterlooErik's plugin work will help both BB10 phone and Playbook, or only BB10 phone?

    Last week I got paid from RIM,

    compared with iOS/Android/Win8, the paying speed is amazing.

    However, with the problems above,

    I am very sorry to get those money by a game lack of minimum standard performance.

  • Would this work for a Myst style game or is better to simply split a whole video into several individual sprites and soundfiles?

    This idea is interesting, but as far as I know, it's hard to "sync" the frames with your triggers by video.

    It's work or not depends on how precise you want your game looks like.

  • Wow, high-tech!