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! 

Nice! I just now gave it a try on El Capitan... I wish I had a bug to report or something, but not yet. :-) 

Minor, yet important update.

Did a few caching optimizations in the rendering code of the iOS VR target, to speed up things in world, entities and text rendering. As a result, playing the game on a iPhone 6 with a VR case is now done at 60fps, guaranteed. (Which means, since the game is rendered twice, one per eye for VR, I essentially have a 120fps engine. Could not feel happier about it :D ).

Can't wait for you guys to try it out. ;) 

Another update for the iOS VR target.

Support has been added for custom command lines, reachable from the Settings app on the iPhone. Up to 16 different command lines can be used, and of course they are all editable. For the time being, I added "-hipnotic" and "-rogue" as the second and third command lines, so now you can play the game Mission Packs with no problem. (Provided you copy the game folders to the device using iTunes File Sharing, of course).

Of course, this also means you can now play custom mods in the game. Just be sure to copy your folders to the device, adjust the command line appropriately, and you're ready to go!

And once again, feel free to let me know your experience with this! 

Just a FYI: DOPA runs just fine with these changes (yay!).

The only odd thing I noticed with DOPA is a bit of a FPS drop on the third demo. That area has quite some detail in it, so I'm not really sure if I can do something about it. But check I still will :) 

Yet another update:

Lots of work have been poured into the iOS VR target. The app will now display some guide screens to let the user configure the device to play the game more easily - unpacking the Shareware episode embedded in the app and the gaming controller, for example.

A few minor rendering issues have been also fixed, related to underwater warping mode and repeating textures.

With this, and one more asset I need to create for the app, I believe I'm ready to attempt publishing this to the App Store. No idea what will happen after that - I'll let you know how that goes. 

Update? 

Update: The app was submitted yesterday (July 11, 2016) to the App Store. Today, I got a "In Review" notification. So far, so good. I'm sweating bullets over this ;D 

BIG FREAKING UPDATE: The iOS VR target of the project has finally made into the Apple App Store! See my newest thread for details. Yay! 

Hmmm. Tons of people have iPhones and iPads.

I personally don't anyone with either of the following devices, let alone both of them ...

*Google Cardboard
*ios Compatible Extended Gaming Controller

I just want to point out that if reception is weak, the requirements each are very uncommon and combined together --- there may be all of 30 people in the whole world that could run your app.

If I were in your shoes, I would invest the time making the requirements optional in a 2.0 version.

Or I could be all wrong about everything above, it's happened before and it'll happen again.