Which is why it worked so well in chrono trigger, only 2 sprites on top of the effect.Quote:
Originally Posted by TrekkiesUnite118
Which is why it worked so well in chrono trigger, only 2 sprites on top of the effect.Quote:
Originally Posted by TrekkiesUnite118
Here we go, you know more than the developer . Not only is the Saturn version running at a Higher Res, double the frame rate its also feature spot effects not seen in PS version like reflections - all thanks to the VDP 2 Mode 7 effect , mind you thanks to Hardware support the Saturn version does lack 3D transparent effect seen in the PS version. ;The PS came out 2nd best in all the games that used the Saturn VDP II in a major way , Street Racer on the Saturn kills the PS version, Grandia VDP II effects kill those in the PS version and the PS version of the VDP II effects in Thunder Force IV are laughable its untrue . I wouldn't say too much but you go on about Sonic R and even talked of a interview with Jon and how the the PS would have issues trying to handle the Saturn Playfield hardware and the effects and framerate would sufferQuote:
Originally Posted by TrekkiesUnite118
In that context though, games using a flat terain plain should still run faster than those using more complex polygonal terrain on the PSX. (unless the flat terrain one used much higher res textures and ate up more bandwidth that way . . . or used a huge number of polygons stitched into that plane rather than a few big ones -or just 2 triangles as a single rotated rectangle and raster effects for perspective in software -like Mode 7 needs)Quote:
Originally Posted by Kamahl
It's not an issue of the Saturn "saving on polygons" so much as the Saturn just having more rendering bandwidth overall. VDP1+VDP2 combined have much more rendering bandwidth than the PSX GPU does by itself. If the Saturn had managed to unify all its rendering bandwidth in a single, more powerful GPU set-up, it would have blown away the PSX in all types of rendering . . . or at least those that were GPU bottlenecked. (and ignoring quads vs triangles for the moment)Quote:
Originally Posted by TrekkiesUnite118
That's actually one of the biggest arguments for "what if" Sega designed the Saturn differently. One based solely around a fast 2D/3D GPU/blitter style graphics engine with roughly the combined bandwidth of VDP1+VDP2 could have been awesome all around and more straightforward to program for, more flexible, etc. (not necessarily cheaper than the existing Saturn set-up -depending on other factors- but almost certainly a much better value since that power/cost could go to real use much more often)
It's not like that should have been impractical to manage either . . . VDP1 at 2x the clock speed may not have been practical with the manufacturing tech Sega was using (.8 micron CMOS), but doing a similar VDP that operated at 32-bits wide rather than 16 and was optimized for fetching/drawing muiple pixels/textels per read/write could have done it. (like the 3DO's GPU, but more than 2x as fast -3DO uses 12.5 MHz 32-bit wide DRAM/VRAM, Saturn uses 28.6 MHz SDRAM) Plus, double the texture/sprite RAM (1 MB instead of 512k), assuming you kept the same 1.5MB total video/graphics RAM.
That sort of design wouldn't be totally superior to what the Saturn can potentially do with VDP2's BGs, but in practical use it would be much better in the vast majority of cases. (having actual multiplicative lighting/shading like the 3DO or PSX would have been nice too . . . and alpha blending beyond 1/2 transparent -overdraw on quads would still be a problem for warped/3D stuff, and I think the 3DO shares that problem -pretty sure it uses warping and not rasterization for its quads)
Again, I didn't say the effect didn't have benefits on the Saturn. In fact I keep pointing them out. I am simply saying the PS1 could do a Mode 7 style floor. That doesn't include every single VDP2 effect, nor does it say the Saturn has no benefits with the effect, nor does it deny what developers have stated. The mode 7 effect in and of itself, meaning the floor and only the floor, is doable to the same level of quality on the PS1, it just doesn't have the benefits it does on the Saturn making it less practical to do.Quote:
Originally Posted by Team Andromeda
Learn to read TA, not just other people's posts, but your own as well.
The Playstation might be able to render the kind of perfect/solid, non-distorted infinite floors/ceilings that the Saturn can (heavier duty than SNES Mode 7). But judging from the games, it can't do them in an average game environment, it must still use less resources to use polygons instead.. but even then, in an average game environment it can't push as much overall as the Saturn's floor/ceiling + 3D combo. Even with the compromised quality (seams, distortion, limited distance, etc).
So what TA has said at times (he kept wording things differently) is true, the PSX has trouble doing it (compared to Saturn). Just as the Saturn can technically do everything the PSX can, but isn't as versatile with some things.
TA always talks in absolutes, that's the problem.Quote:
Originally Posted by Black_Tiger
Most of the time when i try to play a playstation game the polygon tearing annoys the hell out of me so i play a Saturn game instead. All the jittering and tearing in some PS games can borderline give me a headache sometimes. (some games are worse than others)
Both the Saturn and the Playstation can do mode 7 style ground as well as numerous 2d tricks such as the ground scroll in Street Fighter / Mortal Kombat. The Saturn just does them more effectively because it has a chip in it specifically for that, while the Playstation has to do it by manipulating polygons. If not having a specific hardware to do this means that the machine cannot do it, than no hardware past the Saturn can do 2d or 3d backgrounds whatsoever, which is obviously not true.
From where do we know what node the Saturn custom chips were manufactured at? Also; there were at least 2 major versions of each custom chip, and I'm fairly certain that the latter ones were die shrinks.Quote:
Originally Posted by kool kitty89
As far as "what if" scenarios go: give the SCSP hardware compression support, make the SCU DSP actually useful for 3d math to the same level as the PSX GTE (I'm not sure if this was a problem with the chip, the clockspeed, or the lack of development tools - my bet is a little bit on all three), and give the VDP1 some kind of cache that can be used to track which pixels were already processed, to eliminate the pixel overdraw problem and save some bandwidth. If the DSP is made powerful enough for 3d math, you could possibly ditch the Slave SH2 to keep costs down. Also, while we are at it, add in more levels of transparency for the VDP1: the way that thing works, it would be just setting a multiplier.
SCSP can wipe floor with pretty much anything if its synthesizer capabilities were used. You could do ADPCM or something more fancy with the SCSP DSP aswell .... which was also rarely used, only sometimes for reverb and filters... 126 cycles per sample can do quite a few channels. Even the 68K alone could do that for quite a few channels.
I thought we established that the SCSP's DSP could only do effects on the sound output, not actually process data before it was fed to the DACs (or manipulate data in RAM), hence why the 68k handled decompression as often as it did.Quote:
Originally Posted by TmEE
OTOH, there was also talk of the SCU DSP being employed for sound processing, since many games opted to use the SH2s for geometry, leaving that processor free . . . albeit limited documentation/tools could have hindered that too.
The original point had nothing to do with 3DO performance relative to the Saturn or PSX (which I don't think anyone will contend here), but the big issue was claming the 3DO hardware had trouble even keeping up with effects/features common on the MD and SNES.Quote:
Originally Posted by TrekkiesUnite118
And really, it should have taken less than 1/2 the 3DO's rendering bandwidth to match pretty much anything on the SNES or MD on their own terms, while easily having the potential to beat those in other areas in those same types of games (color, animation, graphical effects, sound, etc). Even with inefficiencies of using C and a graphics library, it shouldn't have been that bad. (the libraries may have been restrictive, but they at least should be reasonably well put together for the features they do support directly . . . and coding purely in C for the CPU isn't ideal, but compared to what the SNES and MD had to work with, it shouldn't have been a big issue even with the bus contention and C usage)
The entire Saturn chipset (including the SH2s) should be using .8 micron CMOS chips . . . maybe with some minor exceptions, but I believe the core custom chips and definitely the SH2s were .8 micron. (some stuff might have been 1 micron, but I doubt it -even the 3DO was fairly conservative going with 1 micron in 1993 -well, targeting that much earlier in the design phase obviously- and the Jaguar was more aggressive with .8 micron too -more so in the context of deciding that back in 1990 and having first silicon in late 1991 -for TOM's first revision)Quote:
Originally Posted by zyrobs
I'm not sure there were ever die shrinks either. I know a few things were consolidated (like the 68k merging with the SCSP), but that may have been using larger chips of the same process. (silicon gets cheaper all the time too, so that becomes more feasible, die shrinks aside)
Plus, going below .8 micron would be problematic with the Saturn being an all 5V design. Anything below .8 micron* needs lower supply voltage and thus a heftier redesign would have been in order for the system as a whole. (hence why the PSX uses 3.3V logic in the first place -pretty sure those were all .5 micron . . . might have been .6 or .65, but I remember .5 micron specifically coming up before)
*--There's a few cases of .75 or .7 micron chips running at .5 volts, but those are probably right on the line. (AMD's 5V 486 DX2s did that iirc, not sure if there are any other cases, 5V below .7 microns is definitely a no-no though)
I'm positive the 3DO used 1 micron ASICs and the jaguar used .8 micron.
In any case, all of that is tangent to my supposition about the Saturn using a wider, slightly more feature rich (3DO-like) VDP1 in the Saturn. The Saturn VDP1 was already running at more than 2x the speed (at least on the I/O end -RAM access) than the 3DO's Cel engine (GPU), but the 3DO worked on a 32-bit bus and had optimizations to handle reads/writes of multiple pixels at a time rather than the single pixel 16-bit wide access of the Saturn. (don't think even 8bpp mode on the Saturn changes this . . . 3DO definitely does 2 16-bit pixels at once though, hence 25 Mpix/s at 16bpp on a 12.5 MHz 32-bit bus)
Slaving an SH2 to 3D math was easier to program and faster for the most part than the SCU DSP. Had they used a single SH2 (let alone SH1), the SCU DSP would have been absolutely critical to 3D performance though.Quote:
As far as "what if" scenarios go: give the SCSP hardware compression support, make the SCU DSP actually useful for 3d math to the same level as the PSX GTE (I'm not sure if this was a problem with the chip, the clockspeed, or the lack of development tools - my bet is a little bit on all three), and give the VDP1 some kind of cache that can be used to track which pixels were already processed, to eliminate the pixel overdraw problem and save some bandwidth. If the DSP is made powerful enough for 3d math, you could possibly ditch the Slave SH2 to keep costs down. Also, while we are at it, add in more levels of transparency for the VDP1: the way that thing works, it would be just setting a multiplier.
This is somewhat unrelated to the current discussion, but can the n64 turn off its texture filtering? Could a game be programmed to not use texture filtering? Or Is it just always on no matter what?
I think that's what the Turbo 3D mode/microcode does but don't quote me on that.Quote:
Originally Posted by AlecRob
Will you stop that . Mega Drive can do OutRun , the PC Eng can do Power Drift but they're miles of the Coin Up's thanks to lacking scaling Hardware. My old Pentium II 400 Mhz Pc could do Half Life , could do unreal but you add in a 3DFX card and thanks only to hardware support for effects the game looks better, my old ST (hell even my CDI) can do parallax scrolling but its miles of what the Mega Drive, Snes and Amiga can do .Quote:
I am simply saying the PS1 could do a Mode 7 style floor
Any system can do a effect or a game with in reason , hell the Mega Drive can even do Virtual Fighter II , the GB Resident Evil but that cames at a cost Or what are you saying now that the PS can do everything the Saturn can do and its games look as good as Saturn games ? Given that you the one more that most singing the Saturn praises, pointing out its advantage in games is beyond me , when all the time the PS could handle Saturn games and all its effects .
It's an option in Hexen 64.Quote:
Originally Posted by AlecRob
TA, once again, completely misses the point.
Interesting, I wonder how that improves performance then. The DS pretty much proved that texture filtering doesn't really improve the image quality, just changes it. I thinkQuote:
Originally Posted by Black_Tiger
that one N64-PS1 3D action-adventure game with the dead guyShadow Man let you turn on and off the texture filtering in the Dreamcast version too. The setting was just "blurred, realistic" or something like that.
Quote:
Originally Posted by Kamahl
To be fair, he probably meant "3DO can't do Mode 7 exactly like Mode 7 at the same framerate and exact color and appearance." So in the same way the PS1 can't do VDP2 floors and not suffer color loss, add gouraud shading and full screen dithering/filtering and probably suffer framerate loss. We all like to say that the Sega CD could handle Super Scaler games and Sega was weird/stupid/wetalldid for not making all_of_them for the platform. But the reality is the Sega CD couldn't do even System-16 colors and framerate in scaler games. I'm pretty sure that is where TA has been coming from the whole time.
But that's not what he says now is it? And when people say "is this what you mean (insert that quote)?" he just parrots what he said before, usually with some partially incorrect quote from some developer in a magazine. Afterwards he uses terrible unrelated examples to prove his non-existing point. People don't say the Sega-CD could make perfect ports of Super Scaler games, just that it could do much better versions of them then the genesis, since the genesis can't do them in any way shape or form at an acceptable framerate (just shitty animation based approximations like, ironically, TA's stupid examples in his previous post).Quote:
Originally Posted by sheath
I know, he gets hung up on his own particular interpretation of a particular quote and doesn't let go. But, I think it is relatively true that making other systems approximate warped 2D backgrounds without hardware support usually results in trade offs. I think that is all he is being obstinate about.Quote:
Originally Posted by Kamahl
Yes it is. But that's not what he says, if it was, discussions with him wouldn't go on for 50 pages.Quote:
Originally Posted by sheath
"Discussions" are going on for pages because people are trying to make other people admit they are wrong and lament over their own foolishness. This will not happen.Quote:
Originally Posted by Kamahl
You misunderstood my post. Had he clarified his position as what you said (and we tried to ask if that's what he meant multiple times on every single subject he "discussed") it would have stopped right there and then. This is not the forum discussing, it's the forum arguing with TA because he's an idiot.Quote:
Originally Posted by sheath
There's no performance improvement IIRC (in Hexen's specific case). It just looks less blurred and fucked up with the filtering off.Quote:
Originally Posted by sheath
I'm pretty sure even the original "fast 3D" code offered that. The API should have the ability to turn on/off any effects that aren't hard-coded by the GPU . . . it's just more limited by the things that are actually handled in software by the RSP (more or less). The big thing about "turbo 3D" was use of lower precision geometry computation. (the texture cache management was also a big issue -which is handled in software by the RSP- but I'm not sure if they changed that for Turbo 3D -a huge issue was being limited to 1 texture per polygon without the ability to tile . . . the higher poly budget of turbo 3D helped work around that in any case though -tiling polygons themselves)Quote:
Originally Posted by TrekkiesUnite118
The thing is, many of the features don't gain you much or any speed boost when disabled, and this may very well be a hardware feature. (or at least with the way the API/RSP coding is typically set up) There's several contemporary PC GPUs that did nearly all their effects at full speed, like comparing the Voodoo to the Rage or ViRGE series cards. (Rage and ViRGE had considerable gains when reducing filtering, z-fogging, and some other effects -Rage even had gains for reducing perspective correction detail -I think Nvidia's Riva 128 may be closer to the Voodoo in these respects, but I'm not positive: I do know that the Riva and Voodoo both were limited to 16-bit color depth for 3D while the ViRGE and RAGE all did 32-bit color -in the ViRGE's case it actually avoided some errors/bugs seen in 16-bit mode, like the rectangle mattes around alpha textures)
Most games that offer unfiltered textures as an option or cheat code (or gameshark hack) do it for aesthetic reasons alone, either for the odd case where the game might actually have some specific art that looks wrong filtered (bigger deal for some 2D stuff too) or as a joke or testing mode. (I think one of the Tony Hawk games had a "playstation" graphics cheat code as a joke)
Wrong on the Mode 7 comment. 3DO (and PSX) both render at 15/16-bit color depth, and the SNES uses paletted 15-bit RGB color. So a "mode 7" style rotated/scaled 2D object (software raster effects applied for perspective -as with SNES) using a 256 color paletted texture should be identical in appearance as the SNES. (aside from the higher screen resolution)Quote:
Originally Posted by sheath
Handling it at similar framerates as the SNES should also be very doable . . . definitely if you're talking about the same limited usage as the SNES allows (no other BGs on the same scanlines as "mode 7" only sprites on those lines). The Jaguar would have a harder time with it, but that's another story. (texture mapping limitations of the blitter)
Actually it is. The original argument was TA's claim that the 3DO couldn't handle some effects common to MD and SNES (first parallax/scroll layers and then the Mode 7 thing) style graphics, and it really should be able to comprehensively outperform both of those in every category. And, hell, Mode 7 should be less GPU taxing than managing 2 or 3 scroll layers given how limited its use is on the SNES. (plus the comment about doing things "in hardware" totally nixes mode 7 in this context anyway, since "hardware" can only treat it as a single rotated/scaled object, and it takes added software assist to manage the raster effects for perspective -granted, all this is software controlling over graphics hardware to some degree, which is part of the point of the counter-argument in the first place ;))Quote:
Originally Posted by Kamahl
Bringing the Saturn into the picture totally changed things though, since that has massively more rendering bandwidth (VDP1+VDP2) than the 3DO (and without contention), and the PSX has a great deal more resources for 2D as well. (again, without CPU contention)
SNES doesn't have "hardware" support for warped rotated BGs either . . . that's a software assisted effect applied to the more limited scaling/rotation of a single tiled plane/object that Mode 7 handles.Quote:
Originally Posted by sheath
I'm still discussing too. :pQuote:
Originally Posted by Kamahl
I'm actually addressing other aspects of these arguments and pointing out some interesting specifics or possible contention in the actual arguments. (and clarification -like the whole point of the original "argument" on the 3DO that cropped up in the 4th gen thread being from SSFII's scrolling and TA's claim that the 3DO couldn't handle MD/SNES quality effects properly) --which is also why I refrain from commenting on many of TA's further responses in general. (nothing new/different to comment on :p )
For that matter, I'm still wondering about the SCSP's DSP again, now that Tiido brought it up. (I'm pretty sure we established several times that it wasn't useful for compressed sample decoding . . . in fact I recall him actually explaining that himself before)
Yes of course, Mode 7 proper is only scaling and rotated square objects, the tilt is just, what, line scroll effects using rasters. Still, it is hardware supported and not all software as it would be on other fully or more capable platforms.Quote:
Originally Posted by kool kitty89
The biggest problem is they wouldn't bother making a flat scrolling/rotating floor with "256" colors just to look exactly like a SNES game, though I guess they did in Chrono Trigger and Final Fantasy IV and whatever else. On the 3DO the closest I've seen is BC Racers minus the scaling sprites and low-low framerate. Otherwise clearly the system can do better than Mode 7. Atari Karts is also a nice 60FPS higher color higher resolution example than Mode 7.Quote:
Originally Posted by kool kitty89
The SNES should technically be able to do 8+ cell scroll layers like some Genesis games do as well, but it just didn't happen because it wasn't as easy to implement. My point wasn't that it was technically impossible, but rather technically unlikely to be implemented in exactly the same way.Quote:
Originally Posted by kool kitty89
3DO, PSX, or Jaguar wouldn't be doing them "purely" in software either . . . 3DO doesn't have near the CPU resource to do that competently, but all 3 of those have hardware texture mapping capabilities (including drawing scaled/rotated rectangular objects or "sprites").Quote:
Originally Posted by sheath
And in the Jag's case, it wouldn't be able to do 60 FPS in some cases. (like mode 7 used as full-screen running at 60 FPS on the SNES . . . well, technically you could if you used fast ROM -or on the Cojag- due to having multiple interleaved RAM/ROM banks for higher bandwidth -blitter is unbuffered and only renders one textel at a time for rotated objects, at only ~2.4 Mpix/s peak, so less than 1/10th that of the 3DO, CoJag should do ~6.65 Mpix/s)
The 3DO and PCFX would be the only consoles of that time without hardware support and with enough CPU grunt to at least moderately handle those sorts of effects in software. (computer platforms with faster CPUs are another story, of course)
True, but I was just addressing TA's original comments (both the Mode 7 and SNES/MD parallax thing). As to "256 colors" . . . that's actually not unusual for 3DO textures . . . I'd expect a ton of 3DO stuff to stick with 16 color textures to save space.Quote:
The biggest problem is they wouldn't bother making a flat scrolling/rotating floor with "256" colors just to look exactly like a SNES game, though I guess they did in Chrono Trigger and Final Fantasy IV and whatever else. On the 3DO the closest I've seen is BC Racers minus the scaling sprites and low-low framerate. Otherwise clearly the system can do better than Mode 7. Atari Karts is also a nice 60FPS higher color higher resolution example than Mode 7.
("Texturemap source bitmaps can be 1,2,4,6,8, or 16 bits per pixel and are
RLE compressed for a maximum combination of both high resolution and small
storage space.")
So that's 2, 4, 16, 64, 256, or 65k colors. (or subtract 1 if transparency is present -ie for non-rectangular or non-solid tiles/sprites)
And, again, texture mapped effects on the Jaguar will only be able to hit 60 FPS in some situations due to the blitter bandwidth limitations. (Mode 7 will beat the Jaguar in speed for full-screen rotation effects) I'm also not sure Atari Karts is using highcolor textures . . . it would have made more sense to use 8bpp (256 color) textures for the terrain and perhaps a mix of color depths for the sprites (probably 256 colors or less). The Jag's CLUT only has 256 entries, so you won't get more than 256 unique colors on sprites unless using 16bpp (uses lots of space), though you could certainly have more than 256 colors on-screen due to shading/blending effects. (selective use of 16bpp textures wouldn't be totally unrealistic either, but it's definitely going to cost you on animation and/or texture detail/resolution/size)
In any case, SNES mode 7 stuff should be similarly colorful as 3DO/Jaguar/PS1 stuff consuming similar amounts of memory. Granted, the VRAM (and DMA) limits on the SNES would greatly reduce the maximum practical resolution of textures and/or number of unique tiles used. (it's also limited to a tileset of 256 unique 8x8 cells, and 128 colors if you want per-pixel priority)
In general though, mode 7's raw color capabilities are great, the best of any video mode on any console of that generation. (256 colors from 15-bit RGB with any pixel on any tile able to use any of those colors -and separate from the normal sprite/tile palette entries; of course, that also means each pixel takes up 2x as much as 15 color tiles) The higher resolution/detail allowed by the open-ended texture sizes/resolutions would be a much bigger advantage for jag/3DO examples (scaled sprites and polygons aside).
What do you mean by 8+ cell scroll layers?Quote:
The SNES should technically be able to do 8+ cell scroll layers like some Genesis games do as well, but it just didn't happen because it wasn't as easy to implement.
Almost no platform would be implemented in exactly the same way, be it differing tile/sprite formats, or totally different rendering mechanisms altogether. (be it doing sprites like the 2600/A8, or sprites/objects like the 7800/Panther/Jaguar, framebuffer/blitter type rendering, multiple hardware framebuffers, mixed tile/sprite/framebuffers, etc, etc)Quote:
My point wasn't that it was technically impossible, but rather technically unlikely to be implemented in exactly the same way.
Having to implement something differently is a very different matter than being genuinely difficult to program, and the 3DO isn't even a "weird" architecture (like the 7800 for its time) since framebuffer/blitter style rendering was a very common technique to use.
Lack of parallax on SSFII on 3DO is just about as stupid as the almost absent parallax on the FM Towns SSFII release.
Eight or more independently scrolling rows or columns of 8x8 pixel tiles. As seen in "parallax" backgrounds in Genesis games like Sonic 2, Musha, Ranger X, or whatever else. That is as opposed to line scroll effects on background segments. It is what TA is referring to when he says that no other system can do parallax like the Genesis. Other system's can, they just don't have any (or many) games that manage it because it wasn't a hardware supported effect. On the Genesis the VDP handles it in a different way than other systems, even though H-DMA should supposedly make the SNES just as capable.Quote:
Originally Posted by kool kitty89
Pretty much the whole point in a large nutshell.Quote:
Originally Posted by kool kitty89
Rows are easily done on the SNES . . . AFIK the only reason for a game to feature or lack that would be sheer artistic choice. Linescroll could take a little more CPU overhead since you're managing a lot more specific PPU interrupts (at least for a large area of linescroll -like floors in fighting games or the BG in EWJ2's "Puppy Love"), but it's not a big issue.Quote:
Originally Posted by sheath
Doing "parallax" that way on the NES or SMS (and obviously PC Engine) was quite doable too. (or C64, or Atari 800, Amiga, etc -anything with hardware scrolling and some sort of raster/scanline interrupt support, be it tile or framebuffer based graphics -software scrollers could obviously do it too, but that's a different context in general)
Column scroll OTOH is a different animal entirely and is one of the MD's more interesting features. It's not on an 8x8 tile basis either; it's in 16 pixel wide columns, but still useful and something that was not a common standard feature of other hardware scrolling game graphics hardware. I don't think the SNES can actually do that at all, I know the PC Engine doesn't do it, and I know the Amiga physically can't (it's a linear framebuffer type system so it can't segment vertical scrolling, that is, but it could use brute force blitter drawing to "scroll" columns -on the ST it wouldn't matter since scrolling columns would about as resource intensive as screen scrolling in general)
I've seen mention of the SNES's mode 2 graphics allowing tiles to be "individually scrolled" (including the wiki entry), but I'm not sure whether that refers to column scroll or not. (if it does, that would imply better column scroll than the MD in that it's got 8-pixel granularity rather than 16 pixel)
Right, in the discussion I had over at spritesmind what I was stipulating was relegated to "excessive" scrolling. The most "rows" I have seen in a SNES game is five in Super Valis IV, I'm pretty sure I saw another game do the same recently though. Still, something to the extent of Ranger X, Sonic 2 (Especially Aquatic Ruin), Thunder Force IV or even Gynoug/Wings of Wor seems out of the SNES' reach. I think the TG16 could do it if not for the single background. It does seem like it takes up too much CPU on the SNES to pull it off, or it could be a simple artistic choice. I just can't imagine why more depth of field would be a bad thing artistically.Quote:
Originally Posted by kool kitty89
I wonder what the deal is with column scrolling, is it too hard because DMA and registers are on a per line basis? I know the VDP has actual Vertical Scroll RAM to facilitate the effect.Quote:
Originally Posted by kool kitty89
Supposedly H-DMA fixes everything on the SNES, it just didn't in a production game.Quote:
Originally Posted by kool kitty89
"Individually scrolled" is exactly what it says, you can scroll each tile individually. See Super Bonk 2.
It's just an "artistic" choice, in that its use isn't restricted by hardware power in 16-bit games. It's more the opposite, in that it was more used as filler to save space by making tiled spamming look less repetetive. Which is why you didn't see it in arcade games, but did see it in 8-bit console games. In games like Mickey Mania(?), the Genesis verson uses it a bit at the bottom of one layer while the SNES version has an entire extra overlapping scrolling layer. PCE games have 20+ strips at a time. The floors in 3DO SSFIIX are basically 50+ strips of the same thing, only one(?) pixel thick. The fact that it's a relic if the 8-bit generation is a good sign that it's not a cpu intensive eftect.Quote:
Originally Posted by sheath
Sonic unfortunately popularized a mixture that gives an unrealistic depth of field. Instead of creating the kind of depth that the mutli-plain camera was designed for, Sonic games give the impression of holding an ant farm in front of your face and walking in front of a wallpapered wall. The layer that Sonic interacts with is so tall that the strips behind shouldn't be so thin for many elements and the back layer in general shouldn't scroll much vertically. Instead it's just a "video game" effect for the novelty of having a cool looking effect, instead of a depth of field effect. But since Sonic was so big on Genesis, too many Genesis games tried to ape the overall effect, often moving further away from real depth of field. SNES games went for more of an arcade aesthetic right from launch.
PCE games (such as Browning and the Downloads) seem to more often scroll those horizontal strips vertically and overlap them, creating an even greater depth of field impression (when done right). I believe that it is again, done to get more out of limited storage space than super powers of the hardware and I'm sure it's no problem for SNES and Genesis.
Can't unsee...Quote:
Originally Posted by Black_Tiger
Where in Super Bonk 2? I didn't notice anything obvious? Plus that game runs in mode 1 for the main game parts, not mode 2 (4 color tile layer used for status overlay) and it seemed like that scrolling feature was specific to mode 2.Quote:
Originally Posted by Kamahl
Video is scanned out to the screen a line at the time . . . sprite data is buffered into line RAM in h-blank and tile data is scanned out during active display. (a pretty common arrangement, and even the Amiga does something like that, sprite in hblank and framebuffer(s) in active display)Quote:
Originally Posted by sheath
Since it's a line at a time, you can use interrupts (CPU interrupts and/or VDC/VDP/PPU/etc interrupts depending on the system) and modify certain parameters before the next line gets scanned out. (or set it up to do it on a row basis rather than line, depending on the system in question)
Vertical strips are another matter entirely, and need specific hardware support to make possible . . . or have interrupts between every single pixel/tile segment fetch, but there's almost never support for that and it would take a lot of overhead if it was supported. (you'd need a bunch of interrupts each line rather than 1)
With a specific table to control column scrolling, this can be handled by the VDP(etc) and adjust the scroll position of the individual tile columns (or pairs of tiles in the MD's case -16 pixel wide strips). This is more practical on a tilemap based system since it's already using a nonlinear display system (using a table to select which tiles to scan out when/where rather than linear data scanning as in a framebuffer . . . or even a specifically arranged nonlinear framebuffer like the ZX Spectrum -reading pixel and color attribute data separately).
You could technically allow for similar support on a framebuffer based system, but it would take a much larger table to support, since it would be controlling vertical scroll of a ton of single pixel tall line segments rather than tiles. (you'd also need the bandwidth available to have the VDP reading the added data from that table mid-screen . . . or more hblank bandwidth and more registers or buffers to account for the more complex display lists/commands) -So, again blitting (software or hardware) is the main option for vertical column scroll with framebuffers.
On an "all sprite" system, you'd avoid that issue, but be limited to scrolling columns by the width of the sprites used. (narrower sprite strips gives finer columns)
Wow . . . yeah, Sonic 1 MD looks really weird in that respect, and the fast autoscrolling clouds in the JP version make it even weirder.Quote:
Originally Posted by Black_Tiger
Sonic 2 and 3 don't seem to do this. Emerald Hill zone in particular makes a very obvious contrast with very slowly scrolling far BG in a similar scene as Green Hill Zone. Some other stages have faster BG scrolling, but it makes more sense since that's things like walls, ruins, or a forest (Angel Island) where the "far" BG is much closer than in Green or Emerald Hill.
Emerald Hill actually looks WAY better now that I think about it. (I'm not really a fan of the blocky art style used for some of Sonic 1's BGs either . . . I realize it's a reasonably well adapted design that allowed for much better compression in ROM, and it looks OK for what it is, but when you can actually spare the space for proper detail the difference is definitely noticeable)
The big pixelated bonk face animation is using mode 2.Quote:
Originally Posted by kool kitty89
Funny how y'all are taking about 16 bit consoles in the 32bit console thread.
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.