No NGAGE 2 using OMAP 2 w MBX rumor posts here yet?

Shogmaster

Regular
What say you, Kristof!?! Simon? Spill it!! :D

http://www.ga-forum.com/showthread.php?t=39805&

Specifications for the gaming platform:
OMAP Full Compatibility
90-nm CMOS System-on-a-Chip OMAP2420

330-MHz Central Core with Floating Point Unit ARM1136JS-F

220-MHz Digital Signal Processor for Audio TMS320C55x

Video Playback and Image Display Imaging Video Accelerator
...... VGA 30-fps Encode/Decode Full-Motion Video

2D/3D Graphics Accelerator with SIMD Co-Processor PowerVR MBX with VGP
...... TBDR (Tile Based Deferred Rendering)
...... 200Mhz clock speed
...... 360Mpixels, 2xOverdraw = 720Mpixels, 3xOverdraw = 1.08Gpixels
...... ITCâ„¢ - PowerVR Internal True Colour - 32-Bit Blending and Depth Test Precision Independent from Buffer Depth
...... FSAA4Freeâ„¢ - Supersampling Full-Screen Anti-Aliasing With No Performance Lose
...... DOT3 Per-Pixel Lighting Support
...... Spherical Harmonics Lighting Support
...... Bilinear, Trilinear, Anisotropic Texture Filtering Support
...... Vertex Shader 1.1 Programmability with Skinning
...... Curved Surface Processing with Fractional Tesselation and Support for Differing Levels-of-Detail on Neighboring Patch Edges
...... PVR-TC (PowerVR Texture Compression)
...... Multi-Texturing
...... Fully Programmable 3D T&L (Transform & Lighting)
...... Over 2.5M-tri/sec

Nokia Plans on revealing the system at E3 2005.
 
I wrote up the Renesas list with the hope for more amusement that it too would eventually spread everywhere on its own, shamelessly mistaking common sense for some inside info leak.
The SPoNG mailbox today saw proposed specification for the N-Gage 2 land in it, not unusual given that on a daily basis we receive such emails from alleged insiders with Hotmail accounts.

So why do we pay these any attention? Because what was offered is an almost exact version of the mooted specs we saw during the recent Games Developers Conference in San Francisco.
Both lists are a little inaccurate, though: the OMAP2420 on MBX clockspeed and fillrate, and the SH3707 on MBX clockspeed.
 
http://www.engadget.com/entry/1234000200036866/
Not only is it not EOL for the N-Gage (remember: it still exists), but there’s some word on the street (more like back alley, but hey) about the specs for its possible next revision. A lot of the alleged features tip into some obscure hardware mumbo-jumbo that we can’t guarantee either ArcadeStation or perhaps even Nokia just invented out of thin air (you know how we love these purely speculative rumors), but click on for the run-down regardless.
The funniest part is how backward the response has been that says what good competition these specifications make to the PSP when it was actually OMAP2420 and MBX that released first, almost a year before.
 
Hmmm I'd be curious if the VGP keeps up the same "tradition" PowerVR's geometry processors or cores had until now. Normally you'd get on Elan the same performance with 1 or 6 lights f.e.
 
The unusually high lighting capabilities for ELAN were, in part, a request of SEGA's. I think the VGP is more about flexibility.
 
Lazy8s said:
The unusually high lighting capabilities for ELAN were, in part, a request of SEGA's. I think the VGP is more about flexibility.

If you can, try and find some ancient Polygon Throughput numbers from 3dmark2001 and KYROs. There's no geometry processor on those.
 
Ailuros said:
Hmmm I'd be curious if the VGP keeps up the same "tradition" PowerVR's geometry processors or cores had until now. Normally you'd get on Elan the same performance with 1 or 6 lights f.e.

Will vertex lighting be getting any use?
 
No idea. The MBX VGP is their first publicly available VS1.1; Elan is a T&L unit. Simon could maybe shed some light onto that one.
 
Ailuros said:
No idea. The MBX VGP is their first publicly available VS1.1; Elan is a T&L unit. Simon could maybe shed some light onto that one.
I should think that vertex lighting is still used but, just remember, in order to do pixel lighting, you still need to do quite a bit of per-vertex maths as well (e.g. mapping from one coordinate space into another).
 
should think that vertex lighting is still used but, just remember, in order to do pixel lighting, you still need to do quite a bit of per-vertex maths as well (e.g. mapping from one coordinate space into another).
That's not stricly true. Normal maps can actually be defined in model space as opposed to tangent space (or texture space), in which case tangent space setup is not required. Such textures are likely to occupy more space though since you need unique mapping across your model.
 
SuperCow said:
should think that vertex lighting is still used but, just remember, in order to do pixel lighting, you still need to do quite a bit of per-vertex maths as well (e.g. mapping from one coordinate space into another).
That's not stricly true. Normal maps can actually be defined in model space as opposed to tangent space (or texture space), in which case tangent space setup is not required. Such textures are likely to occupy more space though since you need unique mapping across your model.

I was discounting Model space normals for the texture space cost reason. (Well, that's my story and I'm sticking to it :) )

What happens with skinned animation and model space normals? There'd still have to be some sort of per vertex transformation of the light direction, n'est pas?
 
Back
Top