xpenguins cont'd - repainting a window after penguins walk on it, and when penguins overlap.
Hi all, After a few days' break I've returned to modifying the xpenguins source to run in a window of my choosing (e.g. terminal). I've finally (partially) resolved the problem of restoring the background behind the penguins (so they don't leave trails where they've walked over icons and such) with as little flickering as possible. I ended up keeping a penguin-bounding-box-sized pixmap of the original background behind the penguin, and selectively sending a clear/expose event to the strip that the penguin-rectangle had just left, while updating the background pixmap with the strip that the penguin-rectangle would move to next. Then this updated background pixmap is painted onto the window where the penguin will go and the penguin is plonked on top. It means that instead of clear/exposing the entire penguin-rectangle for each frame of the animation, only the little strip that is exposed when the penguin-rectangle moves is. Sounds a bit confusing but I don't know how else to explain it. One problem remains and that happens when penguins overlap each other -- suppose penguin A overlaps penguin B and they're heading towards each other (in xpenguins penguins just go through each other). Then when penguin A's background pixmap is updated, it will contain a little slice of penguin B in it (in the wrong position) and vice versa. This little slice of penguin propogates through the background pixmap as the penguin moves, which looks a little odd. Can anyone think of a nice way to handle this? The only thing I can think of is to do some sort of collision/overlapping detection and then be careful about the bits of background that gets copied between the penguins in question. However I'm not a computer scientist and the only way that makes sense for me to implement this is lots of inefficient loops to check every penguin against every other penguin. A related question -- do you think it's viable to make one (transparent) window per penguin? It would be easier than drawing them directly onto an existing window (Famous Last Words), but say I had 25 penguins -- would 25 new windows be a big memory drain or is X good at that sort of thing? (Thanks for that suggestion Xavier. I would rather not assume a compositor though, I have Fedora at work and Ubuntu at home but it's too sucky to have Compiz on it). cheers, Amy - By the way, if anyone can make a Grug theme for xpenguins ... I would be so happy :D ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: xpenguins cont'd - repainting a window after penguins walk on it, and when penguins overlap.
Can anyone think of a nice way to handle this? The only thing I can think of is to do some sort of collision/overlapping detection and then be careful about the bits of background that gets copied between the penguins in question. Or accumulate all your updates then merge them and do them However I'm not a computer scientist and the only way that makes sense for me to implement this is lots of inefficient loops to check every penguin against every other penguin. That's a beginners game writing question not surprisingly. Games often solve this in simple form by keeping all their sprites (penguins in your case) in a sorted list (eg top to bottom, left to right). You still have to do a bit of scanning as obviously the top of one penguin can land on the feet of another, but you can do a lot less scanning that way. A related question -- do you think it's viable to make one (transparent) window per penguin? It would be easier than drawing them directly onto an existing window (Famous Last Words), but say I had 25 penguins -- would 25 new windows be a big memory drain or is X good at that sort of thing X really doesn't care mich about lots of windows. A modern X server should also handle lots of penguins Ok. The old X implementation was very bad at complicated shaped windows but nowdays it seems much better. ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: xpenguins cont'd - repainting a window after penguins walk on it, and when penguins overlap.
Sounds like a very fun X benchmark in the making -- Hey Eric, I get 20K xpenguin per second on this build! ... a Grug theme for xpenguins Can you provide a link to that idea? My Google search had some odd results. On Mon, Jun 6, 2011 at 1:32 AM, Amy C mathematical.cof...@gmail.com wrote: Hi all, After a few days' break I've returned to modifying the xpenguins source to run in a window of my choosing (e.g. terminal). I've finally (partially) resolved the problem of restoring the background behind the penguins (so they don't leave trails where they've walked over icons and such) with as little flickering as possible. I ended up keeping a penguin-bounding-box-sized pixmap of the original background behind the penguin, and selectively sending a clear/expose event to the strip that the penguin-rectangle had just left, while updating the background pixmap with the strip that the penguin-rectangle would move to next. Then this updated background pixmap is painted onto the window where the penguin will go and the penguin is plonked on top. It means that instead of clear/exposing the entire penguin-rectangle for each frame of the animation, only the little strip that is exposed when the penguin-rectangle moves is. Sounds a bit confusing but I don't know how else to explain it. One problem remains and that happens when penguins overlap each other -- suppose penguin A overlaps penguin B and they're heading towards each other (in xpenguins penguins just go through each other). Then when penguin A's background pixmap is updated, it will contain a little slice of penguin B in it (in the wrong position) and vice versa. This little slice of penguin propogates through the background pixmap as the penguin moves, which looks a little odd. Can anyone think of a nice way to handle this? The only thing I can think of is to do some sort of collision/overlapping detection and then be careful about the bits of background that gets copied between the penguins in question. However I'm not a computer scientist and the only way that makes sense for me to implement this is lots of inefficient loops to check every penguin against every other penguin. A related question -- do you think it's viable to make one (transparent) window per penguin? It would be easier than drawing them directly onto an existing window (Famous Last Words), but say I had 25 penguins -- would 25 new windows be a big memory drain or is X good at that sort of thing? (Thanks for that suggestion Xavier. I would rather not assume a compositor though, I have Fedora at work and Ubuntu at home but it's too sucky to have Compiz on it). cheers, Amy - By the way, if anyone can make a Grug theme for xpenguins ... I would be so happy :D ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: pekan...@gmail.com ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: xpenguins cont'd - repainting a window after penguins walk on it, and when penguins overlap.
On 2011-06-06 02:32, Amy C wrote: Can anyone think of a nice way to handle this? Create one window per penguin, using the SHAPE extension. The server will handle this (and most of the rest of the things you mention above) so you don't have to. A related question -- do you think it's viable to make one (transparent) window per penguin? It would be easier than drawing them directly onto an existing window (Famous Last Words), but say I had 25 penguins -- would 25 new windows be a big memory drain or is X good at that sort of thing? 25 windows is not many at all. The real cost is in exposing the underlying windows, but you're already doing that. (Thanks for that suggestion Xavier. I would rather not assume a compositor though, I have Fedora at work and Ubuntu at home but it's too sucky to have Compiz on it). SHAPE has been a standard extension for as long as I can remember. It should be available everywhere, and does not need a compositor. (The down side vs translucency+compiz is you can only have sharp edges with SHAPE; no alpha blending) Peter Harris -- Open Text Connectivity Solutions Group Peter Harrishttp://connectivity.opentext.com/ Research and DevelopmentPhone: +1 905 762 6001 phar...@opentext.comToll Free: 1 877 359 4866 ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: xpenguins cont'd - repainting a window after penguins walk on it, and when penguins overlap.
On Mon, Jun 6, 2011 at 2:10 AM, Alan Cox a...@lxorguk.ukuu.org.uk wrote: However I'm not a computer scientist and the only way that makes sense for me to implement this is lots of inefficient loops to check every penguin against every other penguin. That's a beginners game writing question not surprisingly. Games often solve this in simple form by keeping all their sprites (penguins in your case) in a sorted list (eg top to bottom, left to right). You still have to do a bit of scanning as obviously the top of one penguin can land on the feet of another, but you can do a lot less scanning that way. Indeed, this is a classic question in games: How does one efficiently and quickly search for spatial collisions? Alan's answer is great for your case. If you're feeling adventurous, you could create a spatial dictionary -- an associative array which stores all of the penguins by coordinates, using buckets which correspond to spatial areas. This massively reduces collision checking time for one-against-many, especially when you have lots of sprites to check. It might be overkill here, unless you're planning on making thousands of penguins. :3 ~ C. -- When the facts change, I change my mind. What do you do, sir? ~ Keynes Corbin Simpson mostawesomed...@gmail.com ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: xpenguins cont'd - repainting a window after penguins walk on it, and when penguins overlap.
Thanks all for your suggestions, they're much appreciated! I'm going to try the collision detection as an exercise since it seems like a classic problem and I have an easy case (2D rectangles). I'll also look into the SHAPE extension and have a tinker. Pat - the Grug books by Ted Prior were some of my favourites when I was little (still are!) :) http://www.childrensclassics.com.au/ccp0-catshow/grug_books_ted_prior_series_collecting.html I'll check back with the xorg list once I've made a bit of progress/gotten stuck. cheers! Amy On 07/06/11 00:10, Peter Harris wrote: Create one window per penguin, using the SHAPE extension. The server will handle this (and most of the rest of the things you mention above) so you don't have to. On 07/06/11 03:47, Corbin Simpson wrote: Alan's answer is great for your case. If you're feeling adventurous, you could create a spatial dictionary -- an associative array which stores all of the penguins by coordinates, using buckets which correspond to spatial areas. This massively reduces collision checking time for one-against-many, especially when you have lots of sprites to check. It might be overkill here, unless you're planning on making thousands of penguins. :3 ~ C. ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
