Framebuffer device
fnuecke opened this issue ยท 12 comments
You should add the current state of the mod to the README file. Also, is this the actual screen GUI or the animated panel on the block?
I have always wanted a way to draw reasonable pixels in OC. So I would be very happy about such an implementation.
What exactly would this be? A way to directly draw pixels? If so, allowing the use of a sort of limited opengl/webgl would allow programs to do so much quicker and more efficiently, but could be limited to only running if the user has the device in view/the gui open (idk if this has a gui), and is disabled when the player is afk, to save resources.
I could see that potentially causing a load of issues though, especially with large projects with massive screens someone somewhere is going to do. If you make the screens stop updating, then it could cause problems for people.
Like, for example, a massive screen only parts of it closer to you update but farther away get frozen and it looks bad, or with that "no updates if 'afk'", then people watching a movie or something or waiting for a big task to complete are going to get mad that the screen stops.
Besides, rendering is client side, not server side. Sure, updating the screen data itself is definitely a server job, but it seems like a lot of work for not very much gain to do it right.
Most realistic way IMO is to do it the way most mobile devices do it; just define a region of RAM (maybe add a VRAM module?) which corresponds to each pixel on the screen at some preset colour depth etc. and leave the process of determining what goes on each pixel to the end user. That way you could (theoretically) run anything on it, not just OpenGL stuff. Looking forward to the Doom port
Besides, rendering is client side, not server side. Sure, updating the screen data itself is definitely a server job, but it seems like a lot of work for not very much gain to do it right.
Agreed. Just leave rendering of the screen on at all times so long as the screen is within render distance, seems like the easiest way to do it. It seems that the current implementation is to render a static image if the screen is >5 blocks away but idk if this will scale well if, like in the original OpenComputers, multimonitor support is added
if the screen is >5 blocks away
What if the render distance depended on the size of multiblock screens? that way 20 spaced small screens wouldn't cost exorbitant amounts, but a large screen could be seen from across a large room.
I have an idea: What if you just lower the quality or something the farther away you get? Like the way mip maps work. Then, it's not so much work rendering things farther away that you might not notice as much.
I agree about the screen size affecting things IF that were a must
I still think it would probably be best to try to avoid doing anything at all though, because somewhere it will probably cause issues for someone.