Jump to content

Recommended Posts

Ooops,

no uploads today ?!? We should change that, so here are:

- donald_sex 64k (has a small bug, otherwise its funny!)

- spaceship 320k (rotates and zooms)

- tits_64k (just funny, thats all!)

 

greetings, Andreas Koch.

Share this post


Link to post
Share on other sites

Hmm,

when using the exomizer to pack 64k animations, some garbage appears at the bottom of the screen - is there a way to avoid this ?!? Or is the only solution to switch off the screen completely ?!? -Andreas Koch.

Share this post


Link to post
Share on other sites

this garbage is:

; -------------------------------------------------------------------
; this 156 byte table area may be relocated. It may also be clobbered
; by other data between decrunches.
; -------------------------------------------------------------------
exod_tabl_bi = $BF60		; EXOD_DECRUNCH_TABLE (156 bytes)
exod_tabl_lo = exod_tabl_bi + 52
exod_tabl_hi = exod_tabl_bi + 104

Share this post


Link to post
Share on other sites

@ TeBe:

And is there a way to relocate this "garbage" automatically to another (unused) memory area (not $BC00-$BFFF), so it does not appear on the screen (or place it at the end of loading, maybe as color-flicker, as with other packers, when they are depacking) ?!? I tried using a small title screen, which switches off the screen, except for one line that displays the title. This title screen is using page 6 ($0600-$0668) and is shown all the time while loading, alas it works only with some animations (like Juggler, Juggler 2, etc.) whereas some other animations (e.g. Puppy, etc. allthough they do not seem to use page 6) crash while loading with this title...

 

Besides, can you re-create or remake some of the older animations like Puppy and so forth with the new TIP animatior 2.7 ?!? In older versions the depacking was not visible in any way - and I recently downloaded some more of the animations to my real A8. Some older animations (e.g. created with V.2.3 and others) left the screen blank for more than 10 seconds, so one could think the computer has crashed...

 

Maybe the memory usage in TIP animator for 64k should be limited in such a way, that a) the animations will always work on real Ataris (e.g. $0a00-bbff, $c000-cfff, $d800-fffx minus the depacking routines) and b) there is enough space left for the RLE and Exomizer depacking routines (without showing garbage on the screen). If an animation does not fit in that given area, it must use XRAM...

 

Speaking about XRAM, the 256k upgrades are very popular in the US (where you replace 64k RAM by 256k RAM, thus gaining 64k base RAM and 192k XRAM; total memory = 256k RAM; types are Newell, Buchholz, S. Peterson and similar upgrades), maybe TIP animator could support these machines too and not only the next bigger 320k machines...

 

greetings, Andreas Koch.

Share this post


Link to post
Share on other sites

OK, played a little lately...

 

Small "comeback" to Diablo - this time two heroes' animations (no tits there? - check succubus! :D )

 

Also here's another anime animation and one called qlskull (130XE one, but i like it, too!).

 

Enjoy!

warrior1.zip

succubus.zip

anime3.zip

qlskull.zip

Edited by miker

Share this post


Link to post
Share on other sites

Hello folks,

at first I wanted to dedicate this animation to some C= guy... but who knows how bad he would have reacted...

So I just upload it here without dedication: troll 64k (used two different speed delays: $0009=faster and $0010=slower).

 

Greetings, Andreas Koch.

Share this post


Link to post
Share on other sites

@CharlieChaplin

 

I've noticed that some part of your animations can fit 64k if they were exomized. Yes, there is a bit of garbage on screen but you then can use the memory from $0400 do $bf60 (thus almost 47kB) for the animatation itself. The program also tells you when you can make the file exomized (and with which parameters), so you do not need to worry if it succeed or not.

 

Greetings!

 

miker

Edited by miker

Share this post


Link to post
Share on other sites
@CharlieChaplin

 

I've noticed that some part of your animations can fit 64k if they were exomized. Yes, there is a bit of garbage on screen but you then can use the memory from $0400 do $bf60 (thus almost 47kB) for the animatation itself. The program also tells you when you can make the file exomized (and with which parameters), so you do not need to worry if it succeed or not.

 

Greetings!

 

miker

 

 

Yes,

I know - but I don`t like the garbage on the screen. So I avoided the 64k exomizer-packed files for a while. But now I am using a screen-off utility in front of the animation (on the A8!). The garbage then does not show (the title screen is also gone, but exomizer files are 64k anyway), luckily the color-flicker which shows depacking is still there. Just as I wanted it to be...

 

Still I would like to see some older 64k animations re-done with version 2.6 or 2.7 (so you always see the color flicker while depacking and know for sure the computer has not crashed). And err, a support for 256k machines would be nice too...

 

Anyway, here is another small animation I made in the meanwhile: Skiing 64k. When I converted the PC pics to 160x119, I got TIP pics with 160x119, but some lower part of the pics was missing, so I converted all pics into 160x100 and now the TIP pics and the animation seem to be fine; its still strange, since TIP pics allow 160x119 - maybe the TIP animator does not ?!? Afaik, the same happened with my trampolin 128k animation...

 

-Andreas Koch.

Share this post


Link to post
Share on other sites

OK - it's good idea to support most mem-extensions. I've looked at Atari FAQ (here - yeah, the name that appears there looks familiar :) ) and i think it's best idea to get to know which extensions are most popular. Though are some "not-so-useful" ones (esp. those in section "C").

 

Meanwhile i've done some anims but the best is "ipod fattie" and i want to include it here. :)

fat_ipod.zip

Share this post


Link to post
Share on other sites

Well,

I have given "Natasha" another try - removed the background by painting it black and then created a shorter 128k animation. Since the animation was quite fast, I slowed it down... (now its too slow for most others, but I like it that way). For all those that want a faster animation, I have included the *.TIP files. Greetings, Andreas Koch.

 

P.S.: Painting the background black took some hours, so I will not give it another try for a lake and trees (as suggested by someone here)...

Share this post


Link to post
Share on other sites

Well, here are:

- Smut 64k (originally named "smutnalakad.gif")

- SSD 64k (abbreviation for Seven Segment Display)

 

I have included the *.TIP files, in case someone wants a different speed setting (or use the SSD frames in reversed order, as a kind of countdown)... -Andreas Koch.

Share this post


Link to post
Share on other sites
OK - it's good idea to support most mem-extensions. I've looked at Atari FAQ (here - yeah, the name that appears there looks familiar :) ) and i think it's best idea to get to know which extensions are most popular. Though are some "not-so-useful" ones (esp. those in section "C").

 

Meanwhile i've done some anims but the best is "ipod fattie" and i want to include it here. :)

 

ipod fattie for the win!

 

Stephen Anderson

Share this post


Link to post
Share on other sites

Well,

did some very time consuming work today (but even my wife helped me doing this)...

 

1) Converted the GIF animation "snowy_night.gif" which had 45 frames into TIP format and tried to create an animation, but TIPANM27 always responded with "error anm.dat is too long". Tried various settings, but the error always re-appeared...

 

2) After thinking about it (give it up - or re-paint the background), I decided to re-paint the background ! This had to be done for 45 frames... and err, the background originally used 4 blue lum. and "greyscale" (pixeled) snow. So I did set the background color to one blue tone and removed all snow pixels (45 times), luckily my wife likes drawing/painting on the PC and so she re-painted half of the frames for me...

 

3) When all re-painting was done, I converted the new 45 frames into TIP format and again tried to do the animation... but I got this not so nice notice "error anm.dat is too long". Were all the hours of work for nothing I asked myself ?!? Again, I thought about just giving up...

 

4) But luckily I had one more idea, I had 45 frames but some of them did not contain any movement or action (compared to the previous frame). Maybe if I remove them, the animation works...?!? Found seven frames that could be easily removed. Then I re-numbered the TIP files and tried to do the animation again... and err... well, its getting boring "error anm.dat is too long". Damn it !! What now ?!?

 

5) Thought about deleting everything, but then my wife said, hey why not remove the first three pictures, where the snowman is only standing still (and the snowgirl is not visible) ?!? Hmm, don`t think this will help much, but I will try it out, I said... I started the TIPANM27 once more and started the anim. creation at picture number four... and it worked !! Finally, we were both happy, all I had to do was to set the speed delay once more, but the whole thing was running !

(Thus, of the 45 frames I had removed the ten frames 1,2,3,9,11,13,15,18,31 and 36)

 

6) Thought the animation would require a minimum of 320k RAM or even more, but unbelievable, the final result was only 80kbytes long and works on a 128k Atari 8bit (or emulator)...

 

So, if you see this simple 128k animation, keep in mind that I had one day of trouble and hours of work with it. Hope you like it, allthough its not suitable for children (would not call it porn or x-rated, but still not suitable for children)...

 

-Andreas Koch.

 

P.S.: As always, sources included...

Share this post


Link to post
Share on other sites

@CharlieChaplin:

 

When "error anm.dat is too long" appears try increasing value after "v" parameter eg. v3, v4, ...., v9. It causes that more data will be stores in dic-s. Also adding h64 parameter comes handy (or h(actual_frame_height)).

Share this post


Link to post
Share on other sites
@CharlieChaplin:

 

When "error anm.dat is too long" appears try increasing value after "v" parameter eg. v3, v4, ...., v9. It causes that more data will be stores in dic-s. Also adding h64 parameter comes handy (or h(actual_frame_height)).

 

 

Thanks Miker !!

With that tip I could convert some animations that did not work before...

 

Anyway, here are:

- Trampolin 64k and 128k (just another try, not really better, but therefore I added a 64k version)

- Boo! 64k (just funny)

- Family Guy 64k (It`s peanut butter jelly time ! This is also the unreadable yellow text at the bottom)

 

Greetings, Andreas Koch.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

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...