-
Hey, guest user. Hope you're enjoying NeoGAF! Have you considered registering for an account? Come join us and add your take to the daily discourse.
Nintendo Not Allowing Third-Party Sound Engines for DS
- Thread starter Bishman
- Start date
Kumiko Nikaido
Vindication...sweet.
WELL THAT JUST ABOUT WRAPS IT UP FOR DOLBY DIGITAL 5.1 AND DTS SURROUND SOUND ENCODED GAMES FOR DS!
Kobun Heat
Member
I think lots of people would love to troll this but have no idea what the fuck it means.
Jonnyboy117
Member
Well, for instance, on GBA you have developers like Shin'en, which has its own sound engine for GBA and licenses it to other developers. It's quite superior to the stock GBA sound tools, and you can hear it in many high profile GBA titles, including the Tony Hawk games and Shin'en's own Iridion series.
i'm guessing Nintendo doesn't want developers getting that close to their hardware, especially WiFi. i'm sure their default tools will suffice, but IIRC a small company developed a MOD player that powers the music for many GBA games today. It hurts smaller dev houses that would otherwise license a third party solution in lieu of scaling back the audio portion of the project.
Edit: Beaten by Johnnyboy.
Maybe not, i mean how many GC games used DiVX over something like Bink! or their own proprietary tools? And how many just didn't bother to add that much video or cut out extras in the GC version?
i don't know enough about development to say that this is horrible, but it's another con for developers who want to add superior quality sound than what Nintendo's tools offer.
i don't know enough about development to say that this is horrible, but it's another con for developers who want to add superior quality sound than what Nintendo's tools offer.
Shogmaster
Member
We're talking about the DS, right? Who gives a shit? Are you gonna carry around your Sennhauser with the DS or something?
First if you read it, Nintendo is "currently" not allowing third party to create sound engines, even the last sentence implied that that rule will eventually be gone. It's not a permenant thing.
I think they are doing this to simplify programming on the NDS for early generation of games until they 1) fix problems that are inherent in creating sound engines or 2) They can provide more documentation on it since programmers would want support from Nintendo on creating those sound engines(think how developers had to struggle with PS2 at the beginning... because of lack of decumentations) or 3) Until they had develop enough tools, compiler, etc.... to let developers do it(Same with PS2 again).
If they go ahead and let developers create their own engines, it's only going to cause delay. What happens if they can't find out why they couldn't get WiFi to work correctly as a result of a new sound engine? If Nintendo doesn't provide them the tool to create the engine or didn't have documentation, the game will get delay.... rather than going through a lot of potential headaches, Nintendo just made things easier by making that rule. They will eventually let third parties do it once they got everything ready.
I think they are doing this to simplify programming on the NDS for early generation of games until they 1) fix problems that are inherent in creating sound engines or 2) They can provide more documentation on it since programmers would want support from Nintendo on creating those sound engines(think how developers had to struggle with PS2 at the beginning... because of lack of decumentations) or 3) Until they had develop enough tools, compiler, etc.... to let developers do it(Same with PS2 again).
If they go ahead and let developers create their own engines, it's only going to cause delay. What happens if they can't find out why they couldn't get WiFi to work correctly as a result of a new sound engine? If Nintendo doesn't provide them the tool to create the engine or didn't have documentation, the game will get delay.... rather than going through a lot of potential headaches, Nintendo just made things easier by making that rule. They will eventually let third parties do it once they got everything ready.
Funny you should mention that, because i was playing Warioware on GBA with some Sony D66 Eggos, thinking just how horrid the sound was. But i'd love to use my Sony EX-70's with my GBA, but it just sounds horrid. A better sound chip and higher SNR would make me seriously consider the PSP over the DS.Shogmaster said:
And i didn't know you posted at 1src. Small world.
Shogmaster
Member
aoi tsuki said:
Do you use the same handle at 1rsc? I hardly go there now. The thrill is gone.
BTW, don't your Eggos require a lot more power to sound good then what any portables would provide? I get all my Hi-fi knowledge rubbed off on me from my obsessed friend, and he carries around a hefty little pre-amp for his protable audio gadgets. Makes the whole portable thing moot though, don't it?
edit: HEY! What's up with my tag! *scratches head*
Crazymoogle
Member
Shogmaster said:
This problem has nothing to do with headphones.
The GBA has no dedicated sound hardware. Period. The very same CPU that is trying to keep the game in working order has to take time out of every frame just to crunch audio data. With Nintendo's official choice, Musyx, near SNES quality audio would take over 100% of the CPU!
3rd party solutions have provided some good alternatives, but certain genres will always get stuck with shitty audio in order to support everything else.
To be honest, I have no idea if this DS report is true or not, but I suppose the concern would be that if another terrible sound interface is locked in, game audio is going to have a tough time getting anywhere near the SNES level of respectability.
Yeah, but their closed nature provides adequate sound. Plus, i have too much stuff in my pockets and on my belt loop (wallet, keys, change, PDA, GBA, cellphone) to be bothered with an amp most days. The little bit of time i have to enjoy portable audio of any sort, be it from my Minidisc or GBA, is so limited that i can't justify buying or making one right now.Shogmaster said:
And yeah, my username is the same. i hardly posted on it when it was Cliesource because i spend most of my time here, but i visited today looking for a files section, hoping to buy a new appointment manager for my UX-50 (i think the freeware A5 is causing crashes). There's no files section on 1src; it's all limited to "Must have apps" threads now. i don't remember anyone calling Cliesource on their instant transition into 1src right before Sony's "official" pullout, but it seemed so obvious.
i love my UX-50, but i'm really looking into geting a Pocket PC for my next PDA, seeing as how the Palm side of things has been slow (where's my OS6?), and i'm tired of being stuck on the losing side of things... Minidisc, Dreamcast, and now Clie. i stand by such decisions, but lack of support really hurts. Especially with Sony, who seem content to provide poor customer service and, with the exception of Minidisc, poor quality control. [/rant]
WTF is wrong with Nintendo?!
This whole DS thing seems like a waste of time, money and resources to me. They should concentrate on a handheld that can compete with the PSP...not this little side-project.
I've used Krawall's Tracker for the GBA...it allowed for MODs and S3Ms to be played back by the GBA and was easy to implement into a game engine. You can have excellent sounding music and sound effects that sound better than most GBA games. It was developed by a programmer who doesn't work for any big developer or anything like that. Devs like Factor 5 came out with their own audio tools as well. This is retarded.
The GB/GBA's sound capabilities sucked to begin with, Nintendo doesn't value audio as much as they should. These tools developed by Devs/Hobbyists were the best thing to happen to the GB/GBA audio-wise.
God Dammit...wake the f*** up Nintendo!
This whole DS thing seems like a waste of time, money and resources to me. They should concentrate on a handheld that can compete with the PSP...not this little side-project.
I've used Krawall's Tracker for the GBA...it allowed for MODs and S3Ms to be played back by the GBA and was easy to implement into a game engine. You can have excellent sounding music and sound effects that sound better than most GBA games. It was developed by a programmer who doesn't work for any big developer or anything like that. Devs like Factor 5 came out with their own audio tools as well. This is retarded.
The GB/GBA's sound capabilities sucked to begin with, Nintendo doesn't value audio as much as they should. These tools developed by Devs/Hobbyists were the best thing to happen to the GB/GBA audio-wise.
God Dammit...wake the f*** up Nintendo!
The Faceless Master
Member
score 1 more for you-know-who... way to go nintendo :-/
Jonnyboy117 said:
the same goes for the NDS. Last month, Shin'en updated its website.
(src: http://gba.n64europe.com/index.php?id=2527)
why would they create the engine, and allow licensing if Nintendo wouldn't allow it? I didn't really believe the story from Nintendoinsider tbh.
The only thing that I see confirmed in this report is that third parties are cut out of a potential revenue stream and that they are likely to not have games that sound as good as Nintendo's. I have no idea as to what the quality of Nintendo's current tools, nor does the article rule out if Nintendo is working closely with someone else to make tools, so I wouldn't be quick to write off the sound for the system. Hopefully Nintendo will find a solution which works out for everyone.
Lord Error
Insane For Sony
What I'm wondering is - if ARM7 is locked to actual programming (it seems to me they are not only not allowing custom sound engines but custom *anything* on it, which is kinda confirmed by some developer info leak) what is used to create graphics on the 2nd screen? Does ARM9 have to run them both, and does that mean that 2nd screen *has* to be 2D graphics?
Kobun Heat
Member
I think the "each processor runs one screen" thing was something the Intarweb came up with on its own.Marconelly said:
Pac-N-Roll had 3D on both screens IIRC.
Kobun Heat
Member
Look, let's break it down. Some guy on Nintendo Insider obviously has a buddy at some shitty developer who got NDS kits and are working on making Spongebob Squarepants Touches Himself DS. Their team of l33t haxx0rs, rather than attempt to come up with fun gameplay, decide that they want to reverse engineer the whole system. They're pissed because they aren't allowed access to the ARM7, so buddy calls Nintendo Insider and gives him an anonymous exclusive.ge-man said:
Of course, the reporter didn't go to other developers for corroboration and he didn't go to Nintendo for their side of the story. So we have no idea what's actually going on and no clue how long this situation will last, or how it really affects developers. We even have evidence for the other side, noting that Shin'en has done a DS sound engine.
Dragona Akehi
Retired
Considering that our own beloved Pana has already mentioned said this:
Now who do we believe. Pana might not have an actual kit, but I'm pretty sure we're not going to have AGB sound quality (or rather lack thereof) again.
Now if Nintendo does something completely retarded again like they did with the AGB (internally mixing music at 16-bit and then outputting at EIGHT just so they can save a few pennies), then I'm going on a firebombing mission.
Panajev2001a said:
Now who do we believe. Pana might not have an actual kit, but I'm pretty sure we're not going to have AGB sound quality (or rather lack thereof) again.
Now if Nintendo does something completely retarded again like they did with the AGB (internally mixing music at 16-bit and then outputting at EIGHT just so they can save a few pennies), then I'm going on a firebombing mission.
Panajev2001a
GAF's Pleasant Genius
Bishman said:
If the ARM7 has been locked away to developers while running in DS mode than I am not liking this choice: it wa slike locking the RSP from developers... the perfromance of the standard micro-code Nintendo provided at first was nowhere near the peak the RSP could provide and from what CrazyMoogle says about GBA's Musyx, the situation with Nintendo's standard tools has not improoved much in terms of efficiency.
Since, by looking at the DS's 2D specs, the GBA 2D engine in the ARM7 chip is used as the DS 2D engine and there is the possibility of running 2D graphics in one screen and 3D graphics in the other.
Let's try to approach this logically.
I have one question: can 2D be done in the non touch-sensitive screen using the GBA's ARM7 CPU ?
This is not so simple to answer as we can do 2D graphics with a 3D graphics engine, it would not be impossible, although it would not be efficient, to use the ARM9 and whatever 3D graphics logic they have on both screens since I was under the impression that you can do 3D on both screens.
There is the possibility then that the ARM7 chip is kinda locked to the touch-screen.
We have the precedence of the GBA in which we have the ARM7 processor and the GBC's CPU which is basically not available in GBA mode so Nintendo might have done something similar in respect to the machine programming model with the DS: handling more than one processor at a time with their own DMAC is not an easy task after-all, so they might have made a judgement call there.
I am the kind of guy that generally wants an alternative to be available.
Maybe Nintendo has an alternative and developers are working on it: the alternative might be that you have to buy a special license and then you only get to program this software module that over-writes official one Nintendo provided. I do not know.
I think that sooner or later developers will find a way to access it, the GBA's ARM7 is not like a closed chip like the RSP in the N64 and I do not think (I hope) that they did not lock it in the Firmware or something.
To go on record, I am not exactly happy that the VME, the AVC decoder and the Media Engine in the PSP are only re-configurable, but not user-programmable.
It is possible for Nintendo to allow nice 2D graphics to be done, but only allow a minimal exposure of the ARM7 in DS mode: you could have a high-level abstraction of the DMA engine (3 channel DMAC) and of the 2D resources: basically you tell where the graphics are in ROM, you tell the libraries to upload them and you get to specify some parameters.
You lose some speed potentially (not too much, this is not a DMA "use it ultra well or dieeee" system like PlayStation 2 ) as in every game you tend to optimize things specifically to the gameplay's needs and constraints and we do not know if we can assume Nintendo's libraries will be very optimized out of the gate although we can all hope.
Panajev2001a
GAF's Pleasant Genius
Dragona Akehi said:
I think the ARM9 with the announced 3D performance should be enough to handle the graphics in SOTN: the main obstacle for SOTN on GBA was the cart space in terms of animation frames, Background tile data, intro FMV and Music all of which can take quite a bit of space and might degrade in quality a lot if you ultra-compress them to make them fit in a 8-16 MB cart.
With the raphics being handled well by the ARM9 ( or the GBA chip, I do not really care
), WiFi being off (not needed), Touch-screen functionality sitting idle , etc... there should be more than enough processing power left in the ARM7 (which is now clocked at 2x the frequency in DS mode) to do very nice Sound and Music processing.inpHilltr8r
Member
I'd expect that every new console is going to have at least one 'locked' or rather, 'trusted' processor. DRM innit.
Crazymoogle
Member
Panajev2001a said:With the raphics being handled well by the ARM9 ( or the GBA chip, I do not really care
One can hope. *goes back to N64 flashbacks*
That's an interesting idea, though - if Nintendo has the ARM7 set up so the audio can't overload the WiFi and touch screen processing, this would almost be a smart move. (Almost...because the RSP lock sounded okay at one point too)
My concern would be more with the Musyx issue - even 2x GBA clock frequency would be bad news for a 16 channel SNES game. If Shin'en has a DS audio middleware license, then the point is moot, because we know that a good solution is out there that isn't going to bleed the CPU dry.