hello all, I was just wondering how to create animations such as the shutdown animation in OneOS and buffers for gui's.
animations and buffers
Started by cdel, Jul 11 2014 07:27 AM
2 replies to this topic
#1
Posted 11 July 2014 - 07:27 AM
#2
Posted 11 July 2014 - 08:16 AM
I use my Drawing API to draw both the animation and buffer everything, so if you want the least work you could use that, it's pretty easy to use.
In terms of the animation it's just a pretty simple loop. It could probably do with a tidy up really, but basically all it does is draw a white rectangle that slowly gets smaller and then 'fades' to black. You basically just chuck a bunch of small sleeps between each different step of the animation.
In terms of buffering, the best way to do it in my opinion is to either make or use a drawing API similar to the one linked. Rather than using term.writes or other hacky things it allows you to minimise the length of your code, make it more obvious what it does and allow for future additions (for example, in OneOS I've just made away, using my Drawing API, that things like buttons or windows can't draw outside of their frame).
In my drawing API you "draw" each aspect (for example, a box or some text) to a table (not to the screen yet) and once everything (buttons, etc) has "drawn" you then write the buffer to the screen. To do this you have another table of what was previously written to the screen and if there are any differences you change that pixel. My method (below) probably isn't the most efficient way of doing it, and sometimes that's quite noticeable when OneOS is lagging. You could also take a look at LyqydOS' way of doing it or GopherAlt's redirect API.
In terms of the animation it's just a pretty simple loop. It could probably do with a tidy up really, but basically all it does is draw a white rectangle that slowly gets smaller and then 'fades' to black. You basically just chuck a bunch of small sleeps between each different step of the animation.
Spoiler
In terms of buffering, the best way to do it in my opinion is to either make or use a drawing API similar to the one linked. Rather than using term.writes or other hacky things it allows you to minimise the length of your code, make it more obvious what it does and allow for future additions (for example, in OneOS I've just made away, using my Drawing API, that things like buttons or windows can't draw outside of their frame).
In my drawing API you "draw" each aspect (for example, a box or some text) to a table (not to the screen yet) and once everything (buttons, etc) has "drawn" you then write the buffer to the screen. To do this you have another table of what was previously written to the screen and if there are any differences you change that pixel. My method (below) probably isn't the most efficient way of doing it, and sometimes that's quite noticeable when OneOS is lagging. You could also take a look at LyqydOS' way of doing it or GopherAlt's redirect API.
Spoiler
Edited by oeed, 11 July 2014 - 08:19 AM.
#3
Posted 11 July 2014 - 09:21 AM
okay, thanks
1 user(s) are reading this topic
0 members, 1 guests, 0 anonymous users











