We NEED more developers!

[Alien]

I ask you to stop destroying the threads.

[ai]

I ask you to stop destroying the threads.

That would kill his purpose of trolling these forums.

[tundramagi]

I ask you to stop destroying the threads.

Those who respond to "nexuiz needs help" with "here are feature requests that I want you, the developers and or developer to code" destroy the thread. Unless, ofcourse, you agree that such things are relevant and desired on a "please help nexuiz" thread?

Presumably desired:
"Nexuiz needs help, there is too much work for X developers"
'Oh, hello, I will help nexuiz by programming/modeling/etc for it and decrease the load'

Presumably not-desired:
"Nexuiz needs help, there is too much work for X developers"
'Oh, hello, First off I would like to tell you that nexuiz sucks on Machintosh-Avante-Vangaurdism-Computer, What I need you to do is comply with these following ten demands which will take about 5 months of your time developer/developers...

I can also model but I won't do any of that crap untill you comply with my demands. My demands are logical you cannot refute them. Apple is the best. Oh, BTW, to show how much programming skills you are losing if you don't bend to my will I will attack QuakeC and say that C is better... yea that will make me sound like a pro-grammar."

Only apple users could see that as "helpful" and a proper response to "we.need.more.developers".

[ai]

Your rants and personal attacks on everyone who doesn't do exactly as you vision the world is also not related to this thread's topic. Ender.saka's posts are actually more along those lines compared to your two posts here.

Now stop it, DON'T respond to this and leave this matter alone unless you can talk and reason like a sane person. You always prejudge someone in a harsher way than Christianity.
If you post anything that is unrelated to the topic at hand I will delete your post. That means, don't attack anyone, don't rant, don't spam, don't hyperventilate etc.

Case closed.

[ender.saka]

Apart this, I want to tell you all (developers) that I have started to code a Cocoa port of vid_*.c. I called it vid_nsgl.m (the "m" extension is just for GCC to automatically compile it with Obj-C dialect, actually I could compile it in Obj-C without the need of that extension, but that way I have not to waste my time with other settings). I do it in spare time, so I do not know how much time I will need to complete it.

Now I have some questions and proposals:

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.

[divVerent]

Adding new files is always a long and complicated process, as many people are using proprietary project files (e.g. for Visual Studio) and then a rain of complaints about undefined symbols comes.

As for quakedef.h - feel free to move declarations to individual header files matching the .c file name. This file is simply a legacy from the Quake 1 origin of the engine.

As for where video is started - no idea, just use a debugger. It is that way because many subsystems require video to be up, and e.g. the cfg file normally gets parsed before the video initialization. If the cfg file executes a command that requires video to be initialized, video is initialized at that point. Why does this even matter to you? Just initialize video in VID_InitMode, and all will be fine.

On the other hand, one can't initialize video before reading the cfg files, as the video resolution is stored in there.

[timotity]

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

[[-z-]]

epic first post, thanks for joining and taking the time to understand how the game code works.

[tundramagi]

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

Your opinion is worthless. Learning quakeC takes no effort. Even a stupid person like me has been able to make a few doodlings in it. Clearly you've never programmed anything worth a damn (or anything at all).

I also am sure that the trees around you are not on fire.

[esteel]

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

Before other keep bashing you.. if you had read the thread you would have noticed several hints that quakeC is VERY VERY VERY.... VERY similar to C and basicly needs no further understanding if you know C to get started. Of course there are certain areas that you 'need to get into' but that applies to every new project one joins..
Besides a rewrite to C is very very unlikly to happen because it takes lots of man power to rewrite all the current (good and tested) code..