Sprite system physics demo released!
BlitzMax Forums/BlitzMax Programming/Sprite system physics demo released!
| ||
| http://www.seamlesstexturegenerator.com/systems/Swift.Sprite.System.Physics.Demo.zip Click the left mouse button to reset the objects for another run. There's no collision with the sides or the bottom of the screen yet, I still need to make a function to handle that. Each object in the demo has a realistic mass. I simply looked up how much each object weighs in grams online, and used that weight as the mass value. |
| ||
| thumbs up! |
| ||
| sweet ! checking this out now. |
| ||
| hard to see if its any good, the objects all float away from each other. |
| ||
| Well they do bounce on occasion if you keep resetting it. It'll be better when I make the sides and bottom collidable. :-) |
| ||
| yeah, cant test it properly because there aint much bouncing going on :) |
| ||
| When I add the collision with the floor too I'll be able to set the Elasticity parameters properly, so you'll see that some of the balls will bounce more than others and things like the cinderblock won't. Though I guess I'm going to have to guess because I doubt it will be easy getting coeffiecient of restitution data for most of the stuff, particularly the balloon and cinderblock. :-) |
| ||
| waiting in anticipation :) |
| ||
| Hm... it appears there's more to collisions than just coefficient of restitution. You wouldn't beleive how hard it is to get this info though. Almost all collisions between objects in physics are done between objects with the same elasticity, and finding info on what happens when two objects with different elasticity collide is nigh impossible. But I got lucky and found this: "A perfectly happy ball is one that bounces to its original height when dropped on a massive, rigid surface. A completely unhappy ball does not bounce at all. In the former case, the coefficient of restitution (COR) is unity. In the latter case, the COR is zero. It is shown that when an unhappy ball collides with a happy ball, the COR increases from zero to unity as the stiffness of the happy ball decreases from infinity to zero. The COR is independent of the mass of each ball." Which tells me exactly what I need to know, and it now appears that I need to add a stiffness parameter, and use that to calculate the COR after a collision. The only problem is I have no idea how one determines the "stiffness" of an object so I don't know realistic values for this. Interesting to consider though is a perfectly elastic ball with infinite stiffness. It would be like a pool ball, but bounce like a bounce ball. The only thing is, I couldn't imagine energy not being lost in great amounts with each collision due to the sound produced from the hard object hitting the hard surface. Loss of energy being something I'm also not simulating yet. :-) But anyway, now I have to figure out how to convert that first paragraph into an equation which takes Sprite1 and Sprite2 elasticity and stiffness into account to calculate cor. (Elasticity is what I call cor in my system.) |
| ||
| mac demo plz :) |
| ||
| I don't have a mac to compile on! You know, Mark should really set up a way for people to compile programs in Max through the website, so I can feed it my source and have it produce binaries for linux and mac. |
| ||
| Sswift. I'm sure you've seen these already, but just in case here is some good reading material. http://www.myphysicslab.com/collision.html http://www.d6.com/users/checker/dynamics.htm |
| ||
| You know, Mark should really set up a way for people to compile programs in Max through the website, so I can feed it my source and have it produce binaries for linux and mac. Or he should work on letting you compile for all platforms in one go, so the roll-out process could be fully automated. |
| ||
| How about a realistic use of it where they actually collide? 'Cause at the moment they all just go past each other and never touch. How does this handle ~100 objects? |
| ||
| I tried to use the Chris Hacker pages, but he writes all his equations out Calculus style, and even though they were simple and I thought I had my solution right, another page I found which had much easier to follow equations proved I had gotten them wrong. But anyway, I already implemented the stuff on his page. My problem is something not covered on either of those pages, and that is dtermining what happens when a bouncy ball hits a cinderblock. The cinderblock would have a coefficient of restitution of 0, and the bouncy ball would have a coefficient of restitution of 1. Neither of these values would provide the correct collision result. The way I was doing it was to multiply them togther, but that's not right, because then the cinderblock makes the bouncy ball not bounce off it, and that is clearly wrong. I found this equation in a pdf document about collisions between cars with varying stiffness: Elasticity# = Sqr(((Sprite2._Mass#*Sprite1._Elasticity#)^2 + (Sprite1._Mass#*Sprite2._Elasticity#)^2) / (Sprite1._Mass# + Sprite2._Mass#)) But it doesn't work. The objects bounce off one another with great velocity. And COR is not supposed to be tied to mass according to other pages I've read. I might end up coming up with a different fake. Multiplying the COR for each sprite together doesn't produce good results, but adding them and then dividing by 2 would at least produce better results, if not entirely physically accurate ones. Of course that would still be wrong since you don't want a perfectly elastic ball hitting a perfeclty inelastic floor to only rebound with 50% of it's energy. So maybe a better solution is to use Max(COR1, COR2). Then collisions between elastic objects will be right, and collisions between ineslastic objects will be right, and collisions between elastic and inelastic objects will be trated as elastic. I'm not sure if that last one is the correct physical result , but it might be close enough. [edit] Well I don't know if it is physically accurate or not, but Max seems to work well and the results it produces look realistic enough. So I'll go with that for now. [/edit] |
| ||
| Okay, I've released a much better version of the demo where the objects now have varying elasticity and collide with the walls and floor! Link is same as old demo: www.seamlesstexturegenerator.com/systems/Swift.Sprite.System.Physics.Demo.zip Some things to note: There's no air friction being modeled yet, so you'll see objects with low mass like the balloon occasionally fly about like mad. Air friction would limit the top speed so it would slow down quickly after receiving such an acceleration. There's no sliding friction along the ground. I don't know if I will implement that or not, but I may well implement something similar where energy is lost during each collision. The only problem there is I have to tie that to the physics step time, or else sliding objects would slow down faster when doing more physics steps per frame, or when the framerate is higher. On the flip side, doing that means that the amount of energy lost in a regular collision would then be tied to the time step, and that would mean that that would vary instead. Hm. Perhaps the only way to solve that is to implement both. Anyway "ground friction" at least will be implemented, but that will affect an object whether it is colliding with anything or not because people need that for overhead games. |
| ||
| Something you may want to consider, sswift, is that they're actually slowly sinking into the floor if you let them sit. |
| ||
| Noel: Well I hadn't witnessed that for myself, but I did read on Pono's first link that that might be a problem. I don't plan to solve it the way that link says though. I think the problem there is just the interpenetrating issue. I need to move the objects back after they interpenetrate so they aren't interpentrating any more before continuing with the simulation. That should stop the floor sinking, and it should also stop things like the cinderblock sliding across the bottom and then crushing the tennis ball up against the wall to the point where they're forced to interpenetrate. |
| ||
| I just updated the demo a bit. There's two EXE's now, the old windowed one and a new fullscreen one which also allows random negative velocities for the objects that I mistakenly didn't have, which is why the cinderblock always went to the right. :-) |
| ||
| heh, he's right...they do sink |
| ||
| going to check the new demo out shortly. Seriously considering buying this now. |
| ||
| This didnt compile on my Mac, missing file import. |
| ||
| The circle part it's fair easy. The problems comes when you have to play with polygons. Also for just circles it's to slow. |
| ||
| What do you mean it's too slow? How do you come to that conclusion? It runs at 60fps doesn't it? The framerate is capped at that in that demo. As for polygons, what are you going to use those for? I don't see too many people bothering to create editors to allow them to define polygon shapes. Most people will want to just plug stuff in and have it work. And that means using the masks. Those objects there are colliding with masks, not circles. The collision calculates as if it is dealing with a circle, but that's not really a big issue, as you can see with the collisions with the cinderblock which look realistic enough. The next update will also allow you to specify the collision normal yourself, so you could calculate it precisely from the sprite's alpha map if you wanted. I don't know if I'll be making a helper functon to do that in the immeidate future though. I've got other stuff I need to work on. Angel: Well of course it didn't compile on your mac. You have to have the system! The demo source is only included in that zip so you can see how easy it is to set up. |
| ||
| Pfft. Not fast enough he says. Here's an updated demo, where I've unclamped the framerate. Also demonstrates Sprite.OverlapsRect() used to make the mouse pointer highlight sprites pixel perfect. www.seamlesstexturegenerator.com/systems/Swift.Sprite.System.Physics.Demo.zip 1000fps! Too slow my arse! :-) |
| ||
| Looks good to me. <edit> Except Balloons shouldn't fall as fast as concrete blocks. Is that to do with Air friction as you mentioned earlier? |
| ||
| Well I misunderstanded you. I just seen all those circles and thought you were using circles I have played a little bit with collisions and phisics with BMax and I said to myself : this is to slow for this kind of thing. |
| ||
| Doesn't handle friction, centre of gravity and rotation. |
| ||
| It will handle friction, soon. There's functions in there for setting it. It just hasn't been implemented yet. As for center of gravity, that only matters if you support rotation, and one can EASILY mimick that by just offsetting the sprite in the image. As for rotation, just so nobody is confused, you can rotate the sprites. It just doesn't support torque, ie, rotation caused by collisions pushing on the objects, or rotational inertia, rotation which continues as a result of those forces, or rotational friction, which would slow down said rotation over time. If someone could come up with some good reasons to simulate rotation with physics, then I might be convinced to add it sooner rather than later. Chances are I will add it at some point, but my priority is right now on getting the stuff working that I need to get my own game done, and I don't see many people using that rotation stuff in their own games. You wouldn't want mario to start spinning when a koopa paratrooper hits him in the head. :-) |
| ||
| This is impressive. With air friction implemented, this would be an ideal system for a game I'm about to start... |
| ||
| Ugh, I'm trying to solve this stupid interpenetration issue, and nothing I try works, even moving the objects back to where they were in the frame before they overlapped! They just end up sticking together and it's worse than before! I've tried moving them back, applying a force equal to the force that brought them together in reverse, doing both of those at the same time, and even calculating whether the objects are moving towards or away from eachother so I can do nothing if they are already moving away! Argh! |
| ||
| Ugh, I'm trying to solve this stupid interpenetration issue, and nothing I try works, even moving the objects back to where they were in the frame before they overlapped! They just end up sticking together and it's worse than before! I've tried moving them back, applying a force equal to the force that brought them together in reverse, doing both of those at the same time, and even calculating whether the objects are moving towards or away from eachother so I can do nothing if they are already moving away! Argh! Sounds like a tunneling problem :). That stuff's always a bit tricky to deal with correctly. I haven't had a chance to take a look at the demo yet, but I do know if you are waiting to do collision response AFTER objects overlap you will have issues trying to get rid of tunneling. With the 2-D physics we're implementing we detect collisions before the objects physically touch, therefore you are never in the situation of one object penetrating another. my best advice would be to determine the actual position of both objects when they FIRST hit each other (this is not the first frame you see them overlap either) and do collision response from those two positions. |
| ||
| AlexO: I tried that technique, but I was getting object sticking together. It was driving me nuts. I found a solution though, finally, this morning. There wasn't much of a tunneling issue if the sprites were totally elastic, but there was when they were less than perfectly elastic. I figured out that I could take the difference between what I wanted, and what I'd get with perfect elasticity, and then move the objects one time using the perfect elasticity when the collision occurs. If you imagine a ball sitting on the ground, and imagine that you wait one second between physics calculations, then each second, a 9.8 pixel downward acceleration will pull the sprite against the ground. This will make it penetrate the ground. Now, if I have elastic collisions, it will immediately move back up, to rest upon the ground again because it is in effect, bouncing, even though we can't see it. But if the collisions are somewhat less elastic, then the rebound force will be less than the force needed to get it back to it's original position. The result? Objects sink into the ground. I figured out though that I can have the benefit of both worlds, by taking that moment to move the object back the amount needed to put it back outside the ground again, moving it just enough to compensate for the little bit that the somewhat inelastic collision won't give back. The ball will still only have the inelastic amount of force returned to it, but it will not sink into the ground either. It works great so far. The only problem I'm having now is that when a sprite collides with a square object, because the collision normals I'm using are for a circle, it passes through the corners as if they are not there. There's no restitutuon in the correct direction to push it back outside the object. So now I have to solve the problem of calculating the correct normals for oddly shaped sprites. |
| ||
| Good to hear you got it worked out :). And makes sense: for every action an equal opposite reaction, without anything pushing back on the sprite to put it to rest it would fall through. It works great so far. The only problem I'm having now is that when a sprite collides with a square object, because the collision normals I'm using are for a circle, it passes through the corners as if they are not there. There's no restitutuon in the correct direction to push it back outside the object. So now I have to solve the problem of calculating the correct normals for oddly shaped sprites. I'm assuming you are using some sort of distance of a line to a point in space algorithm? If so then you might be missing a case in the general point to line distance formula? Imagine a horizontal line and a point in space (ignore the words): . EMPTY SPACE _________ the distance between that point and the line is just the distance between the point and the left end point of the line. could this be what you are missing? Because this and normal point to line distance works for any oddly shaped object if you look at the objects in terms of line segments... I might be on the wrong track here, but I'll look at the demo later tonight and maybe post some insight if you're still in need of it. |
| ||
| Alex: I'm afraid you're way off the mark there. On the plus side, I found a solution to my problem which works 95% as well as I possibly hope it could. If I could get the real collision normals it'd probably be 100%. So in celebration of me getting it to a state I'm happy with making available to the general public, here's a new version of the demo! :-) www.seamlesstexturegenerator.com/systems/Swift.Sprite.System.Physics.Demo.zip New features: Move the mouse over one of the objects to see the sprite system's ability to brighten a sprite in action. Also, it will display the name of the sprite, which is a new capability. As for the physics, 99% of interpenetration issues are now history, and the system handles difficult situtations likea small ball getting wedged against the wall by the cinderblock which has huge mass and doesn't want to slow down. Also when wedged between the volleyball and basketball, the balloon will slide upwards and sit nicely on top of them because it has little mass and the right shape to do that. The physics system interface has had an overhaul too. Remember how you would set up collisions in Blitz3D? By specifying two ID's that should collide, and setting the ID for each entity, so it is part of a certain group of objects that behave a certain way? Well you can do the exact same thing with the physics system now. You still have to manually update certain things like collisions with walls, but most of your sprite to sprite collision stuff can now be handled with collision sets! See the demo source to see how both methods work. So anyway, I'm pretty happy with it at this point. It's not perfect yet, but it's pretty darn good, and it's easy to use now. I'll be sending an update out to registered users shortly. |
| ||
| now I am really thinking of purchasing :) |
| ||
| If someone could come up with some good reasons to simulate rotation with physics, then I might be convinced to add it sooner rather than later. If you don't know the reasons there's no way on earth you know how to do proper physics.Dude, you haven't got a *clue*. Wheels, barrels, hell, any kind of machinery. |
| ||
| OEJ: I meant a good reason to simulate rotation in a SPRITE system. How many people would use it? And for what? Wheels? Not! There aren't too many side scrolling sprite games which need realistic physics simulation of wheels. :-) One could make an argument for a boulder that rolls downhill after a fleeing indiana jones, but one could also just as easily make an argument that you could just as easily simulate the rolling simply by calculating how far it has moved each frame and turn it acordingly, which is what I did in a 3D game where I simulated ball physics, and it worked just fine. :-) Machinery? Well, I suppose if I was making Castlevania I might want giant gears my protagonist could stand upon to reach higher locations, but again, I don't see many Blitz users making the sorts of games that could use that. My main concern is simulating stuff most people will need right now, not stuff one person might need six months down the road, and most games only use the most basic of physics and collision detection. The only reason I even added physics is because in my own game I need to simulate lots of little objects moving along a track which push one another along. That's a niche in itself. That's why I supported paths too btw. So yes, I have a clue. :-) I just am not convinced people would actually put it to use for those things, and I can't think of stuff that lots of people WOULD put it to great use for. |
| ||
| Another demo update has been released: www.seamlesstexturegenerator.com/systems/Swift.Sprite.System.Physics.Demo.zip This version is mainly code changes that might be of some interest. I changed the name of a function or two, and combined the physics and collision checking function call into a single physics function call. You can of course still do collisions manually, though now you use Physics.Collide instead of Physics.DoCollision to make objects bounce off one another. Anyway, the main loop and the rest of the code is now a bit cleaner as a result. |
| ||
| Neat demo. Did you use Youngs Modulus? Ever tried making it negative? :-) |
| ||
| Have you ever tried revering the polarity of the neutron flow? http://www.efunda.com/formulae/solid_mechanics/mat_mechanics/elastic_constants_E_nu.cfm /head explodes NOOOOOOOOOOOOOO. I used this: http://www.d6.com/users/checker/pdfs/gdmphys3.pdf Well not even that actually, cause I couldn't make heads or tails of the equations in there, but it's the same method, with the same elasticity constant. I had to invent my own method to determine the elasticity in a collision when the elasticity is different for the two bodies. It turns out that using Max(Elasticity1#, Elasticity2#) works great. I could find almost no resources that talk about this issue, and the few I could provided insanely complicated math that I would have no part of, mainly because it was beyond my comprehension. :-) [edit] On second thought, looking at other links on it, it appears I did use Young's modulus, because it is represented by E, which is what I used. [/edit] |
| ||
| Nice work, the demo is amazing. You need a link in your signature to this product |
| ||
| Hello. Very nice, though obviously you have no clue or understanding of what you're trying to do, damned fool!! ;o) I keep getting a corrupted archive message when trying to extract the last demo. The main question, though, is should the sprites when 'at rest' slide gently along the bottom of the screen, moving to the right? Anyway, I suggest you give it up, you're making yourself look silly. Goodbye, |
| ||
| Assari: Thanks. Done. :-) |
| ||
| sswift: lol that article is funny. And I don't evny you having to work out the collision between two objects with different elasticities haha. Do the objects slide to one corner and then the other (very slow) because you are changing gravity, i.e making it non vertical? |
| ||
| O well, no harm in trying to help :). I looked at the demo, very well done. |
| ||
| "Do the objects slide to one corner and then the other (very slow) because you are changing gravity, i.e making it non vertical?" No, they slide because I apply an initial random velocity to them so they don't all just fall straight down and sit there, and because there is no friction, the horizontal component of that velocity is still there after they are on the ground, an there is no ground or air friction to reduce it over time, so they just keep moving back and forth. So there's no problem, and the gravity is not changing. It's just a lack of friction. I'll be implementing friction in the next version probably. |
| ||
| "Very nice, though obviously you have no clue or understanding of what you're trying to do, damned fool!! ;o)" Oh no! I've been found out! "I keep getting a corrupted archive message when trying to extract the last demo." I reuploaded it just now, but I suspect your issue is just that your archive program doesn't like whatever old version of Winzip I have. Maybe you should get a new one. I bet you're using the windows zip thing. :-) "The main question, though, is should the sprites when 'at rest' slide gently along the bottom of the screen, moving to the right?" Yes, because they are not at rest, they are on a frictionless surface, in a vaccuum. :-) When I implement friction, they will come to a rest. If I did not impart intiital velocities to them they would just fall straight down and sit there, and that would be downright boring. :-) |
| ||
| I get it, shoulda realised thanks. I did friction in my Iron Fist game for when you kick each other and crates etc. Actually the formulas can get quite complex depending on how accurate you want to go... "mu" is what you'll be needing, the coefficient of friction. good luck ;-) |
| ||
| I've implemented ground frictioon and air frictoon in the past, I don't know what you mean by complex, as far as physics go, friction is the SIMPLEST thing to implement. :-) |
| ||
| Depends how far you simplify the air friction calculation and if it is a physically correct friction (-> momentums) |
| ||
| It's only the simplest when you don't have rotation physics :) |
| ||
| ok good for you. btw, you've got mail :-) |
| ||
| Dreamora: I use the same physics equations from Nasa's website for calculating air friction. You are correct that there's different levels of simulation you can do, for example, the air friction coefficient that resists a plane's forward motion is different from the air friction coefficient that resists a plane's, pitch, yaw, or roll motion, (especially roll) but I'm not making a flight sim here, and the idea is to make the physics simple enough for anyone to use even if they don't know much about physics, or don't want to have to set 50 variables. Btw, I tried making a flight sim once. I had tons of variables in it calcualting horsepower and torque and all sorts of stuff like that, and the stupid plane still wouldn't fly because I needed to simulate still more things. The more you simulate, the more you have to simulate to get stuff to work the way you want. :-) OEJ: I suppose you're right, because if you take the example of a pool ball, when you hit it initially, it will slide, and that results in X amount of sliding friction, but then it starts rolling, and then you're dealing with X amount of rolling friction instead. And of course you have to determine if the ball is in contact with the ground or not to decide whether to apply either friction, or just a simple "ground friction" as I will be using which is somehwere between the two. |
| ||
| Grey: Hey, I didn't approve that sprite system logo! LAME! I'll come up with a logo for you. :-) |
| ||
| sswift: Even on regular ground friction, momentums exist if you apply it to real objects, not only mass points (which are the formulas that normally are used like ForceFriction = frictionKoeff * ForceNormal). Thats why I meant: friction is only easy as long as you simplify it to the lowest abstraction level. This does not mean that you aren't capable of creating it :D |
| ||
| Deam: I'm not sure what you mean. The physics stuff I've read for the most part says that ground friction slows an object down at a constant rate of speed, regardless of the object's speed. That means that a specific amount of force must be applied to get an object moving if it is experiencing ground friction, but once it is moving you can accelerate it forever. If you stop accelerating it, it will slow down at a constant rate fo speed until it's velocity is 0 once more. Air friction on the other hand increases as the speed of the object increases, which results in a fixed max speed for a specific amount of thrust. |
| ||
| sswift: Ground friction is relative to v, air friction is relative to v^2, which is "the reason" for the maximum speed. Your general understanding is correct as well, but this is a very simplifyed version of what friction really causes and only holds for objects that can be assumed to be mass points. (1 single point that is assumed to hold the whole mass for the object) A box for example with an uneven weight distribution (heavier on the side it is moving to) will start to raise its back and depending on its content and weight even roll over to its "front side". Thats happens due to the behavior of mass: it will move further in the direction it was moving before. You see this behavior every day btw: When you use your bikes front brake on high speed, you will fly like a bird ;-) Reason for this is the equation for ground friction: It depends on the normal force at the spot you apply it, which itself depends on the weight at that spot. With an uneven weight distribution, the friction won't have the same effect everywhere which leads to a momentum. As mass points only are 1 single spot, this does not happen on this simplifyed situation. (they are defined not to have momentums as well) => The equation system describing that can become very complicated. Thats why I meant with "only simple if simplifyed". But I think we went far enough from topic, sorry for hijacking |
| ||
| sswift: don't you read your emails properly ;-) I said "do you have a proper logo that I can show as the first splash screen?" When you get it to me I'll post a demo then, if you're cool with that. Did you read the bit about detecting collisions with ground and objects to play sounds? |
| ||
| woah, just noticed that when compiling with debug on, the demo crawls, what gives sswift? |
| ||
| Grey: What gives is that debug mode is on. Debug mode does stuff to keep track of variables and arrays and stuff. I don't know what it does, but lots of times it will cause things to crawl when you enable it. It did that in Blitz 3D and BlitzPlus as well. Here's that logo you ordered. :-)  If you want to play a sound when an item hits something, there is SpriteName.SetCollisionFunction() which you can set to point to a function you define that will be called each time a collision is detected. Because resting on the ground counts as a collision though, it will end up playing the sound repeatedly when it is doing so. You could solve that by checking SpriteName.Speed#(), and you could scale the volume of the sound by the speed, and not play it at all if the speed is below a certain threshhold. |
| ||
| And yes you can post a demo. |
| ||
| woot! Nice logo lol. I'll plug it in later and release a demo, gotta teach Aikido first for 3 hours! Thanks. Hmm, so I can't treat the ground as different from other objects in your mini-demo to play a different or no sound? I'll expiment a bit. Actually I'd need to check speed to adjust the volume anyway, so maybe that'll be OK. re: debug, yeah I know it used to slow down BPlus a big, esp. with loops etc. It's just my new framework runs almost the same in BMax with debug on, probably due to lack of variables :-) Whereas I guess your collision code must freak the debugger out a bit... |
| ||
| Grey: You know, I might have been mistaken, cause the collisoons with the ground are done differently. There won't be a fucntion call for collisions with the screen because those are handled manually. But since they are handled manually, it's quite easy to play a sound whena collision is detected, just look at the function in the main program below the main loop which does it. Normally though, you could treat collisions differently because the function gets pointers to both sprites involved in the collision, which in turn gives you access to those sprites' collision ID's, which tells you what sort of object they are. |
| ||
| Just to let you know about the speed. the latest demo, on my work computer (p4 2.8ghz, 760 ram, S3 Virge DX/GX (video card) the frame rate is 60 until there is a collision then it drops to 8 (every collision it freezes for almost a second) so given its 60 fps until colision, i dont think its a graphic card issue. if you have more specific questions you can reach by the email i gave you when purchasing (ez to find, it starts with smurftra!) Smurftra P.S., for shareware dev., its important to make the specs as low as possible, so pentium 1s or 2s should be enough to run multiple collisions, imo. |
| ||
| You're running it in debug mode. |
| ||
| Yep, it had to be done! ... Check this out, it's the Swift Sprite System Physics Demo plugged perfectly into my BlitzMax Game Framework: http://www.greyaliengames.com/aotmg/greyaliensss.zip (2.71Mb) It was actually really easy due to my code structure and Sswift's too! The hard part was getting the sounds OK, and they're still not right :-( I could fiddle for longer, but I think you get the idea. It was actually very easy to add sound support to the sprites though. Some keys: Press <Esc> to quit the game. Press <F> to toggle full screen/windowed mode. Press <V> to toggle VSync on/off. Press <D> to bring up the debug display. Whilst in debug mode, press <T> to toggle full speed. Whilst in debug mode, press <L> to toggle slow motion. Whilst in debug mode, press <I> to toggle Flip modes. Whilst in debug mode, press <A> to toggle anti-lag fix. Press <P> to pause the game. Press <S> to toggle sound on/off. Press <M> to toggle music on/off. Press <-> and <=> to adjust sound volume. Press <F12> to take a screenshot. Press <Ctrl+X> to exit the game instantly. You can find out more about my framework here: http://www.blitzbasic.com/Community/posts.php?topic=59329 and here: http://www.greyaliengames.com/framework/faq.html I fully endorse the sprite system. Sswift knows what he's doing and is adding more stuff all the time. It will be cool when friction is implemented. |
| ||
| greyalien: i would be interested in seeing the code to your demo (not your game engin's code) to see how it looks and how both work together. I bought sswift's sprite system and i love it, and im very lazy (and overworked!) so i would also be interested in simplifying my life by buying your engin. I'd like to see how coding it looks tho. thanks, you can reach me at smurftra@... if you dont want to post it. Smurftra |
| ||
| Smurftra: emailed you to keep sswift's thread on topic. |
| ||
| Is this physics + sprite system still valid? I'd love to see a demo. |
| ||
| Yes, but I am currently on vacation, and for some reason the fellow providing me with webspace seems to have chosen a particularly bad time to decide to change hosts. I don't have his name or email on my laptop so I haven't been able to contact him to resolve the issue. Anyway this means sales of my systems and texture generator are at a standstill, and I can't easily send them to people anyway through gmail. I should have the issue resolved by wednesday. Oh, and the physics system is only about 75% complete. I ended up not needing it for the game I was developing so it fell by the wayside. It does everything you see in the demo of course; collisions, acceleration, etc... but it lacks certain features like friction. I could add friction in a day or so if someone requested it however, but I don't think anyone is using that aspect of the system yet. |
| ||
| Hi Sswift. I have been one of your customers of the Terrain System andnow, after years,I was trying again something withBMax and was in need of a 2D physics system. So maybe I'll be again one of your customers :D Is there any demo I can download? Thx :) |
| ||
| Hi, Here are all the sprite system demos: http://raccoonrocket.com/blitz/Swift.Sprite.System.Demos.zip http://raccoonrocket.com/blitz/Swift.Sprite.System.Physics.Demo.zip And the link below to the order info is now working again as well. The order info for all the systems is at the bottom of the worklog, and the worklog contains info on all my systems as well. |
| ||
| Hey Swift, What is the current version of the Sprite System? Thanks. |
| ||
| 114, internally. The current version people recieve when they buy it though is 105. Why are they different? Cause I like to make sure when I add certain features that they won't need to be changed right away. For example, I added the ability to cause sine animations to repeat a specified number of times, and then removed it a few versions later because it was either not working properly, or was of dubious usefulness. If someone who's bought it wants the latest version right away though, they can always email me. |
| ||
| Hi! sswift, just a question... what's the difference beetween the professional version of your Max Sprite System and the shareware version? I guess I'm going to buy it! ;) Regards & all the best! |
| ||
| The professional version allows you to send me as many support questions of feature requests as you like without feeling like a cheapskate. And it encourages me to answer your questions more quickly and in more detail, and consider your feature requests more seriously. You also help to ensure that future development ont he system will continue. I can't keep working on it full time for free! :-) Beyond that, you gain the right to publish your game in stores. And that's about it! There's only one version of the code itself. Btw, the current non-public release version of the sprite system is 117. The latest changes include tying the physics update code to the regular animaton update code to make it easier to just use the physics at any time with no special setup. If you're just getting the system you might want to request this version, but none of the demos have been updated to use it. It does have information on how to convert old code to use the new setup though. Few function calls have changed and the main loop needs a little rearranging on the functions. Shoudn't affect anyone's projects beyond that. |
| ||
| Ok, understood... I like your answers because they're absolutely complete and extensive. Just a question more... There is some problem buying first the shareware version and update after that to the commercial version? Is the same lib? Thanks in advance and best regards! |
| ||
| Sswift, The latest version I have is 103. I haven't received an email or notice or anything since then. Have there been public releases between 103 and 117? SpaceAce |
| ||
| The latest version I'm giving people when they buy it is 105. But the latest internal version is 117. The versions are different because I wait a while before releasing changes to make sure everything is stable and bug free, and the new features are good ones. You can always request the very latest version if you want it though. Just email me. Pinete: No, there's no problem with that. (Other than people never bothering to upgrade! You know who you are!) :-) The lib is exactly the same. There's no difference in the code between the two versions. Only the license is different. And as I don't include the license in the download, the zip you download is identical for either version. I just keep track of what email address is associated with each license. |
   |