Messages

Just a quick FYI,

I tested some of the Android games some of the brilliant minds have made on here. 

BlackBerry 10 now has Android built in and they finally added Native support as of 10.2.1.

Testing the apps and games on here I found they all worked very well

I know, BlackBerry is evil (etc.) but they buy more paid apps by far.  If anyones interested - I'm going to write a simple game (I have a glbasic license from the old gp2xwiz days) and do a step-by-step article on getting your app on BB10.  I have a good 50 apps for sale already but would love to be one of the first with a GLBasic game

Just wanted to share my findings this afternoon,


Ed.

Sorry folks, I tried a bunch of different ways.  Simple hello world and up.  I am able to go from Glbasic to Android fine.  APK signs and seems OK - didn't have problems there.

But as Kitty surmised, once ported to BAR (PlayBook format) it signs and pushes to the device but only shows a black screen.

If you can punch out a Java based Android APK you can still score the free PB.  They are for sale overs here for 199 anyway so don't kill yourself trying

The PlayBook now supports Android files.
BlackBerry has a promotion going on, sign and submit an app to AppWorld by Feb 13th - and you get a free PlayBook.
All of this can be done for free with GLBasic

How to do this:
1)  Use GLBasic to create an Android App
2)  Package your APK
3)  Use the http://www.blackberry.com/developers link (look under Tablet OS) and download an app signing BAT file
4)  Register for the signing keys
5)  Use the BAT file and signing keys to convert the APK to a signed BAR
6)  Submit the BAR to AppWorld (all of this free)
7)  Once approved, RIM will email you asking for your shipping information.

http://us.blackberry.com/developers/tablet/playbook_offer2012.jsp

  Oh, and did I mention - that means we can use GLBasic to program for the PlayBook and Android now

Code (glbasic) Select Expand

BUILD FAILED
Q:\Compiler\platform\android\android-sdk-windows\tools\ant\main_rules.xml:384: Compile failed; see the compiler error output for details.

Total time: 1 second
Android=C:\adveng\distribute\Android
success

I had the same problem.  Try:

1)  pushing your project to: C:\temp\temp instead of C:\adveng\distribute\Android.
2)  make sure you didnt install GLBASIC beta with spaces or brackets in the filename. 
3)  make sure everything is installed on 32bit system - I put mine on a bootcamp Win32 XP SP3 OS.

Now mine compiles and runs.  But it does not install on my 2.3 and earlier Android devices (basically any devices that are unable to run Flash).  2.3 with flash and higher might work.  It just says its an invalid package on those other Android OS's.  Higher versions seem ok though.  I won't know until my testing group gets back to me on the build.

My compiled app is here:

http://filearchivehaven.com/downloads/android/StarsTest.apk

Its a rewrapped version of the Starfield demonstration that comes with GLBASIC.  Basically, it adds colours to the program and allows you to change the direction of the stars by your mouse clicks.

I'm planning on creating the same FPS calculator in GLBASIC, Java (Eclipse), Simple Android Basic, and that easy Android Application maker for comparison with different graphic modes.

Still on my to-do list.

Lloyd

384 is to do with spaces - do you have any in the project name or path?  Are you using the latest hotfix?

I downloaded and installed the latest fix,
and as you can see by the output text, there are no spaces in the project name

Code (glbasic) Select Expand

Android=C:\Dropbox\GLBasic\8BitBob\android
I wonder if it's because it starts with a number?

Just copied the code into a new project
EightBitBob and it works fine, so it looks like starting your project name with a number will cause a 384 error.

Nice find!  It was failing for me with a number in the name anywhere with that error.

I tried  the number at the start, middle and end.  It seems to be the path containing a number not just the project name.

Cheers!

one of the articles mentioned problems with nvidia cards such as fx5200 and 5600.  This worried me a little bit as I didnt think they were quite that old?

i dont think the operating system was making much of a difference.
I suppose the other thing is it might only be a very small percentage of people who won't be able to play.

Good question, it does and it doesn't.  Operating systems make a huge difference, there are a lot of requirements.  For example, OpenGL is supposed to work a 'certain way'.  But that doesn't mean it actually will on all video cards, on all platforms.  The more common the platform, the more effort that manufacturer will put into that platforms driver.  And the older the hardware the less likely they worked on OpenGL support (especially in the early days).

For example, take Windows 98.  It had a very buggy driver system compared to XP.  Drivers needed to be upgraded by hand manually quite often.  Most video cards were very sketchy on this platform with *any* graphics method.

Next, in Windows XP, drivers are easier to upgrade but still not fantastic.  Drivers can be cumbersome, but so many people have XP and it has such a high amount of focus developers focus on creating extremely stable drivers.

With Windows 7 and on, drivers are more automatic in terms of updating.  Still not perfect, but better.

I suppose the other thing is it might only be a very small percentage of people who won't be able to play.

With *any* graphics library there will always be a small number of people who experience problems.  This could be problems from the video card manufacturer,  OS, development problems, etc.  The problems plague everything from OpenGL, DirectX, etc.

As a developer, you will - at some point - need to create troubleshooting materials and work with end-users to identify problems no matter what you do.  Also, I have always found DirectX to be less portable than OpenGL.  As it requires a very specific type of computer & system installation to use.

In my personal opinion, OpenGL is more reliable on older systems than things like DirectX which is far less portable.  If I was working on an 'optimum' graphics library though, I would jump into C++ and write up a graphics library that uses *only* the features I need.  That's really the only way to minimize potential failures and to make sure you can fix and resolve any issues.

With all of that said, OpenGL is very safe by most standards and would do better than many graphics libraries in development.  Hope it helps!  And this is all opinion based so - as always - take it with a grain

Ed

Hi all,
I've a crash in the process of updating GLBasic from 8.200 to 9. The app just crashes not so long from the moment you click on the button "start update"..
Someone else has experienced this problem? how could I fix it?
I'm working with a windows 7 machine with a standard configuration without 'strange' things installed.. so really it's the same computer I use to work everyday with GLbasic..
Thanks in advance

Same crash happens for me moving from 8.x to 9.x on Windows XP on a bootcamped Mac

Just a heads up, I tried to compile the samples - they also show up with fragmented colours on GP2X Wiz

I only understand polyvectors in SVG - that is instead of having a set scale X/Y/X2/Y2 image you can have all 4 as variables.  So you can stretch an image unequally (look at it like the Transform command in Adobe Photoshop). 

With that said, I have plans to test polyvector in glbasic - but haven't had a need (yet).  From a development perspective it gives you a lot more options though (mock-3d through fake perspective via polyvector for example).

No I know I'm cool with slow 3d - I remember some of your tests.  In my case though the 3d app is very low in its poly count and should run fine.  I know earlier the GLBASIC team had to patch the update so the colours and 3d objects would work on t he WIZ again.  But it looks fully busted.  2 updates ago, the colours were off and now on the current update its really messed up.  Anyway, I dont mind the performance ATM - the performance speeds are a-o-k.  Its just the fact its unviewable

Oi, before I forget:

I tried:  With and Without texturing.  With and without lighting.  Different colours (incase its a transparency thing) And different lighting scale modes

 

Hola Kitty and team,

The last few builds have had some strange behaviours for 3d on GP2X-Wiz.  The objects are not solid - they look like they have a 'blinds' effect on them and colouring doesn't match up.

I've tested the builds in the samples as well as my own code.

Running:  GLBasic IDE, Version: 8.085, Everything up-to-date.  Any thoughts?   If we can get a solid release candidate for 3D - I'll burn it to a CD or something so I wont bug you about it anymore.

3D looks fine on Windows etc, its just on GP2X wiz.

No worries, it was just something I noticed   But I know hardyx had some questions in this thread and I seemed to have somehow hijacked it. 

Something to do with Setting-Transparency having issues on the GP2X-Wiz.  I can't really replicate it myself - I use GIMP for my .png files and I never had any transparency issues.  I do know that faded 32bit alpha has issues (it resolves to a 24bit transparency - meaning all or nothing) - but thats a Wiz limitation I believe not anything to do with GLBASIC.  And its easy for me to code around.

@mentalthink > you are my hero,

I recompiled and it works just fine.  I have to re-examine my code now and see where I broke it.  This worked perfectly, thank you.

- I tried to change your texture to a small .png (64kb) - but the framerate was about the same (which makes sense).
- I removed the texture and recompiled, ran nice and fast
- I removed the square and replaced it with the pyramid from the sample, ran perfectly.

I compared our code side-by-side, and i can see quite a few differences that might explain it.  My camera used a lot larger values and I used a movement command. 

Anyway, that gives me a ton to go off of, so thank you big time.  I'll revisit 3D later on - Just because the games code is already started and I'm down to 7 days remaining  

But it is a good start, so thanks a ton!   It works great without texturing so its something I might need to consider later on.



I've included the pyramid code (with your camera settings) and all seems well.  I included it just in case some other people as new as myself to GLBASIC are looking for more examples!

[attachment deleted by admin]

@mentalthink

It works beautifully - thank you.  I'm going to try recompiling it on my glbasic and see what hte result is.  The code I posted (above) only works if you created the pyramid.ddd file from the glbasic help file.  But there might be something else going on with it. 

This helps, big time thanks.  I'll let you know how the compile works out.