This discussion is about how 5th generation systems can implement background effects like 4th generation consoles did in hardware.Quote:
Originally Posted by AlecRob
This discussion is about how 5th generation systems can implement background effects like 4th generation consoles did in hardware.Quote:
Originally Posted by AlecRob
Slate style parallax works best with horizontal shooters. Although some might argue that developers had difficulty pushing the genre on SNES, the fact is that shooters became unpopular later in the 16-bit generation and the SFC just happened to show up several years in. If shooters stayed popular longer, I'm sure that we would have seen many more good examples horizontal strip parallax in SFC/SNES games. One great example is Macross Scramble Valkyrie.
Slate style parallax is awesome when you can't see the cut.
Good Examples: Kick Master (NES), Vice Project Doom (NES), Ristar (MD)
Terrible Examples: Too many PCE games... Air Zonk for one.
I'm not fond of a some of the bgs in Air Zonk and pretty much all of Coryoon, but the PCE is also the home of so many great examples. It just has so many games with it (and shooters) in general.Quote:
Originally Posted by Kamahl
Yeah coryoon is even worse than Air Zonk in this regard.
Chuka Taisen's boss battles are gorgeous. Coyoon's try to do pretty much the exact same thing, but are painful to look at.Quote:
Originally Posted by Kamahl
The desert stage of Lords of Thunder opens with a gibberish background. It doesn't really look like anything, even though the base graphics are nice. Meanwhile other scenes in the same game, like the opening of the water stage, look great.
It may not be technically difficult for the hardware to perform, but it sure seems challenging to pull off well artistically.
We should probably switch this discussion over to the 4th gen thread. This effect wasn't used in the 5th gen afaik.
I wouldn't be too sure of that . . . granted, it was popular to use real 3D for doing perspective BGs in 2D/2.5D games, but row scroll or (better) linescroll would still make tons of sense for providing good perspective effects for parallax. At least for linescroll, there's plentty of cases with broad terrain (plains, marhes, low-lying cityscapes, low lying hills, etc, etc -anything appearing flat-ish from the foreground PoV) that would be best achived (for 2D) using linescroll rather than any overlapping. (if texture space was an issue, combining that with hardware scaling per-line might have been attractive too)Quote:
Originally Posted by Kamahl
Now, combining that effect with overlapping layers/objects (or even multiple linescrolled layers with overlap) could make tons of sense in many cases too, and there's other cases where the BG perspective is too sheer and/or uneven (not flat-ish) to make sense to use with linescroll.
For reasons I stated earlier, it wasn't needed as much, but games like Keio Yugekitai, Macross Do You Remember Love?, Mobile Suit Gundam, Guardian Heroes, Princess Crown, Astal, Shinobi Legions, Rayman, Kolibri, Knuckles Chaotix, Adventures of Lomax, Megaman X4, Adventure of Little Ralph, Hermie Hopperhead, Mischief Makers, and Wonder Project J2... -all use the effect in varying ways.Quote:
Originally Posted by Kamahl
They use a similar effect, the layers are fully independent (at least the Playstation/N64 ones).Quote:
Originally Posted by Black_Tiger
The effect isn't always done the same way on 16-bit consoles either. Many games tack on sprites for overlapping and PC Engine games often do it with animation.Quote:
Originally Posted by Kamahl
Which effect are we talking about again?Quote:
Originally Posted by Kamahl
Air Zonk/Sonic style sliding parallax spams.Quote:
Originally Posted by zyrobs
Simple parallax scrolling? Tons of Saturn games did that... a lot of them being 2d shooters. Darius Gaiden from the top of my head, but Radiant Silvergun had that (vertically) as well as others.
Oh, and some of the "heavy parallax" examples used above - Sonic and Thunder Force - have had pixel perfect Saturn ports too.
Quote:
Originally Posted by Crazyace
I was thinking on this again, and reading through Brennan's and Mathieson's interviews on the SLipstream archive, and noticed there's even more detail to the Jaguar's object processor being "out of place" in a Flare design than Brennan's comment about the Panther:Quote:
Originally Posted by CrazyaceJust to fix the bugs to have gpu run from external would be enough - and launch fully in 93 :)
or just leave the blitter as is ( barring bugs ) - although a single indirection would be nice for colour expansion as seen in the jaguar 2 blitter.
I disagree, why would you need line buffers - just a simple 64 or 128 bit fifo driving a fixed 320pixel 16bit display would be enough, why would games want 24 bit mode?
Changing Z/Gourard seems to be moving away from the main design of the Jaguar too much, whereas removing the object processor is taking something that wasn't 'Flare'
I was concentrating on just removing Jerry and the object processor - as Jerry would be a major cost.
Yes, it was that comment that made me think about it.Quote:
Originally Posted by kool kitty89
There's the Panther comment already mentioned:
http://www.konixmultisystem.co.uk/in...content=martin
But then there's also the comments both Brennan and Maithieson make regarding the Amiga and Flare 1:Quote:
It was a novel video architecture that allowed you to create windows of different sizes and different bit depths. Essentially you didn't have a frame store - it was a composite of frame stores - a kind of smart video frame store. It would have allowed a great deal of sprite style animation. Sprites in general in those days would have been of a fixed size e.g. 16x16. The games looked 'spritey' because of that, this would have been quite an interesting departure. I wasn't keen on it, but I designed it and the chip was built.
But while I was over in California in '89, I actually convinced the bosses at Atari that 3D was the way to go, with the experience we'd gained on Flare one - if you didn't just do flat rendering, but shaded rendering you got a 3D appearance.
At the time, I was seeing pictures in magazines where computers were rendering photo realistic 3D wire meshes and I said "these are static images, but they only contain a very few number of polygons - we could take that, animate it and you could produce a game that was a quantum leap away from the current games".
http://www.konixmultisystem.co.uk/in...content=martin
http://www.konixmultisystem.co.uk/in...ent=john#startQuote:
We based a lot of it on the Amiga as well. That was a great influence - they seemed to have designed a very powerful games machine - if not a games computer then at least a games capable system. They had Commodores purse to design that - and it showed - there seemed to be several different ways you could do the same thing on the Amiga which struck us as overkill. We felt there were lots of instances of doing the same job - but one way - the best way, and it would end up being cheaper. Plus there were certain things we didn't like about the architecture - it was bit planes architecture rather than a bit per pixel, so we felt we had some ideas that would make our lives and the game writers lives that much easier.
When you say was the Flare one derived from the Loki - I think you've got to say that Loki and Flare one were derived from the Amiga, so you've got to pay tribute to those guys.
Quote:
we believed that the Amiga was over engineered - it could animate with sprites and with a blitter, but why have both? We figured that if you could implement a system that could animate the screen then you only needed one set of hardware to do it. So we proposed a computer called 'Loki' as a Spectrum successor. The idea was never more than a paper design because Sinclair sold out and Amstrad took over before anything productive could happen to further the project".
The Jaguar's use of the Object Processor alongside the Blitter seems to contradict the very concepts and methodology originally applied to Loki, Flare 1, and Slipstream.
Technically speaking, the Panther itself didn't contradict that concept since its graphics were purely generated by the Object Processor (aside from possible software rendering to object windows), but Brennan just mentioned not really liking the architecture in general.
So the way the Jaguar was configured really seems odd in that respect, both in the context of Flare's general design concepts and the heavy emphasis on low cost with the Jaguar's design (and Atari Corp's market model in general).
Then there's the issue of magnetic or optical mass storage vs ROM carts in the Jaguar. The use of CD-ROM in 1993 wouldn't be far off in terms of cost/performance trade-offs as the DSDD floppy drive would have been in 1989. Plus, piracy concerns wouldn't have been an issue for CD-ROM yet. (and Flare's original semi-proprietary 880 kB floppy format would have reduced that to some degree as well)
And looking at the idea of a single-chip Jaguar more conceptually similar to the Slipstream, you've got the framebuffer controller, video DACs, DSP, audio DACs, CRAM and DSP scratchpad, main memory/CPU bus interface, and (in the final revision of Slipstream) integrated floppy disk controller as well. So compare that to the possible Jaguar ASIC based around a beefed up blitter, realtively framebuffer controller (some buffering to make decent use of bandwidth -like a pair of 128 or 256 bit buffers) and probably only direct color modes (no need for CRAM -aside from possible blitter CLUT), and integrated sound, IO (controller ports, UART, CD-ROM interface), and GPU/DSP RISC core with scratchpad (or, better, an actual cache). Except, unlike the Slipstream, you'd have a very powerful and flexible MPU in place of the DSP and thus no fundamental need for a dedicated CPU at all. (plus, the advanced design of the J-RISC also avoided some of the conflicts of handling both sound and 3D processing compared to the primitive Slipstream DSP)