divVerent wrote: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.

divVerent wrote: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).

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

divVerent wrote: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.

divVerent wrote: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,

ender.saka wrote:

divVerent wrote: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.

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

divVerent wrote: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.

divVerent wrote: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.

divVerent wrote: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.

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.

ender.saka wrote: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.

Alien wrote:I ask you to stop destroying the threads.

Alien wrote:I ask you to stop destroying the threads.

1. Please notice me by PM if there will be other Mac developpers that will offer their help, so we can join our efforts;
2. I have a doubt. I am reconstructing the engine behavior using a UML Sequence Diagram (to depict the actual engine architecture). The fisrt step is to understand the calls sequence that leads to call [vid_agl.c] VID_InitMode(), that is the function that actually creates the Drawable Window, with the OpenGL Context with the correct Pixel Format. The sequence, I reconstructed till now, is: [host.c] Host_StartVideo() -> [vid_shared.c] VID_Start() -> [vid_shared.c] VID_Mode() -> [vid_agl.c] VID_InitMode(). Though I do not understand which file and which function actually calls [host.c] Host_StartVideo(). The most probable solutions I found were [cl_screen.c] SCR_BeginLoadingPlaque() and [menu.c] Call_MR_ToogleMenu_f().
3. A proposal. Searching the code to resolve the previous point, I observed that the code organizzation problem, that I pointed out previously, is not so stupid. The fact that all declarations are grouped in qtypes.h and quakedef.h is not only a problem for the IDEs I use, but also for me. I am often in the situation that I doubt which implementation file implements the declarations in the headers, and to understand it I have to follow back all the functions calls. Also, I think that smoller files would help making the code more readable (less functions grouped in the same file) and therefore would help having some more developer that easily join the project because code is not so slow to read. The way to do this could be to subdivide implementation files in smaller chunks (and give them more specialized names). Though this is just a proposal (please do not take it as a war, I am just discussing). I could do the actual job of splitting those files for you, based on some planning discussion we could open, if you agree. I think it could be a really soft process (version by version) and not invasive. After all I am not proposing to change any code, just to organize it a little more.

epicgoo wrote:good luck with finding a quakec programmer...
maybe if you start using normal c you can find developers easier.
learning quakec takes some time and not enough people willing to learn it imho

epicgoo wrote:good luck with finding a quakec programmer...
maybe if you start using normal c you can find developers easier.
learning quakec takes some time and not enough people willing to learn it imho

epicgoo wrote:@tundramagi this kind of approach won't help nexuiz.

EvilAIM wrote:I've played the game a few times and think I might be able to make it a bit smoother and build more on your great work.
If you're interested in a *nix based coder feel free to contact me via here or my email