Tweak nexuiz for highest perfomance over VNC?

[sebastian]

Here is a video of my first attempt of running Damn Small Nexuiz over VNC:

http://www.youtube.com/watch?v=BSXfUHGGb2U
(Watch in HQ, if it doesn't work in normal)

Any suggestions? Seems like the shadows are causing too many colors and making dark sections in 8bit mode, causing it to lag.

Is there something like mat_fullbright?

And what to do about the mouse? If I keep the mouse in the center, the player is still. But if I move the player will start rotating very quickly even when Im keeping it still outside center.

Its like the mouse "accelerates" when I approach the edge. I would wish it to not accelerate.

If it isn't possible to do "normal" mouse in VNC/nexuiz,
is it possible to configure Nexuiz's mouse handling to handle relative positions instead? I wish it so center->Left edge of VNC window is 180 degrees CCW, center->Right edgle of VNC window is 180 degrees CW, and left edge->right edge is 360 degrees around.

Center->top edge should then be 90 degrees upward and center->down edge should be 90 degrees downward.
Then players has to be used to run the mouse like it was a joystick. Theres nothing to do. But its better than current.

Any idéas on how to configure mouse in nexuiz to behave like this I have described? In other words, I would want movement based on relative mouse position instead of absolute.
About the degrees I can configure with sensitivity.

[lda17h]

I still think you are wasting your time

[sebastian]

lda17h: How are Im wasting my time?
Don't you think its good to try find a way to defeat cheaters completely?

Btw, fixed the mouse, I lowered mouse sensitivity a little.

Got better performance with r_fullbright 1, g_fullbrightplayers 1, g_fullbrightitems 1.

Im thinking of new ideas of increasing performance, for example, let the game client generate a 2D SVG vector graphic image of the 3D view and send it over network, let the client render the vector grahics image.

Then screen resolution of the client doesn't matter, the SVG image can be "streched" in any way.

I think server rendering will be a good idea to prevent cheaters, but the image needs to be sent in a effective way over the network to the client.

And a note on some cvars: Even if the "g_fullbright 1" cvar is a cheat classified cvar, its not actually unfair advantage, if I decide to continue with this of running a game over VNC, since then every player will be have to use the same settings, eg with g_fullbright 1, and thus, no unfair advantages, everyone have the same advantage. Those cvars needs to be used to gain performance over a system like VNC.

[lda17h]

Well, to repeat myself: I do not think it is possible (with todays technology) to make the remote graphics "fast" enough to give players an experience comparable to just locally running nexuiz.. ("fast" here refers to both the bandwidth required for streaming the gfx in an acceptable quality and also to latency). I just try to save you from spending (wasting) lots of time on this project. But hey, i'll shut up now. Go ahead!

[sebastian]

lda17h: In this, Im more think of sacrifying as much quality as possible, but still keep it playable, to be able to defeat cheaters.

It will not be anywhere near of "locally playing nexuiz".

Im also looking at other games if this could be accomplished with other FPS:es and such.

[GreEn`mArine]

Use gl_picmip to have less detailed textures which can be compressed easier.

Not that it matters, because with this approach you do not have any prediction on the client side (e.g. antilag, movement prediction etc.). This means that your solution is ONLY feasible in a LAN where delays are not noticable. Your solution over the internet will fail badly due to lag. Transmission time jitter or packetloss will play havoc with what the player experiences/sees on his screen anyway...

[sebastian]

About gl_picmip: Does this apply to Damn Small Nexuiz?
Since the textures with r_fullbright 1 is single color, it is no problem there.
I need other tweaks and such.

I also found a commercial solution that is based on my idéa:
http://www.onlive.com/
Apparently, its only requires 1,5 MBPS to send a image in standard quality and 5 MBPS to send a image in HD quality:
http://www.onlive.com/service/faq.html
Its a game streaming service. Its only available i the UK.


So there would be good to implement this in Open Source, just to prevent cheaters.
Im very interesting in this, since this can mean a dead end for cheating in online games.

[FruitieX]

The problem with this idea is ping. There are connections fast enough to send/receive live video at rather high qualities, but there will always be ping (unless you find a way of sending information faster than light ). As Green Marine said, there will not be any clientside prediction in this system which would be very annoying and noticeable even on very fast connections: input lag caused by input hardware (dunno, 5ms?), your input is sent to the server (network lag, average ping at let's say 40ms) + input received at server, server renders and compresses image (tiny delay, say 15ms) + image sent back to client (bit longer, maybe 60 ms) + image uncompressed on client (10 ms?) + image rendered to a screen with a response time of 4ms
Total: 134ms delay for any input action until it is shown on the screen. At this point it'd be extremely unplayable, mostly because of aiming which people would probably find ridiculously hard and annoying already at a ~40ms delay (?). Also, there is no antilag which means that when you shoot a target which is in your crosshair locally, it'll take 45ms before the input is received at the server which should be well enough for the enemy to move away from the crosshair in many situations. In LAN with really short latencies this might work, but I doubt it will for fast paced games like Nexuiz over the Interwebz.

Edit: Idea on how to overcome bandwidth problems: How about you only send some very basic stuff of the scene and still let the client render details such as textures? This means moving further away from your idea though, and just closer to whatever we already have right now
Sure makes eg. aimbots easier again, but they should be just as possible to construct based on the live video feed (scan for patterns looking like players, or if fbskins are on, scan for the same color as players have and aim towards that). Same thing goes for triggerbots, and probably strafebots too, which are about all the worst cheats you can create for Nexuiz (wallhacks aren't very effective due to serverside culling).

Edit2: Just had a great idea, what if you would send a full 360 degree texture of the view from the player position, and let the client look around in this sphere freely. Hud and weapons would still need to be drawn locally, but there is no way to cheat based on info you get from there. This way there would be no mouse lag, and you could create an antilag system by sending the coordinates of the point at which the player clicks and have the server check if it hit a player or not. Movement could *maybe* feel responsive if the client would apply distortion effects/interpolate between the frames in some clever manner based on which movement keys are pressed, until it receives a new image from the server. Heck, the server could maybe even predict where the player will be after [insert ping here] ms, and send this picture instead. This solution would sure be fun to see in action, but probably requires huge amounts of bandwidth, processing power and coding effort

[sebastian]

FruitieX:
Yes, thats a good idéa, but a problem is that this sphere needs to be transferred over network, even if the player does not look at that direction.

But you gave me a pretty good idéa: Im thinking of a tile system of small tiles, and when you turn or move in a specific direction, the tiles will move in opposite direction and new tiles will be transferred over network.

A problem is that if a player moves infront of you without you looking around or you move anything, you will not see the player.

------------

But Fruitex: What do you think of sending a SVG picture over the network?
How well can a SVG be compressed compared to a JPEG? Im think that a SVG can be compressed far more than a JPEG, especially if you use 8 bit colors, eg 256 colors.

Then players can play in fullscreen without the view becoming blurry.

------------

And do you have any idea on how OnLive system is built? Its the exactly what Im trying to create.

[[-z-]]

But Fruitex: What do you think of sending a SVG picture over the network?
How well can a SVG be compressed compared to a JPEG? Im think that a SVG can be compressed far more than a JPEG, especially if you use 8 bit colors, eg 256 colors.

Which layer of the system do you plan on doing the compression on? I don't see how this can be done fast in realtime.