WE are doing split screen HaRd_cOrE NeX Modding _FIRSTSCREEN

[DeVsh]

yes i am fully confirmed that the road to take is

1) enigne mod so it supports two clients
2) aim support for joystick

[DeVsh]

we will never get started, because the design changes all the time. Because if we start doing it and realize that we have come to a dead end then we will end up doing loads of unnecessary work. So i think we better start with joystick aim support first.

[morfar]

we will never get started, because the design changes all the time. Because if we start doing it and realize that we have come to a dead end then we will end up doing loads of unnecessary work. So i think we better start with joystick aim support first.

Nexuiz already have Joystick/Gamepad support. Gamepads is much better for FPS games.
But if you can't aim with joystick it's probably just some cvars you need to tweak. joy<tab> in console.

[Alien]

It seems you need to understand client side - server side architecture first.

[DeVsh]

dude yes we are aware we dont understand the architecture!! but we just need to mod the engine, i thought about possible ways of doing it and with some of you enlighting me i realised that we need to mod the client script of the engine so it can run 2 sets of game data (this doesnt apply to just running two instances of nexuiz, you could run nexuiz in top window and quake in bottom. I dunno why the hell would someone need that but it would be possible after the modded engine finished)

We just need to separate stats and entities of player1 and player2 so player1's values don't affect player2's values. If we missed a bit of code e.g. responsible for health then player1 and player2 would both have same amount of health all the times (so if player1 gets killed both do).

According to LordHavoc

Yes it requires substantial engine modifications, to have separate storage of stats and entities for each player, and a few other things, it's all clientside changes but it's significant work.

at least we know where we are heading

P.S. as i said in the previous post we are starting with gamepad support first, so im fixing my xbox360 one and downloading drivers for it.
P.S.S. Rumble would be funny but tooo much work in engine to send "rumble command" to the driver (the driver doesn't support rumble so here is a dead end). And add the send rumble function to collision checking (which i have no idea how it works).

[DeVsh]

well the aims changed a bit

I'm onto my own game which im making with the hardcore nex Trio. (which i doubt i will finish)

But first of all i decided to proove to myself that i can actually finish something (the split screen). Well my xbox360 game pad driver is not working well. so to hell with gamepad support if i aint got a recognised gamepad. So... i am 1/50th of the way in translating the engine from C to C++ (it isn't much work apart from optimising it and changing #define into constants). And then i will make split screen. If i can be bothered i will edit nexuiz QuakeC to support double HUD and two players, splitting input In other words making the game playable (not just having a second rendering scene). That is just to get me confident with game programming and prooving that i can finish my projects.

[DeVsh]

i dont dare to touch some bits of the code because i have e.g. no knowledge of the windows API or no knowledgee of the linux API for using the CD drive.
So far i have modded qtypes.h - i deleted qboolean struct because its pointless in C++ which has its own boolean datatype.
bspSOMETHING.h nothing really apart from changing all the #define BLABLA 1 to constants and i will do that in other files (quakedef.h), obviously i left the #define that define a non-numerical macro e.g.

#define BLABLA (BLABLA1&& BLABLA2)

i couldnt put this as a constant boolean (just in case BLABLA1 or BLABLA2 change).
There is only one occasion that changing

#define MAX_HULLS 1
TO
const int MAX_HULLS=1;

might backfire. If MAX_HULLS is used in a strings, or worse Console prints.

cout << "Maximum amount of hulls MAX_HULLS";

OUTPUT (with a #define)

Maximum amount of hulls 1

OUTPUT (with a constant)

Maximum amount of hulls MAX_HULLS

So you see the point!!! I know i can get around this one. But what if its not cout but Con_printf();
Although where there is a will there is a way.
When i'm finished i want to see wherever the C++ version works faster than C (probably not much faster or slower)

P.S. I have ported 6 files so far.
P.S.S Btw i made a night/day sky simulation for my game in irrlicht (i find the forums really UNFRIENDLY) with sun moving around in a sun like manner. Adding moon and clouds to it soon. Volumetric would be good and my aim is to achieve clouds that are a bit lighted up on the side facing the sun(maybe not by real rendering but an algorithm changing the colour) . I'm rewriting it because i borrowed some code from some guy. I feel proud like a little boy.

[DeVsh]

sorry its my knowledge and grammatic use of it that is letting me down

CORRECTION #define DOES not REPLACE in STRINGS

[DeVsh]

i give up after translating 20 files. I need more experience with OpenGL!
I will come back to it in the summer maybe

[Blµb]

you need more than just that...
eg. replacing #defines with constants it pointless, really
replacing qbooleans with bools and even using c++ doesn't get you very far, qbooleans work just as well, althoguh a simple 'sed' could get the job done in seconds I guess ...

and it won't work faster, maybe just slower, maybe the same, dependson how much c++ you add
c++ does have some "speed traps" as I like to call them

and in some places of DP it even matters (much) if you just change a
for(i = 0; i < get_some_number(); ++i)
to
int num = get_some_number();
for(i = 0; i < num; ++i)

(I did change some of those for loops and got a major fps boost for certain rendering situations, was quite some time ago... got committed to svn too)

now imagine... you decide to use classes, and use an object in that for loop... even just the ctor call which is then done many many times might take away some FPS...

yay *remembers a certain metaball code and a vec3 class ... ...*

not saying c++ *has* to slow it down - but it needs a little more thinking to make it efficient