..... what....
Like, seriously.... what?

Uhm... well.... that's a very, very, very very VERY bad idea.

Considering the machines' code is executed on the server, this is quite nontrivial, not even to start talking about sandboxing this. There has been some discussion about adding "shaders" or something similar, for more efficient drawing on screens, but that's kind of on the backburner right now.

Check out OCLights, maybe (no idea if that's still being updated though).

Oh, right, also OpenGlasses.

I don't think the DNS tech pack has all of that

Then consult with the author of the pack about adding it or deal with it.

On Thu, 9 Apr 2015 12:51 am Tcll notifications@github.com wrote:

I don't think the DNS tech pack has all of that

—
Reply to this email directly or view it on GitHub
#1031 (comment)
.

Or simply add the mods yourself. 😲

Then consult with the author of the pack about adding it or deal with it.

ouch

I know this is old and all, but I've just been curious of this and havn't asked... heh

Uhm... well.... that's a very, very, very very VERY bad idea.

I don't see why or how, all you're doing is writing the vertices, normals, etc you'd see displayed on the OC monitor in LUA (OC Lights may already do this)
T1 in B/W
T2 in dithered shading (like my 400MHz Celeron dino compy)
T3 in 24bit
or on the hologram projector, which OpenGlasses seems to more than cover, which the vertices could be drawn there.
T1 in B/W (of course)
T2 obvious

anyways, I'm curious as to why API OpenGL is a bad idea??
(why can't it have a native implementation)

if it's a vertex issue and it's because of the number of vertices and what not that would lag a server, then just limit the amount of data that can be drawn (perhapse as via the GPU RAM like how a real card works)

I'm sure a multiplayer game, something of N64 quality could be drawn on an OC monitor w/o killing a server. :)

also...
may I please ask that some of you guys respond a bit nicer :/
I never barked at anyone, so why bark at me

If this is not enough then I don't know what is:

1. Because someone would have to whole sandbox to make OGL calls safe from Lua.
2. Because OGL works in single threaded environment and OC's Lua is multithreaded.
3. Because OGL is state machine and each change has to be reverted. One non reverted change -> crash of OGL context -> world crashes everyone who gets into your renderer range.
4. Because it is already done in OpenGlasses which soon will allow you to use tesselator like object to draw even custom terrain.

1: you sandbox the environment for the OC monitors and hologram projectors, not GL itself ;)
2: shouldn't matter, just sync with the threads... shouldn't be hard :)
3: (most legit and prbly the most time consuming) just be careful and organize your work when syncing with the engine
4: sounds cool, but I'll leave that to OpenGlasses, I'm not asking for that much ;)

I've made a request to include OpenGlasses on the next update to DNS, so I'm still waiting to see how that goes.

I see no reason it can't be implemented, OCLights does implement it's own monitors right??
(I'm not really sure how this works, I just downloaded it, though I'm playing on a server atm)

I will just leave it w/o comment. Oh, it is a comment.

alright, I'll accept that as pending then