Well my biggest challenge was a Graphics Engine fully written in asm, featuring Object Oriented code, GLSL shaders (for example the GLSL shader was a calss called "glShader" ), model loading,texture loading (the last two from own formats), own exception handler,thread manager ( a class too with an array of "threads" and it manages everything you just have to specify some stuff to get it working ) But unfortunately I had many problems with it and stopped developing ( issues with the code on different computers )
But still I have images and videos from it

morphed is responsible for modelling and darkplaces is lordhavoc's creation.
you can find both at irc.anynet.org #alientrap

Hello to all !
I'd like to help with some dev stuff.
I really love C/C++, got some exp but not much, I'm not working as dev unfortunately.
I got some free time now so I'd really like to involve in some project I'm eager to learn, just need to be pointed in right direction and hopefully I'll be of some help soon.
Let me know where to start guys.
BTW Nexuiz is awesome I mean I'm using Linux so simply its best FPP for penguin out there.
Catch u later
Cheers

To all those offering their help: thank you, you're awesome!

As most of you have probably figured out by now, this is quite a big project. It is simply not feasible to attempt to understand it all at once. It is also quite likely that you will be more interested in certain parts of this project and less in others.

The best approach is to join the community, read the forums, hang out on the IRC chan. Often things will come by in the form of "I have a problem with ...", if you're interested in this question - see if you can find the cause! That is a great way of finding your way in all of the code, and after a while you will be able to start coding completely new things yourself.

Another approach is to just play and have fun, but keep your eyes open for bugs or features that could be added. Start with simple little things, otherwise you might get lost in the beginning. As an example, I have been reading through a lot of the server code to see if it would be easy to implement some new admin functions.

Hope this helps,

Okay, I'm a experienced C/C++/Java/C# developer, with a bit of Python (and MIPS) on my hands as well; I don't know QuakeC. Am I useful to you guys?

I'd get up to speed quickly if someone shows me what to read+practice.

(Oh, and BTW, excellent game).

Well QuakeC is very similar to C.. except for the game-domain specific stuff. I'd say the first thing to do is to get familar with svn, do a checkout and maybe just monitor the changes (not that much at as we are in feature freeze for the upcoming release).

The 'game' consists of three levels, the media, the gamecode (written in QuakeC) and the engine DarkPlaces (written in C) which interprets the "byte compiled QuakeC" and also handles the basic stuff like loading and rendering the media, doing networking, input/output.
While the gamelogic is handled in QuakeC and together with the media more or less makes up what Nexuiz is.

You can just readup a tutorial on Quake Modding (DP is a really powerful quake 1 engine) that should give you enough hints to understand the quakeC basics. If you have more questions just ask them here or on irc..
#alientrap @ irc.anynet.org for the devs and #nexuiz @ irc.quakenet.org or the 'normal' channel

Hi,
I'd love to help with the Darkplaces engine - its been a while since I've done any C coding but I will consider it a good refresher. I want to develop OpenGL and TCP/IP coding skills, on a worthwhile project! Let me know where to start.
Cheers.

I'm not so keen on working with QuakeC - but I was interested so downloaded a compiler/decompiler and source for the original reaper bot... from here
http://www.mindspring.com/~win32ch/Reaper.htm
and more background from the wikipedia site
http://en.wikipedia.org/wiki/Reaper_bot
Is this compiler compatible with the QuakeC bytecode used in Nexuiz? Does Nexuiz have bots?

Regarding Darkforces engine work would the bug at
http://sourceforge.net/tracker/index.ph ... tid=563407
be a good place to start?

Would you like to take a look at the game first?

Nexuiz qc code might be using some things, which are not available/not fixed in other compilers.

Thanks Alien,
I was avoiding playing the game because I knew once I did that, that would be it for a while . I wasn't wrong. Love the game - the first one I joined had people running round in Spy VS Spy characters! I spent quite a bit of time trying to shoot once I flew through the teleporters - didn't seem to be able to recreate that bug. So what needs work?
I've downloaded Pelles C as an IDE and taken a look at some of the source. Havn't tried compiling anything.
Cheers!

The bug is hard to recreate unless you have a high ping on the server. And in that case, gameplay will suck anyway.

https://sourceforge.net/tracker/index.p ... tid=563407

this one will be good to fix, if you have an idea how to. It'll be hard though.

Sometimes in map voting, these messages are shown:

Draw_CachePic: failed to load maps/don't care
Got Picture: maps/don't care

You can try fixing these. The file causing them is qcsrc/client/mapvote.qc. It should be easy to fix, I just was too lazy. Maybe the server (qcsrc/server/g_world.qc) part of this needs to be changed too (it might be passing the don't care string to whichpack() too).

The solution will be to carefully check if mv_abstain is 1, and if it is, not load a picture for the last item.

Hello. I compiled Nexuiz from SVN sources and it has some bugs, for example:
I can't connect to any server at all
In "instant action" when any bot shoot at me the game just hang up and so on...
But that's not the point - I work with co-workers via SVN and understand that HEAD revision almost always has some arrears. So how to make know which revision is stable (and latest ).

P.S.: it's all about learning structure of game architecture (and it's hard even without bugs in game). So, another question is "is there any tuts about game entry point, structure and so on...?"

I don't know. Strange. Worked for me last time I've checked out.

Usually Div's policy is to keep EVEN SVN stable (no testing branch).

http://ouns.nexuizninjaz.com/dev:progra ... troduction - aimed at tools.
http://ouns.nexuizninjaz.com/dev:quakec - language syntax reference.

There is no Nexuiz API reference. DarkPlaces extensions also are pretty minimally documented (just enough to explain the interface).

Last revision maybe. That bugs was half week ago - or something like that. I mean, for example, which revision was it when you compiled last stable version of Nexuiz?

Sounds more like you made a mistake somewere.. The 2.5 beta thats up in the forum IS from current SVN and has none of your mentioned problems, besides others including myself use a compiled version from SVN each day and its just working fine. Just tell us what you did to get the game from svn, did you get all three, fteqcc, darkplaces and nexuiz? Did you use some script or did you do it 'by hand'?

Actually, the problem description sounds more like a graphics driver crash issue.

Try r_glsl 0 for a first test.

So, checked that out. Current svn revision (2 hours ago) is 6101. There are the same bugs :
- successfully connected to server, started game, shooted to somebody from shotgun, after some seconds picked up the rocket launcher and game hanged up immediately.
- in "instant action" the same bug right after somebody (bots) shoot at me.
If I understood right, I writed "r_glsl 0" (without quotes) into the console inside the game - it didn't helped.

Version of the game downloaded from http://downloads.sourceforge.net/nexuiz/nexuiz-242.zip (month ago) works perfectly (there are NO one of such bugs).

Linux. Mandriva + KDE. Used script "sb_install_010209.sh".

It's so painfully when game hungup - I connect to network via VPN connection and only one way to exit the hanged up game is to reboot the computer (CTRL + ALT + EXC/F1/F4 doesn't work (why?)) - after that I can to open VPN again only after 10 or so minutes. So, please, just tell me the number of stable revision that I will be able to learn game structure - with such troubles it will be unreal!


P.S. Where can I download (and where to copy them inside the "Nexuiz_SVN_6101" folder) *.pk3 files so not to download them after each new updating/compilation?

Are you sure you have 'proper' drivers installed? does

Code: Select all

glxinfo | grep -i 'string\|direct'

output: direct rendering: yes ? Uhm sorry forget that, when 2.4.2 is working fine that stuff should be alright..

And iirc you need a vid_restart after r_glsl 0 but i'm not totally sure atm..

That .sh script is nothing official but it should work. Have you checked all the output for errors? Maybe also take a look here: http://forums.alientrap.local/viewtopic.php?p=54216#54216 In that post i explain how >I< update my svn stuff. Its quite simple and quite direct, maybe its easier to find a compile problem that way

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.

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.

That would require using threads, and there is no way to do this in portable code.

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.

Why is that a problem? OpenGL is a portable standard.

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).

Or, AGL support should be dropped and only SDL be supported (which already uses Cocoa). Which actually is the only viable choice, given the current number of coders.

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.

64bit is supported perfectly except in the build environment (Makefile). Feel free to submit a patch that compiles it as 64bit. Currently, we simply don't KNOW how to make 64bit binaries for OS X.

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

That's way out of scope. We'd need a whole army of coders to get all that rewritten.

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.

In my experience, this would just make the code look more like "enterprise software" whose code flow nobody can even follow before having read it like 2 years long.

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.

That's a problem of your graphics driver then. The "multithreading feature" does not create any threads explicitly. All it does is tell your driver that it may use multithreading.

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.

All this would be a heavy rewrite for almost no gain (given that the computations aren't even CPU bound). Also, current gcc versions allow using SSE for regular code.

It would require making half the game platform specific (e.g. all the UI stuff), even maintaining three different GUIs, for the only gain that it'd look "more like the OS it runs on". Really not a good idea to do.

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.

Well, this is mostly because the graphics drivers on Mac are very slow and buggy. There've been many examples of Apple simply breaking published and everywhere else working OpenGL APIs, like updating part of a texture (this creates colorful randomness when doing this on a compressed texture).

Basically, what you're suggesting is rewriting the entire code from scratch, and using proprietary APIs everywhere, so it'd require writing about twice as much functionality as there is now to support all theee operating systems. There simply is no manpower for that.

Instead, Apple should simply fix their graphics drivers, or allow GPU vendors like NVIDIA and AMD to make their own (which have proven quite stable on Windows, and in case of NVIIDA, on Linux too, so why can't they do that for OS X too?)

It would be better to rewrite QuakeC into QuakeCv2 with better object oriented structure and drop all irrelevant quake content, which could be easily added as extensions but not as the language feature.

http://www.ohloh.net/p/nexuiz/reviews - 2nd post

Because you use MacOS and there are no MacOS devs (it was going to be dropped if not lixivial's contribution (thumbs up)) it's clear why you see so many issues.

1) Rendering frame rate (take a look at maxfps) is independent from network (take a look at netfps), which is independent from server ticrate (sys_ticrate). The only problem is that increasing ticrate changes physics (usual Quake problem). There ezQuake has an adv. because you can switch server rate without changing client physics (afaik, might be wrong).

"Bad Mac OS X platform support. The community is not friendly with Mac and Mac Users."

So "not friendly" is what we are.

Actually, we simply don't have any mac developers. Has nothing to do with friendliness or not.

Mine are only objective points and critiques. I do not want to offend you and your effort. But it seems that you take this kind of discussions as an attack. This is not the first time your react this way to my critiques.

The comment on ohloh is just a quick description of Nexuiz bad performances, on Mac platform, and it is also the consequence of the bad answers (and bad comments about Mac users... if they are still there I can link them if you want) I received in another thread. And that ohloh comment is not a mystery. Everyone can read it and I wrote it because you and users can read it. It is an honest and objective critique, based on my experience about Nexuiz and Nexuiz Forum, nothing more.

Now, if you still want to talk of practical things and put apart anger, the following are my technical answers.

SDL version of Nexuiz under Mac OS X is simply unusable. SDL has not a real Cocoa implementation (I read somewhere) just a simple wrapper, nothing more.

Ok, the problem is not GraphicsFPS VS NetFPS (not good names but I hope you understand what I mean) but PhisicsFPS VS NetFPS. Though, I observed that, if I enable V-Sync (that results in fixing frame rate to 60 FPS), the problem about sync of the client with the server (that I describe in the following lines) become bigger. In any case, the situation does not change. More that half of bullets simply do not hit the target.

Just to avoid useless comments about my play skill, I can tell that I am not a noob player of FPS games (ok I am neither a super expert). Though, I am unable to go beyond the noob results. I get better results only when I play 150%/200% of my capabilities. I observed that there are intervals of time that I have good frag rates (probably caused by a temporary gain of net performances) and the rest of time I need to shut all my ammo against the targets to kill them, even if they are Autocannon ammo. Most of the times some other player steals my frag when I am about to finish it.
I also watched (as a spectator) what the best players do (from their view) and how fast they move. But I observed that they don't do anything different than me. I expected to see extremely precise people (1 shut, 1 kill... or really close) but I observed that they are not so precise. As like as any other normal human beeings they waste bullets because they loose target, they move normally (nothing super human).

About OpenGL and Mac. I played several OpenGL games (open source too) that works perfectly under Mac OS X; I also tested different engines. You would probably be surprised to know that a Java based engine (that uses JNI to call native OpenGL) works really good.
So, it might be that the Mac OS X drivers are not so good, but there should be also something in Nexuiz code.

I do not want to discuss about Apple OpenGL Drivers and the possibility to have manufacturers proprietary drivers. For what I know, it is not Apple that does not want Nvidia and ATI proprietary drivers. But Nvidia and ATI that don't want to develop them.

About multithreading I think it is not a good approach to implement it based only on drivers support.

About optimizzation with vector math: you say that there would be really few gain. The point is that you answered NO to all my proposals. Now suppose that the vector math alone would gain 1%. Multithreading another 1%. And so on... if you would not be so negative there could be a 5% or more of gain. Don't you think?

About QuakeC. If you use it, it is normal that have hard time to find developers. Honestly, I would like to help you, but I have simply no time to learn a strictly proprietary language that is used only in Quake engine. And I think that many developers think the same (at least this is the answer I received from all the developers I know).

Finaly, to have 64bit code with Mac, you have to move from AGL to NSGL (Cocoa). CGL is also supported, if needed, and is not about to be abbandoned. Though Window and User Input Event Handling have to be implemented using Cocoa.

I do not know anything about anything, but I read divVerent's post like saying "the gain is not much, but the amount of work is huge".

Please consider that divVerent has really a lot of stuff going on and that he repeatedly has stated that all this is putting too much pressure upon him already. So I would consider the main obstacle being the lack of manpower, not unwillingness.

Regarding that mac stuff i have no clue about macs and i honestly also do not have the intention to get a clue about them..

ender.saka wrote:About QuakeC. If you use it, it is normal that have hard time to find developers. Honestly, I would like to help you, but I have simply no time to learn a strictly proprietary language that is used only in Quake engine. And I think that many developers think the same (at least this is the answer I received from all the developers I know).

You are simply wrong there. The "C" part in QuakeC is quite big, basicly if you know C you can also program in QuakeC.. ofc you need to get into the domain specific stuff regarding games and how the gamelogic in Nexuiz works and has nothing todo with learning QuakeC. Besides there are TONS of QuakeC tutorials and tons of mods based on QuakeC.. after all quake 1 kinda started the modding scene

ender.saka wrote:The comment on ohloh is just a quick description of Nexuiz bad performances, on Mac platform, and it is also the consequence of the bad answers (and bad comments about Mac users... if they are still there I can link them if you want) I received in another thread. And that ohloh comment is not a mystery. Everyone can read it and I wrote it because you and users can read it. It is an honest and objective critique, based on my experience about Nexuiz and Nexuiz Forum, nothing more.

As far as i know a LOT of advanced stuff (vertext buffers, r_glsl) which also increases rendering speed HAD TO BE DISABLED in 2.4.2 because of SUCKY apple graphic drivers.. Some of that seems to have improved so the current 2.5 beta does disable less of such stuff and should run faster..

ender.saka wrote:Ok, the problem is not GraphicsFPS VS NetFPS (not good names but I hope you understand what I mean) but PhisicsFPS VS NetFPS. Though, I observed that, if I enable V-Sync (that results in fixing frame rate to 60 FPS), the problem about sync of the client with the server (that I describe in the following lines) become bigger. In any case, the situation does not change. More that half of bullets simply do not hit the target.

In the case of 2.4.2 there was a bug with antilag and is already fixed for the beta..

ender.saka wrote:About multithreading I think it is not a good approach to implement it based only on drivers support.

Why not? There is hardly much to multithread anyway! The sound stuff afaik is already in an own thread, Input handling does not gain anything, so we are left with the gamelogic and the rendering. Due to the QuakeC stuff its hard to make the gamelogic multithreaded and given that in a FPS Multiplayer game there are not many different entities there will hardly be a gain from this. Running multiple servers on one machine might have something to gain here if it were possible to run just one engine but have several server inside the engine but its not really worth the required ammount of changes.

hi ender.saka

Here is my 5

Regarding mac issues: Its preddy simple really - help (or find some ppl that will ) make mac support better or accept that its like it is. since i haven't a clue abt macs ill refrain from commenting more on the subject.

QuakeC: If your a somewhat experienced programmer, the actual language you use wont matter so much. sure QC got a pile of things id like to see gone, but that's not the point. If your proficient with one or more c-derived languages, qc should not be much of a problem. Also, the need for ppl to sort out the engine kinks are larger then having more ppl in game code IMO.

Personally i think threading could be beneficial, but from what i understand it will break mac support.

ender.saka wrote:SDL version of Nexuiz under Mac OS X is simply unusable. SDL has not a real Cocoa implementation (I read somewhere) just a simple wrapper, nothing more.

Well, that's what SDL is on any platform, and it works fine. So why not on OS X too? It's IMHO rather SDL's problem to solve and not ours then.

Ok, the problem is not GraphicsFPS VS NetFPS (not good names but I hope you understand what I mean) but PhisicsFPS VS NetFPS. Though, I observed that, if I enable V-Sync (that results in fixing frame rate to 60 FPS), the problem about sync of the client with the server (that I describe in the following lines) become bigger. In any case, the situation does not change. More that half of bullets simply do not hit the target.

This has nothing to do with that. The reason why bullets often fail to hit is badly made player models that have drawable parts outside the collision box.

But without a modeler, that's impossible to fix.

About OpenGL and Mac. I played several OpenGL games (open source too) that works perfectly under Mac OS X; I also tested different engines. You would probably be surprised to know that a Java based engine (that uses JNI to call native OpenGL) works really good.
So, it might be that the Mac OS X drivers are not so good, but there should be also something in Nexuiz code.

Sure. It is because Nexuiz is not mainly developed on Mac (actually, Nexuiz has not a single Mac developer), so we tend to use OpenGL features that are possibly unstable on OS X. No way to avoid that, really.

However, the driver bugs that have been found have been found by others and published too. Apple refuses to fix them anyway.

Had Nexuiz been developed specifically for OS X, it would simply not use these features at all.

About multithreading I think it is not a good approach to implement it based only on drivers support.

I agree, this is not optimal for performance, but it is portable across operating systems.

The only thing multithreading WILL improve is listen servers (that is, servers that also have a client playing in the same process). That is, the ones you make from the "Create" menu.

Performance on dedicated servers on the other hand will not be improved at all by it, and this means that for over 90% of the players, nothing AT ALL will change.

About optimizzation with vector math: you say that there would be really few gain. The point is that you answered NO to all my proposals. Now suppose that the vector math alone would gain 1%. Multithreading another 1%. And so on... if you would not be so negative there could be a 5% or more of gain. Don't you think?

Yes, but it would be a huge amount of work for still about 10% in total, maybe. Regarding vector math, no library is needed for this, but gcc provides its own methods for it. We could start using that at any time, but some people are compiling DarkPlaces with Microsoft Visual Studio, which doesn't support these gcc extensions. As an alternative, gcc has an automatic vectorizer that you can enable by specifying -ftree-vectorize on the gcc command line. The drawback is that the binaries won't work on any older CPUs, which is why this isn't done for releases.

About QuakeC. If you use it, it is normal that have hard time to find developers. Honestly, I would like to help you, but I have simply no time to learn a strictly proprietary language that is used only in Quake engine. And I think that many developers think the same (at least this is the answer I received from all the developers I know).

To that I agree, but on the other hand, QuakeC is relatively simple, and a developer isn't required to know QuakeC (he can work on the engine too, sure).

Also, QuakeC is necessary for one reason: CSQC allows the server to transfer code to the client, which is executed there (and e.g. handles the HUD). If this were native code, this would be a huge security compromise. In the end, you need SOME sort of interpreted or bytecode-interpreted language for this (sure, it COULD just as well be Java, but Java tends to be much less performant than QuakeC in this specific field of application).

Finaly, to have 64bit code with Mac, you have to move from AGL to NSGL (Cocoa). CGL is also supported, if needed, and is not about to be abbandoned. Though Window and User Input Event Handling have to be implemented using Cocoa.

We have no OS X developer to do this, so it won't happen. And yes, this may mean that eventually, native OS X support has to get dropped, unless this situation changes.

If you were a bit more cooperative, you could start working on this and submit a patch for this, instead of bashing the hard work that's being done here.

You really can't expect developers WHO DON'T EVEN OWN SUCH A MACHINE to make a perfect Mac port.

Another thing you have to take into account: you are proposing writing MUCH MORE operating system specific code. However, as no developer has a Mac, and no developer has OS X development experience, this will easily lead to OS X support breaking indefinitely after some changes (either in the engine, or by Apple), as there's nobody to fix it. The current way of making most of the code platform independent, and have only small platform dependent parts, is much better in this situation.

It would be great if ender.saka could fix this and NetRadiant issues on Mac.

Alien wrote:It would be great if ender.saka could fix this and NetRadiant issues on Mac.

It is what I am going to try.
There is Quake based game out there called TenebraeQuake. It is of course based on Cocoa, to implement the Window and the Event Handling. Unfortunatelly it is quite a big modification of the Quake base code. And it does not match easily with DarkPlaces modifications.
Though, I will use it to understand how they mixed the 2 things.

And I can do more. If you tell me which errors there are in player models I can fix them and maybe make (aesthetically) better models. They are nice but I think they would need a restyling.

Though the "loose hit" problem is not equal for every body. My friend (PC Windows) has no problems about it.

Also default maps need a restyling I also think that some map needs some fine tuning about game play. There is one, for example, where I continue to be blocked by some really sharp obstacles, really little and close square colums coming out of the walls, in really narrow passages, their shapes work as traps, and you know that, in Nexuiz, to not move means to die.

divVerent wrote:If you were a bit more cooperative, you could start working on this and submit a patch for this, instead of bashing the hard work that's being done here.

I think you misunderstood my intentions. You continue to take my critiques as attacks. I do not understand why! I am just discussing. Don't you like discussing? Or don't you like critiques?

I am not here to teach anything to anybody. I am probably the less expert OpenGL developer, here. Though, I am just telling you my opinions, based on logic, nothing more. I can make mistakes or not, in some cases we simply have different opinions.
I am not happy that Apple abbandoned Carbon development. I am not happy to read that Apple do not want to fix Graphic Drivers. But I am not here to discuss about Apple.

divVerent wrote:Well, that's what SDL is on any platform, and it works fine. So why not on OS X too? It's IMHO rather SDL's problem to solve and not ours then.

The point I wanted to underline was not, if SDL team or Nexuiz team should fix it. I just wanted to say that SDL is not the right choice. I was helping you, saying « Do not waste your time with SDL! It is not the solution for Mac port. »; I was not attacking you.

The time for SDL isn't wasted, or rather, it already has been done. There IS a working SDL port of DP that runs - with almost the same code - on all three operating systems.

So in case the AGL one breaks, we'd simply release the SDL one only for OS X until someone is able to make a new "direct" one for OS X.

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.

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). On the other hand, rewriting the whole engine because a single apple fanboy says so is certainly not going to happen. 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.

Also, the GUI is simply not handled by the engine, but by Menu QC code, and that's going to stay (it allows the mod to bring its own menu design without changing the engine). The engine should only be handling creation of the window, drawing with OpenGL in it (exclusively), and running the event loop for it. 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, and also would require rewriting the whole menu, which was a lot of work. However, one thing could be done OS X specifically: in windowed mode, there is a visible menu bar at the top of the screen. Maybe it can get some useful menu entries, but no idea what.

And there's a good reason why so much is done in QuakeC, a bytecode interpreted language: only thanks to QuakeC, you can run Nexuiz on OS X at all. The game code can be compiled on any OS, and then runs inside the engine on OS X too. If it were all native code, Nexuiz would most likely run on Windows only.

Yet another thing: the engine is a Quake engine, that means, it is supposed to run Quake. This is actually a requirement, and especially means that it must be able to run Quake's progs.dat file.