Why are handhelds so.......weak?
- Thread starter Fox5
- Start date
I have to ask this too... what ARE sprites then?
In Saturn, the word sprite was literally defined as affine texture mapped 4 point polygon.
That said, a PSX triangle is the exact same thing just with 3 points instead of 4, and has no 3d information of any kind either.
They are both equally 2d, (or equally not-3d, if you prefer).
Afaik the advantage Saturn had with 2d was with scrolling planes and stuff that the other chip could do on top of polygons - PSX rasterizer didn't quite have the fillrate to compete with that.
What I mean by 'not sprites' (even though sprites are moving objects, even in 3D space) is it isn't using a dedicated 2D mode... it's cheating through the 3D engine.
It'd be like accelerating Windows by treating windows as textures and slapping them onto quads (pairs of tris for most HW).
And likewise the Saturn's 4-point polygons are 2D "sprites" projected into a depth-sorted 3D space...
It's more or less an argument of semantics, I'd say.
But if there's no difference between "2D" and "3D" mode, why can Saturn support HW transparency when in pure 2D, but need to hack about when in "3D"?
It'd be like accelerating Windows by treating windows as textures and slapping them onto quads (pairs of tris for most HW).
And likewise the Saturn's 4-point polygons are 2D "sprites" projected into a depth-sorted 3D space...
It's more or less an argument of semantics, I'd say.
But if there's no difference between "2D" and "3D" mode, why can Saturn support HW transparency when in pure 2D, but need to hack about when in "3D"?
Tagrineth said:
Saturn transparency is a complicated issue, that I'm not qualified to answer (I've never worked on a Saturn but I did read the manuals once for a laugh...). Treasure mastered it but most other developers didn't, what/how they did I don't have much of a clue. Actually I did hear a rumour.... The Saturn DSP's was meant as a vertex transform unit, but being slower than one of the SH-2 it was rarely used. Treasure used the DSP as a custom blitter which included transparency in its abilities, I guess it wasn't fast enough to be used as a custom rasteriser.
The whole 2D to 3D evolution is just the old wheel of reincarnation at work. Each hardware generation added more programmability, sprite hardware could only do straight copies, then rotations and scales, the affine transforms, then perspective transforms.
Both Saturn and PSX came in under affine transform. They just came at it from either end, Saturn's was a generalisation of copying, whereas the PSX was a generalisation of flat polygon rendering. (Actual the Saturn didn't use forward mapping but 3D0 did....)
Here's a quote from Sega's developer technical support on sprite transparency:
"It is possible to instruct the VDP2 to display selected sprites so that they are partially transparent with respect to the VDP2's backgrounds, i.e., the RGB values of the sprite's pixels and those of the background's pixels are combined in a wighted average. This can be done with either paletted sprites or RGB sprites, but it's more useful with paletted sprites, since each paletted sprite gets to decide individually whether it will be partially transparent or not, whereas, with RGB sprites, either all of them are partially transparent, or none of them are, as we shall see.
Note also that, while any sprite may be made partially transperent with respect to the backgrounds, the only way in which sprites may be made partially transprent with respect to each other is to use the VDP1's half-transparency effect, which only works if all sprites involved are RGB sprites."
"It is possible to instruct the VDP2 to display selected sprites so that they are partially transparent with respect to the VDP2's backgrounds, i.e., the RGB values of the sprite's pixels and those of the background's pixels are combined in a wighted average. This can be done with either paletted sprites or RGB sprites, but it's more useful with paletted sprites, since each paletted sprite gets to decide individually whether it will be partially transparent or not, whereas, with RGB sprites, either all of them are partially transparent, or none of them are, as we shall see.
Note also that, while any sprite may be made partially transperent with respect to the backgrounds, the only way in which sprites may be made partially transprent with respect to each other is to use the VDP1's half-transparency effect, which only works if all sprites involved are RGB sprites."
marconelly!
Veteran
I think it said MIPS CPU core + a dedicated chip for graphics, video and sound.
There's no real distinction between 2D mode and 3D mode on the Saturn. In fact, the VDPs had no 3D mode. The Saturn used distorted sprites for polygons. The quote I posted explains why polygons (distorted 2D sprites) couldn't have real transparency with respect to other polygons. Think about it. Just replace sprite with polygon:
Note also that, while any polygon may be made partially transperent with respect to the backgrounds, the only way in which polygons may be made partially transprent with respect to each other is to use the VDP1's half-transparency effect, which only works if all polygons involved are RGB polygons.
Keep in mind most 2D games are sprites on top of backgrounds and 3D games are polygons on top of polygons, hence the reason why 3D games used the dithered transparency effect.
Note also that, while any polygon may be made partially transperent with respect to the backgrounds, the only way in which polygons may be made partially transprent with respect to each other is to use the VDP1's half-transparency effect, which only works if all polygons involved are RGB polygons.
Keep in mind most 2D games are sprites on top of backgrounds and 3D games are polygons on top of polygons, hence the reason why 3D games used the dithered transparency effect.
Bowie said:
I said:
I know that =) Saturn's 2D engine is simply capable of accurately handling and rasterising in depth-sorted space (no Z-buffer) by projecting sprites. It's actually a more sensible evolution from what was originally done for "2D" data (on pre-3D consoles and games), but it's more difficult to work with than triangles.
JacksBleedingEyes
Regular
Getting Back to the topic however...
Has anyone played Super Monkey Ball for the GBA.
I was I guess a bit lost for words with it. I knew the GBA could do 2.5 2D, but super monkey ball looks like a (Sega 32X) game.
And does anyone remember Nintendos neiche little flop?
What was it called... oh yeah Virtual Boy.
How about that for virtual gaming.
Eat that Sony
Has anyone played Super Monkey Ball for the GBA.
I was I guess a bit lost for words with it. I knew the GBA could do 2.5 2D, but super monkey ball looks like a (Sega 32X) game.
And does anyone remember Nintendos neiche little flop?
What was it called... oh yeah Virtual Boy.
How about that for virtual gaming.
Eat that Sony
marconelly!
Veteran
I thought about that. Maybe that's what they meant, I don't know...
It just seems to me that no matter what 32bit MIPS chip they choose it won't do much of a job at being CPU *and* GPU *and* Sound processor at the same time. PSX had 32bit MIPS core, and it had other chips for other functions, PSP is supposed to be more powerful than PSX, from what I've heard.
MIPS32 core simply means it's going to be a MIPS ISA implimentation. "Super one-chip solution" is simply marketting speak for a heavily integrated SoC.
Why bother with any PSX technology? It's gotten way too old for something in 2004-ish. It'll likely be a typical MIPS32 core with possibly any of the following;
a.) a SIMD structure mapped over the GPRs along the same philosophy as MMI (depends on how they impliment the scalar core)
b.) a variation on MIPS-3D ASE sitting on a MIPS FPU sitting on MIPS' COP1 port
c.) a knock-off of VU0 (cut-down and simplified) sitting on MIPS' COP2 or COP2 port (depends if COP2 isn't used for something else)
For straight forward simplicity, I'm thinking of something along the lines of option B (which would be rather interesting since few consoles and zero handhelds/PDAs have ever had an FPU), with the possible combination of A.
The graphics processor would probably sit on an on-chip bus or on-chip fabric (similar to Motorola's OCeaN) and possibly also be accessable to the CPU via COP2 port. Everything else (any I/O logic, memory controllers, audio DSP perhaps) would just dangle off the on-chip bus like your typical SoC.
However the truly interesting part of this thingy is the eDRAM. Most embedded SoC have at most a smidgin of cache or none at all and talk to external modules. The eDRAM makes for an interesting solution since you get impressive performance (you can easily go UMA as well), and can forgo any fancy cache architectures (maybe just a page-buffer and a couple of scratchpads for various devices to work in).
JacksBleedingEyes
Regular
Tagrineth said:
Woaw thank you Tagrineth.
Well with graphics like that
who needs PSP.
IMO, the Pocketeers have already achieved roughly PSX-quality graphics on the GBA... and I suspect GBA2 will be capable of still more, even if it's purely a 2D engine.
I'd really like to see GBA2 do something like Saturn; a seriously powerful 2D sprite engine with the ability to project quads for 3D support; perhaps even take it a step farther, and enable curved quads? Maybe even add a Z-buffer for better precision?
Curved quads -> 8)
I'd really like to see GBA2 do something like Saturn; a seriously powerful 2D sprite engine with the ability to project quads for 3D support; perhaps even take it a step farther, and enable curved quads? Maybe even add a Z-buffer for better precision?
Curved quads -> 8)
