garry's mod EGP monitors

okeey, so because high resolution in requested so much and rejected everytime because of latency, i think i foudn a solution.
the new monitors dont have all the pixels stored, they have objects stored wich are renderd client side, squares as a matter affects.
it would be realle efficient becuase if only had to sendobject changes instead of all the pixels.

the down side is that alot of the code would have to rewritten/ completly new code instead if inheriting the old monitors, and to make pixel control people would come with programs that do exactly that and it would essentially be the same. and them you have the argument of course that it does not fit in with the rest of CC.

-wilco

I like this, as I'm not too big of CCLights. I also like your technical thinking instead of "add real monitors and terminals so it is not all text based" - the repeatedly (denied) suggested suggestion.

I don't get it. How would these "square objects" differ from regular "square pixels"?

Bomb Bloke, on 18 January 2014 - 06:38 PM said:

I don't get it. How would these "square objects" differ from regular "square pixels"?

I assume that the OP thinks that this will reduce the amount of packets that are needed to be transmitted, which it will, but no where near as much as OP thinks it will.

I stand by the decision that dan has made with the computers and I do not think that we need higher resolution computers! If you want higher resolution computers, don't play Minecraft.

It really won't. The issue is the sheer amount of data required to be transmitted. People are still going to abuse them and make displays that change too much too quickly. Even the max-size monitors at half text scale can be lag generators if there are enough in one area. Imagine a normal Minecraft server trying to stream twelve 720p videos to twenty people at once. That's the problem CCLights has, from what I understand.

To clarify, the EGP screens available in Garrysmod draw via vectors; last time I looked at them (more than two years ago) they supported boxes, circles, triangles, lines, arbitrary polygons (filled or polyline), text, and rudimentary support for drawing actual game textures. Objects could be parented to eachother and rotated, scaled. You could make all the changes you like, but none of those changes would be applied until you told the screen to redraw, at which point it sends out only the ACTUAL differences from the currently displayed state. It did not send out the rendered image but instead sent out the object data for the client to render on it's end. It also had hardcoded maximum refresh rates that were configurable by the server, for the reasons Lyqyd brought up. There is also a limit to how many objects can be on each screen. In it's early days lag was a major issue and it has undergone massive amounts of refinement to prevent lag.

It has a lot of capability but is NOT intended for raw pixel access:
http://wiki.wiremod.com/wiki/EGP

In short, OP's actual suggestion boils down to "a vector-based monitor that sends objects for the client to render instead of an actual image, with built in limits to prevent laggy exploitiveness".
It would make an interesting addon to computercraft, but certainly does not fit the mod's goals.

I think I see what you're getting at. Using the combination of only sending changes and combining pixels. You couldn't really use this with more than 16 colors though. I'm not really sure whether it'll actually work well though. The low resolution is part of the charm. If you want a hi res screen make real programs.

Hmm, sounds like it would fit as a peripheral better than it would as an actual part of ComputerCraft.

I would make such a peripheral if I had the patience to research the best way to accomplish it. For now, the ability to set lower text scales and scales other then multiples of .5 would be nice (at least that second part, while are on the topic of lag issues).

it seems nobody would repair openGL monitors :(/>

I got the same idea some days ago…

I like the idea and i got some ideas to make it real, but it will be a bit different (Minecraft :o/>)

so, you would have to use parallel to make "egpBox" working

like:

function rendering()
  -- EGP render Function
end
function allOtherThings()
  -- Your Program :D/>, using egpBox, egpText and so on
end

parallel.waitForAny( rendering, allOtherThings )

(PS: i could write an functions like egpRender and you only have to)

parallel.waitForAny( egpRender, myprogram )

:D/>


I'll try this out ^^

Lyqyd, on 18 January 2014 - 11:18 PM said:

It really won't. The issue is the sheer amount of data required to be transmitted. People are still going to abuse them and make displays that change too much too quickly. Even the max-size monitors at half text scale can be lag generators if there are enough in one area. Imagine a normal Minecraft server trying to stream twelve 720p videos to twenty people at once. That's the problem CCLights has, from what I understand.

Well, CCLights2 is not in 720p, but anyways… CCLights2 is optimized for minimum network usage. The only time when I really send a whole image to the server is on texture upload (from importing of images) and on login/chunk load. Other than that CCLights2 uses a networked drawing language to synchronize clients with servers. Yes, the GPU api is really advanced, but it is really powerful! I'd advise that instead of porting/remaking EGP (which sends code to the client to execute), you should try CCLights2.

Sorry for the self advertisement and stuff but… Yeah.

(also, the GPU api closely resembles the Love2D graphics API :)/> It even has canvases!)

Edit: I started writing a paper on how CCLights2 internals work: https://skydrive.live.com/redir?resid=255843FEA16BED6F!979&authkey=!AF9FU9AE3NM7WqY&ithint=file%2c.docx