Chambahs - Mon Jan 15, 2007 6:38 pm
Post subject:
I would have thought 256 was enough..
Bak - Mon Jan 15, 2007 6:42 pm
Post subject:
Are you sure you have to define all your object ids in one file? i've never had any problems using more than one file, as long as your total number of images is less than 256.
Cerium - Tue Jan 16, 2007 5:03 am
Post subject:
@Bak:
You don't absolutely have to, but it certainly makes it easier to figure out how the images and objects will be defined and handled on the client end -- less likely to end up with bizzaro problems like mine. Plus, as he said, you can change stuff around without requiring a complete redownload.
@Chambahs:
256 isn't even close to enough to what I'd like to do. To complete this project exactly to the original specs I'd need (atleast) another 576 images.
Doc Flabby - Tue Jan 16, 2007 7:32 am
Post subject:
one thing you could do. Is combine say 4 images or as many as you want into one. Then use a black (or whatever colour your background is) lvz to cover the sections you dont want to see.
This solutions i can see being horrible to impliment however. I also have no idea if it would acctually work.
Samapico - Tue Jan 16, 2007 6:59 pm
Post subject:
I thought mapObjects definitions could only apply to files in the same lvz... cool.
Samapico - Wed Feb 07, 2007 8:48 pm
Post subject:
Hmm, quick question about these lvzs...
Is it possible to have Image Definitions (IMAGE#=...) in a lvz, and the mapobjects using that image definition in a different lvz?
Bak - Wed Feb 07, 2007 9:52 pm
Post subject:
no, why would you want to? the meat of the filesize is when you include the File= part.
Samapico - Wed Feb 07, 2007 10:17 pm
Post subject:
its not that i want to.. just wanted to figure out how to make dcme's interface for lvz's, and if it was technically possible to do that, it would have complicated things a bit...
Didn't think it was possible either, just wanted to make sure... stuff started to get confused in my head
thx
Samapico - Fri Feb 16, 2007 8:30 pm
Post subject:
Another thing I'm wondering right now...
What happens if you have, say, a IMAGE0 in one lvz, and a IMAGE0 in a different lvz? Does continuum confuses them? Or does continuum creates its own imageID's anyway? (as long as total of all imageID's isn't more than 256, of course)
Cyan~Fire - Fri Feb 16, 2007 8:50 pm
Post subject:
Continuum does confuses them, it's actually supposed to be a feature.
Samapico - Fri Feb 16, 2007 9:47 pm
Post subject:
gah.. I just re-re-re-read the lvz format...
the Image Definitions sections don't have an ID identifier... so emm... When they are loaded, they get ID's automatically from 0 to 255 within that lvz file? or... ô.o
If that is the case, I can't see how continuum would confuse them... well it would depend on the order in which lvz's are loaded, which makes no sense...
Is MGB's lvz toolkit source available somewhere? I'd like to see how that is done exactly... that or a clear explanation would do
Bak - Fri Feb 16, 2007 10:34 pm
Post subject:
Continuum doesn't confuse them. The numbering is unique to the lvz file, although a total of 255 total images in all lvz files is all that's allowed. If you create an lvz using IMAGE10 instead of IMAGE0, create the lvz file, then decompress the lvz file, it will be IMAGE0 in the ini file.
X-LvzToolkit comes with source if you want a look.
Samapico - Fri Feb 16, 2007 10:37 pm
Post subject:
ok... that now makes sense in my head
So I'm guessing when you build lvz with mgb's lvztoolkit, when you write like
IMAGE23=file.bmp
IMAGE27=anotherfile.bmp
and then
IMAGE23,x,y,blahblahblah
when saving the lvz object definitions, image23 is the first to be saved (id = 0), image 27 is saved next (id = 1), so when the mapobject using image23 is saved, the actual 'ImageID' that is stored would be '0' ?
Bak - Fri Feb 16, 2007 10:41 pm
Post subject:
correct
/**
* We need to map the encoded image num, to the actual one, since we don't get a choice when
* we're encoding the image objects
* @param encodeNum the encoded number in the ini file, that we'll transform into the correct one
* @return the correct byte we should use for the image num in our lvz file
*/
private static int getImageNum(int encodeNum)
{
int num = -1;
for (int x = 0; x < imageObjects.size();++x)
{
ImageObject io = (ImageObject)imageObjects.get(x);
if (io.num == encodeNum)
{
num = x;
break;
}
}
return num;
} |
Samapico - Fri Feb 16, 2007 10:52 pm
Post subject:
alright, thanks
<finishing up DCME's lvz>
Bak - Sat Feb 17, 2007 3:12 am
Post subject:
can't wait bro, DCME is amazing.
Cyan~Fire - Sun Feb 18, 2007 1:03 am
Post subject:
Ooh, my bad. Is it that a file included in one LVZ can be referenced in another? There's something like that.
Samapico - Sun Feb 18, 2007 1:01 pm
Post subject:
Files can be referenced by other lvz yes.
But not image definitions.
So you can define an image definition using a bitmap from a different lvz, but can't define a mapobject using an image definition from a different lvz