Polyvector confusion :(

[Cliff3D]

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:

Code (glbasic) Select Expand

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:

Code (glbasic) Select Expand

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?



Thanks

[attachment deleted by admin]

[Cliff3D]

For ease of viewing, the image I expected to see in that window shown above is the resized bitmap like this:

[MrTAToad]

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]

[monono]

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.

[Slydog]

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.

[MrTAToad]

With the proper graphic, I get :



[attachment deleted by admin]

[Bursar]

What graphics card do you have? Maybe it doesn't textures of that size?

[Cliff3D]

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

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

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

[Slydog]

When it doesn't work, does the following:

Code (glbasic) Select Expand

DEBUG spritewidth+"\n"
DEBUG spriteheight+"\n"
output 1024,1024, or 2048,2048?

[MrTAToad]

It's in the rar attached to the first post

Yes, I didn't see it until later...   

how much video RAM is available for sprites?

Would be nice, but I dont think there is anything platform independent to help...

[monono]

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.

[Slydog]

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.

[MrTAToad]

There was a routine to call OpenGL information commands (OPENGL & GFX CARD VERSION INFORMATION), but the included project was overwritten with  3D Analysis code

[Cliff3D]

When it doesn't work, does the following:

Code (glbasic) Select Expand

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

[Moru]

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.