I'm trying to implement vorbis into our game engine as a substitute to mp3 and wma encoding. And I have some questions/suggestions in how #includes are done in vorbis. Right now ogg and vorbis stuff relies on ogg and vorbis include paths being in global (or local) include path environment. This could easily be avoided by using relative includes in vorbis: #include "..\..\vorbis\include\vorbis\codec.h" instead of #include <vorbis\codec.h> This allows the include of vorbis and ogg .h files to be more plug and play and you can add the .c files of the library directly to a project without defining extra include paths. This is especially important in large projects. Right now its pretty easy for me to just modify the code in ogg vorbis to work this way, but it seems unnecessary. Is there a really good reason that you have it the way it is right now? Also if the test of vobis codec works out ok here I may be able to contribute with optimizations in the form of SSE code and so on, has this already been done / is in the process of being done. Is this something that you are interested in? Regards, Erik Olofsson Starbreeze Studios / O3 Games --- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/ To unsubscribe from this list, send a message to 'vorbis-dev-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
> Right now ogg and vorbis stuff relies on ogg and vorbis include paths > being in global (or local) include path environment. This could easily > be avoided by using relative includes in vorbis: > > #include "..\..\vorbis\include\vorbis\codec.h" > instead of > #include <vorbis\codec.h> > > This allows the include of vorbis and ogg .h files to be more plug and > play and you can add the .c files of the library directly to a project > without defining extra include paths. This is especially important in > large projects. Right now its pretty easy for me to just modify the code > in ogg vorbis to work this way, but it seems unnecessary. Is there a > really good reason that you have it the way it is right now?Yes, there is a good reason it is done that way. On most non-windows systems, the stuff under "../../vorbis/include" is moved to "/usr/include" or "/usr/local/include" at the time vorbis-lib is installed. <vorbis/codec.h> is then the correct way to reference the installed header files. Reading your message headers, you appear to be on windows. Feel free to copy "vorbis\include\vorbis" to "c:\include\vorbis", if you want to create a 'global include' sort of directory to mirror what you would have on a *ix system. Alternately, you could copy the files to %MSSdk%\inclcude\vorbis\ (and %MSSdk%\include\ogg\ for the ogg headers), but you'd have to remember that you'd done that if you ever re-installed the SDK (or when Microsoft moves the default path and you don't notice... again...)> Also if the test of vobis codec works out ok here I may be able to > contribute with optimizations in the form of SSE code and so on, has > this already been done / is in the process of being done. Is this > something that you are interested in?Some of us would find it interesting. The real core developers say that there are more improvements to be made at the C level before they are going to bother with assembly. In addition, I imagine SSE optimisations would be a lot more interesting if they were done to a 1.0 tree. I would find it interesting from a 'How does one go about writing SSE by hand?' point of view. Practically, and for now, I'm happy with the ~20% speedup I get by compiling with Intel's C compiler with SSE turned on. YMMV. Peter Harris --- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/ To unsubscribe from this list, send a message to 'vorbis-dev-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
Sorry for posting html earlier btw. About the copying of includes to mssdk or setting up my own include paths, that is fine by me... but when the 10 other people working on our project gets the new code from source control its much better if they don't have to add new libraries that is used to their compile environment. Is that the way all libraries for *ix systems work? And can it be made compatible with a relative path methodology? -----Original Message----- From: Peter Harris [mailto:peter.harris@hummingbird.com] Sent: den 10 oktober 2001 18:41 To: vorbis-dev@xiph.org Subject: Re: [vorbis-dev] #include scheme in vorbis project> Right now ogg and vorbis stuff relies on ogg and vorbis include paths > being in global (or local) include path environment. This could easily > be avoided by using relative includes in vorbis: > > #include "..\..\vorbis\include\vorbis\codec.h" > instead of > #include <vorbis\codec.h> > > This allows the include of vorbis and ogg .h files to be more plug and > play and you can add the .c files of the library directly to a project > without defining extra include paths. This is especially important in > large projects. Right now its pretty easy for me to just modify the code > in ogg vorbis to work this way, but it seems unnecessary. Is there a > really good reason that you have it the way it is right now?Yes, there is a good reason it is done that way. On most non-windows systems, the stuff under "../../vorbis/include" is moved to "/usr/include" or "/usr/local/include" at the time vorbis-lib is installed. <vorbis/codec.h> is then the correct way to reference the installed header files. Reading your message headers, you appear to be on windows. Feel free to copy "vorbis\include\vorbis" to "c:\include\vorbis", if you want to create a 'global include' sort of directory to mirror what you would have on a *ix system. Alternately, you could copy the files to %MSSdk%\inclcude\vorbis\ (and %MSSdk%\include\ogg\ for the ogg headers), but you'd have to remember that you'd done that if you ever re-installed the SDK (or when Microsoft moves the default path and you don't notice... again...)> Also if the test of vobis codec works out ok here I may be able to > contribute with optimizations in the form of SSE code and so on, has > this already been done / is in the process of being done. Is this > something that you are interested in?Some of us would find it interesting. The real core developers say that there are more improvements to be made at the C level before they are going to bother with assembly. In addition, I imagine SSE optimisations would be a lot more interesting if they were done to a 1.0 tree. I would find it interesting from a 'How does one go about writing SSE by hand?' point of view. Practically, and for now, I'm happy with the ~20% speedup I get by compiling with Intel's C compiler with SSE turned on. YMMV. Peter Harris --- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/ To unsubscribe from this list, send a message to 'vorbis-dev-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered. --- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/ To unsubscribe from this list, send a message to 'vorbis-dev-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
On Wed, Oct 10, 2001 at 05:40:45PM +0200, Erik Olofsson wrote:> I'm trying to implement vorbis into our game engine as a substitute to mp3 > and wma encoding. And I have some questions/suggestions in how #includes are > done in vorbis. > > Right now ogg and vorbis stuff relies on ogg and vorbis include paths being > in global (or local) include path environment. This could easily be avoided > by using relative includes in vorbis: > > #include "..\..\vorbis\include\vorbis\codec.h" > instead of > #include <vorbis\codec.h>...bad idea from the flexibility standpoint. <vorbis/codec.h> is correct usage. The compiler should find local includes from -I or equivalent. It would also make it impossible to use alternate include paths in other testing. (For one, your example would break my vorbis module checkouts which are not in a toplevel directory named 'vorbis'. I tend to have five to ten differing versions checked out at a time).> This allows the include of vorbis and ogg .h files to be more plug and play > and you can add the .c files of the library directly to a project without > defining extra include paths. This is especially important in large > projects. Right now its pretty easy for me to just modify the code in ogg > vorbis to work this way, but it seems unnecessary. Is there a really good > reason that you have it the way it is right now?Yes. :-) Use the power of your compiler.> Also if the test of vobis codec works out ok here I may be able to > contribute with optimizations in the form of SSE code and so on, has this > already been done / is in the process of being done. Is this something that > you are interested in?We're interested. People here have dabbled with optimizations for various platforms, and it's a good idea to discuss optimization work with the list before submitting a patch. Especially in the core libs, simply showing up with a patch could conflict with other ongoing work (which is unlikely) and to make sure it doesn't violate anyone's sense of abstraction aesthetic (namely, mine ;-). Monty --- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/ To unsubscribe from this list, send a message to 'vorbis-dev-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
Actually it is more "plug and play" to use the angle brackets -- the same source can be compiled different environments and the header files are not location dependent. It's not just the library code that includes those headers, the application code needs to include some of them as well. Are you going to edit all those files and change the relative paths any time you want to move the source, relative to the include directory? What about when moving the header files?> This is especially important in large projects.Why? Windows has a number of quirky differences, from other development environments, but one good thing it does have, is the precompiled code mechanism (PCH files) which, among other things, caches compiler settings such as include paths. Are you using precompiled headers? I have that feature turned off for vorbis itself, because it's overkill for the size of ogg/vorbis, however if your project is that big, you might consider it. I strongly recommend checking out the "win32sdk" module and take a look at some of those project files, which accommodate angle include files without any problems. I don't think we want to hard-code header file locations. On 10/10/2001 at 5:40 PM Erik Olofsson wrote: I'm trying to implement vorbis into our game engine as a substitute to mp3 and wma encoding. And I have some questions/suggestions in how #includes are done in vorbis. Right now ogg and vorbis stuff relies on ogg and vorbis include paths being in global (or local) include path environment. This could easily be avoided by using relative includes in vorbis: #include "..\..\vorbis\include\vorbis\codec.h" instead of #include <vorbis\codec.h> This allows the include of vorbis and ogg .h files to be more plug and play and you can add the .c files of the library directly to a project without defining extra include paths. This is especially important in large projects. Right now its pretty easy for me to just modify the code in ogg vorbis to work this way, but it seems unnecessary. Is there a really good reason that you have it the way it is right now? Also if the test of vobis codec works out ok here I may be able to contribute with optimizations in the form of SSE code and so on, has this already been done / is in the process of being done. Is this something that you are interested in? Regards, Erik Olofsson Starbreeze Studios / O3 Games --- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/ To unsubscribe from this list, send a message to 'vorbis-dev-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
Actually you can still add the include path to you environment without problem in case it used relative paths internally. If I don't have the include files in my environment, but still manage to include say codec.h in vorbis, it won't work because vorbis includes <ogg\ogg.h>. But you are right; you would not be able to change the location of ogg in relation to vorbis. That is the only thing I'm asking, that it uses relative paths internally (at least in h files). But I can see why you don't want it that way, and its only two places that I need to change so I can live with that. I have precompiled headers turned off for vorbis. Again I see now why you want it the way it is. -----Original Message----- From: Chris Wolf [mailto:cwolf@starclass.com] Sent: den 10 oktober 2001 19:41 To: vorbis-dev@xiph.org Subject: Re: [vorbis-dev] #include scheme in vorbis project Actually it is more "plug and play" to use the angle brackets -- the same source can be compiled different environments and the header files are not location dependent. It's not just the library code that includes those headers, the application code needs to include some of them as well. Are you going to edit all those files and change the relative paths any time you want to move the source, relative to the include directory? What about when moving the header files?> This is especially important in large projects.Why? Windows has a number of quirky differences, from other development environments, but one good thing it does have, is the precompiled code mechanism (PCH files) which, among other things, caches compiler settings such as include paths. Are you using precompiled headers? I have that feature turned off for vorbis itself, because it's overkill for the size of ogg/vorbis, however if your project is that big, you might consider it. I strongly recommend checking out the "win32sdk" module and take a look at some of those project files, which accommodate angle include files without any problems. I don't think we want to hard-code header file locations. On 10/10/2001 at 5:40 PM Erik Olofsson wrote: I'm trying to implement vorbis into our game engine as a substitute to mp3 and wma encoding. And I have some questions/suggestions in how #includes are done in vorbis. Right now ogg and vorbis stuff relies on ogg and vorbis include paths being in global (or local) include path environment. This could easily be avoided by using relative includes in vorbis: #include "..\..\vorbis\include\vorbis\codec.h" instead of #include <vorbis\codec.h> This allows the include of vorbis and ogg .h files to be more plug and play and you can add the .c files of the library directly to a project without defining extra include paths. This is especially important in large projects. Right now its pretty easy for me to just modify the code in ogg vorbis to work this way, but it seems unnecessary. Is there a really good reason that you have it the way it is right now? Also if the test of vobis codec works out ok here I may be able to contribute with optimizations in the form of SSE code and so on, has this already been done / is in the process of being done. Is this something that you are interested in? Regards, Erik Olofsson Starbreeze Studios / O3 Games --- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/ To unsubscribe from this list, send a message to 'vorbis-dev-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.