Hi All,
I have a prog running on Windows and also compiles to my phone(HTC one) with no probs,when i put it on my tablet(Galaxy Tab S 10.1) some of the graphics are corrupt,I assume that there are some files already on the Tablet that are not being written over.
I have searched for an answer and also tried to find the relevent files on my Tab.
Any ideas what i can do?
Thanks in advance.
What does the corruption look like? If it's displaying white blocks instead of animated sprites, then they are likely not being loaded. It could be a path problem. It might be also be a .PNG problem if you've used alpha in the image.
Do a full, clean compile (click on the dustbin in the IDE before compiling) and ensure that all images are case-correct. Android really is fussy with regards to a stray lower/uppercase letter when it's looking for a file (even check the file format - if GLB is looking for "XXX.PNG" make sure the image is not "XXX.png"). Delete and uninstall the old version from your Tab too, then transfer the newly compiled .APK. Hopefully that will help.
Can you take a screenshot? That may shed more light on the problem(s).
alpha in pngs works fine in my games (im is a heavy user of them), but do have mulitply alpha issues when used on a virtual screen. But howover 8bit pngs is a nogo.
But Ian is right about filenames. That part can been pretty much annoying.
PS. Also you might use the newer Android Extras, which uses a much newer SDK than the stock glbasic (which will been standard in next official version of glbasic).
As part of my debugging procedure i am displaying the graphics after they have loaded.
They do display so they are definitely loaded correctly.
I have done a clean and recompiled to no avail.
It seems weird that it works on my phone so i think it must be a local problem on my tablet.
To clarify when i said corrupted i mean they don't show up.
I am using .BMP
Screenshots attached.
the first is android
I believe i have the latest version of android extras.
Thanks
Looks like you might need to use -
SMOOTHSHADING FALSE
to ensure that the image is pixellated and without extra borders.
Nope it's not that.
Here is a link to the code if anyone has the time or inclination to look.
https://drive.google.com/file/d/0B_jPlZixO8uQa3VmWnhBR01pN0E/view?usp=sharing
ahh, Im now seen its the colboxes that dosent load correctly. This is a issue im have seen before.
You need resize the col image to a bigger size, and you should use "power of 2" images to avoid wierd issues like those. Special, when its a small size graphics. They might not load correctly on some devices.
PS. Im did used something like this in Karma Miwa, its a 1x1 pixel col sprite, but im have no seen wierd collisions issues due that. The sprites is of course newer shown to the user.
It would appear it is something to do with the SPRCOL command after the drawsprite.
If i remove the SPRCOLL section then the graphics display fine.
I am checking a collisionsprite against a background sprite(full screen)
e.g.
DRAWSPRITE ColSpriteB,dude.x#+10,dude.y#+60
IF SPRCOLL(ColSpriteB,dude.x#+10,dude.y#+60,GameBgndSpr,0,0)
dude.yv#=0
dude.y#=dude.oy#
IF dude.xv#>0 THEN dude.xv#=dude.xv#-0.3
IF dude.xv#<0 THEN dude.xv#=dude.xv#+0.3
ENDIF
This can property been a new bug.
Also you might want to try seperate Update() and Paint(), so you do update your game first, and then draw all graphics after that.
I have pulled out SPRCOLL and gone over to a boxCol instead,No more problems...
I stopped using sprcoll due its unreliability
but did use a custom function as a fallback
// Do a test SPRCOLL command and if true then usesprcoll=TRUE else usesprcoll=FALSE
FUNCTION newcoll:id1%,x1%,y1%,w1%,h1%,id2%,x2%,y2%,w2%,h2%
IF usesprcoll=TRUE
IF SPRCOLL(id1,x1,y1,id2,x2,y2) THEN RETURN TRUE
ELSE
IF BOXCOLL(x1,y1,w1,h1,x2,y2,w2,h2) THEN RETURN TRUE
ENDIF
RETURN FALSE
ENDFUNCTION
Thanks for that Mr P.
I would imagine boxcol is a much cheaper way of going about collisions which is fine with a tile based game but what do you do with an irregular or deformable backdrop?
i.e. Lemmings.
I am right on the verge of buying GLB but this might sway it.
Haven't had much call for pixel perfect use myself yet...
However, I believe one way to do it is to have a small array of hitboxes (boxcolls) per sprite maybe in a type so they can easily be looped through...others here might have better solutions. Getpixel is sometimes used too but I expect it might be problematic on Android.
Maybe something like this...
TYPE hitbox
sprite_id%=0
anim_id%=0 //ignore for single sprites
offsetx%=0
offsety%=0
width%=0
height%=0
enabled%=TRUE
ENDTYPE
GLOBAL hitboxes[] as hitbox
Karma miwa uses a 1x1 pixel sprite solely used for landscape collisions and nothing others purpose.
Can you testing that game on your problem device. It's used ANIMCOL and do all engine checks before drawing any graphics.