|
From: | Ivan Vučica |
Subject: | Re: Painter Fuzzy Node in github |
Date: | Thu, 18 Dec 2014 13:00:13 +0000 |
2014-12-18 12:42 GMT+01:00 Ivan Vučica <address@hidden>:I think I get what you want.You want to predict which areas of the screen might require an update in near future, and pre-render the updated graphics. Then, when the time comes, you want to quickly blit the prerendered update on the screen.I do not prerender, I predict :-)
(If I may be blunt on AI techniques) I need to develop the fuzzy math functions for a renderer together with fuzzy rulesets or networks.
The thing is that you indeed render the screen partly i.e. rootwindow from GS with all apps, components, Widowmaker and so on.
The idle time for idling the renderer gets used to reason around your GS system.
That's it apart from GS games such as GMines which can have my system built-in (I told you it was portable objc no deps) so that line, rectangle or pixel drawing gets reasoned around together with e.g. in-game AI.
I doubt GNUstep will have buttons animated with a glow animation before it can render things as layers on GPU, and when it does, advantages you'd get from prerendering this probably be lost.The rule in prolog would be "paint([layer1,layer2,layer3])" with e.g. idle 100 mseconds in between. Note that you can drive the idle and painting mechanism so that you even can render 12 frames (for human eyes) and negate all other dumb rendering, caching compositing cannot better that part of the system.
A cool thing about Cocoa and GNUstep is that, as complex as the rendering process already is, it is still understandable and debuggable. Adding unpredictable update triggers may make debugging harder.It's better interrupt handling yes and it can be done in several ways,
libsigc++ comes to mind but again my thing is portable, no deps. This is why I need good interfaces for the GSFuzzy library.
Either way, I can put it in as a game library developed with and for GS and GS games.
[Prev in Thread] | Current Thread | [Next in Thread] |