Thread: [GD-Windows] MP3 Playback under Windows
Brought to you by:
vexxed72
From: Tom H. <to...@3d...> - 2001-09-22 05:07:32
|
I'm looking for the way to provide MP3 playback with the minimum system requirements. That is, the oldest version of DirectX or Windows Media Player, or whatever else it would take. What APIs and libraries are required, and does anyone have a link to some sample code for doing this? Tom |
From: Niklas H. <ni...@ma...> - 2001-09-22 14:14:23
|
Tom Hubina wrote: > > I'm looking for the way to provide MP3 playback with the minimum system > requirements. That is, the oldest version of DirectX or Windows Media > Player, or whatever else it would take. > > What APIs and libraries are required, and does anyone have a link to some > sample code for doing this? > > Tom > > _______________________________________________ > Gamedevlists-windows mailing list > Gam...@li... > https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows Have you looked at fmod (www.fmod.org) If I remebers correctly it should be able to fallback all the way to windows generic sound system. And shouldn't even require directx. But I haven't looked at that part closely so I might be completely off too. /Niklas Hansson |
From: Aaron H. <Vid...@ho...> - 2001-09-22 20:45:38
|
I highly recommend using either BASS mod player, or FMOD. They both have mp3 playback capability, and are generally great APIs to play with. BASS - http://www.un4seen.com/music/ FMOD - http://www.fmod.org/ Something I found very cool is that FMOD works on CE platforms now too!! It's not perfect, but definitely getting there. - Aaron. Student and games coder Tom Hubina wrote: > > I'm looking for the way to provide MP3 playback with the minimum system > requirements. That is, the oldest version of DirectX or Windows Media > Player, or whatever else it would take. > > What APIs and libraries are required, and does anyone have a link to some > sample code for doing this? > > Tom > > _______________________________________________ > Gamedevlists-windows mailing list > Gam...@li... > https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows |
From: Vek <ve...@ho...> - 2001-09-23 05:33:42
|
I guess this is the best place to ask this - since DX is windows specific... and its not really about Algos or such. I recently got ahold of Geforce3 hardware to test my vertex shaders / pixel shaders in, on my Game Engine. To my surprise though, simply flipping the engine into 'hardware vertex processing mode' cut my framerate to about 50% of what it is in software vertex processing mode. This is when dumping raw vertices to the card to transform and light and render via a vertex shader... using vertex index buffer and vertex buffers... no pixel shaders involved. It also drops to 5% of what it is in software vertexprocessing mode if I additionally mess with those vertexes (Transforming them by my program manually instead of by a vertex shader). Are there AGP specifics I'm missing out on? Or some situations which I'm not aware of? I'm setting the device up almost exactly like the NV demos, etc... except those go at several hundred frames a second in the same situations. I would have thought that hardware vertex processing would be the same speed or faster... not 5% as fast. 500 polygons are enough to bring it to a crawl. If I can't mangle this soon, I'll take the renderer code out and place it into a nice 'clean room' to mess with it, and find out whats going on by brute force ;) But I was hoping someone out there already ran into this. -Nick Lawson ve...@ho... project: http://members.home.net/vektuz/gw2k hooray. |
From: Dirk R. <ri...@ph...> - 2001-09-23 10:19:52
|
Simple stuff. Run benmark from nvidia. If you are below 20mio triangles per second, then there is an agp config error. Greets, Dirk -----Original Message----- From: gam...@li... [mailto:gam...@li...]On Behalf Of Vek Sent: Sunday, September 23, 2001 7:35 AM To: gam...@li... Subject: [GD-Windows] DirectX Pure Device / HW Vertex Processing Stuff I guess this is the best place to ask this - since DX is windows specific... and its not really about Algos or such. I recently got ahold of Geforce3 hardware to test my vertex shaders / pixel shaders in, on my Game Engine. To my surprise though, simply flipping the engine into 'hardware vertex processing mode' cut my framerate to about 50% of what it is in software vertex processing mode. This is when dumping raw vertices to the card to transform and light and render via a vertex shader... using vertex index buffer and vertex buffers... no pixel shaders involved. It also drops to 5% of what it is in software vertexprocessing mode if I additionally mess with those vertexes (Transforming them by my program manually instead of by a vertex shader). Are there AGP specifics I'm missing out on? Or some situations which I'm not aware of? I'm setting the device up almost exactly like the NV demos, etc... except those go at several hundred frames a second in the same situations. I would have thought that hardware vertex processing would be the same speed or faster... not 5% as fast. 500 polygons are enough to bring it to a crawl. If I can't mangle this soon, I'll take the renderer code out and place it into a nice 'clean room' to mess with it, and find out whats going on by brute force ;) But I was hoping someone out there already ran into this. -Nick Lawson ve...@ho... project: http://members.home.net/vektuz/gw2k hooray. _______________________________________________ Gamedevlists-windows mailing list Gam...@li... https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows |
From: Vek <ve...@ho...> - 2001-09-23 20:21:33
|
Thanks for the response. Dang... its way, WAY above that. So I guess this is nothing to do with AGP... I'm going to do it the long way (Rip the renderer out of my engine, create some test models in MAX (one with lots of tris but one texture, one with lots of textures but same amount of tris, one with many submodels one texture, etc) and try to see why its grinding so badly. For some reason it drops terribly when I mess with vertex buffers myself, before throwing it to the vid card... but it also drops significantly when simply throwing pre-built, static models (in vertex buffers) directly to the card, using a vertex shader with no pixel shader. The real question, I suppose, is what would case a program to go SLOWER using hardware vertex processing, than if using software? And I mean a heck of a lot slower. :( -Nick Lawson nl...@ho... PS. If nobody's seen this kind of thing before and responds, I will go ahead with the renderer tests and post the results here. (Unless someone objects of course!) =) -----Original Message----- From: gam...@li... [mailto:gam...@li...]On Behalf Of Dirk Ringe Sent: Sunday, September 23, 2001 3:21 AM To: gam...@li... Subject: RE: [GD-Windows] DirectX Pure Device / HW Vertex Processing Stuff Simple stuff. Run benmark from nvidia. If you are below 20mio triangles per second, then there is an agp config error. Greets, Dirk -----Original Message----- From: gam...@li... [mailto:gam...@li...]On Behalf Of Vek Sent: Sunday, September 23, 2001 7:35 AM To: gam...@li... Subject: [GD-Windows] DirectX Pure Device / HW Vertex Processing Stuff I guess this is the best place to ask this - since DX is windows specific... and its not really about Algos or such. I recently got ahold of Geforce3 hardware to test my vertex shaders / pixel shaders in, on my Game Engine. To my surprise though, simply flipping the engine into 'hardware vertex processing mode' cut my framerate to about 50% of what it is in software vertex processing mode. This is when dumping raw vertices to the card to transform and light and render via a vertex shader... using vertex index buffer and vertex buffers... no pixel shaders involved. It also drops to 5% of what it is in software vertexprocessing mode if I additionally mess with those vertexes (Transforming them by my program manually instead of by a vertex shader). Are there AGP specifics I'm missing out on? Or some situations which I'm not aware of? I'm setting the device up almost exactly like the NV demos, etc... except those go at several hundred frames a second in the same situations. I would have thought that hardware vertex processing would be the same speed or faster... not 5% as fast. 500 polygons are enough to bring it to a crawl. If I can't mangle this soon, I'll take the renderer code out and place it into a nice 'clean room' to mess with it, and find out whats going on by brute force ;) But I was hoping someone out there already ran into this. -Nick Lawson ve...@ho... project: http://members.home.net/vektuz/gw2k hooray. _______________________________________________ Gamedevlists-windows mailing list Gam...@li... https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows _______________________________________________ Gamedevlists-windows mailing list Gam...@li... https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows |
From: Jon W. <hp...@mi...> - 2001-09-24 03:27:16
|
> grinding so badly. For some reason it drops terribly when I mess > with vertex buffers myself, before throwing it to the vid card... You're aware that vertex buffers are in un-cached memory, right? You should never read them, and you should only write them linearly and completely. If you need to keep the data somewhere for modification, keep it in regular system memory, and "mess with it" on its way into the vertex buffer. On DirectX, you could structure your engine to use DISCARDCONTENTS for buffers that don't have static data, and just cycle through some number of buffers. On OpenGL, you could do the same with NV_fence. Cheers, / h+ |
From: Tom H. <to...@3d...> - 2001-09-23 21:51:35
|
At 01:23 PM 9/23/2001, you wrote: >PS. If nobody's seen this kind of thing before and responds, I will >go ahead with the renderer tests and post the results here. (Unless >someone objects of course!) =) This is list designed for Win32 related stuff other than DirectX (such as finding CD-ROM drives, dealing with installers, WinSock, etc). DirectX stuff should be posted on the DirectX list instead since that's where you would get the best results. I can understand the confusion and we'll have to update the charter to reflect this. Tom |
From: gaspow20 <gas...@nw...> - 2001-09-24 18:38:20
|
MP3 requires licensing per file, and I think as a result, many games ship in violation. But if you use the Miles sound system, it comes with a royalty-free MP3 license. That's most of the motivation for us for using Miles. Plus it's fully backwards compatible with even non-DirectX systems, not too expensive, and has wicked fast decoding/mixing. Scott > -----Original Message----- > From: gam...@li... > [mailto:gam...@li...] On > Behalf Of Tom Hubina > Sent: Friday, September 21, 2001 10:08 PM > To: gam...@li... > Subject: [GD-Windows] MP3 Playback under Windows > > > I'm looking for the way to provide MP3 playback with the > minimum system > requirements. That is, the oldest version of DirectX or Windows Media > Player, or whatever else it would take. > > What APIs and libraries are required, and does anyone have a > link to some > sample code for doing this? > > Tom > > > _______________________________________________ > Gamedevlists-windows mailing list > Gam...@li... > https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows > |
From: Daniel V. <vo...@ep...> - 2001-09-24 19:06:12
|
> MP3 requires licensing per file, and I think as a result, many games > ship in violation. But if you use the Miles sound system, it comes with > a royalty-free MP3 license. That's most of the motivation for us for > using Miles. Plus it's fully backwards compatible with even non-DirectX > systems, not too expensive, and has wicked fast decoding/mixing. Or you could use Ogg Vorbis which works fine for us. There should be sample apps available at http://www.vorbis.com. - Daniel Vogel, Programmer, Epic Games Inc. |
From: Scott B. <gas...@nw...> - 2001-09-24 19:19:51
|
> > MP3 requires licensing per file, and I think as a result, > many games > > ship in violation. But if you use the Miles sound system, it comes > > with a royalty-free MP3 license. That's most of the > motivation for us > > for using Miles. Plus it's fully backwards compatible with even > > non-DirectX systems, not too expensive, and has wicked fast > > decoding/mixing. > > Or you could use Ogg Vorbis which works fine for us. There > should be sample apps available at http://www.vorbis.com. We tested Ogg Vorbis a while ago, but we found that its decoding performance was way too low to be useful to us. But that was at least a year ago, I assume it's been optimized since (especially if you're recommending it). Btw do NOT use WMA for anything. It is SLOW SLOW SLOW. The audio quality and tools are quite good but it is designed for IE and media players, not for low-latency games. Scott |
From: Scott B. <gas...@nw...> - 2001-09-24 19:28:37
|
Hey this discussion got me thinking. When are consumer sound cards going to start supporting hardware decompression? Or at least provide some common DSP type functions that can be used by drivers to aid decompressing formats like MP3, WMA, and Ogg? Are do they do this already and nobody uses it? I would like to keep all of our sound samples in compressed format, but there's just too much overhead - even on a fast PC, decoding and mixing 10 MP3 samples simultaneously will eat up a bunch of CPU, so we reserve the compressed samples for the streaming type stuff like musical score, ambient effects, and dialogue (never more than 2 or 3 of these at once). I assume that the little handhelds like the Rio have an ARM or something that decodes in software... But in order for games to use this, we'll need multiple simultaneous sample decoding support with dedicated circuits, not an embedded risc processor. Is this kind of thing on the horizon? Is there even a need for it?? Scott > -----Original Message----- > From: gam...@li... > [mailto:gam...@li...] On > Behalf Of Scott Bilas > Sent: Monday, September 24, 2001 12:17 PM > To: gam...@li... > Subject: RE: [GD-Windows] MP3 Playback under Windows > > > > > MP3 requires licensing per file, and I think as a result, > > many games > > > ship in violation. But if you use the Miles sound system, > it comes > > > with a royalty-free MP3 license. That's most of the > > motivation for us > > > for using Miles. Plus it's fully backwards compatible with even > > > non-DirectX systems, not too expensive, and has wicked fast > > > decoding/mixing. > > > > Or you could use Ogg Vorbis which works fine for us. There > should be > > sample apps available at http://www.vorbis.com. > > We tested Ogg Vorbis a while ago, but we found that its > decoding performance was way too low to be useful to us. But > that was at least a year ago, I assume it's been optimized > since (especially if you're recommending it). > > Btw do NOT use WMA for anything. It is SLOW SLOW SLOW. The > audio quality and tools are quite good but it is designed for > IE and media players, not for low-latency games. > > Scott > > > > _______________________________________________ > Gamedevlists-windows mailing list > Gam...@li... > https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows > |
From: Daniel V. <vo...@ep...> - 2001-09-24 19:55:50
|
> We tested Ogg Vorbis a while ago, but we found that its decoding > performance was way too low to be useful to us. But that was at least a > year ago, I assume it's been optimized since (especially if you're > recommending it). It's fast enough for streaming music - that's what we use it for. - Daniel Vogel, Programmer, Epic Games Inc. |