We NEED more developers!

[divVerent]

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.

[Slav]

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

[Alien]

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

[Slav]

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?

[esteel]

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'?

[divVerent]

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

Try r_glsl 0 for a first test.

[Slav]

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?

[esteel]

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

[ender.saka]

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.

[divVerent]

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