such things generally require proper camera control. This means you need code client-side.

This means you have 5 options...
1) Grab a C compiler and rewrite chunks of the engine yourself. QuakeSpasm is one of the cleaner engines if you want to go this route.
2) FTE (my engine, yes I'm biased but its awesome).
3) DP (somewhat dead now, which by definition makes it stable).
4) Target vanilla (and compatibles), using pure ssqc. Feel crippled. Moan about the lack of tracebox. Suffer from network precision/protocols. Etc.
5) Get an answer from someone in the Quake2 community...



http://daemonforge.org/?i=riftlords 2d csqc-heavy example that should work in both fte+dp.
(being mostly-pure csqc, it skips all the networking stuff which makes things a little simpler but removes the possibility of multiplayer).

http://www.google.com/search?q=%22The+Ascension+of+Vigil%22 is an older example that should actually work in most Q1 engines. You should be able to achieve the equivalent in Q2 also. However, imho without some clientside enhancements its always going to feel a little clunky. 

camera control? are you sure you're not mistaken in thinking I want to make third person game?

Also Ascension of Vigil looks great, I love it. Very impressive.

How hard would it be to get the software look in FTE?

If I was rewriting chunks of the engine, that'd be like, going into the engine itself and rewriting it? I think that might be a bit too much.

So 4 is definitely out of the question, I don't really like DP, so, if I used FTE would I primarily be using CSQC then?

Also, if you know any communities of Quake II modders, I'd love to go and ask, I had a lot of trouble just finding this place, lol 

Once you try to make a model for Quake or write some QuakeC (the game logic, it is not part of the engine) ...

... you'll run away screaming and yelling as if you were ignited by spontaneous combustion.

Unity has video tutorials, documentation, deep support, 1000x the capabilities and is refined.

Quake is like banging rocks together to try to start a fire. Plus there's nearly no documentation or tutorials for writing code or making models. 

Yes but I want it to run on a raspberry Pi 

Then get started with QuakeC tutorials.

http://www.insideqc.com/qctut/

Making a game means coding game logic. 

camera control applies to side-on stuff too.
you can set the m_pitch and m_yaw cvars to 0, which prevents the user from being able to fight the gamecode, but that also means you can't use the mouse for anything at all (like rpg dialog stuff, or aiming, or whatever).
Some of the videos of TAoV have really jerky cameras due to limited network precision (csqc to the rescue!).
Either way you'll want a custom hud at some point, and that requires client changes.

If you want something like Ascension of Vigil, then you can just manually move your entities through the world while being very careful to not move them very far along the y axis. If you're okay with gibs falling out of the level then you could simply use all the normal physics functions with a clip brush blocking the hole in the side of your map (this doesn't stop tracelines, but will stop traceboxes that have size - q1bsp is a little awkward in that regard).
All of that can be done from ssqc in a multiplayer-friendly way.
Your csqc can then do the hud+camera+mouse, and let the engine deal with interpolating everything.
So you'd have some logic in the csqc code making stuff feel nicer, with the actual game logic+movement+etc in the ssqc.
If you were going with the hack-an-engine route then it'd basically be the same things, just in C instead of QC.

https://sourceforge.net/p/fteqw/code/HEAD/tree/trunk/specs/csqc_for_idiots.txt?format=raw This is a primer I wrote for csqc a while back. Its not perfect, but what is?

The alternative is to shun ssqc completely, the full entity states are instead directly known clientside and without latency. You need to do some manual interpolation (check my purecsqc mod as an example for that, maybe just frame interpolation, possibly origin+angles too), but if you go that route then you can completely skip ALL the networking stuff, which makes complicated UIs much easier and it all becomes more self-contained.
The catch is that with the networking gone, there's no more multiplayer (although I guess you could do splitscreen easily enough if you wanted).

http://triptohell.info/moodles/junk/purecsqc.zip there's my 'purecsqc' example/test mod, other than the .src and a few extra .qc files the 'ss'qc code (from CleanQC in this case) is unmodified, just running clientside (overkill - I used some wrappers to csqcify various ssqc-specific things like writebytes).
screen.qc CSQC_UpdateView: lots of code that throws things at the screen. called by the engine each frame.
purecs.qc CSQC_Init: called by the engine at startup. sets up the worldmodel, spawns everything.


I don't know of any q1 engine that doesn't support chunky-pixel stuff - just provide a default.cfg file with your mod that sets gl_texturemode gl_nearest_mipmap_linear or something.
FTE has some additional 'perversions' like replicating software renderer's colourmap (aka: r_softwarebanding 1), and gl_affinemodels 1 which 'bugs out' model rendering so that textures no longer follow straight lines... Disabling interpolation is also an option.
There's a preset that you can apply in FTE that will set all of these options, but for standalone mods its best to put it all in your default.cfg and not risk the user picking a different preset.


Regarding the Q2 community, I always found them a little fragmented myself (considering that I'm quite Q1-centric). Most of the contact I've had with them has been via http://forums.insideqc.com/ which is more of a Q1 site (note that that site has a load of [cs]qc discussions too, while this site is more focused on mapping, but is less active).
quetoo, q2max, quake2evolved, yamagiq2...

... you'll run away screaming and yelling as if you were ignited by spontaneous combustion.
This is why all the recent mods I've made have had absolutely no chance of working on vanilla... and others...

regarding the rpi specifically, afaik fte currently doesn't support the rpi-specific egl thing. It also doesn't support inputs on linux except via x11 or sdl. It should start up (when compiled for arm), but it'll be limited by mesa's software renderer. 

If I did go the route of QuakeC, I'd go fully CSQC, because I plan on it being a single player experience that's not a hassle for non-Quake players to play.

I'm also considering just learning C and doing it in C as that would provide more transferable skills, I imagine learning QuakeC doesn't transfer that much to actual C, but learning C could transfer to C++ and that is very generally useful, even if it didn't transfer to C++ I'd still be able to screw around in all the id tech engines up until id tech 4 and maybe other engines too. 

if you're familiar with halflife modelling, you can export .smd files from whatever editor you like.
If you're familiar with unreal modelling, you can export .psk/.psa files from whatever editor you like.
(or .md5mesh or .fbx or .obj)

You can then use Lee Salzman's iqm compiler ( https://github.com/lsalzman/iqm ) to then convert them into .iqm models for either fte or dp.
There's a fork of it on fte's svn ( http://forums.insideqc.com/viewtopic.php?f=13&t=5839#p58369 ) that uses scripts instead of just commandlines, which makes it a smidge easier to use (as well as providing for a few fte-specific iqm extensions).

If you want to specifically create an .mdl then taniwha's blender exporter is probably your best choice, assuming its kept pace with blender's continuous python incompatibilities. Many people use a program called qME to make mdl models, but you probably don't want to use it for any actual editing (just as an obj->mdl converter).

Note that I don't personally have the patience to make models so this should be considered as second-hand advice. 

if you want to go C (especially if you're still learning it), you're probably best going with yamagiq2, simply because q2's gamecode is already C (which means you don't have to rewrite much of the engine first).
Yamagiq2 is supposed to be a clean+faithful q2 engine, which means it should still look decent.
While awkward, you can do hud stuff from q2's serverside code (there's some sort of script that says where+when to draw stuff). You would also need to do something weird to lock the player in place.
The down sides are that its quite easy to corrupt all sorts of things in weird ways with double-frees etc with C. Q2 also has a fixed 10fps network framerate, which makes it feel really laggy even in single player (although with C you should be able to edit the engine+protocol and switch it to 60fps or so).
You can then fix up everything else when you need it (like adding more hud commands so your hud isn't quite so limited).

Right, that said, QuakeC is nice because arrays are bounds checked, its sandboxed so (in fte) you can safely just strcat strings and never bother to free them. If you're using an unmodified engine, you can just provide a single copy of your mod, instead of having to recompile it (and the engine, it you changed that) for every system that you want to support, and no complaints from users of other systems for you not supporting their system. Its slower, yes, and less transferable.

It is possible to run C gamecode inside FTE (eg: ktx), but not clientside. That said, personally I wouldn't take that option (partly because the exposed feature set is much more limited). Its also not well documented.

The way to survive C++ is to stick to a sensible subset, and to never have to read someone else's code (at least if they used a different subset). C++ is MUCH harder to debug, in part because you've no idea what's a function call and what isn't, hence subsets. 

I gave up trying to do that for very good reasons.

Mostly lack of support, bugginess, untestedness of FTE and DP features, jumping through hoops to get simple stuff done, eventually understanding I was being a lot more masochistic than I really want or need to be.

You're relying on obscure, obsolete software tools when you could just use a modern engine like a normal person.

CSQC isn't the answer to everything, it actually is often pretty hacky. It's a honeypot. You're depending on one programmer's work and goodwill. You can do simple camera and UI stuff with it, but again, why wouldn't you use Unity or Unreal? Where do you get the idea that Unity and Unreal have "bad performance" or anything like that? Unreal, for instance, is MADE for first person action games.

You need your game to run on a raspberry pi? Well that might complicate a lot of things, but it also, again, sounds slightly masochistic to me. 

all I'm getting from Jonas is that it's a better idea to learn proper C and dive straight into the engine itself as opposed to relying on CSQC, which I think is what I'm probably going to do

Spike, if you're still there, you said Quakespasm is a good engine to use if I wanted to go that route, why is that specifically?

Also I'm definitely going to check out Yamagi Quake II 

Why does it have to be ID ? http://cubeengine.com/ 

I'm assuming Unity is a good choice and if you want brushed based construction it's available as a plug-in.

https://logicalerror.github.io/ 

I'd suggest Quake III as being the most appropriate id engine; it has the best combination of flexibility and performance, and a lot of the horrible work you'd need to do to get it working on e.g. GL ES platforms is already done for you.

Older != better; not always. In the particular case of Q1 it has a lot of cruft, grot and senseless assumptions from it's origins as an MS-DOS program that needed to run in 8mb of RAM on a platform that didn't support multitasking nor virtual memory. The GL version is riddled with bad practices that back in the day were hidden by a 3DFX mini-driver which intercepted the calls and translated them to something more sensible. Q2 doesn't have the DOS crap but still has the bad GL crap. There's just too much work involved in bringing these engines up to spec for modern hardware - even modern low-end hardware - and unless doing that work is something you want or enjoy, just choose an engine that's more sensibly designed to begin with instead. 

As someone who actually tried to make a game in ID1 tech (albeit with Darkplaces and its buggy physics), I left for Unity for these reasons:
Unable to implement crouch and proning in a way that didn't fail and stick the player inside or to a wall.
Unable to implement leaning.
Unable to effectively have different size bounding boxes for items, enemies, etc. without them randomly falling out or getting stuck.
Able to implement mouse cursor, but not able to raycast from the mousecursor into the world, only good for UI.

Unity, you're doing it wrong. Performance is possible, even on raspberry pi.
Don't use shadows. Bake them in or even use sprites under characters.
Don't update everything every frame. Use time based updates to space them out every 0.1 seconds, similar to how quake does it. This is super important for lowe end CPUs. Of course you can still update camera movement amd player movement every frame.
REALLY JUST DON'T use one 3D model for the whole level. Break it up into small chunks otherwise the WHOLE level is rendered even with occlusion culling.
Don't use antialiasing.
Minimize GetComponent calls.
Minimize materials such as through texture atlasses.
Minimize texel density (minimze pixels per screen pixel).
And, most importantly, DO NOT USE THE GARBAGE COLLECTOR. By destroying objects you subject yourself to a random performance hit on a random frame where Unity cleans up the memory. ALWAYS create a pool of all objects and simple enable and disable them to "remove" from the level such as gibs, corpses, bullets, particle effects.

Pool is cool.
Destroy i s b ad. 

I said quakespasm because its simple and not a kitchen sink, but still runs on more than one system. If you're new to C, this will be much less confusing than FTE or DP would (personally I still struggle somewhat trying to read DP's code, so I expect other people would have similar issues with FTE - either way complexity is bad for beginners).
Plus if you're after transferable skills then fixing up its limitations means you'll be forced to learn more than just your own code. :)

YamagiQ2 and QuakeSpasm fill the same niche, just for different games. Both have limitations, but with a little C you can work around the simple omissions. Complex stuff requires lots of maths too... 

you guys decide to invest years of work into making a game without knowing how to program and the basics of computer graphics?! 

This is the interplanetary spaceship paradox.

If you send a human in a ship to Alpha Centauri, a newer generation ship launched decades later would get there first due to advances in propulsion.

By the time someone learned all the sticks and stones methods to make a "new game" in Quake using the archaic methods ...

... a future version of Unity or a future version of Raspberry Pi come out by then.

Eliminating the logic of the original decision. 

I'm targeting a Pi because of the specs, not just because it's a Pi

I'm considering Unity but no matter how much people say it's "optimized" I'm not seeing anything that shows that it's anywhere near as optimized as an old 3D engine game or GameMaker or OGRE or anything. 

the point of what "optimized" means. 

I just think that learning this stuff will tremendously help you guys to finish something. And I want to see more stuff finished. 

Specifically what I'm saying is, they claim that it runs as well as the code of the developer working with it and coding for it, so in theory it should run on just about any kind of PC that Unity compiles to with the right, lightweight game, but I can't find a single example of that. 

that you optimize for a specific target architecture and application (i.e. graphics level). Quake is optimized for 90ies hardware and quake graphics. Unity is optimized to do other things really well. 

The problem isn't the engine. The problem is you.

You can't swim. You plan to swim across the English Channel when you can't even float in the deep end of swimming pool is the problem.

Unity has a path for people with your level of experience to get results. Quake virtually requires years of experience coding to do anything complex. 

Quake has numerous quirks that make it difficult for beginners. First is the problem with models. Each frame of animation in the model file is basically its own model with the same number of verts just in a different positioning. This has the benefit of being able to animate effects that are nearly impossible in any other engine such as creatures that melt or morph into different shapes, but has the HUGE drawback of taking forever to manually move the vertices around for each frame. There are ways to use Blender and export, but fine tuning will need to be made for any enemies inside QME.

Second, you are limited to a 255 color pallet (256 is transparent). Some engines allow for override full color textures but this means you need to make each texture twice, one for a wad file to use in the editor (which will not be the right color so editing will feel wrong), and one for the actual game at runtime.

Third, physics are limited to 3 hull sizes. Quake generates 3 different sized "envelopes" for collision against. There are only 3 different sized objects: point, 32x32x56, and 64x64x80. All 3 only calculate physics as though objects are merely a point so collision checks are lightning fast. The three hulls are 0: the world, 1: the world inset from itself 16 units, and 2: the world inset from itself 32 units. Any other sized object will get rounded up or down to those sizes for movement physics (gun hits use any custom size FYI).
There are other drawbacks too that I can't think of right now.

Unity performance is marred by a vast amount of people not using it in a way that makes it performant. If you try to throw reflections, realtime soft shadows, bump maps, DOF, Temporal AA (seriously would be nice in Quake tho) and the like in, then Unity will be slow...because those things make any game engine slower because of the tremendous overhead on the CPU and the GPU.

Unity can be fully tailored to do anything at your will, but this comes with the cost of you being able to make something that runs poorly. It is up to you to make it run smooth and fast just like Quake. Unfortunately, most things you have to do yourself since many internet tutorials have methods that kinda sorta work but not very efficiently.