PS3 SDK 1.80, OS memory reductions, new features

[betan]

OS reserved memory: 48 MB (main) + 24 MB(vram)
Three new "utilities" available to developers:

1. Screenshot to XMB photos [3MB] (Very cool, we can now finalize AA and resolution discussions. I wonder which developer wanted that though. At least PR guys wouldn't want with all the bullshots around.)
2. User supplied background music [12MB].
3. Display to PSP [8MB] (I thought that was available already)

http://www.innerbits.com/blog/2007/08/21/ps3-180-sdk/
ps: I posted here as I don't see much to discuss technology-wise.

 

[DeanA]

1.80 was out absolutely ages ago.. 1.90 has been in developer's hands for a few weeks.

Dean

 

[Konrad]

1.80 was out absolutely ages ago.. 1.90 has been in developer's hands for a few weeks.

Dean

So you are saying that the list above really belongs to 1.8 SDK. And that a new one is delivered with a complete different set of requrements/tools. Or did they just mix up the versions?

 

[D3B]

1.80 was out absolutely ages ago.. 1.90 has been in developer's hands for a few weeks.

Dean

I hope that means HS supports screen shots:smile:

But any way its a cool feature and Sony should make it be mandatory for all games now.

 

[Arwin]

We don't usually get this kind of information publicly at the time of release. I assume it's leaked, officially or otherwise, and tends to lag behind reality quite a bit. But that doesn't mean it's not interesting to people outside of NDA realm.

 

[betan]

We don't usually get this kind of information publicly at the time of release. I assume it's leaked, officially or otherwise, and tends to lag behind reality quite a bit.

It's supposed to be an "unofficial" leak, at least a few weeks after release time, more if it's for 1.8.

 

[DieH@rd]

I hope that means HS supports screen shots:smile:

Screw that, I hope it supports PSP play.

 

[djskribbles]

I posted here as I don't see much to discuss technology-wise.

i posted this in the 2.0 firmware rumor thread, but i guess its getting more attention here.

 

[deepbrown]

SO OS is down to 74mb? Getting there - slowly. Now 12mb for ingame music is far too much! But I suppose devs who have been used to the previous 96mb (or 82mb) - then perhaps they can implement it. This reduction in memory usage is also good for games that don't need a custom soundtrack as they come close to finalisation (HS, Lair) since it will help the framerate!

Yay!

 

[inefficient]

Feature list is starting to get very good. Now they just need to work on optimizing for memory usage!

I wonder what language they are using to write the OS functionality. Because of the memory requirments I wouldn't be suprised if they are actually running some kind of virtual machine for security and implementing the actual functionality in a higher level language targeted to run on the VM.

 

[Rainbow Man]

Now 12mb for ingame music is far too much!

Ordinarily I'd say yes buit ewhat if Sony buffers the entire music track in memory (and reserves a large memory sapace for long tracks). This would help in games that stream a lot of data I guess since it wouldn't require spurious harddrive accesses that might slow down the loading of other data.

Not that I would consider such a solution particulary ideal, but.. *shrug* Why else woudl they need 12MB just for MP3 playback?
Peace.

 

[Shifty Geezer]

Targetting long tracks will never be enough though. Depending on encoding and track length, 12 MBs can be exceeded. The largest music file I have is a 13 MB Rachmaninov piano concerto movement. Had I ripped the concerto to a single track, that'd be nearly 30 MB. If you're going to just target a best case average, you'd be aiming at, I guess, 4 MBs to load the average low quality MP3 album track. That would serve most people's music needs. Anyone exceeding that use might, like me, be exceeding it by a lot and pushing the 12 MB limit.

I can't see any reason to exceed 4 MB. The amount of HDD access will be very small in the grand scheme of thing if you cache a suitably sized block of audio data. At worst you'd suffer a minor glitch in frame-rate for a frame or two, and given that games have that already these days, that has to be a better choice than eating 8+ MB of unnecessary RAM. Adding the full set of online extra-gaming functionality eats a crazy amount of RAM. I can't fathom why. You have three consumers - code, data and workspace. Code is small. Data in a lot of these can be small too. You don't need rich GUI data to implement a freinds list or background audio. And I can't see any reason for a lot of workspace either. I'm bemused!

 

[deepbrown]

Targetting long tracks will never be enough though. Depending on encoding and track length, 12 MBs can be exceeded. The largest music file I have is a 13 MB Rachmaninov piano concerto movement. Had I ripped the concerto to a single track, that'd be nearly 30 MB. If you're going to just target a best case average, you'd be aiming at, I guess, 4 MBs to load the average low quality MP3 album track. That would serve most people's music needs. Anyone exceeding that use might, like me, be exceeding it by a lot and pushing the 12 MB limit.

I can't see any reason to exceed 4 MB. The amount of HDD access will be very small in the grand scheme of thing if you cache a suitably sized block of audio data. At worst you'd suffer a minor glitch in frame-rate for a frame or two, and given that games have that already these days, that has to be a better choice than eating 8+ MB of unnecessary RAM. Adding the full set of online extra-gaming functionality eats a crazy amount of RAM. I can't fathom why. You have three consumers - code, data and workspace. Code is small. Data in a lot of these can be small too. You don't need rich GUI data to implement a freinds list or background audio. And I can't see any reason for a lot of workspace either. I'm bemused!

Why cant they just stream it like the 360? Is it necessary to load the whole track? What if you did part of it? I guess that's streaming... lol

 

[jonabbey]

Targetting long tracks will never be enough though. Depending on encoding and track length, 12 MBs can be exceeded. The largest music file I have is a 13 MB Rachmaninov piano concerto movement. Had I ripped the concerto to a single track, that'd be nearly 30 MB. If you're going to just target a best case average, you'd be aiming at, I guess, 4 MBs to load the average low quality MP3 album track. That would serve most people's music needs. Anyone exceeding that use might, like me, be exceeding it by a lot and pushing the 12 MB limit.

I can't see any reason to exceed 4 MB. The amount of HDD access will be very small in the grand scheme of thing if you cache a suitably sized block of audio data. At worst you'd suffer a minor glitch in frame-rate for a frame or two, and given that games have that already these days, that has to be a better choice than eating 8+ MB of unnecessary RAM.

What if one wants to play music from a DLNA server during game play?

 

[betan]

Targetting long tracks will never be enough though. Depending on encoding and track length, 12 MBs can be exceeded. The largest music file I have is a 13 MB Rachmaninov piano concerto movement. Had I ripped the concerto to a single track, that'd be nearly 30 MB. If you're going to just target a best case average, you'd be aiming at, I guess, 4 MBs to load the average low quality MP3 album track. That would serve most people's music needs. Anyone exceeding that use might, like me, be exceeding it by a lot and pushing the 12 MB limit.

I can't see any reason to exceed 4 MB. The amount of HDD access will be very small in the grand scheme of thing if you cache a suitably sized block of audio data. At worst you'd suffer a minor glitch in frame-rate for a frame or two, and given that games have that already these days, that has to be a better choice than eating 8+ MB of unnecessary RAM. Adding the full set of online extra-gaming functionality eats a crazy amount of RAM. I can't fathom why. You have three consumers - code, data and workspace. Code is small. Data in a lot of these can be small too. You don't need rich GUI data to implement a freinds list or background audio. And I can't see any reason for a lot of workspace either. I'm bemused!

Audio streaming is cheap, easy and what everybody else does.
In addition to the fact that "streaming" is explicitly used in the article, there is no way they would limit the audio file size. I, for one, often listen podcasts while playing.
If the streaming is from HDD they wouldn't even need caching. Even if it's from network cache size would be minimal.

The memory requirement is likely due to gui and/or breathing room for future features.

 

[patsu]

OS reserved memory: 48 MB (main) + 24 MB(vram)
Three new "utilities" available to developers:

1. Screenshot to XMB photos [3MB] (Very cool, we can now finalize AA and resolution discussions. I wonder which developer wanted that though. At least PR guys wouldn't want with all the bullshots around.)

1. 
   
   Ok, one step closer to the Trophy video example they showed. Hurry up
   Betan, the screenshot feature is useful for players to brag, share or report problems.
   -

 

[Shifty Geezer]

Audio streaming is cheap, easy and what everybody else does.
In addition to the fact that "streaming" is explicitly used in the article, there is no way they would limit the audio file size. I, for one, often listen podcasts while playing.
If the streaming is from HDD they wouldn't even need caching. Even if it's from network cache size would be minimal.

Well exactly. And you could stream and play audio files in a few hundred KB. Worst case, 4MB would be extreme.

The memory requirement is likely due to gui and/or breathing room for future features.

But that makes zero sense. What GUI do you need for a background music player? Why take 12 MB of game resources to have a fancy GUI? Why even use hungry bitmaps for a GUI?

None of these reserved memory amounts make sense to me! Is there any way to get someone to talk on the issue and explain why they're so large? I don't suppose so.

 

[betan]

Well exactly. And you could stream and play audio files in a few hundred KB. Worst case, 4MB would be extreme.
But that makes zero sense. What GUI do you need for a background music player?

Audio selection/folder browsing, multiple playlists, etc. (most of which are absent from the current form of XMB)
Just speculating of course.

Why take 12 MB of game resources to have a fancy GUI? Why even use hungry bitmaps for a GUI?

None of these reserved memory amounts make sense to me!

I cannot say they don't make sense without knowing the details or their plans.
I agree 12 MB looks too much though.
But I suspect this feature will be used initially by arcadey PSN games for which memory may be less of a problem.

Is there any way to get someone to talk on the issue and explain why they're so large?

Do they even know?
(you see what i did here)

 

[Gradthrawn]

None of these reserved memory amounts make sense to me! Is there any way to get someone to talk on the issue and explain why they're so large? I don't suppose so.

I think everyone is under the assumption the memory requirements are additive. Meaning Feature A at 12MB + Feature B at 10MB + etc all add together for the total memory requirement. Instead, it may be the case where there are some common elements required for the features, the limited in-game XMB for example, needed by the some of the larger optional features. So, perhaps 8 of the 12MBs for music is actually used for the XMB, while adding on another element, such as the Friend's List, only needs an additional 8 (instead of 16) since the common elements are already loaded for user controlled music playback.

Well exactly. And you could stream and play audio files in a few hundred KB. Worst case, 4MB would be extreme.
But that makes zero sense. What GUI do you need for a background music player? Why take 12 MB of game resources to have a fancy GUI? Why even use hungry bitmaps for a GUI?

I'm guessing they want a common, streamlined interface. The "in-game mini-Blade" for the 360 is functional, no doubt. It has everything one needs such as music control, friends list, messaging, Live status, but it sure as hell ain't pretty. Nor does it truly match the Blade theme. I'm guessing SCE would like to keep the XMB whenever possible for the player interface, even at the sacrifice of additional memory requirements. Form and functionality vs Functionality and form. Although, IMO, form often seems to have an effect on functionality (positive or negative).

 

[oramay]

...

None of these reserved memory amounts make sense to me! Is there any way to get someone to talk on the issue and explain why they're so large? I don't suppose so.

May be Beyond3D can try to interview the PS3 firmware team?