4 ms·
Out of curiosity, why not the idea of: * pick number of frames (say, 24) * for each pixel, (pseudo)randomly pick which frame it turns red on (0-23), gathering
by arjie 9y ago
Out of curiosity, why not the idea of:
* pick number of frames (say, 24)
* for each pixel, (pseudo)randomly pick which frame it turns red on (0-23), gathering them into a list for that frame (0 -> [1, 1024, 1048576],...)
* paint the list for each frame in order
Still has the property that each pixel is drawn only once. Also has the property that you're guaranteed to terminate in a fixed amount of frames. Also works for any resolution.
Is it because there'll be a short pause as you calculate everything? (probably unnoticeable now, but noticeable then)
Or is it because you essentially need to hold the whole thing in memory until the end?
It's probably the latter, I suppose, that's the problem, since if you have k pixels, you need log k bits to address each pixel so you need k log k memory. That's a whopping 15 million bits (2 megs about) for this op alone on a 1024x768. Okay, then.
- deleted 9y ago[deleted]
- tinus_hn 9y agoNeeds a 'lot' (which is relative, of course) of memory, slow (because you have to precalculate and also read all that memory every frame) and there is a more lightweight solution.
- arjie 9y agoNot all the memory each frame, right? You only read once to calculate and then read the entire memory once again to write.
- tinus_hn 9y agoNo, you have to calculate once and then read and compare the value for each pixel every frame to decide if it's time to turn it on. It can probably be done because the system doesn't really have anything else to do on a game over screen but it's still a waste.
- arjie 9y agoAh no, you don't set pixel to frame number. You set frame number to list of pixels. Same memory, but you only read the pixel corresponding to which frame you're on.