SPRCOLL freezes Android GB 2.3.4

[Miroslav-Stimac]

Hello,

Today I bought GLBasic premium. I had been using the free version of GL Basic since several weeks ago and I have to say that it is the programming with it is the greatest fun for me since the good old times of the Commodore 64.

Sadly, I found a problem. The method SPRCOLL freezes my Lenovo Ideapad A1 that is using Android GB 2.3.4.
My program runs without any problems on Windows Vista, Windows 8 Consumer Previed Edition and Caanoo. But it freezes on my Lenovo Ideapad A1 whenever there is a collision of two sprites.

About the sprites: both have a normal size (less than 100 px width and height) and have no animation. I tried to use BMP and PNG, but in both cases the Android GB 2.3.4 freezes when there is a collision. One of the two sprites is rotated with ROTOSPRITE. The other one is just drawn by using DRAWSPRITE.
If I use my own collision detection function, based on BOXCOLL, then there are no problems.

Here is my method call:

Code (glbasic) Select Expand


FOR i = 0 TO 10
IF SPRCOLL(10, Shuriken.PositionXAsInt%, Shuriken.PositionYAsInt%, 20 + i, Monster.PositionXAsInt%[i], Monster.PositionYAsInt%[i])
// do many actions
END IF
NEXT


I have several monsters. Therefore I use arrays and scan within the loop for any collisions of the shuriken and any of the monsters.

I am wondering that this does not work because SPRCOLL is one of the most important functions in GLBasic.

Best wishes,
Miroslav Stimac

[spacefractal]

http://www.glbasic.com/forum/index.php?topic=7359.0

did you use the newest version of glbasic (10.283)?

Also SPRCOLL is not supported on all Android devices yet, due differents implements of OpenGL (also colored drawing commands also fails on some devices too). But howoer its should not freeze anyway, but instead doing a boxcol instead if not supported.

[Miroslav-Stimac]

Yes, I have the newest version of GLBasic.
I read the old thread already and it did not help me. The problem is really the function SPRCOLL because if I replace it with my own function, that is based on a simple BOXCOLL, then there are no problems. But I would prefer to use SPRCOLL because it is a standard in GLBasic and maybe better and faster than my function.

Best wishes,
Miroslav Stimac

Update:
Now I tried it with a Samsung Galaxy S Plus Smartphone and there it works. I did not change the source code. It looks like that there is an incompatibility between the compiled program and Android GB 2.3.4 on the Lenovo Ideapad A1.
What may be the reason?

[Kitty Hello]

Buggy drivers . Thats Android for you. Nothing much to do. Sorry.

[spacefractal]

Other than detect the buggy driver from PLATFORMINFO("GLEXT:xxxx"), so its can been skipped, and then instead using a alternative software based version (howover would been nice if that was possible).

[Miroslav-Stimac]

Thanks for the fast answers. Ok, I will try to use the BOXCOLL function. It should be acceptable.

But I think that I found an other Android 2.3 related bug. Please take a look at my newest thread regarding bad quality of background pictures in the English GLBasic forum.

http://www.glbasic.com/forum/index.php?topic=8064.0

Best wishes,
Miroslav Stimac

[MrTAToad]

Unfortunately that isn't a bug either - most mobile devices currently use a 16-bit graphics screen and thus 32-bit files would be converted to 16-bit...

[Miroslav-Stimac]

I am just wondering why this is so. When I open the picture in the picture viewer of the device then it looks nice (I think it is 24 bit color depth; or at least it looks so). But when it is displayed in the game, then it looks like 16 bit color depth. Is it a driver problem or OpenGL or SDL?
How does the picture viewer show the picture?
Not via OpenGL and SDL, or?

I am totally new to Android. In fact, I do not like Android tablets, but iPad is too expensive and Windows 8 will need some time to arrive. So I have to survive with Android until I see some not too expensive alternatives.

[MrTAToad]

Its probably an SDL limitation, I would think...