Weird and neat!
Community Forums/Showcase/Weird and neat!
| ||
| I decided that just making the little spheres randomly shift about on the screen in my sprite demo was boring, but I didn't want to make them bounce about either, cause that would mean managing all their positions and such, and that was not only boring, but a lot of work too. So then I had the clever idea of making the sprites move about without having to store vectors for each of them. But how to do that? It occured to me, that I could make each sprite calculate a direction vector towards the next sprite in the list, and away from the previous, and then move it in whichever direction I then ended up with. (I normalize these vectors so the sprite wants to move at the same speed in both directions. And instead of adding the vectors, I just translated the sprite twice which has the same effect.) Well the results are really weird and neat, when you've only got a few sprites on the screen. Many sprites will orbit around a center point like electrons around an atom. When you have three, Sometimes two will sit opposite eachother while a third bounces between them, but it turns out they are actually switching places. And sometimes they will fly around a roughly circular track. Sometimes four will sit in a straight line on the screen that just wobbles a bit. Other times they will move in complex patterns. Take a look for yourself: www.seamlesstexturegenerator.com/systems/sprite_system_demo_3.zip To make it easier to see what is going on, one sphere will always be red. Press insert and delete to adjust the number of spheres. Press spacebar to randomize the color and position of the spheres. It might be kind of neat to see how this motion differs in 3D. Btw, note that there are no constraints keeping the spheres on the screen! They just magically stay centered roughly around whatever point was the center of mass when they started moving. I tried this with 2000 of them moving very fast and they still stayed on the screen. So I guess there's something about this equation which keeps the system from collapsing or exploding. |
| ||
| nice little clip :) thanks for sharing nice partical system on the way |
| ||
| Cool... With 4 particles I jsut got a setup where two particles sit opposite eachother and the other two are paired together and fly back and forth between them. This is really addicting to watch. I was playing around with just three hitting the spacebar over and over to see the different configurations for a while and now I'm trying four. :-) |
| ||
| Hello. Spooky, very natural movement. Goodbye. |
| ||
| Mmmm... emergent behaviour. Very interesting. :o) |
| ||
| What is quite interesting is if you knock the number up quite high and just watch one and see where it moves... Could make for interesting attack waves on your shootem up |
| ||
| Very nice... you reallystart to anthropomorphise the motion on some patterns.... i just had four spheres playing a tag game where 2 just sat at either end of the screen and the other two skipped along an 'S'-shaped path holding hands. ... errr! Maybe I should get out more ! |
| ||
| Black: That sounds like the same pattern I mentioned above. The two at the end sometimes wobble back and worth and the path the other to follow across the middle also wiggles. |
| ||
| If you redownload the sprite system demo in my first post now, then you can toggle trails on by pressing T. Now you can see more clearly the patterns that are being created. It's kind of like a spirograph. |
| ||
| smart sprite bots... cool... hey... it seems as if the target sprite is still moving after the attacker has started his flight towrd him... is the attacker guy constantly updating his vector? --Mike |
| ||
| What in the world are you going on about? :-) |
| ||
| hehehe... sorry... was just wondering... does logic controlling the sprite that is heading toward the other one constantly update the vector while it is moving towards the other one... the orbiting sprites seem to be in motion constantly... that's why i asked... --Mike |
| ||
| Red: The algorithm is very simple: For each sprite: Calculate a normal Nx, Ny pointing away from the previous sprite in the list. TranslateSprite(Nx, Ny) Calculate a normal Nx, Ny pointing towards the nex sprite in the list. TranslateSprite(Nx, Ny) Next If the previous sprite in the list is Null (Indexing past start of list) then it treats the last sprite in the list as the previous sprite. If the next sprite in the list is Null, it treats the first sprite in the list as the next sprite. So the sprites are randomly positioned on the screen, and the list of sprites is treated as a cicular list, and each sprite in the list, each frame, is moved away from the sprite that comes before it in the list, and towards the sprite which comes after it in the list. None of the sprites store any vectors. They only move towards or away from the current location of the other sprites adjacent to it in the list each frame. So yes, they do change direction constantly as they move. And the reason I don't let you reduce the number of sprites to 2 is because the sprites would just sit there and do nothing. Each one would move towards, and then back from, the other within the span of a single frame, so neither would move at all. Btw,. the BMX file there is the source, so you can look at it if you want to see what it does. :-) It just won't compile cause the sprite system itself isn't included. |
| ||
| ahh... i see now... thanks... --Mike |
| ||
| pls dont set the monitor refresh rate.. the demo looks crap on mine cos it cant handle 80hz. |
| ||
| Yavin: But if I DON'T set the refresh rate, it defaults to 60hz... which can be headache inducing. I don't want to set the refresh rate, but on my system 800x600 should default to 85hz, but Max starts it at 60 instead. So what's the right way to deal with this? It's bad for Max to deviate from the default settings, because I might not have that mode properly configured on my monitor. Not a big problem for me, but anyone who uses my program will have the same problem and some of them might not know how to fix the squashed image. Me setting the hz to 80 doesn't solve that, but I just set it to 80 cause I know 60 sucks in 3D apps, and I thought it was supposed to run at the default if it fails to set that mode. Also, you don't have your system configured right if it is running at 80hz but your monitor doesn't support it. If you have installed the right monitor driver, then Windows should know which modes the monitor doesn't support. It's dangerous not to do this because some programs (like this one) try to set the refresh rate, and if it is too high you can burn out your monitor. I didn't expect anyone here to not have their monitor drivers set up right, so I didn't think the 80hz would be a problem. |
| ||
| What is quite interesting is if you knock the number up quite high and just watch one and see where it moves... Could make for interesting attack waves on your shootem up Which is actually what sprang to my mind! Taking the basic principle using types to build and keep track of 'the list'. but Of course, it will be changed quite a bit and of course credit will be given - if you have no objections, Sswift? Anyway, nice stuff... |
| ||
| I don't own the idea of making objects move towards and away from other objects on the screen, so go right ahead. I don't really care if you use that code either. If someone wants to fix it up so it doesn't need the sprite system so you can play around with it, that'd be easy enough, so go ahead. :-) |
| ||
 This was cool to watch, I think there's probably about 15 marbles, but only one red one which just swung pendulously back and forth across the screen despite the frantic action in the 'background heh. Thanks Sswift ;) |
| ||
| Yikes! My monitor can only do 60Hz - it's 'special'. :P It ran the demo OK, though. I'm pretty sure if it was receiving an 80Hz signal, the display would have been messed up. Not sure what's going on... |
| ||
| big10: Max is supposed to drop down to the default Hz if the mode you attempt to set fails. If you have your monitor drivers set up right, which you probably do, then this will succeed. But if you don't, then it will set whatever mode the program wants. |
| ||
| yeah... i'm on a fixed rate Sony here that appears locked on 60hz as well... and the demo ran fine... but yeah, i would like to hear some thoughts on this... like, how are you setting the refresh rate (sorry to appear so dense)... and don't some adapter/monitor combos allow you to set the refresh rate or give the app the option of setting it... also, if 60hz is ditracting (headaches) wouldn't that indicate that teh code might benefit from some timing as the logic and gfx refresh rates aren't synched close enough... ... just asking, as this is always been a gray area with me. --Mike |
| ||
| Oh one other thing I wanted to mention... I did find some configurations of four spheres which seemed to move off the screen as a group. I'm not sure whether or not this was a periodic motion and whether they would have returned eventually or not, but they didn't seem like they were going to. So it seems like while most shapes will remain in one fixed location, it is possible to set up situations where the group as a whole can move. This reminds me of an algorithm called "Life" where different configurations of pixels would do different things. But this is much simpler than that as far as what you can do. You can't make multiple shapes that interact with one another. |
| ||
| Red: BlitzMax lets you specify the HZ when you use the Graphics command. It's not like BlitzPlus or Blitz3D where you just set the graphics mode, and it picks the default hz. It sounds like it's supposed to pick the default hz if you don't specify one, but in my tests it always picks 60 even though my card and monitor are perfectly capable of and default to much higher refresh rates. "also, if 60hz is ditracting (headaches) wouldn't that indicate that teh code might benefit from some timing as the logic and gfx refresh rates aren't synched close enough..." 60hz here has nothing to do with how often the game loop is updated. It has to do with how often the electron gun redraws the screen. Just as people can get headaches from flourescent lights because they flicker 60 times a second, you get the same flickering on your monitor when the refresh rate is set too low. It's usually hard to see this, but sometimes if you look out of the corner of your eye, you can see it in your peripheral vision. And even though you can't percieve it when looking right at it, it still affects you subliminally. This effect will happen even if you're looking at a static unchanging screen. That's why monitors supprot higher refresh rates. It's not so you can run your games faster. It's because it makes the picture more stable and reduces eye strain. |
| ||
| ahhhh, ok... thx for that, i'm not inot B'Max as of yet... 60hz here has nothing to do with how often the game loop is updated. It has to do with how often the electron gun redraws the screen. yeah... that i understand all of that... that's not what i'm trying to point out... the rate at which the game logic loops and the rate at which the screen refreshes do have a definite effect on anything that is in motion and will be displayed on the screen (at least that's the way it seems to work in B3D)... i just discovered this when piling a lot of particles in this lil app i'm working... i had to slow down the main loop so that it wasn't outpacing the refresh rate... --Mike |
| ||
| Btw... sprite system is pretty far along now. I just did a bunch of testing to make sure all the parenting stuff was working right. Like parenting, then unparenting while retaining screen position, then parenting again while retaining screen position, and after a bunch od debugging that all works now. And I decided to get rid of GetX#() and just use X#() and stick those _ things on my private fields after all. GetX#() and all the other get things was just too much typing, and it's much nicer to do A# = ThisSprite.Alpha#(True) or ThisSprite.Alpha#(1) to get the global alpha of a sprite, than sticking Get on every instance where I need to get the values. I still have the "Put" on all the commands to change the values of course. Anyway, so far so good, everything seems to work, even when scaling and rotating. Even the alpha is adjusted by the parent alpha. |
| ||
| Red: Yes, things won't move as smoothly if you don't sync the framerate up exactly with the refresh rate, but that's not the problem I was describing here. |
| ||
| k... --Mike |
   |