PNG is compressed, it's just not `lossy` compression, so it is possible it looks better than a larger jpeg.
On my old ibook which had a totally minimal gfx card ATI Mobility thing, it reported max texture size of 4096x4096 for OpenGL. Then on my much newer iMac with GeForce4, it says 2048x2048. The ibook had a software GL driver, no hardware acceleration, which is probably why it had larger texture sizes, and why in some cases it actually supports more features than the newer iMac (aux buffers, etc)
I have no idea what happens when you try to upload a texture that is larger than the available size. Blitz would first be allocating texture space because, if I remember, it creates an empty texture first then uploads the image to it, so if it can only do 512x512 and you try to make a 1024x1024 texture I have no idea what it would do. I don't know if Blitz splits it up for you or if it would just fail, or whether the image gets cropped to the size of the texture, or whether it just looks like junk due to the rows being a mismatched number of bytes, etc. IT's probably unpredictable the effect you will see when there is a mismatch of size so generally you should avoid it ever happening.
Also of note standard OpenGL has square textures only, from 64x64 upwards. Rectangular textures are not supported without extensions or a higher GL version than the standard 1.2
Local SizeVariable:Int
glGetEnv(GL_MAX_TEXTURE_SIZE,Varptr(SizeVariable))
or something very close to that, is how you get the max texture size for OpenGL. It will just return one number, e.g. 2048, meaning 2048x2048, due to square textures.
Here's what I would do (and am doing):
Think of images (which are textures) as just a blank buffer space that comes in chunks of whatever the maximum texture size is e.g. 256x256. Think of it as similar to like a file read buffer or an array that you predefine as a certain size that you add extra size to [..newsize] when it is full. So the amount of space you have in that chunk of video ram is maxtexsize*maxtexsize. I would avoid rectangular textures unless you're requiring your customers and their customers to have higher versions of GL which are less common.
Then think of the `images` that you want to throw onto the screen, not as BlitzMax `Image`s, but as a custom image type which may be a collage of 1..N BlitzMax images. So say your maximum texture size is 256, and you want to upload a 1024x1024 picture, you will need (1024/256=4)*(1024/256=4) = 4*4=16 BlitzMax images at 256x256 each. So your custom image type will have an array of 16 Images, based on the fact that the texture size is smaller than the picture size. If the picture size was <=256x256 you would only need one Image to be referenced. So think of that array of Images as an array of fixed-size buffers, needing several to make up the whole image.
Then when you need to draw this large image, you position, rotate, scale, and draw each of the individual BlitzMax images that it is composed of, like a grid. You can use the image Handle as an offset from the center of the whole large picture, so that any rotation will be relative to the center of the whole thing. Also if you scale, you'll have to scale that Handle offset or you'll get gaps. It's also a good idea to use at least Floats for all the coordinates so you get sub-pixel accuracy.
So then any operation you do on the whole image you apply to each sub-image (BlitzMax Image) individually, acting as a group.
This way no matter what the maximum texture size is, you will never have a problem with it because you will compose your graphics using `pieces` that are as large as possible on that platform. You should always use the largest size textures that are allowed so you don't have do too many switches between textures (like a context switch) which is time-consuming overhead.
Then you should also think of each BlitzMax image as being able to comprise multiple sub-images or areas of that image. I call these sub-textures. Thus any given `picture` can be using an Image which other `pictures` are using as well. Like 50 frames of `bullets` or something, all can be on one BlitzMax Image, and each bullet `picture` refers to that same Image/texture, but to a different sub-image within that. Then you'd use drawing of a Rect Image to draw only portions of that Image for each picture. If you can keep animation frames within the same BlitzMax image that also is more efficient and cuts down on swapping between images.
This is the system that I'm using in my blob game. It then doesn't matter whatsoever what the maximum texture size is because images have been abstracted as a custom type referring to images as just resources. I plan to put multiple 512x512 textures onto a single 2048x2048 texture to get 16 frames of animation with no swapping between textures - using sub-textures for each frame, while with the same system will be using animations of small particles as subtextures either as a `spare part` of a larger texture or just as a smaller texture.
This then leads to whether you'd want to consider `sorting` pictures and `optimizing` them to make the most use of available free sub-texture space as possible, or to rearrange them on the texture to waste as little space as possible. It's then useful to be able to download/save an image comprising multiple sub images, as like a sprite sheet, and vice versa loading a sprite sheet and turning into a single image or part of an image or broken across a few images with a `sub-texture` for each sprite.
Of course, this is somewhat more complicated internally than the easier method of just going with what texture size is popular and hoping it doesn't break etc.