Jump to content
IGNORED

TIP Animator


Recommended Posts

Hello Shaun, guys

 

So they should just stop playing around with the TIP Animator and posting their work, because someone might not like them?

As MaPa already said, nobody is saying they should stop. But often, the guys posting an animation themselves tell us that the animation isn't that great. If THEY don't think it's that good, why should the rest of us look at it.

 

Greetings

 

Mathy

Link to comment
Share on other sites

No one said that.. but I think if they plays with TIP animator it should produce animations and not TIP slideshows ;) Honestly.. do you like "animation" ie. some flight combat scene posted here where you even can't recognize what is happening there? It's just my opinion.

 

I agree with you about some of the animations... the speed is a little too slow. I was speaking mainly "tongue in cheek", and I think partly it's a language issue. :)

 

To everyone creating animations, keep it up, especially if you are enjoying it!

Edited by Shawn Jefferson
Link to comment
Share on other sites

Alright now,

the criticism here got me thinking for a while (and as you can see I have removed all my attachments at AA). Anyways, after a week or so, here is what I think about it:

 

- complaints in general: this is an open forum (as long as you apply to the rules!) so anyone may upload/download any Atari related stuff here; if you don`t like it (e.g. if you don`t like the TIP animations) there is no need to download it - and if you realize you don`t like it, after you already downloaded it, just delete it !! Personally I think that animations (no matter if TIP or GIF or FLI or ...) are a matter of taste, just like movies or music or clothing, etc.

 

- slow animations / slideshows etc.: Well, I have been experimenting with TIP animator and posted all my results here, even the not so good / bad / extremly bad ones. Think I am writing some short article at atarionline.pl about TIP animator and which circumstances will give bad results or failures... since I also posted the sources here anyone could have tried to do it better (alas, except Miker no-one did)...

 

- flicker: this is basically a problem of the TIP animator and/or the Atari 8Bit (even GIF or FLI animations that do not have any flicker at all do sometimes produce flicker in TIP animator / on the A8), BUT of course most flickery animations were produced by the users (like me), because we a) had to reduce the frames to make the ani work (or to save memory space) or b) there were simply not enough frames in the original (GIF, FLI,...) animation available; there are folks out there which will notice flicker very fast and complain about it (even if its just one frame/picture) and folks which will not notice it so well (only if a big part of the ani or the whole ani has flicker). Of course I know, that Blue Lightning and many other of my animations do have flicker (and BL is extremely flickery) but I wanted to test out the limits of the program, regarding size, speed and other factors and err, well, think I found some of its limits (e.g. its no good idea to convert more than 1 minute long movies or game intros into A8 TIP animations even if you have 1MB XRAM available)...

 

- speed: Well, I tested most of the animations only on my PC and Atari 800 Winplus 4.x. Thinking of the past, when I had a 486 PC with 66Mhz, I remember that Atari 800 (DOS version) was running very slow there and most A8 programs reached only 33%-50% of original Atari speed (or they crashed). Well, nowadays we have faster PC`s, but I guess that in Atari 800 Win emulator the speed of the PC still matters. My PC is an older 1,8 Ghz AMD PC with 128MB gfx card, but if you use even slower PC`s with Atari 800 emulator, the emu will surely run slower and thus the TIP animation will also run slower. Of course, since I have not tested most of my ani`s on a real Atari I may sooner or later find out, that they run extremly slow on the A8 (I hope not, but it could be the case) and NTSC vs. PAL might be an issue too...

 

Enough said. You have the tool (TIP animator), you have seen how easy animations can be created - why don`t you join us and create some...?!? Currently we have approx. 200 TIP animations, but less than ten contributors... -Andreas Koch.

Edited by CharlieChaplin
Link to comment
Share on other sites

Alright now,

the criticism here got me thinking for a while (and as you can see I have removed all my attachments at AA). Anyways, after a week or so, here is what I think about it:

 

I'm sorry to hear you deleted all your attachments CharlieChaplin...

 

 

 

My post where I said "here's another not so great one" was a criticism of my self... It was, in no way, intended to reflect upon the work of others in this thread (which I gather it somewhat did)...

 

My Top 3 picks:

Moon Danc(er?)(ing?)

Frog on a Swing

The Wall (not because I made it, but because it shows what we have all hit making these animations and an effort to make the screen wipe work for us...)

 

EDIT:

Just a quick question... What kind of benefits in terms of animation speed could be gained by going to a narrow playfield?

Edited by dwhyte
Link to comment
Share on other sites

In general, the animations with changing tempo and/or greater differences between frames are most likely to show "screen redraw". It's because of lack of screen-double-buffering. It may appear in some of the next versions of Tip Animator but we will see if it happens. Also the animations with smaller resolutions can produce too much "pixelized" TIP-animations (one example is in the attachment, and yes, it looks ugly when compared to the original).

demo.zip

Edited by miker
Link to comment
Share on other sites

Hello Miker,

you were faster with converting that manga animation than me (think I can delete the 76 frames from my harddisk now). Luckily I did not do it, otherwise everyone would have complained about the slow animation with high flicker. But now, thanks to your explanation, everyone knows whats wrong with it...

 

On the other hand, if you like re-painting dozens of pictures (like I once did with the snowy_night and other animations), say 73 pictures, you may speed up this ani. Try using one blue colour for the sky in the background and remove the strange pixels from there, think this could produce a better result for the first half of the ani (for re-painting use a paint program or maybe gimp and its fill + paint options)... just a thought... And err, I first converted the frames to 160x100 pixels on the PC (not via TIPconv.), so the TIP pics do not look so bad or pixelized...

 

Besides, what program did you use to convert the JPG/GIF/PNG frames into TIP ?!? I always used the Tipconv. 1.0.0 by Epi, alas it only allows to convert *one* picture/frame at a time. So converting more than ten frames takes quite some time. Is it possible to add a batch function ? Lets say you have chosen the color palette (e.g. G2F), the saturation level (e.g. x2.0) and the brightness (e.g. linear) and after converting 2-3 frames into TIP, you realize the frame(s) looks best with it, now it would be cool if you could just set these parameters and let the program convert all 70 frames in one go (and not one after another manually)... this would speed up the creation of TIP animations enormously...

 

-Andreas Koch.

 

Edit: added one sample picture with new background (one blue color for the sky, one blue color for the sea), so you know what I mean - of course re-painting the frames this way will only work with those frames that show sky and sea (and err, after half of the ani you only see the manga girl and sky and sea are gone)...

Edited by CharlieChaplin
Link to comment
Share on other sites

Hi CharlieChaplin.

 

Well - changing the background is maybe the way to go, but (as i'm not-so-familiar with graphics [re]painting) maybe i couldn't do it. For converting i use TipConv too (i use also VirtualDub for crippling the GIF/other animation into single frames). Also, in this particular animation the sky/background moves too and it's probably another reason for its file-size. I think it can look better in some other graphics mode...

Link to comment
Share on other sites

Well,

for those few Atarians that like tip animations, I have prepared a small archive, sorted by memory requirements (it does not include the x-rated animations, to avoid further complaints)... Today, I am starting with the 64k tip animations (including two new animations by me and some new and/or updated animations by Miker)... no sources included, since no-one seems to use them... -Andreas Koch.

Link to comment
Share on other sites

Well,

for those few Atarians that like tip animations, I have prepared a small archive, sorted by memory requirements (it does not include the x-rated animations, to avoid further complaints)... Today, I am starting with the 64k tip animations (including two new animations by me and some new and/or updated animations by Miker)... no sources included, since no-one seems to use them... -Andreas Koch.

 

Thanks for putting those up. I can't say think much of the complaints. This is a new tool and you and Miker are at least plumbing it's strengths and weaknesses so that everybody else can learn what works, what doesn't, and what you need to do if you particularly want an animation to come out well. I also appreciate that time and effort went into this and everybody else gets to download and possibly enjoy for free.

 

Don't let the whingers get you down!

Link to comment
Share on other sites

Err well,

just found out another stupid thing (stupid me, stupid me!): I have prepared and watched all my animations in the Atari 800 Win internal color palette (thought it is the same as the external default.act, but it is most likely not). When you watch them in a different color palette (say G2F.act or Jakub.ACT) most of them look extremely different. The same counts for some other animations, e.g. the Chuck Norris ani (chuck_320k.xex) or the two animations made from the Mechwarrior 2 intro (they were both named tipanm.xex here at AA, I renamed them to Walker1_320k.xex and Walker2_576k.xex in my collection).

 

In some animations the color difference is just like day and night if you choose a different palette (also a lot of false colors appear here and there)... oh well... maybe for future animations we have to add which color palette is the best for viewing or we all use just one and the same color palette... (I vote for G2F palette or Jakub palette)... -Andreas Koch.

 

P.S.: Just take a look at the jagboot_64k.xex or jagintro1 and jagintro2 - watch them with the internal palette (untag "use ext. palette"), the "jaguar" letters are completely red (thats how I wanted them to be), watch them with the G2F palette (tag "use ext. palette" and choose G2F.act) and they are red, pink and green... oh shit...

Edited by CharlieChaplin
Link to comment
Share on other sites

I tried a couple of these at 7.16mhz but they didn't seem to 'run' any faster. A teeny bit less jerky - maybe. Are there any that really need more processor speed? Are there any other 'video' compilations that I could try in a 64K machine?

 

Bob

 

Yes,

there are some other A8 video compilations available (hint: e.g. Movie-Maker!), but therefore I have to start a new thread, since none of them are tip animations... -Andreas Koch.

Link to comment
Share on other sites

The animations use an almost fullscreen DLI "kernal" to toggle GPRIOR for the TIP mode.

 

So, regardlesss of the machine's speed, any extra cycles in the graphics area are wasted/lost.

 

Maybe you guys could do an alternate version for faster machines? Or just incorporate it into the existing program and have a speed test which decides which system you have.

 

For 7 MHz, you should be able to easily get away with having one DLI per scanline, which would leave some extra cycles free for the main program.

Another nice option might be to have a kind of "Wait for Vsync" option which could ensure that fast machines don't play the animations too fast.

Link to comment
Share on other sites

Hello folks,

and here are the 576k animations I have archived at last...

 

And now its time for me to do some new animations. Alas I am still thinking which (emu) color palette I should use - which one is the closest to the real A8 in your eyes ?!? As said before, I always used the "internal" palette of A800 Win when viewing/testing my created animations and they looked good, but with external palette like G2F or Jakub (not to mention Xformer) they look extremely bad colorwise... -Andreas Koch.

Link to comment
Share on other sites

Alas I am still thinking which (emu) color palette I should use - which one is the closest to the real A8 in your eyes ?!? As said before, I always used the "internal" palette of A800 Win when viewing/testing my created animations and they looked good, but with external palette like G2F or Jakub (not to mention Xformer) they look extremely bad colorwise... -Andreas Koch.

 

In my opinion both defaultl palettes (Atari800Win and XFormer emulator) are incorrect. Look at guide here:

http://atarionline.pl/v01/index.phtml?suba...&ct=nowinki

atari800Win.act and xformer.act are the worst. I suggest to use laoo.act (darker) or g2f.act (lighter), but even real.act and jakub.act are better than emulators default palettes.

Edited by Kaz atarionline.pl
Link to comment
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.
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...