Jump to content
IGNORED

TIP Animator


Recommended Posts

@w1k: Nice animation ! I also started with such flickery animations. Use tip-animator 2xb (double buffering) for less/no flicker; which palette do you use ? Don`t use the "default" palette, since this one is really bad. You can also lower the resolution of the frames (e.g. with Xnview, Irfanview and others) and then use a black border around each frame (so you have 160x100 pixels resolution again)...

 

that was first try, now i trying different pallete, bright, etc :)

Link to comment
Share on other sites

Hello,

 

@Sikor: Where did you find "Bambi meets Godzilla" ?!? I am asking because I have a very old Movie-Maker animation of this in my collection (works on 48k and/or 64k Ataris) - see attachment... ;-)

 

 

Somewhere on internet.

Yes, moviemaker version is good, but not original ;P

Link to comment
Share on other sites

  • 3 weeks later...

Well,

 

1) load Tipconv.JAR, (with JAVA)

2) when loaded, click on "Image",

3) then click on "Resize",

4) finally click on / highlight "Fit"

 

and the full picture will be used.

 

Guess you have used "Crop to fit" or it was chosen automatically (could be the standard config. which you did not change, maybe). But, on the other hand, a tip-picture can have 160x119 pixels (tip-converter allows that too), however tip-animator uses only 160x100 pixels so that could also be the case why your picture is cropped. Solution: Downsize your frames to 320x200 or 160x100 pixels, so that Tip-Converter will use max. 160x100 pixels for the tip-picture (and tip-animator will work fine then)...

 

Attached two new versions here, one created with tip-animator v2.9 and one created with tip-animator 2xb (double-buffer, thus less flicker). Both creations work on 128k Ataris and since the earth moon is not so colourfull, they are greyscale only...

-Andreas Koch.

fullmoon.zip

Edited by CharlieChaplin
Link to comment
Share on other sites

  • 4 weeks later...
  • 1 year later...

I tried the animated bug about 3 years ago and never got a nice animation. Today I tried again and came up with this.

Bugbitz.xex

Attaching the zip file with all the tip files and batch file I used for creation. I used version 29 for the tip to animation.

bugbits.zip

 

Reminds me of the old Mimo Avatar.

Edit: requires 130XE..

Edited by rdea6
Link to comment
Share on other sites

And err,

 

here is the "Bugbitz" version for 64k computers. Note: The tip pictures/frames use 160x119 pixels resolution, tip-animator however allows max. 160x100 pixels resolution, thus the animation is a little bit cut-off at the bottom (not my fault). @rdea6: Maybe you can downsize your source pics/frames (PNG, JPG, BMP or whatever) to 160x100 pixels and then convert them into tip pics/frames ?!?

 

Attached also another animation, one of the intros of the Bugs Bunny Show. Source was an old VHS video tape which had been uploaded to youtube, in other words: the source was not very good to begin with, so the result on the A8 could not be any better. The animation (or short video-clip) requires 576k RAM and is available as unpacked *.XEX file for emulator users and as packed *.XEX file on an ATR image for floppy-disk users (uses PAL config with OlivierP palette)...

 

-Andreas Koch.

 

bugbitz_64k.zip

bbshow1_576k.zip

Link to comment
Share on other sites

Alright,

 

here is a 64k version of the new Bugbitz version (with white background)...

 

@rdea6: creating 64k animations is relatively easy:

- if you have Windows XP go to the command prompt (C:, Windows, System32, cmd.exe; hopefully it is still there in Win7 and Win8) and now you see a screen similar to MS DOS

- enter the subdir of Tip Animator (e.g. cd tip animator)

- assuming you have already converted all frames into TIP, you can now start the Tip Animator 2.9, e.g. with tipanm29 1 30 max [Enter]

- the tip animator will create a tipanm.xex file for 128k computers, but it will also display some info, like:

tipanm onedic+exo dic$0400 prg$xxxx delay8

- the displayed information is nescessary to create a 64k animation, so do it like this:

tipanm29 (start tip-animator 2.9) 1 30 (your 30 frames) onedic+exo dic$0700 (+0300) prg$xxxx (+0300) delay8

- onedic+exo will create one dictionary and pack the file with exomizer so it works on 64k machines; don`t use $0400 for the dictionary, since this memory adress is too low for real Ataris, use a minimum of $0700 and when doing so use prg$ a little higher, e.g. when prg$ originally was $1A7F, then use dic$0700 (+0300) and prg$1D7F (also +0300)

- tip animator will now create a new tipanm.xex file that is packed with Exomizer and works with 64k machines; in case this does not work you will get an error message...

 

Greetings, Andreas Koch.

 

bugbitz2_64k.xex

  • Like 1
Link to comment
Share on other sites

  • 3 weeks later...

Well,

 

here are some more tip animations I did recently...

 

- Balls: could be named Balls and Boobies, a funny animated GIF

 

- Beavis2: another Beavis and Buthead animation

 

- Colzoom: an animation with endless loop (named Zoom, but since we already have a 576k ani with such a name I renamed it to colour-zoom)

 

- Face Morph: an animation with morphing faces

 

- Sparkles: a great looking firework

 

- Waterslide girl: what the name says...

 

- Girldog: a small animation (originally 8 frames), where a girl morphs into a dog

 

All animations were created with OlivierP palette and 128k or 320k memory requirements.

-Andreas Koch.

 

beavis2_128k.zip

balls320k.zip

colzoom_128k.zip

face_morph_320k.zip

sparkles_128k.zip

watslide_girl_320k.zip

girldog_128k.zip

  • Like 1
Link to comment
Share on other sites

  • 6 months later...

Hi there,

 

Charlie Chaplin sent me a bunch an TIP animation a while ago (Dec. 2012, huh,... )and mentioned some of them showed garbage during the first iteration of the animation for some unknown reason. Today I found his mail on my todolist (yes, it's looooog) and had a look. The reason for the garbage is that the bank counter variable is not initialized explictly before the animation starts. Due to some memory copying that takes place before this, the value of $8d may or may not be zero at the start (depending on the individual animation). Once the animation reaches the first data in the 2nd bank, the value is updated and everything is fine after this.

 

So maybe tebe can add "mva #0 bank" to the begin of "tipanm_engine.asm" to fix this.

 

Because hardly anybody would re-encode the existing animations (well maybe except Andreas with his endless passion and patience;-) ), here also a small fix for the existing ones:

- Copy the .xex file

- Append the following bytes to the and of the file using a hex editor or your favourite DOS: $8d $00 $8d $00 $00.

 

This works for the version the I've seen. Older versions might have a different value then $8d for the bank counter.

Edited by JAC!
  • Like 1
Link to comment
Share on other sites

Hello Peter,

 

thanks for the information and making available a fix for this bug (when I asked TeBe he could not find/see the bug I mentioned). The mentioned bug happens with all tip animations created with tip animator 2xB (double-buffer version). Think I have hundreds of files that were created with version 2xB and thus, I do not have the motivation to fix/patch them all. But hopefully TeBe can add your fix to tip-animator 2xB and then release an update of it, so that future animations created with 2xB will work correct.

 

Currently, if you start a tip-animation created with version 2xB, the animation will first show some garbage, the garbage more and more disappears and finally is gone when the animation re-starts. So all one has to do is load the ani and wait until it re-starts, then everything will be fine...

 

And now to something strange: If I load such an 2xB animation on my 576k 800XL with 512k SRAM upgrade by Bernd & mega-hz (and similar upgrades by tfhh, HiasSoft and others) the garbage will appear and it disappears when the animation re-starts. But when I load the same 2xB animation (can be any tip-animation created with 2xB) with my U1MB upgraded 800XL, the garbage is not there / does not appear at all, no clue why... so, it looks like the garbage-bug of version 2xB also depends on the kind of RAM expansion you are using... (For tip-animations the U1MB upgrade works better / shows no garbage with version 2xB when in 1MB mode, on the other hand some software, like e.g. Turbo-DOS, Bibo-DOS, X-Demo, etc. does not work with U1MB when in 576k or 1088k mode.)

 

-Andreas.

 

P.S.: Could you release a small COM/XEX file Peter, that contains the above mentioned data $8d $00 $8d $00 $00 ?!? I could try to use Superpacker/Exomizer by TeBe then to add this data to all my tip-animations that use version 2xB and take a look if it cures the bug (garbage) for all files. Since I am no programmer I do not know how to add some bytes with a hex-editor to existing A8 files...

Edited by CharlieChaplin
Link to comment
Share on other sites

TIP Animator autodetects the banks and if there are more/different banks the memory initialization and layout will vary. I'm fairly sure all garbage is in any case caused by the missing intialization.

 

As for the fix, I've attached the fixed file which you can simply put save in the "atari-lib" folder of the TIP animator. Maybe you can try if this works as you probably have the original TIPs (for example for HOMER).

tipanm_engine.asm

As for the existig anims. I have created a small batch file for (mass)fixing:

tipfix.zip

- Unzip it.

- Open the command shell and change to the "tipfix" directory.

- Put all broken files in the "tipfix/broken" directory

- Start "tipfix.bat" from the command shell.

- All fixed files are in the "tipfix/fixed" directory.

 

Best regards, Peter.

Edited by JAC!
  • Like 2
Link to comment
Share on other sites

Hello JAC!

 

I tried your (batchfile) fix and alas, it does not always work. Most animations seem to work fine after the fix (tried them only in the emulator yet), but there are a few ones, where the fix does not seem to work.

 

Attached you will find a few examples... maybe you can find out whats wrong there...

 

 

tip_anims_bugs.zip

Link to comment
Share on other sites

Hello JAC,

 

it`s 2:30 a.m. in the night here, everybody sleeps, while I re-worked some tip-animations again. In most cases I did not keep the unpacked file versions, so I simply had to do them again. Here they are, all of them fixed with your FIX#1 as mentioned above, alas, these animations still show some bugs at the beginning. Hopefully you can come up with another fix (Fix#2) that will remove this (these) bug(s)...

 

Greetings, Andreas.

 

 

tip_anims_bugs_unpak.zip

Link to comment
Share on other sites

The garbage in these cases is caused by the large INIADR segment at the begin of the file.


EXE: Loading program 023F-63DA to 1000-719B

EXE: Loading program 63DF-63E0 to 02E2-02E3

EXE: Jumping to 1000


Here the frame buffers at $9000/$a000/$b000 and $c000/$e000/$f000 are cleared.



7433:123: 71 | A=00 X=0E Y=19 ( I ) | 101E: 99 00 E2 L101E STA $E200,Y ;$E219

7433:123: 76 | A=00 X=0E Y=19 ( I ) | 1021: 99 00 F2 STA $F200,Y ;$F219

7433:123: 81 | A=00 X=0E Y=19 ( I ) | 1024: 99 00 C2 STA $C200,Y ;$C219

7433:123: 86 | A=00 X=0E Y=19 ( I ) | 1027: 99 00 92 STA $9200,Y ;$9219

Seems like then the first 1 or 2 (key) frames are unpacked there before the loading continues.

Unfortunately this first/second frame is not correct and ofter has pixels in areas that are not overwritten by the immediately following frames.



7453:120: 38 | A=00 X=BC Y=42 ( I ) | 11A2: 4C 7C 11 L11A2 JMP $117C

7453:120: 42 | A=00 X=BC Y=42 ( I ) | 117C: AD 8E 11 LDA $118E

7453:120: 47 | A=44 X=BC Y=42 ( I ) | 117F: CD A7 11 CMP $11A7

7453:120: 52 | A=44 X=BC Y=42 (N I ) | 1182: D0 06 BNE $118A

7453:120: 56 | A=44 X=BC Y=42 (N I ) | 118A: B0 19 L118A BCS $11A5

7453:120: 59 | A=44 X=BC Y=42 (N I ) | 118C: AD D5 44 LDA $44D5

7453:120: 63 | A=01 X=BC Y=42 ( I ) | 118F: 8D 19 92 STA $9219


This write access to $9219 is the topmost superflous pixel in the first frame, i.e. the first error.


If I explicitly insert clearing the buffers again before the program starts, almost all artifacts are gone.

But also some black pixels appear in the first few frames, because they are now also gone in the initial key frame of course.


Maybe this helps tebe to locate where the bug in the key frame depacking is.

cube5_laoo_128k-almost-fix.xex

Edited by JAC!
  • Like 2
Link to comment
Share on other sites

  • 5 weeks later...
  • 1 year later...
  • 1 month later...

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...