Hello!
So I am still happily working away on my first glbasic game with an artist friend of mine. Although we're targeting iOS and Android, I've only just picked up an android device (tablet!) to test with. We've been testing on windows so far.
We are currently using 32x32 sprites for our main puzzle pieces, and have been testing under windows with the project settings set to the resolution 320x480. My tablet has a resolution of 1280x800. When I try to run my app on my tablet, this results in it taking up a tiny 320x480 part of the screen. I've attached a pic to show what I mean ;p
Anyway, I was sort of under the impression that somehow things would scale up on the device. I get the feeling I may have to do that myself? I am new to android development but I know there's an AndroidManifest.xml that seems to hold certain relevant settings for the project in terms of scaling. As far as I can tell though GLBasic generates all those platform-specific files for me while doing the build->multiplatform process. I'm not really sure how to change that file and have GLBasic pick up the new changes.
Does anyone have suggestions?
Thanks in advance..!
[attachment deleted by admin]
you'll find some more useful information here:
http://developer.android.com/guide/practices/screens_support.html
on my HTC device I changed the settings in AndroidManifest.xml as follows:
<supports-screens android:resizeable="true"
android:smallScreens="true"
android:normalScreens="true"
android:largeScreens="true"
android:anyDensity="true" />
somewhere in the forum I've read, that some of those settings are obsolete, but don't remember which one.
Problem with this settings: Always the highest available resolution is used independet of your procject settings.
QuoteAlways the highest available resolution is used independet of your procject settings
Depends on the device. Using 320x480 in iOS scales up on a 640x960 (ie. Retina) device automatically.
Cheers
As far as I did check it, the screens will not auto-scale on Android since OS id 3 (1.2 perhaps?).
I have made a solution using a sprite and scaling it.
I make my game for a target resolution of 1024x640, and scale down to device resolution, so I have the highest quality posible (it is better to scale down than scale up). It also draws the image centered on screen.
I choose 1024x640 because:
-It is 16:10, as many PCs had.
-It is native iPad resolution (1024x768)
-It is the biggest texture size for some devices (iphone 3G is 1024x1024)
createscreen 1,100,1024,640
usescreen 1 //just add this at the start of your program
FUNCTION sc: //call sc() instead of showscreen
LOCAL x,y,xz,yz,z
VIEWPORT 0,0,0,0
USESCREEN -1;ALPHAMODE -1
GETSCREENSIZE x,y
xz=x/1024;yz=y/640
z=MIN(xz,yz)
if z>1 then z=1 //this line dont scale up. Remove if want to scale up.
STRETCHSPRITE 100,(x-(1024*z))/2,(y-(640*z))/2,1024*z,640*z
IF MOUSEAXIS(4)=1 THEN ShowZones()
SHOWSCREEN
VIEWPORT 0,0,0,0
ALPHAMODE -1
USESCREEN 1
SETTRANSPARENCY RGB(0,0,0)
DRAWRECT 0,0,1024,640,RGB(0,0,0) // will draw black colour _AND_ transparent alpha
SETTRANSPARENCY RGB(255,128,0)
ENDFUNCTION
Search the forum for my generic resolution code. It resizes all images and saves them in another directory. If you don't update a graphics version file then the next time it loads it will just load the resized versions immediately, saving time and memory. Plus it uses the sprite memory commands so retains all different levels of transparency (ie. if you have images with more than one alpha colour)
Cheers
Crivens method had his adventages and disaventages:
PLUS
-Memory usage (less)
-Fastest drawing speed
MINUS
-Will not work on some Android devices (mem2sprite, grabsprite,... dont work)
-Harder to program, as you have to code with relative (to real screen size) coordinates.
Don't forget the multiple levels of transparency ;) Ah, ang on, didn't really read your code fully. Yeah, can really do the same then right?
Also I've tried it on my Android tablet and it worked fine. It uses mem2sprite not grabsprite (my old routine used grabsprite but obviously you can't get the different levels of transparency). Note that createscreen/usescreen didn't work (at least v8 didn't) on my older laptop. Ok is a few years old but still has Vista on it and could run Doom3 *just* about ok at 1920x1200 resolution. Just totally refused to do those commands for some reason. No big deal for mobiles but might be an issue if want to work on PCs.
I don't find it too hard to program. You just have to remember to use *x and *y for anything drawn to the screen. Placing /x and /y into the mouse routines means you don't have to worry about that as any touching of the screen works out to the correct position on the target resolution. True, there are one or two confusing things at times but works pretty well.
My biggest problem with it is all I do it pick out the pixels at the correct points to scale the image. While this works for upscaling and downscaling it could have a better algorithm for picking the colours when downscaling. For example I used a single pixel black edge for fonts and this could get lost on downscaling. Of course using double pixel edges works fine but it would be nice if a better algorithm could be used to be cleverer. The other problem is the built in font system. I've found single letters on a scaled font will be fine normally, but if a whole sentence is used then leakage from one letter gets into another. Not a biggie (I just use my own routines) but is a little annoying. Probably a slight mistake in my code, I dunno, but annoying.
On the other side of the coin since mucking around with 3D I think I would just do everything in 3D in future. Even the 2D bits. It all scales nicely without any resizing of graphics (ok, so uses up more memory, but if you zoom in on a 3D object then should be even better close up). Only problem is I cannot get that 2D to 3D world command working properly. Then could just say exactly where you want a button, text etc and use it to plonk the 3D in the correct place for a 2D view. Only thing I haven't tried is if alphmode -1 works on 3D objects. If not then will stick to 2D for buttons/fonts as the icon program I use is brilliant for using multiple alpha channels to give a smooth icon. My old single alpha icons in Rotaslider look like crap in comparison.
Cheers
My Android tablet 2.3 fails miserably on grabsprite/mem2sprite, and Gernot says it is a driver issue...
On my previous (unfinished) game I have made/scaled manually all the graphics on photoshop, and use
getscreensize x,y
mediapath$="Media/"+x+"/"
and have in /media dir 3 extra dirs:
media/480
media/960
media/1024
and the game is completly coded with X,Y coordinates multiplied by "zoom" (480=1, 960=2, 1024=2.13). Yes, it works, but is is a real pain in the ass to keep it aligned.
Quote from: Crivens on 2011-Sep-06
Only problem is I cannot get that 2D to 3D world command working properly.
That's easy. X_MAKE3D, then X_CAMERA. Now use X_SCREEN2WORLD with an estimated "z" value (into-screen value) and place the 3D object there. For clicking some object you can use X_SCREEN2WORLD twice to get a "ray direction" for the pixel under the mouse and can use X_COLLISIONRAY to check if it clicked.
QuoteThat's easy
Ok I will try it out sometime. Is there some example code/project around? Out of interest how would 3D objects work with textures that have multiple alpha channels? I have, for example, some nice multi-alpha icons that use the alpha channels to give a smooth edge, which look brilliant with 2D sprites in alphamode -1. If I create a 3D plain object and just texture it with the same graphic as the sprite then would it retain the multiple alpha channels or not?
QuoteMy Android tablet 2.3 fails miserably on grabsprite/mem2sprite, and Gernot says it is a driver issue...
It might be your device. Mine works on 2.3 (think is 2.3.1 to be precise) but my wife's Wildfire fails on 2.2 (only does white for sprites).
Cheers
Cheers
alphamode for 3D is fine. Problem might be drawing order for real 3D models. (no z-sorting performed).
Hmm, got the alphamode working but not exactly sure how to integrate the screen2world with the 3D entity system. Ideally I'd like to be able to set 2D flags onto each object, then in the 3D entity system it will know to deal with these differently and place them in the 3D world at the 2D X/Y/Z coords setup against the object, but I'm getting a bit lost on the actual drawing of the 3D objects. Think I'll leave for now and get on with the main game functionality as I'm really close to finishing it.
Cheers
something like this:
MOUSESTATE mx, my, b1, b2
x_make3d
x_camera
if b1
x_screen2world mx, my, -1, wx1,wy1,wz1
x_screen2world mx,my, 1, wx2, wy2,wz2
x_movement; x_rotation; ...
// x_drawobj id,
IF x_collisionray(id,0, wx1,wy1,wz1, wx2, wy2, wz2) <> 0.0 THEN hit()
endif
Isn't all the x_make3d, x_camera stuff inside the 3D entity system?
Preferably it would be nice to integrate it into that. Could the positioning code then be made in the drawall 3D entity function for objects that are flagged as 2D? It's a bit confusing as the function is called several times (I assume 2D flagged objects would only need to use screen2world on the 1st pass if we ignore things such as lighting and shadows for them) but would it be too late at this point to use the entity positioning functions?
Cheers
entity system??? There's the "EntityPickLine" command.
The 3D entity system. I would have thought the ideal way to make 2D objects in 3D would be to alter the 3D entity system code so that you can flag an object as 2D with 2D coords, and then in the function which re-draws everything do the correct screen2world movement calculations. I just don't know exactly how to implement the final bit as there is a fair bit going on with lighting, shadows etc that looks pretty complicated to mess with.
Or is it more a matter of using the 3D entity system, and then using separate x_make2d and X_camera and screen2world commands outside of it? Sorry, not been using 3D for long.
Cheers
I can make such a function for the ES. No big deal.
Excellent :) I know it's cheeky but any chance of while you are at it checking the lighting code for iOS (because of that weird brightness I was getting only on iOS)? I'll promise to shut up then for a while. :x Maybe...
Did you get the TP in the end? I'm really quite enjoying it now and really will only be swayed by an iPad if they really do come out with a retina version next year.
Cheers
I have been trying to work on implementing the scaling code ampos has so graciously provided, and seem to have it working under windows. For some reason it won't work when I try to test the app out on my tablet :/ It's almost as if it's an issue with the USESCREEN command maybe? It looks like the sprite I'm drawing to with USESCREEN 1 doesn't have anything when I draw it to the back buffer using USESCREEN -1. I basically just get a black screen. I can for example print text to screen -1 (the backbuffer) and it shows up fine.
I have included a simple demo project that tries to scale a screen of 320x480 to your android's resolution. It simply tries to draw a rectangle for the screen size to show the screen border, which then gets scaled up to whatever size the app's resolution is run in.
Again, this seems to work fine under windows (which in the sample project scales up to a window sized 480 x 720), but not on my asus eeepad transformer. Anyone able to test this on another device? Any ideas what could be going on here?
[attachment deleted by admin]
My current Showscreen function:
getscreensize xres,yres
FUNCTION sc:
LOCAL x,y,xz,yz,z
VIEWPORT 0,0,0,0
USESCREEN -1
xz=xres/1024;yz=yres/640 //scales with aspect ratio
z=MIN(xz,yz)
INC alfa,dalfa //autofade! Just set alfa&dalfa as global
IF alfa>-0.01 //alfa=-0.01 dalfa=-0.01 for fade IN
alfa=-0.01;dalfa=0 //alfa=-1 dalfa=0.01 for fade OUT
ENDIF // dalfa is the speed
IF alfa<-1
alfa=-1;dalfa=0
ENDIF
ALPHAMODE alfa
x=(xres-(1024*z))/2
y=(yres-(640*z))/2
// STRETCHSPRITE 100,x,y,1024*z,640*z //it didnt work on my Android tablet
STARTPOLY 100,0 //and they said this is faster!
POLYVECTOR x,y,0,0,RGB(255,255,255)
POLYVECTOR x,y+(640*z),0,640,RGB(255,255,255)
POLYVECTOR x+(1024*z),y+(640*z),1024,640,RGB(255,255,255)
POLYVECTOR x+(1024*z),y,1024,0,RGB(255,255,255)
ENDPOLY
IF MOUSEAXIS(4)=1 THEN ShowZones()
IF KEY(31) //press S for a screenshoot
SAVEBMP RND(9999)+".png"
END
ENDIF
SHOWSCREEN
VIEWPORT 0,0,0,0
ALPHAMODE -1
USESCREEN 1
SETTRANSPARENCY RGB(0,0,0)
DRAWRECT 0,0,1024,640,RGB(0,0,0) // will draw black colour _AND_ transparent alpha
SETTRANSPARENCY RGB(255,128,0)
VIEWPORT 0,0,0,0
ENDFUNCTION
IF KEY(1)
END
ENDIF
you dont need that, just put
ALLOWSCAPE TRUE
and ESC key will quit
And your program... it should work. Perhaps is the same error I got with stretchsprite, fixed when I changed to polyvector.
Also try to define at hand screen values. Instead of getscreensize x,y just x=320 y=480
also I got sometime ago a someking of bug using GENSPRITE and just do it the other way: spscreen=1
Hm.. well I've gotten your code working again under windows, but it won't work on my device..! :noggin:
After reviewing the glbasic docs for CREATESCREEN I see this note:
QuoteGLBasic uses the OpenGL extension GL_EXT_framebuffer_object for real OpenGL implementations. This extension can cause trouble on some (generally rather old) systems. In this instance, GLBasic will still provide the CREATESCREEN functionality however it may become slow and the screen size might be limited to the physical window size.
Use PLATFORMINFO$("GLEXT:glBindFramebufferEXT") to check whether your card supports the fast version - it will return 1 if it is supported.
When I check that platforminfo command, I see that my windows laptop returns TRUE, but my tablet returns FALSE :(
"it might be slow and limited to the physical window size"
[edit]
Just tried it out again with a CREATESCREEN command set to the physical window size, still won't show anything on my tablet.. seems like CREATESCREEN doesn't work at all..! bah
[/edit]
well then.... not too sure what I should do.. this is a brand new tablet sporting the latest version of the OS and everything, why would this extension be unsupported?
Are there any alternatives to scaling that don't use CREATESCREEN? I guess my only option is to actually scale all of the individual drawing commands I do, and keep drawing to the backbuffer.. hrm.. sounds like a pain but I guess not sure what else I can do.. I wonder if this is the norm for anyone else?
ignore that extension check. It's not an extension for mobile devices anymore.
Android, right? CREATESCREEN should really work. Just use it without the check.
Oh ok so the extension thing is irrelevant, well then I'm really not sure why this won't work on my device.
I attached my current example code I'm playing around with. It basically calls CREATESCREEN 1 and USESCREEN 1 to work with a virtual screen buffer, and draws a rectangle the size of the original resolution (320x480) to this buffer, and then uses POLYVECTOR to draw this virtual buffer to the back buffer.
I even tried doing a DRAWSPRITE after, which of course simply draws the un-scaled rectangle. Then did a PRINT and a RECT for good measure.
On my laptop it works fine, you see the scaled source rectangle filling the whole window, along with the DRAWSPRITE'd smaller rectangle on top, and finally the word "TESTING" printed in the corner, along with a little rectangle I draw with RECT.
On my android device, all I see are the PRINT and the RECT. Trying to draw the sprite I created with CREATESCREEN seems to not really be doing anything.
Is there anything I'm doing wrong in the code? It's basically what ampos provided, updated with some globals instead of hard-coded numbers.
[attachment deleted by admin]
QuoteAre there any alternatives to scaling that don't use CREATESCREEN?
Yes. I mentioned scaling routine code I posted a while back earlier in this thread (http://www.glbasic.com/forum/index.php?topic=6415.0 (http://www.glbasic.com/forum/index.php?topic=6415.0)). But it's not as hard as you believe. The routine automatically scales all pngs if a graphic versions flag has changed and the screen size is different to the intended. It uses sprite2mem so you retain all the different levels of transparency (unlike grabsprite which will only get one really). My latest version ignores 3D images (prefix with 3D) as these don't really need to be resized, and has a progress bar. Once it loads the graphics the first time then as long as the graphics version flag doesn't change it will use the resized graphics from then on. No slowdown with scaling methods like createscreen as you are just drawing sprites like you normally would. When it comes to the mouse just change the routine like I show in the example so that X and Y are correct to the target resolution. Then whenever you draw a sprite (and if you have a routine like the 3D ES system then can all be done for you) just remember to multiple by the ratio. So 100*x,100*y instead of 100,100. That's about it really. Couple of things to look out for but is pretty simple. Plus it has another advantage of using up a lot less memory because the images are resized.
Saying all that, if I could get the new 3D code Gernot put into the ES system to work to allow 3D objects on the screen in a 2D position, then I could replace 2D images with 3D ones (ie. make a plain rather than a cube), but it doesn't seem to work for me. Plus it would really need to be able to allow an object to be not effected by lights. Would totally work then and no resizing would be required unless you wanted to save memory really. Gernot?
Cheers
Made some changes and now it works fine on my Android (800x480)
GLOBAL ScreenWidth = 320, ScreenHeight = 480 // Our "standard" resolution we are scaling up from
GLOBAL xres, yres
GETSCREENSIZE xres,yres
GLOBAL spScreen = 100
//CREATESCREEN 1, spScreen, ScreenWidth, ScreenHeight
ALLOWESCAPE TRUE
CREATESCREEN 1, spScreen, xres, yres
USESCREEN 1
WHILE TRUE
GOSUB Render
WEND
SUB Render:
DRAWRECT 0,0,320,480,RGB(255,0,0)
PRINT "BIG TEXT",50,50
// DRAWRECT 0, 0, ScreenWidth, ScreenHeight, RGB(255, 0, 0)
// DRAWRECT 1, 1, ScreenWidth - 2, ScreenHeight - 2, RGB(0, 0, 255)
sc()
ENDSUB
FUNCTION sc: //call sc() instead of showscreen
LOCAL xz,yz,x,y,z
VIEWPORT 0,0,0,0
USESCREEN -1;ALPHAMODE -1
xz=xres/ScreenWidth;yz=yres/ScreenHeight // defined elsewhere as GLOBAL ScreenWidth = 320, ScreenHeight = 480
z=MIN(xz,yz)
x=(xres-(ScreenWidth*z))/2
y=(yres-(ScreenHeight*z))/2
STARTPOLY 100,0 //and they said this is faster!
POLYVECTOR x,y,0,0,RGB(255,255,255)
POLYVECTOR x,y+(ScreenHeight*z),0,ScreenHeight,RGB(255,255,255)
POLYVECTOR x+(ScreenWidth*z),y+(ScreenHeight*z),ScreenWidth,ScreenHeight,RGB(255,255,255)
POLYVECTOR x+(ScreenWidth*z),y,ScreenWidth,0,RGB(255,255,255)
ENDPOLY
PRINT "SMALL TEXT",0,0
//PRINT PLATFORMINFO$("GLEXT:glBindFramebufferEXT"), 100, 100
SHOWSCREEN
VIEWPORT 0,0,0,0
ALPHAMODE -1
USESCREEN 1
SETTRANSPARENCY RGB(0,0,0)
DRAWRECT 0,0,ScreenWidth,ScreenHeight,RGB(0,0,0) // will draw black colour _AND_ transparent alpha
SETTRANSPARENCY RGB(255,128,0)
ENDFUNCTION
Crivens, do you have a link to the routine you are referring to? I just did a search for posts by your username and couldn't find it..
ampos, yeah that code works fine on my computer as well, but still doesn't show anything on my android :/ just the "SMALL TEXT" PRINT output to the backbuffer, nothing to the virtual screen shows up. Not sure why, pretty frustrating though..!
This tablet seems to be kinda buggy though, maybe it's something to do with the new TEGRA 2 processor it has, or the drivers for it or something.. For example the little time trial nag thing that shows up only shows a white rectangle with a little time bar under it, no actual log inside the rectangle.. some apps I've downloaded just crash, etc.. I may end up returning it and trying with another one.. Ideally my game code would work on all android devices though of course..!
This code I sent you works on my tablet Coby Kyros 7024 2.2 as in Windows.
I changed the project settings Android screen size from your 9999x9999 to 2000x2000. Try setting up your real device resolution...
Quotedo you have a link to the routine you are referring to
Look at my last post again. I modified it: http://www.glbasic.com/forum/index.php?topic=6415.0 (http://www.glbasic.com/forum/index.php?topic=6415.0)I do have a newer version (avoids 3D graphics and has a progress bar) but I'm away for a week in Dubai so can't post yet.
Quotebut still doesn't show anything on my android
I had problems with my Android 800x480 tablet until I upgraded to 2.3. Works much better then. Saying that I have had createscreen problems on certain devices. Mainly older ones. My main development laptop (bleeding edge back about 5 years ago and still not bad) just doesn't do it at all for example (old ATI 9600 Turbo Pro card). It's the main reason I went with alternative routines.
QuoteIdeally my game code would work on all android devices though of course
Yeah, don't take that to the grave or anything. I've found Android devices are a bit of a mixed bag. They are the most similar to PCs really. In a bad way. There are so many different types that you just can't get something working on everything. Anything before 2.2 for example and you are stuffed. My wife's Wildfire just shows everything in white. My Android tablet shows everything upside down...
Cheers
Quote from: ampos on 2011-Sep-15
This code I sent you works on my tablet Coby Kyros 7024 2.2 as in Windows.
I changed the project settings Android screen size from your 9999x9999 to 2000x2000. Try setting up your real device resolution...
Yeah everything is working fine in windows.. but unfortunately not on this asus transformer tablet :/ I tried changing the project resolution to 800x1280, but it does the same thing.. I think the resolution is being set up fine, as I can see the drawing commands I'm doing to the backbuffer and they seem to be in native (tiny) resolution. It's just the CREATESCREEN part that I think isn't working on this particular device.
It's running Android 3.2, which AFAIK is the latest version of android.
Crivens thanks for the link! I'll start setting up some sort of demo project to see if I can get this implementation working I guess.. I'd be interested in seeing your newer code if you get a chance to post it when you return from your trip.
Thanks again everyone, this is proving frustrating but your suggestions are all very appreciated!
No worries. That code should be a full demo project. Good luck with it all!
Cheers
Quote from: Falstaff on 2011-Sep-15
Quote from: ampos on 2011-Sep-15
This code I sent you works on my tablet Coby Kyros 7024 2.2 as in Windows.
I changed the project settings Android screen size from your 9999x9999 to 2000x2000. Try setting up your real device resolution...
Yeah everything is working fine in windows.. but unfortunately not on this asus transformer tablet :/ I tried changing the project resolution to 800x1280, but it does the same thing.. I think the resolution is being set up fine, as I can see the drawing commands I'm doing to the backbuffer and they seem to be in native (tiny) resolution. It's just the CREATESCREEN part that I think isn't working on this particular device
I used the sc() function for scaling in my project and I've just got a 1 star review saying that on a Asus Transformer no graphics are displayed. Does anyone know how to get around this or if there is a possible fix while still being able to scale the graphics easily up or down?
Yeah I'm just about to re-examine how I do scaling in my game as I sorta put it aside for a bit to focus on other aspects in my game. I don't have my Transformer anymore so I can't do direct testing, but I remember seeing another forum member posting about having one and noticing similar issues..
That being said, Crivens' method he outlines in his post here: http://www.glbasic.com/forum/index.php?topic=6415.0 might be my next attempted implementation. AFAIK it'll run on first run of your app, and loads each image and scales it to the specific resolution of the device, then saves it back to the device. From there on out you just load those custom tailored images and draw them using regular drawing commands. This does of course mean you have to account for the scaling in each line of code you have that deals w/ rendering/collisions, etc (which you haven't had to with your method)
Alternatively, I noticed that the STRETCHSPRITE command worked on the Transformer - so you could use that to scale each image on-the-fly. Of course Crivens' method would be faster than that, but it's another option..
I just wish we could somehow get CREATESCREEN fixed on that device - I don't know if it's a driver issue or a GLB issue, but yeah it sucks in any case, which leaves us with these workarounds.
I hope it's a easy fixable problem in the createscreen command rather than something that is hit and miss across devices because that would kind of put a dampener on things. It seemed like such a good way of supporting lots of screen sizes with the minimum of fuss. :(
Well what do you know, there may be hope yet (http://www.glbasic.com/forum/index.php?topic=6998.28)!
Quote from: ampos on 2011-Sep-06
My Android tablet 2.3 fails miserably on grabsprite/mem2sprite, and Gernot says it is a driver issue...
Same problem here, GRABSPRITE not working on android tablet archos 101G9.
Dear Administrator, i'm facing a strange problem with my android tablet:
i use LOADSPRITE (bmp and png), STRETCHSPRITE, GRABSPRITE.
After some tests, GRABSPRITE works on the local win7 compilation, on the Android emulator, but not on the device (Archos 101G9). What's up Doc'? (driver issue?)
The program: one set of a game keeps displaying the same few sprites over and over, and each set has its own sprite size, to maximize screen space usage.
My strategy to spare some repeated stretchings by creating some "pre-fetched" sprites to the right size:
LOADSPRITE "name.png", 10 // about twice too big
// SETORIENTATION 0
STRETCHSPRITE 10, 0,0, newsize, newsize //correct size, smaller. Printed on backbuffer
GRABSPRITE 10, 0,0, newsize, newsize // or assign a new SpriteNumber, same result (sob)
//inside the drawing function
DRAWSPRITE 10, poz_x, poz_y // always working
//even later
SHOWSCREEN i tried various "setorientation values" to no avail, as well as setting android:resizable="true" in AndroidManifest.xml. I also tried to replace the coordinates 0,0 with 2,2 for stretchsprite and grabsprite, without result.
However, using only some repeated STRETCHSPRITE 's does work (but CPU consumming, not elegant).
Any idea anyone?
PS the rest works well now. i do a fresh win7 boot, connect the tablet or open the simulator, open a console and type "adb devices" or "adb usb", start GLbasic as administrator, then the automatic installation on the device/emulator does work from the IDE compilation for android. Nice job Gernot! :nw: =D
Tha main problem should be the resize of the background since it should be easy to resize sprites
Tiling a sprite can be done very quickly using POLYVECTOR as long as the graphics size is a power of two. There are a few commands that dont work with and some that are dependant on having decent drivers