3D - F030 vs Amiga 1200

[Zamuel_a]

Since HAM mode is only for static images or animations in best case, there must be a lot of ways to produce better images on an Falcon. By just flicking between two 64k images you get millions of colors and takes no CPU speed at all.
Are there any viewers that do this or did all of them just settle with 64k images?

[Frank B]

Since HAM mode is only for static images or animations in best case, there must be a lot of ways to produce better images on an Falcon. By just flicking between two 64k images you get millions of colors and takes no CPU speed at all.
Are there any viewers that do this or did all of them just settle with 64k images?

Ham 8 is only useful for pre calculated static animations. Compared to 16 bpp it's a bad joke IMHO. God knows why Commodore didn't go high colour.

[CiH]

Since HAM mode is only for static images or animations in best case, there must be a lot of ways to produce better images on an Falcon. By just flicking between two 64k images you get millions of colors and takes no CPU speed at all.
Are there any viewers that do this or did all of them just settle with 64k images?

I think Doug Little's Apex Media viewer proggies improved on the 65k colours.

Ah, here we go, a handy readme file.

The image is rendered onto the screen using an advanced
24-bit 'emulation' mode which uses software trickery to
increase the Falcon's colour limit beyond 16-bits to a much
smoother looking 24-bit display.

Support: * Any standard YCbCR-IDCT-Huffman based JPEG format.
* Works only on Falcon030 machines.

Colours: * Approx 16.7 million / 24-bit.

[ctirad]

Ham 8 is only useful for pre calculated static animations. Compared to 16 bpp it's a bad joke IMHO. God knows why Commodore didn't go high colour.

That would require a major chipset redesign. The Commodore was probably not in a good shape to afford that.

[Zamuel_a]

I think 16 bit chunky graphic mode is much better than HAM8, even that every Amiga enthusiast say the opposite

[dml]

I think 16 bit chunky graphic mode is much better than HAM8, even that every Amiga enthusiast say the opposite

Yeah, anyone who's a fan of moving graphics finds HAM less than optimal

[Zamuel_a]

HAM was a clever idea to get more colors on screen on an Amiga 500, but for the 1200 it's less than optimal.

[calimero]

HAM was a clever idea to get more colors on screen on an Amiga 500, but for the 1200 it's less than optimal.

I am not sure but I think that they want in one point of time to remove HAM from silicon (not sure why) but it would leave whole in chip (maybe it is an urban legend but I am pretty sure that I read this somewhere)

[Zamuel_a]

I am not sure but I think that they want in one point of time to remove HAM from silicon (not sure why) but it would leave whole in chip (maybe it is an urban legend but I am pretty sure that I read this somewhere)

Yes it's true. I read a interview with the creator once and he said that the original idea for HAM was not like it turned out. It was not based on RGB but on HSV (I think) and designed to be more easy to use. But after the rest got finished the HAM mode wasn't useful anymore and he wanted to remove it, but it would cost to much and they left it in. It turned out to be useful in some situations, but not like it was thought of.

[Frank B]

Ham 8 is only useful for pre calculated static animations. Compared to 16 bpp it's a bad joke IMHO. God knows why Commodore didn't go high colour.

That would require a major chipset redesign. The Commodore was probably not in a good shape to afford that.

Shame they didn't release AAA

[mc6809e]

I think 16 bit chunky graphic mode is much better than HAM8, even that every Amiga enthusiast say the opposite

Yeah, anyone who's a fan of moving graphics finds HAM less than optimal

At least the hardware sprites are still usable, though small -- just 128 pixels of sprite data per scanline.

Had sprites been 32 pixels wide instead of just 16 there might have been a few more HAM games.

[Frank B]

I think 16 bit chunky graphic mode is much better than HAM8, even that every Amiga enthusiast say the opposite

Yeah, anyone who's a fan of moving graphics finds HAM less than optimal

At least the hardware sprites are still usable, though small -- just 128 pixels of sprite data per scanline.

Had sprites been 32 pixels wide instead of just 16 there might have been a few more HAM games.

64 wide I believe and not 128. How many are available with scrolling extra fetch and fmode set to max? One 3 colour (3 + transp) I think?
My memory is fuzzy on the topic.

[calimero]

I think 16 bit chunky graphic mode is much better than HAM8, even that every Amiga enthusiast say the opposite

Yeah, anyone who's a fan of moving graphics finds HAM less than optimal

At least the hardware sprites are still usable, though small -- just 128 pixels of sprite data per scanline.

Had sprites been 32 pixels wide instead of just 16 there might have been a few more HAM games.

HAM games? Is there any HAM games??

Bte 128 pixels per scanline is more than 1/3 pixels in 320x200 resolution! I would not say it is small, or bad?

[mc6809e]

At least the hardware sprites are still usable, though small -- just 128 pixels of sprite data per scanline.

Had sprites been 32 pixels wide instead of just 16 there might have been a few more HAM games.

64 wide I believe and not 128. How many are available with scrolling extra fetch and fmode set to max? One 3 colour (3 + transp) I think?
My memory is fuzzy on the topic.

I'm mean on OCS. There are eight sprites per scanline that are each 16 pixels wide. Each pair of sprites share a group of three palette entries. That gives a total of 128 pixels of sprite data per scanline and 12 colors.

Pairs of sprites can also be attached. Attached sprites, where they overlap, select from 15 palette entries. That typically gives four, 16 pixel-wide, 15-color sprites. That might be where you're getting the 64 pixel number from.

Partial overlap of attached sprites is possible, too, giving wider sprites with some limits on colors. For example, two attached sprites can be partially overlapped to create a 24 pixel-wide sprite with the left four pixels selecting from three colors, the center 16 pixels selecting from 15 colors, and the right four pixels selecting from a second set of three colors. Such a scheme would give 96 pixels of sprite on a line and in most cases allow 15 color sprites.

Sprites can also be repositioned with the copper or CPU during the scanline allowing them to be reused with some limitations.

I'm not sure what the absolute limit on the total number of sprites obtained per scanline. A MOVEM.L d0-d7/a0-a7, sprites should be able to rewrite the entire set of sprites each scanline. That would give a limit of 16 sprites per scanline combining DMA fetch and CPU writes. In HAM sprites are still available, although there are fewer DMA slots available for tricks. The practical limit in any case is probably 10-12 sprites per scanline.

It's a mystery to me why someone didn't bother to try writing some simple galaga-style game using sprites on a HAM background. HAM is also fully vertically scrollable, BTW (also horizontally scrollable but care must be taken to hide artifacts). Vertical scrolling over static terrain with sprites overlaid probably had some potential. Perhaps memory limits were an issue (one HAM screen is 40K).

This discussion is actually connected somewhat to the mention of the extra address bus. Anyone that's done Atari 2600 programming knows that playfield and sprite data must be written manually by the processor every scanline. The separate address bus on the Amiga is what allows the chipset to do similar writes to arbitrary register locations. As the one of the designers of the 2600 also designed the Amiga chipset, this extra bus was seen as a great advantage, allowing the CPU to be bypassed and sprite data to be automatically loaded.

As far as scrolling goes, on OCS, the last sprite can be controlled by the copper or CPU if hard scrolling a 320 pixel wide screen with normal centering (a 304 pixel wide screen doesn't have that problem if you're willing to accept a narrower screen). Sprites don't become unusable with wider, overscan, and hardware scrolled screens. They simply must be programmed manually by the CPU or copper as the DMA slots normally used for some of the sprite are reallocated to bitplane DMA.

It's also possible to reuse sprites in the vertical by just using DMA and no tricks. DMA will automatically read in new position and control values for a new sprite at the end of the old sprite. This uses one scanline. Of course the copper can also do this if the programmer doesn't want one scanline to separate the new sprite from the old. This shifting position on a per scanline basis can also make sprites look much wider. A tree standing at a slant might span a total of 32 pixels, but if it's only 16 pixels wide at any one point, the copper and slant it.

I'm really not that familiar with AGA. Those sprites are wider I believe.

[mc6809e]

Bte 128 pixels per scanline is more than 1/3 pixels in 320x200 resolution! I would not say it is small, or bad?

But each of those sprites is only 16 pixels wide. That's just 1/20th of a screen width.

Once you start grouping them together to make bigger sprites, you quickly run out (unless you use tricks).

Still, like I said before, a galaga-style game should have been doable in HAM.

[mc6809e]

Just to wrap this up because it's way OT now:

This discussion about sprites, HAM, blitter area fill for 3D, etc, reveals a big reason why, in practice, the Atari ST and Amiga were often nearly the same.

What programmer that needed to feed himself was going to invest all that time learning enough about the Amiga to perform all those special tricks? Fact is it took an Amiga expert to program all those Amiga-specific features.

It's one thing to program as a hobby. One can waste time with demos, etc. A professional programmer back then just couldn't, though.

The virtue of the ST was its simplicity. The history of the PC with chunky VGA+CPU in 1987 doing everything up until the late 90s, shows it was time for simplicity.

[Zamuel_a]

in practice, the Atari ST and Amiga were often nearly the same.

Many games were developed on the Atari first and after that, ported to the Amiga. It was easier to port an Atari game to the Amiga than the opposite and the makers wanted to earn money fast.

[Flash951]

[quote="Zamuel_a"]Many games were developed on the Atari first and after that, ported to the Amiga. It was easier to port an Atari game to the Amiga than the opposite and the makers wanted to earn money fast.[/quote

That is true. There wasn't much revenue to earn by using resources in the Amiga port of games in the beginning iI think. Very few Amiga's was sold during the first two years. Before the A500 came along with a more affordable price tag and larger number of units was sold.

[galahad]

Its not that people don't take the A1200 seriously as a stock machine, its still pretty capable,

No so pretty. The main problem is the limited RAM size for a prodution work in workbench. It was limited like 512kB A500 before.

Er, that wasn't a problem at all. Unless you were seriously into productivity software, how much ram was available for Workbench and system was irrelevant.

If you were seriously into productivity software and were able to afford to buy some of the VERY expensive programs to use, you certainly could and would be able to afford to upgrade your Amiga A1200 to best take adavantage of it.

Very few Amiga owners have an 060 card. I would say the most common configuration is A1200+Fastram+030card+hard drive, and thats decent enough.

I know very few Amiga users which don't have 060 or at least 040. 030 + FastRAM was typical 1990s setup.

I'm not sure why you bothered to respond, you've basically said in a roundabout way, exactly what I said.

[calimero]

Not sure if we mention this before, but Anouk33 just post on youtube Psychedelic by Virtual Dreams.

It run on stock Amiga 1200 with 2MB of FastRAM.

https://www.youtube.com/watch?v=A-pkP5_4zxo

it has impresive and massive 3D part at 1:30
some nice lightning effects later
and at the end some texture mapped 3D objects.

[mikro]

I wouldn't be surprised if that massive 3D part is a complete fake. ;-) Compare the other 3D parts, those look far more believable. That one you mentions reminds me of this Atari800 demo: http://a8.fandal.cz/detail.php?files_id=3591 (and as you would have guessed, it's not that massive either ;-))

[Trixster]

That big 3d part at 1.20 is definitely pre-rendered