#SaveCel weirdness
6 messages in this thread
Hi Ed!
I just got off the phobne with Brian Rudolph… ran into some real weirdness
today, reproducible weirdness, and I thought I'd run it by you in case you've
seen this before.
In past POCO programming, I've LoadCel()ed and SaveCel()ed with no problems,
but most of the Cels were pretty small. For Larger images, I've always used the
OPTICS.H pragma with no problems (memory screen allocations and such) and done
all my manipulations in session. Well, my latest application needs Cels to go
out on the disk, so I decided to use
SaveCel("CELNAME.CEL");
as usual. No problem using 640x480x256 resolution. However, write up the
folliowing and create varying sized Cels and tell me what happens on your
system:
main() {
if (CelExists()) {
SaveCel("TRIAL.CEL");
} }
You should be able to save whatever Cel you've clipped with no problem. Now
here's the problem. Add the line LoadCel("TRIAL.CEL"); to it and run it a few
times with varying sized cels:
main() {
if (CelExists()) {
SaveCel("TRIAL.CEL");
LoadCel("TRIAL.CEL");
} }
The first time you run it with a given cel, you may get by, but the second
time, you'll probably get weird messages:
"File not found." when saving???
"Disk sector not found." when loading.
Brian has not seen this before, neither have I, but then it's my first time
I've had to send large Cels external. Like I said, I usually keep them in
memory for manipulation. Is this problem reproducible on your system, have you
seen this before, and are you aware of any fixes or workaround?
By the way, here's a gem I wrote last week when I discovered that (itoa) is not
available in POCO language… integer to ASCII. There's (atoi), but no
reversal. This works beautifully:
// ITOA.POC simulates the (itoa) function not available in POCO.
main() { // set itoa1 to whatever value you need translated
int itoa1=459;
char itoa2[80];
FILE *han1;
han1=fopen("itoa.tmp","w");
fprintf(han1,"%d",itoa1);
fclose(han1);
han1=fopen("itoa.tmp","r");
fgets(itoa2,80,han1);
// itoa2 is a stringvar with the (itoa)ed value. Tah Dah. Slick eh?
printf(itoa2);
fclose(han1);
Qtext("(itoa) of the integer complete!");
}
I'm about halfway done with my forum Christmas present. Just got an article off
to Barbara too. Are you writing any for next issue? -dave
<< … run it a few times with varying sized cels:
main() {
if (CelExists()) {
SaveCel("TRIAL.CEL");
LoadCel("TRIAL.CEL");
} }
>>
Looks like you've found another example of weird results associated with
cels.
Have these happened to you (As you noted some occur only with large cels).
– If after using "Element/Cel" in the optics menu you attempt to
re-enter Optics without a cel in the cel buffer, Animator will
abend.
– If you use "Cel/Release" you will be asked if you really want to
delete … A false warning. No file is deleted, only the copy in
memory is released.
– If while in the Animated Cel screen you load a cel and then delete
the file from the disk (using Cel/Browse/Delete), you will not be
able to continue using that cel, though still present on the
screen. You will not be able to save it either. It's gone forever!
(All that was visible was one frame of the cel)
– If that happens to you, make sure you don't need to use the Animated Cel
screen any
more because after leaving that screen you will not be allowed to
re-enter it during that session (unless …)
– Also, be prepared to be greeted with a mysterious "File not found
… name misspelled?" message the next time you start Animator.
Having developed programs under the pressure of deadlines, I think I
know the origin of these and other problems with cels. The following
is MY (unconfirned) theory.
Consider the following scenerio. A successor to the original animator
is being architected. Three items are at the top of the list:
1. Increasing the 320×200 resolution limit.
2. Capability to play high resolution animations at full speed
3. Animated (multi-frame) cels
The first item increases the amount of storage needed. Virtual memory
(disk) cannot be used because of the second item. Memory is the only
candidate.
The third item, animated-cels, requires capability to process two
animations simultaneouslty, potentially requiring additional
memory.
Someone mentions that the new "dos extenders" would make it possible
to remove the resolution limitation from Animator altogether, by
allowing applications to access more memory.
Reducing memory requirements becomes critical. No problem, says the
individual that probalbly also came up with the Swap disk concept for
3DS, cels do not have to be played at full speed and cel data can be
accessed from the hard disk as needed.
The approach however required "exception handling." A no-no in
software development. Cel files were not going to be handled like the
other files. Therefore the problems.
It's a theory anyway.
But do a test, time the time it takes to "load" a multi-meg
animation, both as a flic and as a cel. You'll see the difference.
Most of the cel remains on the disk, and takes no time to load.
You can see attempts at handling cels files differently here and
there. For example, notice that in the animated cel screen it is
possible to load, or save a cel, but there is no way to deleting a
cel.
Oris there? Proper handling of exceiptions is sure to be overlooked
by someone. The current cel can be deleted by first selecting
"Browse" in the "Cel" dropdown menu as mentioned before.
When you delete the current cel from the disk you simultaneously
delete it from memory (virtual memory, but memory none-the-less).
<it's my first time I've had to send large Cels> And only large cels
use the disk for virtual memory. Maybe the POCO implementation didn't
handle the exception correctly either.
<Is this problem reproducible on your system> Yes
<have you seen this before, and are you aware of any fixes or
workaround? > I think youd have to save the cel as a flic by first
pasting it on an empty flic.
<By the way, here's a gem I wrote last week when I discovered that
(itoa) is not available in POCO language… integer to ASCII. There's
(atoi), but no reversal. This works beautifully:>
Neat! Saved it with my other useful Poco programs.
< Just got an article off to Barbara too. Are you writing any for next
issue? >
I just couldn't find the time. It would have taken me away from a
really exciting job: writing sample code for the script extension
modules. I'll be uploading some animations soon.
What did you write about?
Ed K
/*
– If after using "Element/Cel" in the optics menu you attempt to
re-enter Optics without a cel in the cel buffer, Animator will
abend. */
Yup, had this happen numerous times.
/*
– If you use "Cel/Release" you will be asked if you really want to
delete … A false warning. No file is deleted, only the copy in
memory is released. */
This also results when you use the CelRelease() equivalent… problem must be
in core then.
/*
– If while in the Animated Cel screen you load a cel and then delete
the file from the disk (using Cel/Browse/Delete), you will not be
able to continue using that cel, though still present on the
screen. You will not be able to save it either. It's gone forever!
(All that was visible was one frame of the cel) */
Woh. No. I'll have to check that one out. Ouch!!!
/*
– Also, be prepared to be greeted with a mysterious "File not found
… name misspelled?" message the next time you start Animator. */
This one seems to show up frequently. 🙂
/* It's a theory anyway. */
It's a good one, Ed.I figured it was a memory allocation handling
error. I use malloc, calloc and other mem functions for allocating
blocks of memory for image manipulation and playback and realized
that several of the above problems went away as soon as the cel was
treated by screen definitions (SCREENvars) rather than using the
actual cel functions. IBROWSE (oops, wasn't supposed to let that one
out of the bag yet) creates cel/pic/flic thumbnails of any resolution
with no problems loading or saving since it uses OPTICS.H functions
and basically loads celdefs into **char(s) before loading and saving.
These functions always demand malloc/sizeof definitions based on
their uniques sizes. Guess what… no problems.
Most of the POCO functions seem to work independent of core, as
separate functions… which makes sense since POCO is described as a
"super macro language"… what's weird is that the actual Cel
Save/Load functions work fine regardless of size, yet through POCO we
get errors. The problem is definitely related to the size of the cel
too, guarenteed, which indicates it has to do with memory block being
used by LoadCel/SaveCel. Gotta be.
/* <have you seen this before, and are you aware of any fixes or workaround? >
I think youd have to save the cel as a flic by first pasting it on an empty
flic. */
This'll work if the original cel borders are saved as intvars for later
CelGet()s.
/* Neat! Saved it with my other useful Poco programs. */
And very practical when you want to report… uh… cel parameters to
the screen? 🙂 For example after SCREEN var has been defined and set
to a GetCelScreen(), GetScreenSize reports width and height in
intvars. If you wanted to post these using strcat functions into,
say, a dialogue prompt, no dice until the intvar is converted.
/* I just couldn't find the time. It would have taken me away from a really
exciting job: writing sample code for the script extension modules. I'll be
uploading some animations soon. What did you write about? */
Easy one… delta segregation. I'll be uploading BUBBLY.ZIP and
SAUCER.ZIP here shortly (two 320×200 equivs of 640×480 (save on
upload time)) which correspond with article's focus. Figured it was
time to do an article on the benefits of sprite/streaming and such to
create what look like very long animations but are actually
incredibly short… I even noticed an IPAS out there to do bubbles.
Imagine that when you can do it in Ani in about 5 minutes… thousands
of them if you want. Amazing what people will pay for when they don't
know how to use what they already have. 🙂
I'll post the article to you via MAIL. Please let me know if the
content seems clear in first draft form. Sometimes it gets very
lonely out here on Planet Animator… nice to see another indigenous
lifeform once in a while. 🙂
dave,
Both yours and Ed's messages have been saved and forwarded to the proper people
here at Autodesk.
-Brian
/* Both yours and Ed's messages have been saved and forwarded to the proper
people here at Autodesk. */
Thanks Brian. As you can imagine, this one's a really important one…
loading and saving Cels is essential to most AniPro uses… we don't
get problems using the pulldowns, but this is programming. Thanks.
dave,
I was able to reproduce most of the CEL load/save problems you encountered. See
my e-mail to you for more info.
-Brian