just because they can view the images in paint/another program doesn't mean the image isn't suspect in some way as far as dbpro vs a user's system is concerned (see below).
Quote: "Some videocard doesn't support big image files"
and some don't support the full gamut of dimensions (ie,
power of 2, etc)
as only you know what's being done under the hood, is there anything special about the list of images being reported?
and, the user with malevolence installed on 2 separate computers has provided you with
both images for your scrutiny? has he/she copied the "working" image to the other system and re-tested? installer corruption might be in play here, as well?
and, updating drivers has been (strongly) suggested since the beginning for reasons just like this. we've all had games (i know i've had my share in the past couple decades, atleast) that had anomolies or issues that went away when drivers were updated. that's standard practice that i don't believe warrants "more questions". (out of curiosity, what would some of those questions be?)
one thing comes to mind while reading through the above which is that dbpro has a (not so) funny way of reading images. i recall an update when dbpro started loading images without regard for the filetype extension while, instead,
deciding for itself how to go about it.
run this (it shouldn't but it will):
cls rgb(255,0,0)
get image 1,0,0,64,64,1
save image "test.png",1
delete image 1
load image "test",1 `note the lack of file extension
load image "test.png",2
load image "test.bmp",3 `and the incorrect file extention
cls rgb(0,0,0)
do
set cursor 0,0
print image width(1)
print image width(2)
print image width(3)
for x = 1 to 3
paste image x,x*64,64
center text (x*64)+32,88,str$(x)
next x
loop
add the
,1 texture flag when loading images 1 or 3 (that don't exist) and you'll get your error (and, note that it will add the final "divide texture"
,0 in reporting...)
...it may or may not have anything to do with your issue, but it might.
seeing how you're using a variety of image types and knowing the photoshop/etc have different ways of saving each filetype, and seeing how dbpro has the
funtionality displayed in the code above, and you might have someplace to start your search.
batch converting all your images to a single "standard" filetype (and, of course, replacing references in code) to ensure proper handling and consistency throughout is also something to consider.
looking through the
update history might be a place to look, as well, as you'll see image handling begins to change (starting with update 6.0, mostly, where D3D formats are being mentioned).
while i don't envy you, i do wish you happy hunting
Virtual Nomad @ California, USA . DBPro V7.7 . Matrix1Utils 05.27.12
AMD Phenom™ X4 9750 Quad-Core @ 2.4 GHz . 8 GB PC2-6400 RAM
ATI Radeon HD 3650 @ 512 MB . Vista Home Premium 64 Bit
