NQ connecting to QW?

[ArchAngel]

[mh]

[Spike]

[ArchAngel]

Ok fantastic thanks, that's a lot to digest. Unfortunately simply linking the DLL isn't really an option for me as I'm working from the SharpQuake code base this time (C# all the way...), but at least having a timeline for the connection and the ability to partially test as I go a long will help. I'll have a good read through that again tomorrow at a saner hour and see where I get to...

... really quite tempted to have a look at porting a QW server over to Azure as well just for kicks

[Baker]

It is always cool when someone with past Quake interests has that interest revived.

If you don't mind, what are you engine goals?

I'm kinda curious since most people with an engine project have something different in mind. In recent times, most of them tend to be targeting another platform (PSP, iPhone, another gaming device, etc.) to some degree even with MH (Direct 3D ... although in addition to that, MH wreaks vengeance on the plethora of things he "does not like" or thinks should not be accepted) or Quakespasm (getting FitzQuake-style immersive single player in a desktop-platform neutral way) or well Mankrip/Qbism/leileilol+andrewj's software renderer stuffs.

[ArchAngel]

No, I don't mind at all

I'm working on 3 different Quake projects, because I've never been able to start a single project and stick to it... I get distracted and want to test out other things while I try and figure out why the other bits don't work properly

The first is an engine based on SharpQuake (Quake re-written in C#). It's great because of all the syntactic sugar in C#, it means a lot of the code can be made neater and I can use a lot of existing C# libs to extend things without too much hassle (for example, I got compressed Zip/PK3 support in the engine in around 10 minutes).
This project is designed NOT to be Quake... by which I mean I can break protocols and mess around with things that otherwise should be left the hell alone. One of the issues I've seen in Quake development in the 12 years since the source released is that coders keep finding themselves constrained by not wanting to break compatability with the original protocol, if you stop thinking about it as a Quake engine and just think of it as an engine it means you can play with whatever you feel like.

The second is a QuakeWorld client written in normal boring C. All I'm looking to do with this one is add some convienience to the engine without game play changing features. I want stuff like built-in server browsers and AVI recording, but I don't want transparent water or crazy shadows. While I love this stuff for normal play when it comes to QW that's all I want to play.

The third is a QuakeWorld server but re-written in C#. I'm planning on butchering some of SharpQuake to get a leg up on this project as it's worryingly huge. The final end goal with this is to port it to Windows Azure. As a Microsoft Partner I get free time and bandwidth with Azure, so I thought it might be cool to try out Azure with this, especially if I can get it to take advantage of some of the dynamic scaling from Azure.

[Baker]