WaterlooErik's Forum Posts

  • Hi Tobye, I'll do my best to help get you to a point where you're ready so submit; and hopefully this will help some other starters too. As noted mzo's guide does a good job of bringing all the information to one place, but if you're looking at it all for the very first time, it can look like quite a bit. Let's try to pick out some of the more urgent pieces first.

    Just to understand where we're starting, is it safe to say that you're familiar with C2 to the point where you've created projects and can export an HTML5 version of those project? (i.e. the HTML, CSS, and JavaScript files are generated in a standalone folder.)

  • HenMex: That's what I like to hear! :-)

    lougazzola: Thank you for clearing that up.

    If there are still any concerns out there, by all means don't hesitate to ask.

    For those looking at participating for the first time, I've given mzo's documentation (on the first page) a read through and it does a good job of covering a lot of the pieces you'll go through. Even if you have no development experience and are unsure about Code Signing Keys, downloading SDKs, etc. there are people like me (who you can reach at eoroswcy@rim.com as well) who will be online during the Port-a-Thon actively helping you overcome any challenges you encounter.

    Best of luck all!

  • Hello all, I'll do my best to answer the questions at hand.

    RE: Terms and Conditions

    I've reached out to the team organizing the Port-a-Thon to get official clarification on that section.

    In my opinion (and I am far from a lawyer), I don't think the statement is as broad as is being discussed based on the definition of information.

    ny and all information you provide to RIM in connection with this Program, including but not limited to any ideas, suggestions, improvements or modifications, to or for RIM's products, that are included in your App or that arise from your participation in the Program constitute "Information".

    Things that begin with "You guys should..." or "I improved performance by..." might fall under the category. Otherwise an open-forum webchat where information is flying freely would simply not be possible. But that doesn't mean free reign over redistributing your products. Again: not a lawyer, didn't write these, but does that interpretation seem reasonable to others?

    I do agree that the wording could use a facelift though :-) Ultimately, developers fully own the applications that they submit to App World, and I'll provide the "official interpretation" as soon as I have it.

    RE: Quality of Submissions

    In testing, there is a subjective element to applications. Games are judged more on the experience they provide than just whether they run. It doesn't mean something simple can't be compelling, but a Tic-Tac-Toe game would require a lot of polish and presentation. A lot of the Construct 2 games I see out there wouldn't have an issue on that front though; the tools do a great job of giving you a lot of power in creating solid applications. If you enjoy the game, chances are others will too.

    RE: Target Resolutions

    Regarding the resolution, BlackBerry 10 devices are launching with 1280x768 and 720x720 resolutions; you could target just one of those. You can design for 1280x1024 as long as it scales to the device appropriately (i.e. content isn't cut off.) To help with this, there is the Ripple tool which emulates device dimensions as a Google Chrome extension:

    developer.blackberry.com/html5/download

    If I missed anything, please let me know.

  • Yup, I've discussed the exporter with Ashley. The previous round of BB10 OS updates had some larger rendering issues that prevented some solid testing. I've been firing along issues to our teams but a few are still outstanding. That being said, we'll see how this week's update looks and hopefully it will prove more viable for testing.

  • I've been away from technology for the last week and really appreciate the discussion going on above. I'm hopeful that the next OS release for BB10 will have an inherent answer to the Power of 2 issue; as long as it's not dependent on a larger fix, initial testing looks likely but I can't confirm all of the updates that make it into a release.

    With regards to panning, this will occur if any content stretches beyond the dimensions of the screen. Will keep the fullscreen setting in my back pocket :-) Again, thanks all for the great discussion.

  • jeddtobee: Thanks for that feedback. I'll add that to my testing and feedback for our dev teams.

    kenli: Thanks for the direction, I'll check that out for sure. I may have to put a pin in it for just a little bit until we iron out some of the core functional issues. But I'll definitely explore Clay.io.

    bjadams: Unfortunately no date on when PlayBook will get BlackBerry 10 yet but it most definitely will. It will be some time after the initial launch, but I can't speak to a timeframe just yet. Agreed though that once the platforms are sync'd, it should make devs lives even easier.

    Thanks all!

  • Regarding <canvas> applications, the initial issue itself was resolved with the Gold SDK; this was related to <canvas> applications rendering black. At the same time, a new GL rendered was implemented in this release and there are some outstanding issues.

    One of the main issues right now appear to be related to the use of non-power-of-two images that may be causing buffer over/underruns in addition to some skewed graphics. I'm running some tests today and will be raising these issues with our dev teams.

    Overall, this release was a step forward but there is still some work to be done on the GL renderer implementation. If anyone comes across any issues, by all means let me know as much as you can regarding the cause/use-case and I'll test/escalate.

    kenli: Regarding Scoreloop, it's on the radar but I'm not sure about a date. This is one of our biggest outstanding asks (and a common one from the community) so know that we are pushing to make this available.

    austin: I'll admit that I'm not familiar with Clay.io, but I'll give it a look. If you do have any intent to port over to BlackBerry 10, let me know and I'll do my best to provide what support I can.

  • Because the Port-a-Thon came up in this thread, I just wanted to point out that the <canvas> issue which affects the current public BB10 release should be resolved in tomorrow's (Dec. 11th) Gold SDK/OS releases.

    On top of that, approvals for resubmitted apps (to still count towards Port-a-Thon rewards) have been extended to December 23rd. This is only valid for those apps originally submitted during the Nov. Port-a-Thon.

    Best recommendation for any affected developers would be to repackage/test with tomorrow's released tools, and then submit as they're able. With the extended approval deadline, hopefully this gives some breathing room with the new tools.

    Ashley, this would also likely be the best route for your BlackBerry 10 testing as a number of rendering changes have been implemented.

  • Thanks for that extra information; seems there is more to the issue than just Text objects. The BrickBreaker sample did still result in the black screen on the latest PlayBook, but I'll use the above as a basis for more testing.

  • Ah, I thought there might be something like that available. Thanks for the tip!

    EDIT: New BAR files with the recommended Text object implementation:

    webglon.bar box.com/s/ytdf0qbh9eprd8ffort3

    webgloff.bar box.com/s/jaus3uf2rctoajyt41pq

    I also added some particle animations and *think* webgl is running a bit more smoothly (but maybe it's just my eyes seeing what they want to see.) :-)

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • 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?

  • Regarding WebGL, Text Objects, and PlayBook, I just want to confirm that I am testing this appropriately.

    I created a new Construct 2 project and performed:

    Insert new object > General > Text > Insert

    I edited the text value to be WebGL is enabled. and ensured that on the root Project object, Enable WebGL was On.

    I then exported as HTML5, created my own basic config.xml, and leveraged the BlackBerry WebWorks SDK for Tablet OS 2.2.0.5 to create webglon.bar.

    I then repeated the process but instead the text says WebGL is disabled. and the Project object has Enable WebGL set to Off; thus creating webgloff.bar

    I loaded both BAR files onto my PlayBook (2.1.0.1088) and launched each. If I'm understanding correctly, webglon should fail in displaying the Text object and webgloff should succeed in displaying the Text object; is that right?

    In my results, I'm actually seeing both Text objects render just fine, but I want to ensure this actually encapsulates the issue at hand.

    For reference, the two files can be downloaded here.

    webglon.bar box.com/s/ytdf0qbh9eprd8ffort3

    webgloff.bar box.com/s/jaus3uf2rctoajyt41pq

    If the above test case is valid, I'll also perform the tests on BlackBerry 10. Also, if you have a BAR file you want to send me for testing, I'd be happy to do so as well (just as a sanity check whether the issue is actually still there.)

  • I appreciate the great feedback —

    Regarding spaces ( ), hyphens (-), and underscores (_), I ran a quick test on the WebWorks SDK for Tablet OS 2.2.0.5 and BlackBerry 10 WebWorks SDK 1.0.3.8.

    WebWorks SDK for Tablet OS 2.2.0.5

    * spaces: packaging failed.

    * hyphens: packaging succeeded.

    * underscores: packaging succeeded

    BlackBerry 10 WebWorks SDK 1.0.3.8

    * spaces: packaging succeeded.

    * hyphens: packaging succeeded.

    * underscores: packaging succeeded

    The test was done with a ZIP file containing an index.html, config.xml, and three TXT files (this has spaces.txt, this_has_underscores.txt, and this-has-hyphens.txt).

    Seems we're in a slightly better state regarding these limitations with BlackBerry 10. Do we feel that spaces are something that should be looked at being permitted? I cringe a little at spaces myself, but if there's a consensus for 'yes', then I'll push it to our WebWorks packager teams.

    Regarding WebGL + Text, do you simply mean the Enable WebGL property for a project? I'm assuming so, and will run some tests on that here. I'll also reach out to Mr. Wong (likely Alan Wong?) to see if he has any insight on the files you sent him originally.

    And by all means keep the feedback coming. I'm trying to stay on top of everything but if any question's gone un-addressed, don't be afraid to follow-up. I certainly don't mean to avoid any questions, just sometimes things slip past me :-)

  • gonzdevour

    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.

    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?

    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.

    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.

    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.

    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.

  • ronval: I appreciate the information on that. I'll put together some tests on my end to see if we can produce this with the latest BlackBerry 10 system, and if so will raise it with our development teams for further investigation.

    If there's any additional feedback from the community, please don't hesitate in sharing. As noted, I want to ensure as many obstacles as possible are removed for this community.