We NEED more developers!

[Alien]

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

[divVerent]

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

[ender.saka]

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.

[halogene]

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.

[esteel]

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

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

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

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

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.

[tZork]

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.

[divVerent]

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.

[Alien]

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

[ender.saka]

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.

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.

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.

[divVerent]

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.