10~12 out of 32MB of PSP RAM not accessible to the devs!

[cthellis42]

...stripe now time of that appearance is required for also the status reading at the time of the sushi and starting.

Reading those things would be much more interesting if they didn't make my brain hurt.

 

[archie4oz]

Sony actually hasn't demonstrated a real unit yet. Maybe there's hope for the graphics to be even better then.

Huh?

 

[Lazy8s]

The real-time graphical demos weren't running on actual PSP units apparently, from the interview. Being optimistic, perhaps the kits they were using will be improved on for performance by the final hardware.

 

[archie4oz]

The tech demos were... The hardware units have been out for about 2-3 weeks now (although I don't know if any studio outside Sony has had access to them)...

 

[marconelly!]

The tech demos (ducky, bumpmapped planet surface, realtime lit city model) were running on real, final units. A guy who programmed them said so on Tokyopia forums. Pretty much everything else was running either on emulators and then streamed to video frame by frame, or was a terribly rushed job of adapting the code made for emulators to run on a real hardware which turned to be different and better than the emulated code was shooting for.

Did you check out the two psp demos we made, the duck of course, and the city? The psp hardware is a nice bit of kit, and I hate to say it because I like Nintendo but 3d-wise it probably blows the DS out of the water (the DS doesn't have any texture filtering by all accounts?),
.
.
.
By the time the Tokyo game show comes around and developers have had actual access to the final hardware I think we'll see some pretty amazing stuff on display...
.
.
.
They had final hardware for a few weeks in Japan - that's how we got our demos done. Actually our demos are the only examples running at the show that used at least part of the full potential of the final hardware.

All the other demos were either streamed from the emulator into movie sequences or running on the real hardware but not using the full potential. There are several features of the hardware that haven't fully detailed to developers yet, two of which are very important:- how to use vram, and the specs of the vector co-processor (which is *very* powerful).

 

[Farid]

All the other demos were either streamed from the emulator into movie sequences or running on the real hardware but not using the full potential.

ALL the others demos? Even Faf's racer?

 

[McFly]

The coder is Dylan Cuthbert: http://www.q-games.com/prof.shtml

He confirmed that his demos were basically the only thing that were really developed on final hardware, and utilized it's performance at least partially, and also said that Ducky demo was more complex and better looking than the one he did for the PS2. PSP version uses spherical harmonics lighting for realistic global scene illumination, and so does the cityscape demo which calculates global lighting and global soft shadows in realtime. He even said that with some more time he could optimize those routines to run 3-4x faster than they currently do (and yet they still run at 60FPS with given scenes)

Btw, the guy in question programmed Starfox, Starfox 2 and helped develop the 3D coprocessor chip for SNES, worked for SCAE and SCEJ, now he's a founder of Q-games.

The original Tokyopia thread: http://www.tokyopia.com/megabbs/forums/thread-view.asp?tid=887&posts=18

PS2 would be doomed if the PSP had a TV output. (j/k)

Fredi

 

[PC-Engine]

The SH technique is very good at simulating GI, but currently it only works on static geometry.

 

[London Geezer]

The SH technique is very good at simulating GI, but currently it only works on static geometry.

Really? I didn't know! Does it just not work or is it because it would be too slow to calculate the lighting and shadows for moving objects?

Genuine question, I know very little about SH.

 

[DeanoC]

First thing is that Spherical Harmonics (SH) doesn't do anything, its just a basis over a sphere. Engineering and physics have been using spherical harmonics for non graphics things for years.

Precomputed Radiance Transfer (PRT) is an approximation to GI that can use SH to encode the incoming and outgoing radiance (light basically) at each vertex or texel. The cost to use its depedent on the frequency of data captured, higher frequency costs more but you can capture more shadows etc. The P in PRT is the problem for dynamic data. For low frequency data it can be fairly fast but only just getting solution for blended data (skin character etc)

You can also use SH to encode 'normal' non-GI lights. which lets you pack loads of low-frequency lights (fill lights) in a cheap operation.

Its cool but isn't a magic fix to real-time GI.

 

[DeanoC]

The coder is Dylan Cuthbert: http://www.q-games.com/prof.shtml

Btw, the guy in question programmed Starfox, Starfox 2 and helped develop the 3D coprocessor chip for SNES, worked for SCAE and SCEJ, now he's a founder of Q-games.

Dylan also wrote a bunch of modifications for the GCC compiler to get VU0 inline asm working. Just about every PS2 game has benefiting from Dylan's work making GCC less dumb about VU0 inline assembler.

 

[StefanS]

First thing is that Spherical Harmonics (SH) doesn't do anything, its just a basis over a sphere. Engineering and physics have been using spherical harmonics for non graphics things for years.

Make that 200 years...