Polyvector confusion :(

Previous topic - Next topic

MrTAToad

#15
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


Cliff3D

#16
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:

Code (glbasic) Select
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/resources


to 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 :)

MrTAToad

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...

Kitty Hello

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.

Cliff3D

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 :)