Commodore 64 and Amiga 500 video hardware characteristics?

You can talk about almost anything that you want to on this board.

Moderator: Moderators

lidnariq
Posts: 11429
Joined: Sun Apr 13, 2008 11:12 am

Re: Commodore 64 and Amiga 500 video hardware characteristic

Post by lidnariq »

Espozo wrote:Can it also program new graphics pointer data for sprites mid-scanline?
To what end? The sprite data-to-blitter DMA is fixed and only happens once per scanline.

Even if it weren't, the only advantage would be spending one fewer "odd" cycle clocks on DMA (Copper, and that by only updating 16 bits of the address) to spend two more "even" cycle on DMA (Sprite DMA).
tepples wrote:
lidnariq wrote:The modern retreaux "lots of colors but super chunky pixels" is almost entirely without historical precedent.
That depends on what you define as "super chunky". A bunch of old systems had 160-pixel-wide modes, such as CGA (160x100), EGA (160x116), PCjr (160x200), Game Boy, and Game Gear.
2600: ROM space was too much of a premium.
CGA: The 160x100 mode was extremely rare due to lack of BIOS support and still only supported 16 fixed colors
EGA: I've never actually seen any software divy up the RGB components into subpixels on the EGA to generate a 64 color mode. Even then, the 64 color master palette is limiting. (I have seen this trick used with the VGA 320x480 tweak mode to generate a 320x160x18bpp mode ... but 18bpp is a LOT more than 6bpp)
PCjr: 16 fixed colors
Game Boy Color; Game Gear: handheld. Still not MCGA levels of "lots of colors".

I'm basically ranting about the art direction of "Sword and Sworcery", but I've seen the same aesthetic used elsewhere too.
tepples
Posts: 22705
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Commodore 64 and Amiga 500 video hardware characteristic

Post by tepples »

lidnariq wrote:I'm basically ranting about the art direction of "Sword and Sworcery"
Screenshot please. The screenshots I've seen on Google Images look roughly MCGA/VGA mode 13h (320x200 pixels, 256 colors) in their aesthetic. That's roughly as "chunky" as Super NES.
lidnariq
Posts: 11429
Joined: Sun Apr 13, 2008 11:12 am

Re: Commodore 64 and Amiga 500 video hardware characteristic

Post by lidnariq »

tepples wrote:
lidnariq wrote:I'm basically ranting about the art direction of "Sword and Sworcery"
Screenshot please. The screenshots I've seen on Google Images look roughly MCGA/VGA mode 13h (320x200 pixels, 256 colors) in their aesthetic. That's roughly as "chunky" as Super NES.
1- Hardware sprites on real hardware are wasted by single-pixel-wide lines (Obvious exception: Atari 2600 "ball" and "missile" sprites). At the low contrasts as used in this game, single-pixel-wide lines are hard to see over composite video.
2- The game varies its zoom; the introduction starts at a 10x nearest-neighbor zoom (192x108); the first moment of game play is instead a 8x nearest-neighbor zoom (240x135). The former is comparable to the resolution of the Intellivision, but the Intellivision only had a 15 color master palette, and extremely limited color coincidence. The latter is comparable to the NDS, but the field-of-view of the NDS's screen under typical play is maybe 1/4 of a TV or PC monitor. (Human vision cares about pixels per minute-of-arc, not pixels per inch)
3- It's not even maintaining a strict pixel grid, it's just using huge chunky pixels.

It feels to me like trying use the "retreaux" aesthetic to achieve "abstract" but for me it falls flat, feels terribly lazy and cheapens the rest of the game. (CD quality sound but huge high color chunky pixels? FFFFFF)

Regardless, this is extremely off-topic, so I'm not going to talk about this on this thread anymore.
User avatar
Drew Sebastino
Formerly Espozo
Posts: 3496
Joined: Mon Sep 15, 2014 4:35 pm
Location: Richmond, Virginia

Re: Commodore 64 and Amiga 500 video hardware characteristic

Post by Drew Sebastino »

lidnariq wrote:
Espozo wrote:Can it also program new graphics pointer data for sprites mid-scanline?
To what end? The sprite data-to-blitter DMA is fixed and only happens once per scanline.

Even if it weren't, the only advantage would be spending one fewer "odd" cycle clocks on DMA (Copper, and that by only updating 16 bits of the address) to spend two more "even" cycle on DMA (Sprite DMA).
I think there may be some sort of communication error (probably on my part); you see how the background in games like the Amiga port of R-Type II is highly repetitive because the only thing that is being changed about the sprites is their position. I was wondering if you would be able to change their x coordinate in conjunction to their graphics pointer to eliminate this limitation.
lidnariq wrote:
tepples wrote:
lidnariq wrote:I'm basically ranting about the art direction of "Sword and Sworcery"
Screenshot please. The screenshots I've seen on Google Images look roughly MCGA/VGA mode 13h (320x200 pixels, 256 colors) in their aesthetic. That's roughly as "chunky" as Super NES.
1- Hardware sprites on real hardware are wasted by single-pixel-wide lines (Obvious exception: Atari 2600 "ball" and "missile" sprites).
[...]
Oh, I had looked up "Swords and Sorcery" instead of "Sword and Sworcery" and was wondering what you were going on about. :lol:

Image

Yeah, It looks cheap af to me as well. It feels to me like great looking 2D games are largely a thing of the past. :|

Image
Image

...And about the Amiga, I'm surprised the R-Type II port even looked as good as it did, especially considering it only uses a 4bpp bitmap and 2bpp sprites (even if it ran like shit):
Color Count.png
Probably helps that the entire game is in shades of gray and brown...
lidnariq
Posts: 11429
Joined: Sun Apr 13, 2008 11:12 am

Re: Commodore 64 and Amiga 500 video hardware characteristic

Post by lidnariq »

(I didn't actually know anything particular about the OCS beyond the bitplane graphics, HAM6 mode, and EHB mode. Everything I've explained since is just coming from the reference the reference manual that TOUKO linked)
Espozo wrote:the background in games like the Amiga port of R-Type II is highly repetitive because the only thing that is being changed about the sprites is their position. I was wondering if you would be able to change their x coordinate in conjunction to their graphics pointer to eliminate this limitation.
The graphics pointer is part of the Sprite DMA unit, not part of the sprite blitters.

Before the active field, the sprite DMA unit fetches new values to be loaded into SPRnCTL and SPRnPOS. Before each scanline starts, sprite DMA fetches two words into SPRnDATA and SPRnDATB.

Changing the pointer doesn't help (in the same way that changing the SNES's HDMA channels pointer during rendering doesn't help); sprite DMA still only runs once per scanline.

To repeat a sprite within a scanline, you use the Copper to update the X/Y location in the SPRnPOS register. To update the tile graphics you have to send extra data to the SPRnDATA and SPRnDATB registers.

And that's when you run out of bandwidth.

This gives lots of details, saying that you can get one Copper copy per 8 pixels when not colliding with other DMA, or one per 12 or 16 when colliding. Since each sprite can only cover 16 pixels, at least half of your available Copper bandwidth has to go to just uploading new values to SPRnPOS.

The spritetapper archive shows that Brian The Lion multiplexes sprite data as well as sprite X coordinate—but only 1bpp. There isn't enough time to do anything more.
User avatar
Drew Sebastino
Formerly Espozo
Posts: 3496
Joined: Mon Sep 15, 2014 4:35 pm
Location: Richmond, Virginia

Re: Commodore 64 and Amiga 500 video hardware characteristic

Post by Drew Sebastino »

Oh, yeah, I read every game that was mentioned but didn't quite understand that. That really blows. It looks like Agony could have just gotten away with it instead of having to re render the background, but I guess not because sprites are used for the owl and the rain.

Do you know of any Amiga games that actually render what could be considered an additional background layer using one bitmap (for a larger amount of colors), or is this just computationally impossible with reasonable performance (at least 25/30 fps)?
lidnariq
Posts: 11429
Joined: Sun Apr 13, 2008 11:12 am

Re: Commodore 64 and Amiga 500 video hardware characteristic

Post by lidnariq »

I mean, if you do the math, sprites take roughly as much DMA bandwidth (16 words) as each bitplane (20 words). They could have (probably) chosen to have a 7bpp mode instead of sprites ... but I think that's clearly not worth it.

I'm not certain what your question actually means.
User avatar
Drew Sebastino
Formerly Espozo
Posts: 3496
Joined: Mon Sep 15, 2014 4:35 pm
Location: Richmond, Virginia

Re: Commodore 64 and Amiga 500 video hardware characteristic

Post by Drew Sebastino »

I was just talking about how Brian the Lion made a non-repeating 1bpp layer using sprites, while Agony has a 1bpp layer as well but by manipulating the back layer in split playfield mode.
None of those games appear to have an extra layer, and most don't appear to scroll either. :|
User avatar
TOUKO
Posts: 306
Joined: Mon Mar 30, 2015 10:14 am
Location: FRANCE

Re: Commodore 64 and Amiga 500 video hardware characteristic

Post by TOUKO »

You can have some impressive effects like this :
https://youtu.be/j5e78_9Eo2Y?t=55m32s
User avatar
Drew Sebastino
Formerly Espozo
Posts: 3496
Joined: Mon Sep 15, 2014 4:35 pm
Location: Richmond, Virginia

Re: Commodore 64 and Amiga 500 video hardware characteristic

Post by Drew Sebastino »

I have no idea wtf is going on there gameplay wise, but you could accomplish the same thing in the Genesis and SNES (before mode 7) by having prerendered shrunken strips (or at least I think that's how it's done) like in Puggsy or the Lawnmower Man on Genesis.

From a 2D standpoint, I'm not really sure there's much that the Amiga can do that the Genesis can't, or anything it can do that the SNES can't (other than run at 320 pixels wide) but I have to keep reminding myself that it was made in 1985...
Oziphantom
Posts: 1565
Joined: Tue Feb 07, 2017 2:03 am

Re: Commodore 64 and Amiga 500 video hardware characteristic

Post by Oziphantom »

Well I did suggest in a list of things >NES <SNES ;)

but the issue with the MD and SNES is they are VBlanked limited, the Amiga has always on raw access to everywhere on the screen, you can also double/tripple buffer. So While the 3D in the Overdrive 2 demo for the MD was good for the MD, watch some A500 demos. The line drawing and poly-filling hardware allow it to do some unique stuff. A few games let you morph your character because its actually vector. Anything that likes bitmap is going to favor the Amiga anything that works best with tiles will favor the SNES/MD. But it has the CPU as the MD, just it doesn't have a cheap char mode. Amiga invented the FMV ;) Also RAM, an A500 has at least 512K, 1MB is basically standard. 3MB is a rareish but not uncommon set up as well.
You can pull some fancy effects with bit-plane tricks, putting a shadow layer or colour inversion in the palette then move single bitp-lane (shadow vectors). I would like to do the Donkey Kong Country Returns pure black foreground with colour background level idea on an Amiga. 1 bit-plane for the black, make half the palette black job done ;) Sprites for colour accents.

It would be interesting to see what an A500 could do with a tile based video chip on the expansion bus, it would technically have the same CPU as the MD, but if you can keep full access to the RAM then it would really open up the taps, if you can genlock it with the bitmap hardware like the Picasso and Video toaster boards did, really really powerful.

If you want better than MD and SNES then you need to go AGA so Amiga 1200 or 4000 or CD32
psycopathicteen
Posts: 3140
Joined: Wed May 19, 2010 6:12 pm

Re: Commodore 64 and Amiga 500 video hardware characteristic

Post by psycopathicteen »

The frustrating thing about overdrive 2 demo is that it only worked because of VDP glitches.
lidnariq
Posts: 11429
Joined: Sun Apr 13, 2008 11:12 am

Re: Commodore 64 and Amiga 500 video hardware characteristic

Post by lidnariq »

The bitmap AND behavior was only a couple of the effects in the demo. Saying "only" is really exaggerating.
Revenant
Posts: 462
Joined: Sat Apr 25, 2015 1:47 pm
Location: FL

Re: Commodore 64 and Amiga 500 video hardware characteristic

Post by Revenant »

That's like saying every memorable C64 demo since 1987 "only" worked because of VIC-II glitches, which might be almost technically true, but it also discounts the massive amount of legwork and technical ingenuity it takes to turn a hardware glitch into something that's actually interesting to look at.
Post Reply