We NEED more developers!

[ender.saka]

Still, keep in mind that it's a bad idea to increase the amount of platform dependent code, as that will mean Apple support will break very often and easily (as there is no Apple developer in the team, this would happen all the time). Often you'd have months without the engine running on OS X, until finally someone comes to fix it.

The point is that, at the current state, to have native OS X port you (me or who wants to implement it) are obliged to ad platform dependent code. The only way, apart AGL, to create a window for OpenGL is Cocoa, and then Objective-C.
Even if it is not exactly true. There is a way, I thought about this night. It is GLX (I mean the normal X11 APIs for OpenGL, you currently use also for Linux). Mac OS X has a X11 server, XQuartz, and I heard it should be able to support GLX. Someone told me that Blender (that is OpenGL based) can be compiled to run on top of XQuartz instead of Aqua.

Anyway. I think the best path of action would be to implement a new vid_* driver file that's using the current "best practices" interface for OS X, and possibly also a matching snd_* file (in case CoreAudio is deprecated too).

Core Audio is not deprecated neither abbandoned and currently is one of the top technologies provided by the Mac environment. So it would be possible to implement snd_* with it. Though I think that vid_* implementation is more urgent, now. And I am exploring it, at this moment.

On the other hand, rewriting the whole engine because a single apple fanboy says so is certainly not going to happen.

If you, please, can stop to take every opportunity to underline that way that I am a Apple fanboy and other similar names, I would be glad. I am just a Mac User not a Apple Fanboy.

On the other hand, if it becomes too hard to support OS X, we'd simply drop OS X support due to lack of developers for it (well, what ELSE can one do then without an OS X developer...). So be happy as long as OS X is supported at all.

I am agree with that. I am not asking you to maintain it if you don't have developers to do it. When I first posted to this thread, I did it because I read the title, and I tried to give my help with some suggestion.

Making the game menu look like a native OS X application (with separate windows, and in the Apple dialog style) is not desired at all,

I never said I want to do such thing.

About NetRadiant, there could be problems with GTK+. There is a native GTK+ port, based on Quartz (so GTK+ does not need anymore to run on top of X11), maybe it could be used to compile NetRadiant for Mac.

[divVerent]

This will only work if gtkglext works in this Gtk build. Currently, NetRadiant is using GLX (using an X11 server, like XQuartz).

It would be absolutely simple to compile a GLX build of DarkPlaces for OS X. But as X11 is only an optional component of OS X (it's not installed by default), it's not a good idea to depend on it.

So actually, in case AGL support dies down and no alternative is being made, SDL and GLX would still run on OS X (but GLX only once X11 is installed).

[divVerent]

Still, keep in mind that it's a bad idea to increase the amount of platform dependent code, as that will mean Apple support will break very often and easily (as there is no Apple developer in the team, this would happen all the time). Often you'd have months without the engine running on OS X, until finally someone comes to fix it.

The point is that, at the current state, to have native OS X port you (me or who wants to implement it) are obliged to ad platform dependent code. The only way, apart AGL, to create a window for OpenGL is Cocoa, and then Objective-C.
Even if it is not exactly true. There is a way, I thought about this night. It is GLX (I mean the normal X11 APIs for OpenGL, you currently use also for Linux). Mac OS X has a X11 server, XQuartz, and I heard it should be able to support GLX. Someone told me that Blender (that is OpenGL based) can be compiled to run on top of XQuartz instead of Aqua.

Using GLX is not viable, as stated above.

Also. I have nothing against someone making a new vid_* driver, like a vid_nsgl.c or whatever it is called. It can sure be an objective C file if there is a need for it to be (vid_nsgl.m then). It just has to provide the vid interface as the other vid_* drivers do.

It's just that someone has to write it.

As long as it's not finished, it even can coexist with vid_agl.c (as in, different makefile targets could choose between nsgl and agl).

The thing that I do NOT want is making more large portions of the engine platform dependent (that is, parts that currently are platform independent). But exactly that's what you were suggesting above (like, using Apple-specific vector math code). That's absolutely out of the question, and it's what I was referring to with the "apple fanboy" comment.

[ender.saka]

This will only work if gtkglext works in this Gtk build. Currently, NetRadiant is using GLX (using an X11 server, like XQuartz).

I don't know.

It would be absolutely simple to compile a GLX build of DarkPlaces for OS X. But as X11 is only an optional component of OS X (it's not installed by default), it's not a good idea to depend on it.

XQuartz is available as an optional install in the Mac OS X install disk. Though, to install it, is a really stupid procedure. Also, it is available from XQuartz site (the bleeding edge version is more recent than the one shipped with the Mac OS X Updates), because it is a Open Source project. And to download it avoid the little annoyng procedure to istall it from the DVD (though a just a little skilled user would be able to install it locating the package in the DVD without need to launch the whole Mac OS X System installer).
A Mac User that is non able to install XQuartz, cannot be considered a capable Mac User, or more generally a capable Personal Computer user. Honestly a child 3 years old could do it without problems.
Moreover, still many GTK+ applications are compiled to run with XQuartz GTK+ (despite the native Aqua version... that is really recent), like GIMP, Inkscape and many others. So all the Mac Users that like to use Open Source applications, should have XQuartz already installed.

Also. I have nothing against someone making a new vid_* driver, like a vid_nsgl.c or whatever it is called. It can sure be an objective C file if there is a need for it to be (vid_nsgl.m then). It just has to provide the vid interface as the other vid_* drivers do.

It is exactly what I am going to try in my spare time.

The thing that I do NOT want is making more large portions of the engine platform dependent (that is, parts that currently are platform independent). But exactly that's what you were suggesting above (like, using Apple-specific vector math code). That's absolutely out of the question, and it's what I was referring to with the "apple fanboy" comment.

Apart the fact that I do not understand why I should be considered "apple fanboy" if I propose to use some API (even if, platform dependant) in place of another API, my proposals were just based on some opinion/ideas.

I am not scared by platform dependant code. Ok I am not happy that producers make things so difficult for developers.
But, after all, we are about to loose Mac port of Nexuiz for some AGL call.

Ah! I forgot to tell, that it is eventually possible to implement Window and Events using GLUT.

[divVerent]

Actually, that would be an interesting video driver too, if GLUT supports all that DP requires.

Does GLUT run natively on OS X, that is, without X11? Does GLUT's fullscreen mode work?

Of course, it wouldn't support other fullscreen modes than the desktop resolution (as GLUT can't change the screen resolution). Still, it might be an interesting approach to get a simple totally platform independent vid_ driver.

[ender.saka]

I don't know about fullscreen (I will search about it), though yes, GLUT runs natively on top of Mac OS X (using Aqua, not X11). And the library is provided as default with the OS X installation.

[jenizaro]

Hi all,

Do you still need C programmers?

Best regards,

Luis

[Alien]

I think, yes. irc.anynet.org #alientrap

I doubt nexuiz had a huge influx of devs but what could I know.

[ai]

I strongly believe it would be great with some kind of structure for the devs and the contributors. I honestly don't know how many 'devs' there are and how many contributors and what each are doing.
I know Div0 of course, then there's motorstep, terenchehill, Blub, tZork, morfar, mand1nga, SavageX, morphed etc.

Granted that this is open source and people work during their free time and do whatever they want, a structure might be impossible. But it would greatly help out for any newcomers trying wishing to help but don't know how, where and on what they should start.
I did create a thread of 'Visual Artist' (it's been neglected a lot though, basically it's for visual stuff, models, effects, maps etc.) trying to give people (and new possible contributors) and idea of what needs to be done and what people are doing currently.
In my opinion it would be great to have such a thing for coders as well, and just occasionally update it with new stuff that's being worked on.

[tundramagi]

Ah, so basically you want nexuiz to only run on mac OS X. You also come into a "need more developers" thread with a list of demands. Finally we have this wonderful sentiment:

I could help also with Modeling, but I think that is a waste of time to model objects for an engine that I cannot smoothly play on my Mac. So, first of all, I would have something working.

Thanks so much!

Basically you're either a troll trying to piss everyone off or you are a mac square-glass alternative life style with alternative relationships kind of guy. TY for your help! We now know your list of demands "make nexuiz mac only!" and what you won't do "I won't model for you, just need to let you know that, hahhahah! MAC RULES.". Now we know!



Also there is nothing wrong with quake C. The only people who think quake C is a problem are people that haven't even taken a stab at writing in it: their opinion is of absolutely zero value. Also it is fairly object oriented from what I saw in projectile creation code (stuff inherits from other stuff) so that's a garbage complaint (that others were making) aswell. Also procedural code has a lot of logic to it... it's something one can follow easily. It takes very little effort to learn.

Here is an idea: "New potential developers" should help take the load off current developer(s?)... not try to heap more crap on them(?). Nexuiz needs help, not anti-help.

This thread is very long, so I would not read it all.

I don't know if you still need more devs, though I would like to give my suggests.

1) Network have to be corrected or rewriten. Having a network independent from frame rate would be better. Currently, apart Client Side prediction, it seems that everything is FPS dependant.

2) Mac OpenGL backend have to be rewriten. Also GLSL and OpenGL specific parts are probably not well integrated with the Mac OS X system.

3) And Mac UI should be ported to Cocoa. Soon or later AGL and Carbon will be not anymore available (probably with next system, Snow Leopard).

4) 64bit architectures should be supported all around the code. It is predictable that soon 32bit architectures for Personal Computer will be totally superseded by 64bit (Core Duo, Dual Core and Quad Core architectures).
This already happens in Linux and Mac OS X. Leopard is mostly 64bit and Snow Leopard will be probably totally 64bit.

5) I suggest to move QuakeC code to C. So, that you will have more opportunities to find other developers, in the future.

6) The engine sources need to be better organized. It is too much monolitic. Modularity and to follow a MVC pattern, would make it easier for external developers to approach it.

7) Multythreadign has to be modified and used in a better way. Currently it does not work good on Mac OS X. I noticed that disabling it gives better performances.


From the point of view of portability I think that some parts have to be not so portable.

I don't know for other platforms, but Mac offers a wide set of utilities both in Cocoa APIs and in Core Graphics/Quartz APIs. All the texture loading and manipulation part can be moved from libpng, libjpeg and similar to Cocoa or Quartz.
Event Handling, GUI and Threads can be handled using Cocoa APIs.
Fast mathematic computation can be highly optimized usign the API that Apple offers to take advantage of the vector extensions available in all CPUs starting from Pentium 3 (Apple also support similar API for Altivec PPC coprocessor).
Similar APIs should be present in Windows and Linux, considering that the vector math API of Apple is based on Intel directives.

I could help, but the engine as it is, is really hard to be interpreted.

I could help also with Modeling, but I think that is a waste of time to model objects for an engine that I cannot smoothly play on my Mac. So, first of all, I would have something working.