It is currently Tue Sep 25, 2018 11:57 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 77 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6  Next
Author Message
PostPosted: Tue May 15, 2018 9:34 am 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7558
Location: Seattle
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.


Top
 Profile  
 
PostPosted: Tue May 15, 2018 9:48 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 20574
Location: NE Indiana, USA (NTSC)
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.


Top
 Profile  
 
PostPosted: Tue May 15, 2018 11:10 am 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7558
Location: Seattle
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.


Top
 Profile  
 
PostPosted: Tue May 15, 2018 6:33 pm 
Offline
Formerly Espozo
User avatar

Joined: Mon Sep 15, 2014 4:35 pm
Posts: 3364
Location: Richmond, Virginia
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):

Attachment:
Color Count.png
Color Count.png [ 94.28 KiB | Viewed 1062 times ]

Probably helps that the entire game is in shades of gray and brown...


Top
 Profile  
 
PostPosted: Tue May 15, 2018 7:44 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7558
Location: Seattle
(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.


Top
 Profile  
 
PostPosted: Tue May 15, 2018 8:00 pm 
Offline
Formerly Espozo
User avatar

Joined: Mon Sep 15, 2014 4:35 pm
Posts: 3364
Location: Richmond, Virginia
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)?


Top
 Profile  
 
PostPosted: Tue May 15, 2018 9:17 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7558
Location: Seattle
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.


Top
 Profile  
 
PostPosted: Wed May 16, 2018 12:06 am 
Offline

Joined: Tue Feb 07, 2017 2:03 am
Posts: 579
HAM games
http://hol.abime.net/hol_search.php?N_r ... ckmatch=81
EHB games
http://hol.abime.net/hol_search.php?N_r ... ckmatch=80


Top
 Profile  
 
PostPosted: Wed May 16, 2018 5:20 am 
Offline
Formerly Espozo
User avatar

Joined: Mon Sep 15, 2014 4:35 pm
Posts: 3364
Location: Richmond, Virginia
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.

Oziphantom wrote:

None of those games appear to have an extra layer, and most don't appear to scroll either. :|


Top
 Profile  
 
PostPosted: Thu May 17, 2018 5:50 am 
Offline

Joined: Mon Mar 30, 2015 10:14 am
Posts: 275
You can have some impressive effects like this :
https://youtu.be/j5e78_9Eo2Y?t=55m32s


Top
 Profile  
 
PostPosted: Thu May 17, 2018 6:54 am 
Offline
Formerly Espozo
User avatar

Joined: Mon Sep 15, 2014 4:35 pm
Posts: 3364
Location: Richmond, Virginia
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...


Top
 Profile  
 
PostPosted: Thu May 17, 2018 9:01 am 
Offline

Joined: Tue Feb 07, 2017 2:03 am
Posts: 579
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


Top
 Profile  
 
PostPosted: Thu May 17, 2018 11:26 am 
Offline

Joined: Wed May 19, 2010 6:12 pm
Posts: 2751
The frustrating thing about overdrive 2 demo is that it only worked because of VDP glitches.


Top
 Profile  
 
PostPosted: Thu May 17, 2018 11:27 am 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7558
Location: Seattle
The bitmap AND behavior was only a couple of the effects in the demo. Saying "only" is really exaggerating.


Top
 Profile  
 
PostPosted: Thu May 17, 2018 11:30 am 
Offline

Joined: Sat Apr 25, 2015 1:47 pm
Posts: 420
Location: FL
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.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 77 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: Google Adsense [Bot] and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group