with the newest stable source of NeX we programming n00bs to C and CSQC are going to develop split screen. I am doing this because i realized that if you want something in nex that is not approved (let me quote "who would want split screen in FPS) you need to do it yourself. Especially now when the nexuiz developement team has only 5 members.

I am not taking any criticism like "you are not going to make it" or "another dead project" if you want to say something say something to help, for example inform us on How Exactly to get multiple views using CSQC (i know you can). If you are not going to be constructive please LEAVE THIS THREAD. I know a bit of python so i am not a programming n00b, we are currently looking at the engine's source code and a reading tutorials to understand functions etc. Next we will get on with identifying which bits will need changing in the engine and looking at nexuiz's source code to define which bits of that need changing.

We will be setting up a blog/forum to log down every change and document it to an extent that if i had an accident and forgot all about the project i would be able to recall it (im not being serious, so dont play devil's advocate). I AM WELL AWARE THIS PROJECT MIGHT WELL GO DEAD and that is why we are documenting it.

We have set up our targets
NOW onto THE TOPIC. We have sorted our priorities for version 0.1.0 in this order.

A] Understanding how processes take place for all things listed in point B e.g. trajectory of a bullet and bind the view with position of mouse and position of character.

B]
1) managing to produce 2 views one above other (this will give us some hard core CSQC learning time)
2) editing the networking client code so it is able to connect to a non modded server. We will achieve this by locating 2ce as much ports to the client and forward the packets around and making the client add a bit of data to a packet (or label them), so data sent to player one does not affect player 2. The second problem is to cut out (for player 2) only the part of the packet which applies to itself, so the client doesnt get the positions of other players twice and mess up the whole positioning (due to lags). Mapping of values sent by the server to (what it sees as two clients running on same IP) values of player and player2 on the client side.
3)Finding out if the engine supports joystick AXIS (i know joysticks are supported) and if not add axis support & deadzone , threshold.
4) Binding the view to the position of player2 and joystick (RX and RY) and separating inputs (so if you move the joystick it does not affect both views).
5) Redoing/Renaming values so player2 gets his sets of values for health and stuff
6) Sort out .cfg files
7) Making 2 crosshairs, 2 scoreboards independent of each other, "You Fragged" and "You have been fragged by" appear accordingly in the right place and in the right time, Bonus Flash relocated to appear either in top part of screen or bottom (engine modification i think) and loads others
8 ) Aiming support for Gamepads/Joysticks, I have a few ideas but i need to figure out how to make targetting sticky. Make two crosshairs one (dummy) dependant on Rotational joystick in the center of the view and one moving within 50 pixels (or whatever measuring unit in XYZ) of the position of the mouse trying to line up with a hostile target (i need to think how to script the detection of the target and how to make it line up). The basic flow is that there is a constant line drawn between targets in sight and the player on the joystick (lets say the crosshair is X away from player). Now if a point that is X away from the player on one of the lines (that i was talking about previously) is 50 pixels or less (or N away in a straight line or less) from the dummycrosshair's (Rotational joystick's) position then it moves away from the center of the screen to be in line with the target. After target no longer in the boundary the croshair moves back in line with the other one. I know there are going to be two main problems "what if two targets are in the boundary" the closest to the 'false' crosshair will be chosen. Number 2 is obviously aiming rockets, because you need to aim them a bit infront of a running target. Thats why we are going to add a button bind with a variable that will either enable "smart_target" or disable. For example you might map it to button 9 on the xbox controller (which is the left thumbstick pressed down) so you can toggle the targeting with it. This will be hard and probably will require engine modifications OR nexuiz code remake in big style (maybe using some bot AI code). However this is not the top priority and if it will be playable split screen then we crack on with this, but if this takes too long to develop it will be released in version 0.1.1 with all toggling options like multiple keyboard and mice support and enabling the user to switch views(top/bottom) or input devices between player1 and player2.

In later releases we will be cleaning up bugs and code, also we would like to take advantage of stereo sound and map all sounds for player1 to right speaker and all sounds for player 2 will be played through the right speaker, while the music is played through both.


THIS IS HOW THE DOUBLE CROSSHAIR IS GOING TO LOOK (note its a cut out from a 2ce as big picture.

I'm pretty sure i missed out on some other bits that would make the game impossible to play or buggy like one player press left mouse button and both players shoot, and feel free to add to the list of things that need to be done.

P.S. I know i once launched to make in-game VoIP for nex but i promise you if we get bored with split-screen or we finish it we will pick up on VoIP. I found a clear way of doing it. None of the stuff that i do is unfinished, it's only suspended for a long time and doesnt have a resume date.

I'm 100% pro split-screen
I remember playing Serious Sam with my guys, using gamepads on a single machine. That was awesome!

we want to proove that PC has every feature consoles have and that open source games are better (does COD4 have split screen???)

Well, good luck. If more PC games had this functionality there'd be no need for consoles for anything other than using them as doorstops.

currently we kinda managed to get a second view but rendering right under the other one

we froze due to lack of knowledge of quakeC but we are learning quick hopefully (at least i am)

we are running into big problems because the entity type .self

In quakeC it is impossible to create new entity types, but we need 2 .self and .self2.

because the code is compiled not interpreted by the engine, then we cannot solve the problem by editing the enigne.

sorry i got confused here while learning QuakeC (i do a bit in C)

It is impossible with just CSQC, sorry. You cannot run two clients using one connection. You can't even send two aiming angles instead of one.

The way to do splitscreen is rather:

- change the engine to run more than one client (that'll be a huge change)
- call the CSQC drawing functions for BOTH clients
- either set up view ports so they are separate (like r_stereo_sidebyside does), or let CSQC decide where to draw and use the full view port

i tried running two clients on one computer and they connected. What we are on about is making the client LOOK AS IF IT IS two separate clients on same connection.
Now onto the aiming topic, ARE YOU on about SENDING TWO AIMING ANGLES TO SERVER OR CREATING TWO AIMING ANGLES.

However we are well aware that we will need to mod the engine

this is quite clever for the engine bit to run two clients (we might consider)

I AM very curious on how networking works, because my idea was to have the ports in the client 26000-26003 (26000 and 26001 for player1 and other two for player 2) i was curious is it the engine that translates whatever is in the packets and changes variables of .health and etc. on the client OR IS IT THE CLIENT.

ALSO i would like to know what is in the packets (basically networking script)

P.S. I understand dark-places is the linux-gfx.sh and other files in the main directory.
P.S.S I have an idea on how to get the aiming done (partially homing missiles, homing for the first 0.1 of a second)

yes i am fully confirmed that the road to take is

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

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.

DeVsh wrote: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.

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

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

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.

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.

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

CORRECTION #define DOES not REPLACE in STRINGS

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

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

As my mom says "actions speak louder that words" so i decided to get to work for 2 months and here is the RESULT












P.S. joke its my own game, but i loaded a nexuiz level into it.

That side note at the end was really mean

But keep up the work, as long as you enjoy it.

i know im mean :)