213 posts
Posted 05 September 2015 - 07:08 PM
with the new function term.blit is buffering to avoid screen flickering even much needed anymore? I feel since the function can redraw an entire line at a time unless you are changing a lot of lines really fast (animations maybe?) then a buffer just wouldn't offer any improvements over using term.blit in my programs. Assuming there are still improvements while using a buffer has anyone actually written any programs that make use of the new blit function as opposed to using term.write to draw? I would figure a buffer written with blit would be much faster than one individually writing with term.write.
1140 posts
Location
Kaunas, Lithuania
Posted 05 September 2015 - 08:22 PM
A buffer would still help, since you wouldn't have to draw your GUI elements one by one using term.blit or whatever. With a buffer you'd be able to draw a whole line in one go. So yeah, with term.blit() a buffer still makes difference.
213 posts
Posted 05 September 2015 - 08:32 PM
A buffer would still help, since you wouldn't have to draw your GUI elements one by one using term.blit or whatever. With a buffer you'd be able to draw a whole line in one go. So yeah, with term.blit() a buffer still makes difference.
if blit can run every line within one screen refresh it wouldnt make a different if you instead just term.blit every line every time and throw out all the extra calculations of exactly what lines need to be changed as a buffer does. but i see your point you are talking more in the aspect of using a buffer for windowing i believe. in that case yes a buffer would be preferred in conjunction with blit. the question is still has a buffer already been designed using blit. Best to ask now instead of reinventing the wheel :P/>
1140 posts
Location
Kaunas, Lithuania
Posted 05 September 2015 - 09:19 PM
No, I'm talking about simple GUIs too. To blit a whole line at once, with multiple objects, you'd still have to calculate the line, or in other words, have a buffer for that line.
8543 posts
Posted 05 September 2015 - 09:27 PM
the question is still has a buffer already been designed using blit.
Yes. My
framebuffer API uses term.blit for drawing, if available.
213 posts
Posted 05 September 2015 - 09:32 PM
Yes. My
framebuffer API uses term.blit for drawing, if available.
Awesome thank you Lyqyd! Before I just assume I can is your framebuffer free to use in an OS/shell with modifications to the code? (with credits to you of course)
I will still have to test if I get any graphical improvement out of it but as legoman stated and is probably right on a buffer would be more accurate and faster theoretically than just blitting the whole screen every time i draw a new GUI element
Edited on 05 September 2015 - 07:32 PM
8543 posts
Posted 05 September 2015 - 11:50 PM
Yes, it's released under the MIT license, so you can do anything you like with it, within the terms of the license. So, yes, you could modify it and include it with your code, so long as the license text is left intact.
What modifications did you have in mind for it?
213 posts
Posted 06 September 2015 - 12:36 AM
Yes, it's released under the MIT license, so you can do anything you like with it, within the terms of the license. So, yes, you could modify it and include it with your code, so long as the license text is left intact.
What modifications did you have in mind for it?
I plan to use it an shell I have been working on. I prefer to optimize codes I use as much as possible in favor of speed instead of readability and was planning to make a few adjustments to it to pull whatever little bit of extra speed out of it that I can (although it's already written at pretty much the most I will get from it)