I think the technical work you've done with this is very nice.

You don't state whether this is a hardware renderer (OpenGL like) or a software renderer (or both).

I know you used Apple's Metal Framework which also has a 2D API (AFAIK), so it could be used for transferring the software renderer to the buffer.

(If you've put a few months of technical work into something, taking another 5 minutes to upload a screenshot is usually worth it.) 

I explained some of that in the repo's README.

The OS X and tvOS targets both use the software renderer from the engine, but present the rendered frames using Metal. I had no idea Metal had a 2D renderer; I just used a single quad covering the whole screen, with a texture. BTW, it's a 1-byte texture; conversion to RGBA actually occurs in the fragment shader itself (the palette itself is another texture), which speeds things up a bit.

For the iOS VR target, however, I'm actually using OpenGL ES. I had to; I'd prefer using Metal directly, but the Google Cardboard SDK forced my hand to use GL. Hm, now that I think about it, if I ever implement an iPad version, I could start working on a pure Metal renderer...

As for the screenshot, I expect to provide one soon for OS X, and possibly one for the iOS VR one - not sure if I can do that in a Apple TV :). 

@Metal 2D - my mistake. In early summaries by 3rd party new sites it sounded like it would be all-encompassing framework for all graphics API. 

I actually have the new/current Apple TV. Exactly how controllable is it with the remote? :) 

The Siri Remote? Barely. You shiuld be able to, but it can be really cimplex and tiring. And now that I got ahold of a proper game controller and was finally able to add support for it, it is now no longer recommended :) . 

Should, complex. Writing on a phone can also be "cimplex" :D 

Here are some screenshots from the OS X and iOS VR targets:

OS X:
- Running from Xcode, 320x200 : http://imgur.com/XZCu2Eh
- Start screen, 2880x1800 (in *software mode* :O ) : http://imgur.com/KWQDX9a
- Termination Central (e3m1), beginning, showing how awesome of a Quake player I am (at 27HP ;D ) : http://imgur.com/KURM1sW

iOS VR:
- Running from Xcode in Simulator : http://imgur.com/XZCu2Eh
(This last one makes no justice of the actual VR experience; one has to actually experience it to understand.) 

Ugh. My mistake. First screenshot should have been http://imgur.com/ajYm6dH . Sorry about that. 

Regarding quake+ios:
http://www.fsf.org/blogs/licensing/more-about-the-app-store-gpl-enforcement

its nice to have more options for OS X though (where sideloading is still possible, for now). 

Ah, so I guess Open Arena isn't sold for the iPhone then. Oh wait. It is.

https://itunes.apple.com/en/app/id771105890 

So, if I understand things correctly, nothing short of a full engine rewrite will solve that problem in a legal fashion.

Also, there is this issue that has bothered me all this time about the vanilla engine using more global variables than the total number of atoms in Earth, making it virtually impossible to have two or more instances of the engine running in parallel. And the severe memory limits. And some few minor assorted things I've seen in it that I don't like as much.

Hm, maybe it's time... (evil grin) 

hmm, that seems different than how i interpreted it. I thought that the GPL doesn't allow you to redistribute the "product", only the "program". Product contains other copyrighted assets maybe, the program is only the executable to which source code has been GPLed. Just because quake is GPL doesn't mean you can freely distribute the whole game including assets. The app store terms don't seem that different than the terms of sale of traditional software in that regard. And you can sell games that use GPL engines commercially, right? 

you can sell GPL software, you just can't restrict the person you sold it to from re-selling it, and that's what apple is doing, despite it being free (mmm, beer).
the 'gpl' applies to the entire 'derivative work', but not to 'mere amalgamation'. however its a matter of debate whether or not the 'derivative work' includes the qc code that depends upon your engine's builtins or the maps+models which were made specially be be used by that engine+mod.
apple's conditions still restrict you from redistributing the engine part regardless of whether its an amalgamation or a derivative work.

certainly the game content needs to be installed separately from the program, which has little (but not nothing - it depends on your interpretation) to do with the gpl and everything to do with the distribution limitations of the original game content.
this is a major issue with web-based ports and android too, not just ios, its even an issue with windows+linux+etc, but at least they have a somewhat usable file manager type thing.

also, iirc there was some other clause against virtual machines (oh noes! you might hide a competitor to one of their products! no sideloading!), which means you'd also need to ditch qc in favour of native code, or at least find some other way of preventing the user from changing it (like embedding the progs into the binaries - note that q3 can just use shared objects or something). I'm not entirely sure about that, so verify it yourself before you bother to take action over it.

it'd be nice to rewrite quake from scratch, but if you did so it likely wouldn't feel like quake any more, which would kinda defeat the point.

@Baker: So I guess proquake never broke the gpl either. oh wait. it did, originally anyway. 

Spike is not a lawyer.

But he likes to troll iOS and Apple project as if he is a lawyer, because he does not like the platform.

And he'll post wrong, bad and out of date information to do so. And apparently, is willing to muck up your project thread here too with his anti-iOS positions.

Spike should have started another thread to argue his positions and not dereailed your project thread.

/Me exits this sub-conversation. 

Speaking to an actual lawyer about this issue sounds actually like a good idea, in any case.

Besides, even if the lawyer sees no problem with that, the real, actual way to test if this is possible, is actually to go ahead and attempt to publish the app, and see what comes out if it.

(Actually, actually, actually. I like that word. :) 

UPDATE: Network support has been enabled on ALL targets. Local network games work flawlessly, and all targets can be servers for all other targets - just imagine, an iPhone acting as a server for a MacBook Pro and a Apple TV :O .

Also, added a Settings bundle for tvOS and iOS VR targets - with this, the usual network settings (server, port, player name, IP address for multiple networks) can be configured through the Settings app in the device, outside of the game, eliminating the need for a on-screen keyboard (for now).

Remember, suggestions and comments are always welcome!