sheath, on Mon Jan 9, 2012 12:08 PM, said:
10p6, on Sat Jan 7, 2012 9:22 AM, said:
I disagree. For one nothing is special about Starfighter at all on 3D0 or Acorn. Second, programmers go on about the Jag being so hard to program, yet I seen a demo of AVP before the Jag was even released and nothing 3D wise ever really improved over the Jags lifespan when it should have. As for 2D sprite handling of games, look at Outrun and others on the Saturn, then go back to Super Burnout on the Jag, especially in two player mode which shows what it could do. If the music in SB was streamed from CD instead of processed, then that opens up even more processing power.
This is categorically untrue. Starfighter is the only space ship sim that allows you to enter orbit from the planetary surface that I have ever played. The ship physics aren't shabby at all either. Then there is being able to see the planetary surface in real time from space and fly right back down to it, I would be surprised if there was another game that let you do that. It is even noteworthy that neither the Saturn or PS1 versions manage this, instead they both have grey nothing to look through while in space.
Starfighter is an extremely notable and unique game.
I think he meant "nothing special" graphically. (compared to what the Jag is capable of -though that's arguable too, at least as far as the texture mapping at that framerate)
As for gameplay though, Starglider II (and I think the original too) allowed you to fly into space and travel to other planets (and have space battles/dogfights) as well as surface flight/combat. back in the late 80s (on Atari ST/PC/Amiga). Frontier (Elite II) also allowed that among other things. (though that's from 1993)
Both of those do it in realtime too, not in separate levels or such. (Star Fox II is somewhat like that, but still is segmented into separate levels and an overworld -though still non-linear and non stage/mission based)
sheath, on Mon Jan 9, 2012 4:08 PM, said:
I would buy a modern HD free flight shooter that allowed you to exit/enter the orbit of a planet at will in a heartbeat.
I think there's actually some free online games that allow that . . . I remember a review/preview for an MMO-style space flight/combat/trading sim a couple years back. (it looked pretty interesting, but also probably addictive/time consuming
)
I think wikipedia has it listed in their space combat/sims game list page. (look at the releases from the last couple years)
There's been a number of recent indie/homebrew projects in this genre, including several built on the freespace II engine. (Shadows of Lylat is still in the works -the latest test/demo videos look amazing . . . and on such an old engine at that
)
10p6, on Sat Jan 7, 2012 6:42 AM, said:
From my personal experience I would say that the Jag runs rings around the 3D0 in 2D graphics, and sound. I believe it could have on 3D too if programmers learnt how to take advantage of the full system. For programming though the Jag is like a pickup truck with a big engine, it's hard to get the power where you need it, especially from the start. With a custom top notch development system, I think the Jag could outperform the Saturn too, especially with the CD unit so it would not have to process music.
Crazyace, on Sat Jan 7, 2012 8:17 AM, said:
10p6 , are you talking about programming both machines?
I definitely disagree with you about Jaguar beating it in 3D - and there's no way the Jaguar would ever outperform the Saturn.
As far as texture mapped primitives in 3D space (ie using the native quads of the 3DO and Saturn), yes the Jag couldn't keep up. (though there's some cases where the more limited CPU resource -vs DSP+GPU resource- could be the limiting factor on the 3DO -albeit more limited in context since the jag needs the RISCs to handle the 3D math vs the coprocessor in the 3DO -and the DSP in the Jag has nasty bus bottlenecks).
However, in the context of "normal" rasterized triangles (or rasterized -not warped- quads for that matter), the comparison with the Jag would be much more favorable . . . and likely faster than the 3DO (due to the slow CPU -though texture bandwidth would still be an advantage), while the Saturn would still likely be significantly faster. (fast dual CPUs -potential to use the SCU DSP too- and VDP1 on a separate bus).
The Saturn also has the disadvantage of lacking texture expansion support in 15-bit RGB mode (the Jag blitter also can't do that though), so textures will take lots of space (unlike the 3DO or PSX) . . . and you loose the ability to shade/light/blend when using indexed color modes. (and even in 15-bit RGB, shading is limited to simple additive RGB effects, not proper linear/multiplicative lighting as CRY allows -and the PSX and most other 3D GPUs . . . or 256 color shading on PCs for that matter -depending on the palette and LUTs used you could have proper linear shading or a close approximation thereof)
Then there's the more open-ended question of non polygonal 3D/pseudo 3D representations (voxel/span renderers), but the Jaguar would still be bandwidth limited there too while the Saturn would retain similar computational resources (though the GPU+blitter set-up and feature set favors some added possibilities for effects less practical on the Saturn -like the interpolated voxel renderer used in PZ- though a normal voxel/ray-cast renderer may very well be faster on the Saturn, and sprite scaling would obviously be faster in a framebuffer context -cases like most polygonal games and AvP/Doom/PZ rely on blitter rendered scaled sprites rather than OPL sprites -since you need per-pixel depth priority- and blitter sprite scaling is slow for the same reason texture mapping is -the affine rendering logic is relatively basic and limited to single pixel read/writes, no optimization for 64-bit or FPM accesses -well, FPM could be used from SRAM, ROM, or a 2nd DRAM bank)
For 2D it's another story though. The Jag is generally better than the 3DO, but the Saturn is more of a mixed bag. (games that make a good/balanced use of both VDP1 and VDP2 capabilities will tend to smoke the Jaguar, but more "spritey" games could favor the OPL of the Jaguar and make things closer to even -then there's trade-offs of priority/blending/etc of blitter/OPL graphics vs VDP1+VDP2, but that's a more complex issue, among other trade-offs)
Crazyace, on Sat Jan 7, 2012 10:32 AM, said:
Regarding the 2D comparision SuperBurnout is really nice on the Jaguar - but dont think that Outrun is really stretching the Saturn technically. You might want to compare PowerDrift - as that is slightly more technical - or trying looking at StreetRacer's saturn version compared to Atari Karts.
Galaxy force would probably be a good comparison too . . . especially since it uses rotation (which would mean a lot of blitter overhead on the Jag). Games limited to pure scaled (non-rotated) objects would be the most competitive for the Jaguar OPL. (and probably one of the bigger weaknesses of the Jaguar for 2D -or the primitive blitter in general- . . . rotation/warping effects were pretty significant for 2D games of the time -some older/current console games as well as arcade and PC games and subsequent next-gen console games- and the limits of the Jaguar blitter crippled it for those types of 2D effects as much as it did 3D texture mapping -albeit some other areas limited 3D rendering in general, like 3D math+rasterization overhead for the GPU)
Crazyace, on Sun Jan 8, 2012 6:37 AM, said:
It sounds a bit like a layered voxel scene - but the memory costs would be exorbitant.
For your example ( using 8 bits per pixel to save memory ) a single 1280x800 layer would need 1000KB of storage - How many layers would you have - 8,16, or more?
Also how are you going to generate these images in the first place.
And rendering would be expensive - for every pixel you effectively either paint all of the layers from back to front - or 'raycast' from front to back to find the first non opaque pixel, In the first case the OP is the best way, and I think you'll run out of b/w after 10 layers of 320 pixels.
Doing the other way would involve gpu - and be a lot slower ( at least a load/cmp/jump per pixel per layer ) - so you might have trouble with even half that many layers.
Also - if you really want full 3d you have to have a real volume ( 1024x1024x1024 ) to allow any viewing direction.
Of course you might be talking about something simpler, like the scaled sprite compositing made famous by Sega ( and used to great effect in Super Burnout ) - with that the Jaguar can shine, but it's not really full 3D.
Voxel space type engines are interesting, and have potential for flexibility/interactivity beyond conventional polygons . . . but for full 3D projected/layered pixels as such, the resources (memory and computation) would be huge. (perhaps something possible for future generations though . . . sort of like the potential for realtime raytracing
)
OTOH, the "short cut" examples of voxel/height-map span renderers (ie using ray casting in PX/Commanche style -or Doom/Duke style spans) are another story and have a huge advantage in computational simplicity, though also a disadvantage in bandwidth use over polygon/line-fill rendering. (column rendering tends to make poor use of page-mode burst DRAM accesses since you're usually limited to reading and writing single pixels at a time and usually write to a different scanline for each consecutive pixel -so each access will tend to be a random read/write, though that would mean the Jag's slow affine mapping would fit quite nicely
-polygon games can be far better optimized for multi-pixel wide/burst accesses though -since you're filling lines- and even on a single pixel wide bus like the Saturn VDP1, you get a big sped advantage from writing consecutive pixels to the same scanline -though the SDRAM allows random read/writes at almost 2x the speed of the Jaguar)
Granted, you could design a graphics system that specifically buffered for columns (or equally for columns/lines) with something like a destination cache (rendering to a mini framebuffer cell/chunk in SRAM and then copying that out to the screen in large/efficient chunks -ATi actually implemented something like that in the Rage Pro in 1997 -source texture cache as well as a destination cache-, though obviously not intended for voxel/span performance it's still a similar concept)
Edited by kool kitty89, Tue Jan 10, 2012 6:36 PM.
4
