LWJGLStalled. OpenAL OSX doesn't build

OpenGL Development
#1

Okay so I am building LWJGL OSX and all of the graphics stuff builds now. I have not implemented any functions related to windowing and I am not sure if I will, that will be an excercise for someone else I think :slight_smile: Fullscreen stuff should be fine, but since I’m trapped with the deadweight that is OpenAL I had to grab it and build it since _InitializeOpenAL and _DeInitializeOpenAL wouldn’t bind from the OpenAL precompiled binary framework from the Creative site. So I download it and go to build it, and it won’t build. There are all sorts of links to user directories and such.

I don’t have the time or patience to sort that out today so for now, LWJGL development has stalled until I have time to come back to figuring out why OpenAL won’t build. I emplore again that there be an interface between the playing of music/audio and the implementation therein because I have MUCH MUCH MUCH more cleanly implemented and low latency systems on OSX than you have in Windows or Linux to accomplish the same job. OpenAL is a weight around the neck of this porting effort that simply doesn’t even need to exist. Just put up an interface to sound and let the native platform use whatever it wants since its all native code anyways!

#2

Yeah, that would be ideal… - but when you think of it, you’re also saying that we should design an interface AND a native implementation too.

The beauty of LWJGL is the fact that we rely heavily on OpenGL/OpenAL.

As an example, take the OpenAL implementation - it’s more or less the same implementation for linux and win32! - in fact it’s all placed in the common directory (coz it’s shared across implementations) only a couple of #ifdef win32 here and there. When you get OAL to build, you only need to add a method for dynamically loading the OAL dll - thats it, the rest of the implementation can be used for Mac OS X too.

Regarding your troubles with OpenAL, I know that there are two implementations a Mac one, and a Linux one - afaik, the linux one builds on OS X, and the Mac one is carbon (or whatever it is called on Mac). Any problems with OAL, should be addressable through the openal@openal.org mailinglist.

#3

Nah, all I’m asking is that there be an interface between LWJGL and the audio rendering interface so you can plug in OpenAL if you want to, but if you’ve got better stuff on your platform - you don’t have to go into OpenAL and get OpenAL to understand it. In addition if you’ve licensed a commercial audio package that spanks OpenAL into next week, you can use that too. Being bound to having to use OpenAL is a liability IMHO. OpenAL is nowhere near the standard that OpenGL is, and its implementation leaves a lot to be desired with respect to performance on platforms that have multimedia at their core.

#4

If you look at what OpenAL is you’ll notice that its interface very largely divorces it from any particular implementation. That’s all it is - an interface. Very much like the Java interface concept.

The underlying code on Win32 is DirectSound, which is basically as fast as computers get at doing sound.

What you’re asking for is that we somehow have a crossplatform games library and then expect people to write to various different sound APIs. This isn’t going to happen; we needed to pick one API that was crossplatform and stick with it. There is nothing fundamentally flawed about the design of OpenAL.

Cas :slight_smile:

#5

[quote]Being bound to having to use OpenAL is a liability IMHO.
[/quote]
Well in that regard, Being bound to having to use OpenGL is a liability IMO - Direct3D is the way forward (). So instead we’ll just design an interface around it - that way anybody that has anything better, can just plug that in… With all due respect, thats just not what we wanted for LWJGL.

[quote]OpenAL is nowhere near the standard that OpenGL is
[/quote]
So, which audio api just as standardized as OGL or D3D is in the graphics world?

[quote]and its implementation leaves a lot to be desired with respect to performance on platforms that have multimedia at their core.
[/quote]
You have anything to back that up?
First of all, OpenAL is more than enough for the kind of games LWJGL is supposed to be developed for. LWJGL is not meant for AAA games! We just need to be able to play some audio, resonably fast. To that end, OpenAL allows us a GL like interface, 3d audio, streaming buffers and low latency (and many other things).

Regarding performance. The win32 implementation uses DirectSound3D, DirectSound or WaveOut - depending on the capabilities of the soundcard. Furthermore native drivers are developed by Creative for all SB cards, and for all NForce chipsets by nVidia.

Ohh - and one last thing. Unreal Tournament 2003 uses OpenAL, and yet you don’t think the library is good enough for us?

#6

I don’t disagree with the design philosophy of having having a design interface to OpenGL, but during my downtime I’ve had a chance to objectively look at LWJGL without the blinders of using it to write any particular application - and indeed having an interface to drawing (not with any particular library) would have indeed been a better design decision. As much as I hate Java3D because of its closed view to the world - its design is actually a lot cleaner. The ability to plug in any renderer as opposed to being API specific is an asset if you want to move this API to some device that doesn’t support OpenGL.

MilesSoundSystem for commercial games with FMOD APIs having an almost infinite amount of industry traction moreso than OpenAL. Heck it FMOD runs on consoles :slight_smile:

LWJGL is just a technology core. Technology doesn’t determine whether a game is AAA or not. Its quite possible for someone to build a AAA game with LWJGL on the platforms it supports. Technology is a tool, LWJGL is just a tool. Just as with Torque, you can make a game that sells millions - or a little generic game that doesn’t sell at all.

No, I don’t think its good enough for what I want to do in OSX. It gets in the way of mixing samples for dynamic audio ala DirectMusic.

#7

How does it get in the way of doing that? You give it some buffers, and tell it to play them. That’s about as simple as a sound API can get. It goes off and mixes them for you. You are in absolute full control of the buffered data and its output characteristics.

Time and again we’ve had requests for APIs that make such-and-such easier or add this capability or that capability; that’s not what we’re about. We’re providing a base, lowest-common-denominator for graphics rendering, sound rendering, and input processing.

We’d never support any other rendering API than OpenGL simply because there is no other rendering API other than OpenGL that works across all platforms. To put a layer on it is just pointless. A lot of people have asked what the point of having both D3D and OpenGL renderers for Java3D. It makes the whole interface vastly more complicated and more to the point new which we don’t want. Our library is tiny and simple, and does what it sets out to do, which is turn a JVM into a console for playing 2D & 3D games on which will run identically on several platforms*.

If you want to add FMOD support or whatever, that’s all very well but it’s not what we agreed on sound-wise early on as our base specification; it should be a distinct, separate package (although it can still be built upon the LWJGL).

Oh, and Brian - of course we’re targeting AAA games! I’m fully aware this is probably only held up by the lack of structs in the JVM as well. With the LWJGL today there is virtually no difference between using Java and C++ to write a game. Except it’s easier :slight_smile:

Cas :slight_smile:

*but you still have to know how to code for cross-platform ability

#8

[quote]Oh, and Brian - of course we’re targeting AAA games!
[/quote]
k, bad choice of words… What I meant to say, is that we don’t have access to some of the things used in typical AAA games - such as Quake 3, Doom or Unreal engines. Nor can one use SAGE (C&C Conquer’s engine) or RenderWare. Thats just how it is, since we’re still running through a VM - and we only have native access to whatever has been made bindings for.

#9

[quote]The ability to plug in any renderer as opposed to being API specific is an asset if you want to move this API to some device that doesn’t support OpenGL.
[/quote]
Ofcourse pluggable renders would be a cleaner implementation. However that would require us to do both a interface design and create a native implementation. LWJGL is about giving you the most bang for the buck, without all the fuss. If you want abstracted rendering - you could use http://www.jpct.net/. We have decided to go with OpenGL/AL because it is crossplatform, free, easily implementable and fast. Using these native bindings we’re able to give the developer some tools to create much better performing than java games, than has previously been possible.

[quote]MilesSoundSystem for commercial games with FMOD APIs having an almost infinite amount of industry traction moreso than OpenAL. Heck it FMOD runs on consoles
[/quote]
Yeah, and both are commercial offerings - ie. they cost money. This is ofcourse fine for some - but not for the hobbyist (yes, FMOD only costs money if the game is commercial).

As for the rest, what Cas said :slight_smile:

#10

Well I’ve fired off an email to whomever is developing OpenAL and whenever they provide a framework that can link on OSX, LWJGL on OSX will be done (outside of maybe redefining some interfaces in the ext_gl stuff). At that point, people can do whatever they wish to it - according to the people chunking money my way to provide them a solution, LWJGL is a bit far afield from what they really need so I will probably end up going back to pre-LWJGL development and cranking out from there.

With out breaking my NDA all I can say is that LWJGL is fine for what you guys want to do, but from a commercial interest perspective - it misses the boat on some key issues. Hopefully enough people will put out stuff using LWJGL to change the minds of certain people, but at the moment they see a highly portable JVM in a lot of places and quite a few platforms that DO NOT support OpenGL and lots of pain and suffering to morph LWJGL into doing what they need.

I’ve always said that I look at this from a business perspective because I have been (at bethesda) and continue to be on the business side of things. Right now the business side of things sees some potential in Java, but not in any particular graphics API and certainly not in one that is not componentized enough to allow them to mix and match parts from a variety of different systems. So after I’m done - I wish you guys the best of luck, but I’ll have to part ways because your view of the world is too narrow to support what I need to do on the business side.

#11

It is interesting that Gregory brings up the motivation behind the API and I wonder if it has changed for the rest of you too with the release of the JRE1.4.2 beta?

If I remember correctly, Cas started LWJGL because he wanted a graphics API that was separate from AWT and Swing so he could compile it with JET. The reason for this was that the standard JRE download was too big and that JET was able to produce smaller stand-alone binaries as long as he didn’t use AWT or Swing. A few days ago Chris Rijk posted on Javalobby that the JRE1.4.2beta is available in a 1.3 meg option that only contains the essential stuff and lets everything else get downloaded on demand, wouldn’t that solve the problem for Cas too? What about the rest of you guys working on the API?

#12

[quote]but I’ll have to part ways because your view of the world is too narrow to support what I need to do on the business side.
[/quote]
Fair enough. However I fail to see the problem entirely…
Having a pluggable renderer (be it graphics or audio) is not a high requirement of most games. They tend to choose either OGL or DX, if not they’re niche games (). I have yet to see any high performance api’s that are completely swappable (without having all sorts of quirks). At some level you just have to on what to use to render. LWJGL is first and formost an enable technology - if you want to abstract it to be pluggable - then have a fieldtrip.

The guys at EA pacific (or whoever did the SAGE engine for C&C) seem to have quite success at choosing a DX only engine. Likewise with ID software - they choose to use OGL - success too. Swappable renderes have there use - It’s just not what LWJGL is about (IMO).

That said, there is the console market, which is (correct me if I am wrong) what I am reading between the lines that you’re talking about - but since noone of us have access to those, there is not much we can do about it. To have LWJGL running on other platforms we need to have OGL/OAL and a VM running, thats just how it is… But ofcourse - others are free to use the LWJGL code to do a crossplatform pluggable api…

#13

[quote]It is interesting that Gregory brings up the motivation behind the API and I wonder if it has changed for the rest of you too with the release of the JRE1.4.2 beta?
[/quote]
Not for me… Regardless of the 1.4.2 release, Java is still relatively slow - and the api is bloated and memory hogging for many games.

[quote]If I remember correctly, Cas started LWJGL because he wanted a graphics API that was separate from AWT and Swing so he could compile it with JET.
[/quote]
Actually* Cas did LWJGL before LWJGL was born, because I programmed java and he needed something highperformance without GC hickups (for doing television stuff). A secondary goal of LWJGL was to allow for distribtution without awt/swing using Excelsior Jet. This hasn’t changed, even with 1.4.2. First of all, you MUST deploy the whole shebang - you cannot only install parts of the VM that you use. Secondly, though the option of downloading only what you need is a good thing - it doesn’t help if you’re not online at the time the game is launched.

* History might not be entirely corrrct, but something along those lines…

#14

You’re heading down the right path. Suffice it to say that there are devices that surprisingly enough do hava JVMs but have graphics APIs that aren’t OpenGL. I can’t really elaborate on it much more than that though.

#15

Well MacOSX has a full working CoreAudio api for java. The main let down is its very slow at rendering 3D Sound - even if u use simple sound panning. The upside is u get everything to do with audio rendering you would ever wont. Reverb and Mixers are built-in.

We looked into using it to make some realtime 3D related audio stuff for film output. But found it was just to slow. And it seemed to be a little flacky at the times.

The i just splashed the code onto Windows and used OpenAL to render the sound. Worked a million time better for sound localization. But the CoreAudio is a full on audio system that rocks in other ways. HAL and MIDI to boot.

I think it has to be kept to crossplatform Audio SDK’s or things will tend to stop in the zone of development. If u want to use DirectSound then its there. Same goes for anything. But this API should have the OpenGL type Audio API - and thats OpenAL.

I think OpenAL on MacOSX will be a very cool thing for Java with or without all this VM size stuff. As for console games - we are using GL4Java and OpenAL (from LWJGL) to make demo mockups and all is very nice indeed. So i think a MacOSX version would be most cool. So dude bring LWJGL to MacOSX! The amount of people who will then be able to do 3D audio thats simple on both Mac and Windows will help the fun move along.

#16

saying that FMOD looks way sweet… runs and duss alot more then OpenAL. would love to have a Java Port of that i can tell u :slight_smile: but then theres nothing new there.

#17

Well, I’m not sure if this is exactly the best place to say this but here goes:

LWJGL has goals on several levels, all as important as each other.

The first goal is to provide a royalty-free high-performance graphics, sound, and input API to the Java platform.

The second goal is to ensure that what we produce is cross-platform, open, and requires absolutely minimum maintenance through its utter simplicity.

The third goal is to provide the notion of a “platform” upon which cross-platform libraries and games can be written, such that a game written for the LWJGL platform is guaranteed to be able to run on all platforms supported by the LWJGL provided that the specifications of usage are rigorously understood and enforced.

The fourth goal is a political goal; we have made an explicit decision to promote certain APIs because we believe that a fragmented community will ultimately be a weaker community and that one day, DirectX will rule the world if there is not a coherent and strong movement behind alternative APIs. Therefore we have chosen to grow OpenGL and OpenAL. We know that the LWJGL will be very, very, big soon - it’s only in alpha yet it delivers so well already that the only thing holding us back from AAA is the lack of structs :wink: - and we feel that we will add such might and credibility to OpenAL that we will probably guarantee its future and growth. I predict we will have a more significant impact on OpenAL than even UT2003. We may even have a greater impact on OpenGL for games than Carmack if Sun gets the Java gaming strategy right.

The fifth goal is the reason the whole thing started. I’m writing a game; I needed some people to take care of the tedious library maintenance so I could get on with the game.

Now listen up and listen carefully:

A lot of my money is riding on the Mac port of LWJGL and I am especially keen to ensure it works and works exceptionally well, and if this isn’t going to be the case, then this needs to be addressed, yesterday. I’m less than a month away from going gold and I need a Mac release. It is crucial that I have a Mac release. Now do understand that I am so utterly grateful for everyone’s help on the LWJGL that I could not even begin to repay everyone’s kindness but at the end of the day I started the project for a reason and I need to make sure that it delivers if you get my drift.

Cas :slight_smile:

#18

All I can say is smack the OpenAL folks. I’ve pretty much handled the gist of the LWLGL port on OSX. Right now I’m changing some code to use the Amelio HID framework for OSX because it kicks ass and is free. Outside of that, whenever I can link with OpenAL - the port will be complete. We’re looking at like a couple of weeks from the time I can get it to link with OpenAL till the time that its all tested and happy.

After that, I’m off to bind FMOD to PAI. Then I can replace the auto interface with whatever and keep folks happy because FMOD is about as fast an audio API as I’ve seen, completely free for open source projects - and painfully cheap even for commercial ones.

#19

Mr Matzon’s your man; he keeps close virtual contact with one of the lead devs on the OpenAL team, so he should be able to get help sorted one way or the other.

I think you’ll like OpenAL once it starts to work.

Cas :slight_smile:

#20

Its not me that has to like it :slight_smile: If it were just up to me I wouldn’t really care - much of the audio that I deal with involves playing simple MP3 tracks and playing buffered sounds. When someone is passing some cash under the table for a prototype, however, I have to follow the money.