Hi - I'm trying to resize a random bitmap loaded into Sprite 0 to a known size - in this isntance, for testing, I have chosen a 640 * 480 screen to resize to.
If I resize a 950 * 950 .png using this code:
LOCAL spritewidth, spriteheight
LOADSPRITE "P4 woman texture.png", 0 // load texture to use into sprite #0
GETSPRITESIZE 0, spritewidth, spriteheight
DEBUG spritewidth+"\n"
DEBUG spriteheight+"\n"
//Copy sprite #0 to screen and stretch to fit
STARTPOLY 0 // Bitmap = No.0
POLYVECTOR 0, 0, 0, 0, RGB(255, 255, 255) // top left
POLYVECTOR 0, 479, 0, spriteheight-1, RGB (255, 255, 255) // bottom left
POLYVECTOR 639, 479, spritewidth-1, spriteheight-1, RGB(255, 255, 255) // bottom right
POLYVECTOR 639, 0, spritewidth-1, 0, RGB( 255, 255, 255) // top right
ENDPOLY
SHOWSCREEN
MOUSEWAIT
It all looks good, looks like it fills the window nicely without becoming too large or remaining too small. Yet using much the same code on a 2048 * 2048 .bmp:
LOCAL spritewidth, spriteheight
LOADSPRITE "tCube.bmp", 0 // load texture to use into sprite #0
GETSPRITESIZE 0, spritewidth, spriteheight
DEBUG spritewidth+"\n"
DEBUG spriteheight+"\n"
//Copy sprite #0 to screen and stretch to fit
STARTPOLY 0 // Bitmap = No.0
POLYVECTOR 0, 0, 0, 0, RGB(255, 255, 255) // top left
POLYVECTOR 0, 479, 0, spriteheight-1, RGB (255, 255, 255) // bottom left
POLYVECTOR 639, 479, spritewidth-1, spriteheight-1, RGB(255, 255, 255) // bottom right
POLYVECTOR 639, 0, spritewidth-1, 0, RGB( 255, 255, 255) // top right
ENDPOLY
SHOWSCREEN
MOUSEWAIT
Does not seem to resize at all, and I only get part of the bitmap shown on-screen. Any ideas?
(http://i51.tinypic.com/scsxef.png)
Thanks :)
[attachment deleted by admin]
For ease of viewing, the image I expected to see in that window shown above is the resized bitmap like this:
(http://i52.tinypic.com/29gfj12.png)
As I didn;t have the original 2048 x 2048 graphic, I had to take the above + fill the rest with red, to get :
[attachment deleted by admin]
I tried with your rar bmp. Works fine for me. Pls recreate the bug with the code you posted or upload the project. Maybe there is a difference between your posted code and your actual one.
By looking at the photos provided, it looks like it *IS* scaling, but incorrectly.
It appears to be scaling a 1024x1024 section into a 640x480 window.
The portion of the image displayed is exactly 1/2 as high and 1/2 as wide as the original 2048x2048 source image.
Is the project setup to deploy to an iPhone, which limits it's textures to 1024x1024?
(I'm not sure if just setting the project to 'iPhone' limits the PC version while testing)
[EDIT]
Hmm, I guess the iPhone setting doesn't make sense because it is displaying in a 640x480 window.
May be some other kind of texture limit you're running into.
With the proper graphic, I get :
[attachment deleted by admin]
What graphics card do you have? Maybe it doesn't textures of that size?
Quote from: MrTAToad on 2010-Sep-13
As I didn;t have the original 2048 x 2048 graphic, I had to take the above + fill the rest with red, to get :
It's in the rar attached to the first post ;)
Quote from: monono on 2010-Sep-13
I tried with your rar bmp. Works fine for me. Pls recreate the bug with the code you posted or upload the project. Maybe there is a difference between your posted code and your actual one.
I actually copied the code from the project directly, there's not difference between the posted code and the actual code :(
Quote from: monono on 2010-Sep-13
I tried with your rar bmp. Works fine for me. Pls recreate the bug with the code you posted or upload the project. Maybe there is a difference between your posted code and your actual one.
ARGH, this looks like the best bet if the code looks right (and works for others)... let me try it on another PC...
UPDATE: Dagnabbit! Yes, it's the "graphics card memory" limitation that keeps throwing me, both on VirtualPC and on my netbook. As a 2048 X 2048 texture has worked under virtualPC I hadn't expected it to fail here... but it does. Is there any way, does anybody know, of ascertaining when a command has faile dlike that (apart from looking at it) or how much video RAM is available for sprites?
Thanks though! At least now I know it's my computers rather than me per se - and I'll have to installe GLBasic directly to a desktop PC if I want reliability out of it :(
When it doesn't work, does the following:
DEBUG spritewidth+"\n"
DEBUG spriteheight+"\n"
output 1024,1024, or 2048,2048?
QuoteIt's in the rar attached to the first post
Yes, I didn't see it until later... :P
Quotehow much video RAM is available for sprites?
Would be nice, but I dont think there is anything platform independent to help...
No facts, just thoughts,
If you want reliability go with 512X512. Even 1024x1024 is supported by most graphic cards. I guess over 95% of all ordinary desktop or notebook/netbook gfx. Maybe somebody has some numbers about that issue. I heard that even the newest directX is limited to 4096x4096. In high end game engines it is surely tested before loading. Maybe there is a way in GLB. To be sure, you could fake ur big texture using 4 1024th and draw them next to each other.
Yes, it would be nice to be able to know what the current platform can support.
But then, if you know it only supported 1024x1024 and you had a 2048x2048 bitmap, how would you load it?
The LOADSPRITE command would have to be updated to include source coordinates!!
Or updated to return more than one sprite, such as the LOADANIM command.
Or automatically scale the image to fit the max resolution.
Or just return an error if it's too wide.
There was a routine to call OpenGL information commands (OPENGL & GFX CARD VERSION INFORMATION), but the included project was overwritten with 3D Analysis code :(
Quote from: Slydog on 2010-Sep-13
When it doesn't work, does the following:
DEBUG spritewidth+"\n"
DEBUG spriteheight+"\n"
output 1024,1024, or 2048,2048?
DEBUG outputs the correct dimensions of the spirte/bitmaps :)
I'm feeling a bit squished here, in as much as this (and issues I'm having drawing to a sprite off-screen) are fairly central to my requirements.
This isn't what I'm doing, but imagine a game which makes a jigsaw of any - ANY - bitmap on your hard drive, then scrambles it and the "game" is for you to re-arrange it. The important part of that scenarios is that the program has to fit the graphics that it finds, rather than the game author (or associate/s) being able to tailor the graphics to the game. The program must, as a basic principle, be able to handle large and interesting graphic files. If I can't do that with GLBasic - even moving to my desktop PC (where I have now installed GLB) then I'm going to be stymied, quite convincingly :(
Why the jigsaw analogy? In part because what I want to do is a little more complex, so the jigsaw game sounded like an easier way of getting across that in this instance the random size and content of the graphics is "more important" than the program - the imagery is more important than BASIC code, the picture is "THE thing", but also because I don't only have one goal - I have a bunch of potential targets, and all of those which spring to mind will need to be able to load at least one image up to 4000 x 4000 as a texture for a 3D model. Most will likely need to be able to load and manage several images of about that size. Ah well - thanks for all the help so far, let me go and continue fighting with CREATESCREEN and USESCREEN :(
To handle that sort of images you need a grafics card that can handle 64 MB per image, your embedded grafics card might not be the best candidate for this.
Unfortunately graphics cards vary the maximum limit of graphics...
What you need to do is split the bitmap into acceptable blocks, which you stick on the fly or just display sections of it.
Something may be useful @ http://www.yaldex.com/games-programming/0672323699_ch08lev1sec12.html
Quote from: Moru on 2010-Sep-13
To handle that sort of images you need a grafics card that can handle 64 MB per image, your embedded grafics card might not be the best candidate for this.
Looks like I'll have to abandon my virtual pc, and possibly my netbook too. though my netbook has been darned handy for programming this stuff while out and about recently, so that would be a shame. Little netbook and little programming language seemed like a good combo ;)
Quote from: MrTAToad on 2010-Sep-13
What you need to do is split the bitmap into acceptable blocks, which you stick on the fly or just display sections of it.
That may be tricky when the image/texture/sprite is beign used as a texture on a 3D model, as is the case in my situation. I'm not at all sure how I'd go about tiling a series of images onto a 3d model :(
Fortunately, you guys have nudged me into abandoning my nice safe test environment of a virtual PC and installing GLBasic onto a desktop PC with a halfway decent video card. So I've now got this basic code:
LOCAL spritewidth, spriteheight,textureresolutionx%,textureresolutiony%
LOADSPRITE "tCube.bmp", 0 // load texture to use into sprite #0
GETSPRITESIZE 0, spritewidth, spriteheight
textureresolutionx%=512
textureresolutiony%=512
CREATESCREEN 0, 1, textureresolutionx%, textureresolutiony% // create temporary workscreen of desired resolution
USESCREEN 0
//Copy sprite #0 to screen and stretch to fit
STARTPOLY 0 // Bitmap = No.0
POLYVECTOR 0, 0, 0, 0, RGB(255, 255, 255) // top left
POLYVECTOR 0, textureresolutiony%-1, 0, spriteheight-1, RGB (255, 255, 255) // bottom left
POLYVECTOR textureresolutionx%-1, textureresolutiony%-1, spritewidth-1, spriteheight-1, RGB(255, 255, 255) // bottom right
POLYVECTOR textureresolutionx%-1, 0, spritewidth-1, 0, RGB( 255, 255, 255) // top right
ENDPOLY
USESCREEN -1 // switch back to main screen
LOADSPRITE "", 0 // empty sprite 0/release memory/resourcesto work and produce a texture that GLBasic will happily use as a texture on a 3D model, by forcing the bitmap to align with a power of 2 boundary. 4096 is the largest I've tried and it's working fine, so I'll probably tidy this away into a function somewhere to load and resize bitmaps into suitably-sized sprites for 3D, without hard-coding the sprite size as I have here.
I'm not entirely happy - the video card memory is obviously being relied on but that shouldn't HAVE to be the case ... it's a shortcut IMHO to not allow for purely memory-based graphic fiddling about, but one that I can probably live with while I continue to feel my way around. I'm worried about how limited the graphic space may be on some portables though, like the Pandora :(
Thanks :)
I've asked on the Pandora forum - I suspect it certainly wont be 4096x4096 :)
It will probably be a maximum of around 512x512, with smaller textures allowing more sprites/bitmaps...
1024x1024 can be relied on these days. 512x512 was a limitation of Voodoo II cards, which is sort of retro these days. Even the old iPhones can do 1024x1024.
Thanks chaps. By scaling down my expectations/aspirations I am managing to keep my netbook "in the game", I think - while being able to scale up the quality when on a desktop :)
Actually "writing off" the netbook for development would not be good :)