CompuServe Messages

/* – 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. 🙂