Swift Sprite System for BlitzMax now available!
BlitzMax Forums/BlitzMax Programming/Swift Sprite System for BlitzMax now available!
| ||
| My sprite system for Blitzmax is now complete! This source file contains most of the documentation, and lists all the functions and methods available and what they do: http://www.seamlesstexturegenerator.com/systems/sprite.system.functions.bmx This system is a much more cleanly implemented and more advanced version of my BOB system for BlitzPlus. Gone is all the software rendering stuff, replaced with the much faster Blitzmax hardware blending. Added is the ability to rotate and scale sprites, and the extreemely useful and robust parent/child system. Hide a parent, and the children are hidden. Make a parent 50% transparent and the children become 50% transparent. Unless they're already 50% transparent in which case they become 25% transparent! Parent and unparent sprites and they can retain their global position, rotation, and apperance. Or they can be moved into parent space using their current offset. Works almost exaclty like the parent child system in Blitz 3D, but more robust. Did I mention that when you hide that parent and the children are hidden the children remember their own hidden state and will stay hidden when the parent is shown again if they were hidden when the parent was hidden? Rotate a parent, and the children not only rotate with it, but their position changes because they are rendered at their location in parent space. This all carries over to the animation system as well. Animate a parent, and the children move with it. Alpha animation is also handled in this way, as is scale. The animation system has been cleaned up quite a bit as well from the BOB system. Instead of specifying modes and velocity types, now you just have a single flags parameter. setting flags to MODE_LOOP|MODE_PINGPONG|MODE_SINE on a position animation for example would make the sprite in question play an infinite loop of it moving back and forth in a sine pattern. Since you can animate the X and Y axis seperately, you can then make the object move across the screen linearly, but up and down in a sine wave, and voila, you have text moving in a sine wave, or some aliens flying across the screen in an attack pattern. This system is very feature rich. It even supports checking collisions between sprites and other sprites as well as between sprites and rects, (useful for checking if the pointer was on a sprite when it clicked) which takes around seven commands to set up iand check in BlitzMax normally. Considering that the original BOB and AniBOB systems were used to create that game for Lego I wrote, and that thos systems were adequate for that, and this system expands greatly upon those, I'm confident this system will meet most of your 2D animation needs. See this page for order info: http://www.blitzbasic.com/logs/userlog.php?user=963&log=267 There's no demo as of yet, except those basic ones which I posted in the general forum week or two ago. Look at my BOB system if you want to find out more about what this system can do. |
| ||
| Yet another module for sale. |
| ||
| what's the difference between a shareware and commercial license? I.e If I make an Indie game that has demos out there that people buy, that's shareware, but it's also commercial... |
| ||
| I would suggest renaming Animate to AnimatedSprite. Reason: Animate referes to autonom AI driven beeings in virtual environment. |
| ||
| Nice! You got a small demo that uses it (small source code example)? :) |
| ||
| /me readies his paypal account for transaction... AAAANNND... payment sent. |
| ||
| He wants $80 for a sprite system? What is so good about this system that warrants an $80 price tag? Think about what you can buy with $80 (ie. BlitzMax - Torque2d) and then tell me why I should pay $80 for a sprite system. :/ |
| ||
| 25 dollars you fewl. |
| ||
| 25 dollars you fewl. Not for the commercial license? |
| ||
| if you are planning a commercial venture with the costs associated then you can afford the 80 dollars or the time to reinvent the wheel. AND STOP CHANGING YOUR NAME AMON!!!! :) |
| ||
| Well, I'm happy that you paid for it. I am on commercial ventures which is why I bought BlitzMax. Now, take BlitzMax commercial and look at what you can do with it then take SpriteSystem Commercial and look at what you can do with it, then do the Maths. Do you see? I hope you do. |
| ||
| I just don't feel like reinventing the wheel. Especially not for a hobby type situation. If I finish something with the shareware license and decide that I want to publish it... and I get a publisher... then I'll purchase the commercial license. Simple as that. For the time being, I think it's worth the 25 dollars to save the time doing it myself. |
| ||
| Indeed. It's all planning. Do you have the time/patience to code the subsystem yourself or would you rather buy it and get on with the actual product? |
| ||
| DavidTheDivingDonkey: "then do the Maths" Okay, I'll do the math. According to this months Game Developer Magazine, the average salary for a commercial game programmer with less than three years experience, is $53K. Let's assume said programmer works 9am to 9pm. That's 12 hours a day. Let us also assume they work seven days a week, 365 days a year, because, let's face it, you're a slave driver. At that rate, you would have to pay that programmer $145 a day, which is $12 per hour at his rate of work of 12 hours per day. It took me four weeks to write this. Maybe you could do it in less. But can you do it in less than HALF a day? I doubt it. Maybe you could do it in a week if you borrowed the design of the interface rather than figuring out how to make it work nicely yourself, and already knew how to use Blitzmax. If you were a programming GOD that is. So you say $80 is unfair for a commercial license for a library that would take an experienced programmer at least two weeks to do? HA! Ps: I'm really tired of having this discussion every time I release a new system. It's simply economics. If I don't charge, I can't afford to write them. So either I charge, or the libs don't exist for you to license. And because of economies of scale, I have to charge as much as I do becayse there's not a lot of demand. I sell mostly shareware licensese, and I sell like two a month. So... yeah. I'm not getting rich here. I'm just charging enough that when you email me and demand support I'll have a reason not to tell you to shove off and to actually help you instead. :-) |
| ||
| Grey: The comemrcial license has always been a license to sell the game in stores. Though if you make a lot of money on shareware, like $10K a year or something, it would be appreciated if you bought a commercial license since you're operating on a commercial level. The shareware license is really for the hobbist who doesn't know if they're gonna make much off their game or not. And of course you can always buy one license then upgrade later, though I don't encourage that. Costs you more, and it costs me more. :-) |
| ||
| I can't afford it, but this indeed looks and sounds awesome! A much needed addon to BMax and a must have! |
| ||
| Swift, is this built on top of standard Max2D commands? |
| ||
| Geoff: Yes. It is also designed not to interfere with your own use of said commands as best possible. It uses the same scratch collision layer that the imagescollide functions and the like use so as not to interfere with any collision stuff you do, and it saves the current render state before rendering the sprites, so it won't change the color or rotation on you. Oh btw, the system also is SuperStrict friendly. |
| ||
| so what are the MAJOR advantages of using your system above Max2D ? Is it just animation ? and the parenting ? I am not causing to flame, just seriously interested. Anything that could help my projects out, I am interested in pursuing. |
| ||
| It took me four weeks to write this. Four weeks for that? O_o You gettin' slow, old man. |
| ||
| 2 weeks of it with getting around BM inconsistencies if I count the threads on the boards ;-) |
| ||
| Noel: Well I was learning BlitzMax and Object Oriented programming at the SAME TIME as I was writing it. :-) So that's why the extra couple weeks. Figuring out the best way to do all that OOP stuff, and how collisions and linked lists work in Max, and the like. Deux: so what are the MAJOR advantages of using your system above Max2D ? Is it just animation ? and the parenting ? The major advantages are: 1. You create a sprite, and all of the properites of it are stored by the sprite, and they will all be sorted and rendered in the proper order with a single function call. This saves you from having to put all these fields and handle all this data yourself in your monster type for example. You just store a pointer to a sprite instead. 2. The parenting system allows you to do all sorts of neat stuff. You could, if you wanted to for example, use it like the TFormPoint, TFormVector, and TFormNormal commands in Blitz3D. It will happily let you create a sprite with no image and use it to transform the position of another. In fact I'll probably be creating some helper functions that do just this that will be part of a future update. And of course, it's really convenient to be able to create a menu and have all the buttons and sliders and things be children of that menu and then be able to make the whole thing fly off the screen simply by animating the menu background with a single command, while simultaneously rotating it with another command. So that simplifies things a lot and allows some neat stuff to be done easily. How often have you wanted to do some neat animation and then decided it was too much work to bother implementing, or you just didn't have the luxury of time to do so? Now you can do more of that stuff because it only takes a couple commands to make it all work. 3. The sprite system provides a consistent interface for all your in game objects. That makes it easy to implement an animation system or a physics system on top of it. If you wanted to make your own stuff have this consistency you'd have to have all your graphical objects extend a class which would basically be the same thing as my sprite class. And you'd have to write all the code yourself to keep them in lists, and sort them each frame, and draw them, and free them... And you would still not have all the functionality of my animation system on top, or all the parent child stuff which is really useful. So basically, even if you don't use this sprite system, if you're going to make your game consistent you're still going to want to implement a system like it in your game.* * (Unless you're Michael Reitzenstein and still code things completely procedurally like you did in the days of the 386. :-) ) |
| ||
| Seem a good lib swift ! have a nice day :) |
| ||
| Welcome to Max Sswifty. Reasons #1 and #3 there I have already implemented in my own works, but reason #2 is the kicker for me... Can I rotate things on the Z axis as well? |
| ||
| Can I rotate things on the Z axis as well? Can't be done without writing your own 2D system and not just a sprite class (forget about the animation for a second). |
| ||
| "Can I rotate things on the Z axis as well?" If you mean rotate around the Z axis, which is the center of the image, then yes. You can also scale the image on either axis. And that is all handled as far as positioning and moving the children correctly relative to the parent. If you mean rotating around the X or Y axis, no. There is only one axis of rotation available for images in BlitzMax. Oh, and that Zlad thing... AntiPope... I've seen that. Electronik Supersonik is better though. :-) |
| ||
| * (Unless you're Michael Reitzenstein and still code things completely procedurally like you did in the days of the 386. :-) ) Just coz you don't understand that all of this is possible defining the relationships at render time, array boy! |
| ||
| Well what do you know, I managed to spell your name right. :-) |
| ||
| Hunter's (I got tired of spelling Reitzkrieg) name is an abomination against the fingers of typists everywhere. |
| ||
| Yeah, I'll respond to Michael, Hunter or any ridiculously long made up word starting with R... |
| ||
| sswift: thanks fot the info, good luck with it. It is good value if a) you are busy b) you don't know how to make your own. However, I'll probably write my own cos it'll help me learn Max a bit more and I can tailor it for optimium speed for my game, like I did for the bonus games and my pentuple buffer dirty rects system. |
| ||
| Does it cross 3 platforms? I want to purchase to use it on my Mac at my office... |
| ||
| yox: Well, assuming general Max code works across all platforms, it should. I didn't do anything funny or PC specific that I know of. And if there is any problem it should be trivial to correct. |
| ||
| good work swift :] - keep em coming...but next time, i want the sprites to convert into 3D normal mapped skeleton animated meshes.. +also, can you please rewrite the collision system to use shaders so that perpixel testing is all done by the card.. ..oh..oh..one more thing - would it be possible to have all this for $5 commercial license?! :] :p ;) - cheers! |
| ||
| Placed the order, coz I found that I have no time to write games, this can be considered as a small support to you... But It should be useful, if I finished current things I'll start using it. |
| ||
| does it have the ability to show a sprite brighter than normal or tinted a different colour? |
| ||
| Tinted a different color? Yes. Brighter than normal? Not yet, but if you buy it I'll try to add that. :-) |
| ||
| I'll tell you why it would be useful ... the classic shoot 'em up, you hit something and it flashes to show you've hit it. |
| ||
| Oh I know why it would be useful. My BOB system had that capability, and I used it extensively in Lego Builder Bots. :-) |
| ||
Here is a simple example of the system in action, with a basic two frame one second looping animation:
Include "Swift Sprite System-035.bmx"
Graphics 800, 600, 32
SetBlend(ALPHABLEND)
AutoMidHandle True
Alien:TImage = LoadAnimImage("bug-008.png", 48, 48, 0, 2)
S1:Sprite = Sprite.Create(Alien)
S1.SetPosition(400, 300)
Animate.Frame(S1, 0, 1, 1000, MODE_LOOP)
Current_Time = MilliSecs()
Game_Start_Time = Current_Time
Repeat
SetClsColor 0, 0, 0
Cls
Repeat
Time_Old = Current_Time ' Store start time of last frame.
Current_Time = MilliSecs() ' Get the current time. Use this instead of Millisecs() from here on if you need the time.
Time_Delta = Current_Time - Time_Old ' Calculate how long last frame took to render, in milliseconds.
Time_Delta_Sec# = Float(Time_Delta)/1000.0 ' Convert frame time to seconds.
Until (Time_Delta > 0) And (Time_Delta < 250) ' Handle unnaturally long pauses between frames gracefully.
FPS = 1000.0 / Float(Time_Delta)
' Sprites are animated seperately from drawing them, so you can move them, then check for collisions, then change their properties/positions,
' then draw them.
Animate.UpdateAll(Time_Delta)
Sprite.DrawAll()
DrawText FPS, 16, 16
Flip
Until KeyHit(KEY_ESCAPE)
|
| ||
| I've added some new features to the sprite system: - You may now animate scale and rotation. - A child's order is now relative to any parents it has. A negative order for a child will cause it to render behind the parent. And as requested by a couple folks: - You may now set flags for children to allow them to retain their position, scale, rotation, alpha, order, and visibility state, instead of said settings being affected by those of the parent. |
| ||
| I just wanted to comment on this system. I purchased the commercial version and it is worth every penny. Sswift's system has elegant and efficient features that would be a nice addition to anyones sprite/animation library. |
| ||
| Can we see some demos ? I am all for paying for something if I can test it out first, and can see it is worth it :) |
| ||
| Well it's a sprite system. It moves sprites around. My BOB system demo shows that sort of thing off. It's not particularly exciting. But here for yuor enjoyment are the five simple demos that the system currently ships with: http://www.seamlesstexturegenerator.com/systems/Swift.Sprite.System.Demos.zip They demonstrate: Demo 1: How sprite properties, position, rotation, and alpha, are all relative to the sprite's parents. Demo 2: Animating sprites manually, having lots of sprites on the screen. (Interactive! Keys: INS, DEL, SPACE, T) Demo 3: Animating a sprite property, in this case, the frame. Demo 4: Sprite property inheritance again, but this time with a flag that makes the smallest child ignore the rotation of the parent sprites. Demo 5: Demos 3 and 4 combined. Demonstrates when a line is commented out in the code how freeing a sprite frees the children of a sprite as well, and halts animation of both self and children automatically. I think there's also a demo in the general discussion forum somewhere which shows off like 2500 sprites animating at once at 60fps. (On a mid range card.) |
| ||
| ok awesome, I am gonna check these out :) |
| ||
| I told you the demos weren't very exciting. :-) |
| ||
| Another update for the sprite system! This update adds: PATHS! The way paths work is this: Create a path, and then add points to it. Then, apply this path to a sprite with the sprite's SetPath() method. The sprite is now in path space. If you move the sprite on the X axis, it will move along the path. If you move it along the Y axis, it will move in a direction which is perpendicular to the particular path segment is it on. If the sprite has a parent, the path will scale and rotate with that parent. Using the flags to disable the inheritance of certain properties of the parent like position and rotation will disable those for the path as well as the child. Paths use linear segments, and the sprite's speed along it will be constant even if the lengths of the segments don't match. This allows you to make paths using curves which may have more points where the path curves sharply than where it is more linear. |
| ||
| woot |
| ||
| Damn you keep going like a madman! Thanks for the updates!!! |
| ||
| Hi, I'm currently working on my own sprite/animation/image system and i figured since i dont have much time that it could be better to use yours. But there is a feature i need that i dont think you have. I need to be able to know when a particular animation ends. here's some of your example code modified to explain what i mean: MyAnimation = Animate.Frame(S1, 0, 1, 1000, MODE_LOOP) then after the Animate.Update(Delta) call i could do something like Status = Animate.Status(MyAnimation) Is there something i missed that lets me do that? The big idea is to be able to start other animations when a particular animation ends. |
| ||
| Absolutely it can do that. Function Animating%(ThisSprite:Sprite, Transform%=ANIM_ALL) There's a bunch of different animation types: Const ANIM_ALL% = 0 Const ANIM_POSITION% = 1 Const ANIM_POSITIONX% = 2 Const ANIM_POSITIONY% = 3 Const ANIM_ROTATION% = 4 Const ANIM_SCALE% = 5 Const ANIM_SCALEX% = 6 Const ANIM_SCALEY% = 7 Const ANIM_COLOR% = 8 Const ANIM_COLORR% = 9 Const ANIM_COLORG% = 10 Const ANIM_COLORB% = 11 Const ANIM_ALPHA% = 12 Const ANIM_FRAME% = 13 And you can check if any animations of a particular type are playing and/or in queue for a particular sprite. Let's say you wanted a sprite to repeat a one second animation of frames 0 thru 9 three times. Here is the animation function you would use: Function Frame(ThisSprite:Sprite, StartFrame#, EndFrame#, Time%, Flags%=0, TriggerDelay%=0, FreeSprite%=False, StartAge%=0, NewImage:TImage=Null) And here is how you would call it: For Loop = 0 to 2 Animate.Frame(SpriteName, 0, 9, 1000, MODE_LOOP, 1000*Loop) Next Or, simply: Animate.Frame(SpriteName, 0, 9, 1000, MODE_LOOP) Animate.Frame(SpriteName, 0, 9, 1000, MODE_LOOP, 1000) Animate.Frame(SpriteName, 0, 9, 1000, MODE_LOOP, 2000) That will make three frame animations play. One starts immediately, the others go in a queue. The second one starts after 1 second regardless of whether the first is finished, and the third one starts at 2 seconds regardless of whether the second is finished. When one triggers, it overrides any older ones basically. But in this case the trigger times are right when the previous ones end, so you don't have to worry about that. Now if you do this: If Animating(SpriteName, ANIM_FRAME) Animating will return true as long as there is a frame animation animating, or sitting in the queue on a delay timer waiting to begin. And if you do this: If Animating(SpriteName, ANIM_ALL) Or this: If Animating(SpriteName) Then animating will return true so long as there is ANY kind of animation playing. So if you know the only kind of animation you're playing for a particular sprite is it's frame animation, then you could just do If Animating(SpriteName). But you have the flexibility for example to make a sprite pulsate in brightness in a loop forever, but still check to see if it's frame or position animation is finished, and if that's done you can then halt the pulsating animation. Or you can simply use the ability to have the sprite automatically delete itself when the frame animation completed, and then your sprite will dissapear when it has done its job. Ie, a score floating up might play a continuous frame animation of sparkling text. It floats up due to a Y axis animation. Meanwhile, an X axis animation with MODE_SINE and MODE_LOOP set makes it move back and forth in a sine wave forever, while an alpha animation is also playing to make it fade out. Then the position animation which is set to delete the sprite when it completes, finishes, and deletes the sprite, stopping the animations for you. And how would you set all that up? Load an anim image, and make four animation function calls, and call the functions to update animation and draw sprites as usual. |
| ||
| Ie, a score floating up might play a continuous frame animation of sparkling text. It floats up due to a Y axis animation. Meanwhile, an X axis animation with MODE_SINE and MODE_LOOP set makes it move back and forth in a sine wave forever, while an alpha animation is also playing to make it fade out. Then the position animation which is set to delete the sprite when it completes, finishes, and deletes the sprite, stopping the animations for you. this is exactly the kind of small demo(s) you should post! |
| ||
| OK, I just bought the shareware license. After having a long think about it it really would save me a hell of a lot of time and the features are just too appealing. :) If I make it to proper commercial success (don't hold your breath) I'll purchase the commercial license. I'm assuming there's an upgrade path? Now, gimme da system. :) P.S Apologies for being a lamer in this thread. :) |
| ||
| If you make it to "commercial success" then the full price wouldn't hurt you! Const EightyDollars = 80 local fourSales = EightyDollars local success = 100 local sales = getNetSales() if sales >= success uProfitTwentyBucksOrMore = soYouShouldntBeSoCheap endif |
| ||
| Dmaz: Isn't it good enough that I just tell you it can do that? All a demo would do is show you what I just described. What would be the point? :-) Gelly: I've given up on explaining basic economics to people. :-) PS: There will be a major new set of features in the sprite system by Monday. I wonder what they might be! |
| ||
| because a picture is worth a thousand words and that was less than 100... blah blah blah. it's true though. The "product" I'm most impressed with right now is dancingplobb.exe from the guy who made plobb and that was only a demo! lucky for you it's not out yet. ;) looking at your feature list, I bet you could do almost everything he did in that demo. probably not the sin deform of sprites or is that a Monday feature? So there are currently 2 and soon to be 3 sprite libs for max, if you want to maximize your sales, a few little demos that do 1 or 2 things and 1 larger demo that shows off most of the power would help you do that. that's just my opinion of course. (I think having a module version with bbdoc in addition to the inlclude would also help) |
| ||
| Sine deform? Like the sprite itself takes on a sinusoidial shape? My system can scale the sprite's width or height using a sine based timing, but alas, it cannot turn the sprite itself into a sine wave. And no, alas, that's not the new feature. But regardless, I think you will somehow manage to find it in your heart to like new feature, perhaps even, (DARE I SAY IT?), find it USEFUL. :-) (Unlike that sine thing which like one person might use once!) Oh, and I'm not debating that a demo and documentation aren't good things that can help sell a product. But if you look at it from a "how much work will I have to do" versus "how much will it increase my sales" point of view, I've gotten SIX sales so far. At most it would get me one more, and that's just not worth it. Besides, someone is paying me to do this for another game I'm making in Max, and they're not paying me to make demos and docs for the sprite system. :-) The demos I've made have been for testing new features. There will be a new demo for this new feature btw. |
| ||
| At most it would get me one more or AT LEAST,it will get you one more. I'm considering buying this but haven't due to clear doc and demo on what it can do. |
| ||
| Did you look at this? www.seamlesstexturegenerator.com/systems/SwiftSpriteSystem-FunctionList.bmx It lists all the functions, with descriptions of what each function does. It effectively is the documentation, in the same sense of the word that zsprite has documentation. It's just not in handy dandy helpfile format. It's a bit out of date though. I've added a bunch of functions, like the path and transform stuff, since then. |
| ||
| Ok my final questions: 1) Is it compatible with indiepath's glowing lines module? 2) Does it address the 'input lag bug' that has been the talk around here 3) How long do you plan on maintaining it? 4) And for the pricing (which admittedly i find a little high, even if i understand the reasoning) are you willing to implement feature requests? (As long as they are reasonable in terms of developpement time and would profit the community of users) i dont necesseraly need a 4/4 to get the sale. Its just that i'm canadian and US $ are so much expensive :) |
| ||
| oh yah, forgot to also ask, is it platform independent? |
| ||
| 1. I don't know, because I have not looked at it, but I don't see why it would not be, since my system uses standard Max image drawing commands. The only thing to keep in mind would be that you might have difficulty with drawing sprites both on top of and beneath said lines simultaneously. Of course it would be fairly trivial for you to modify the sprite class slightly to handle that I imagine. 2. There's a function in the programming forum to address that now that. It's out of the scope of a sprite system to fix that, and hopefully Mark will just add the fix to Max itself. 3. If by maintain, you mean fix bugs, I still sometimes fix bugs in even my oldeest systems. But bugs crop up so rarely in my code that it's not a big issue to be concerned with. I fixed the few bugs that were reported early on already. If there are more bugs that are reported to me I'll probably fix those too. I'm using this system in my own game, and the functions it has are ones I need, so of course I want them to work right. If you're aksing how many new features I will add, I don't know. There's a big update that should be out in 12 hours or so. After that, I don't know what else I will need to add as I progress on the game I'm working on. If I need a feature, I'll add it. If someone requests a feature and I think it is something that is generally useful to people including myself, I will consider adding it. 4. As I said, I'm willing to consider feature requests. Whether I implement them or not depends on how useful I think they are, and whether they can be done in a reasonable period of time, and won't make the system unweildly to use. And if you buy a commercial license I might be more willing to listen to reason. :-) 5. It should be platform independent. I did not to my knowledge use any commands that would make it otherwise. And as I will need to port my own games to multiple platforms, if there is a problem in that area, it'll almost certainly be fixed. But I don't think there should be any problems. The system doesn't muck about with DX or OpenGL directly at all. I'd be more concerned about that glowing lines module. :-) |
| ||
| Short answer to 5) Yes. Reasoning (aka unnecessary reading): I honestly can't see sswift changing the internal modules and as a consequence potentially causing problems for licensees. He isn't stupid enough to do that (unless he says otherwise O_o). |
| ||
| Okay the update isn't quite done yet, but I just released a basic update for people to play with, so I'll tell you what the latest update contains: --- This latest update is a big one! This isn't a full update, it's more of a sneak peek. The update is 90% complete, but there's a bit of functionality which is missing that you'll get in a day or two. So what's in this update? Physics! And not just moving sprites around and inverting their velocities when they collide, but REAL physics! Sprites now have mass, velocity, and elasticity. When you detect a collision between them, you can call a simple function DoCollision() with just the two sprites involved, and it will recalculate their velocities! There's three different functions for applying forces to sprites, and when completed, the system will automatically account for air friction and ground friction, which can also be set per sprite! These forces can be applied as a constant force, or as an instant impulse. Also, mass can be ignored when applying a force, which is useful in many circumstances, such as when applying gravity, which pulls down different masses at equal rates. One of the force functions for example is ApplyField() which can be used to simulate magnetism, gravity, or explosions, depending on whether or not the force is positive or negatvie, you ignore mass or not, and whether you use the impulse flag to apply all the force instantaneously. You just specify the source sprite which the force emenated from, and use ApplyField() on all the sprites you want to be affected with the same parameters and voila, instant explosive force pushing everything nearby away at great velocity. Oh, did I mention this force can falloff with the square of the distance as well? |
| ||
| sswift, sounds very interesting! look forward to a demo of these new features. I've been thinking about buying, might very well now. |
| ||
| ...same here. If you have a plan for that Shadow system in the notes I'd be swayed. |
| ||
| me too |
| ||
| Tonyg: Uh, drop shadows have been in for a week or two now. Didn't you see my update post in this forum? :-) |
| ||
| Here is an up to date list of all the functions available, with all the function descriptions included. These are, essentially, the docs: http://www.seamlesstexturegenerator.com/systems/sprite.system.functions.bmx I suggest you load it into the BlitzMax IDE so you can see the function names in a few easy to read lists. |
| ||
| ok, I am getting more and more interested :) Do you have a physics demo I can see perhaps ? |
| ||
| Uh, drop shadows have been in for a week or two now. I did read that but didn't equate it to what I was after. e.g. shadows as per the Zombieblast demo. Is that possible? |
| ||
| Tonyg: Ah, I see. You want this: http://www.gamedev.net/reference/articles/article2032.asp No, the system cannot do those sorts of shadows, and I don't have plans to implement them at this time. Plans can change, but there's a ton of work involved in doing that sort of shadow system, a lot of special setup required on the user's spart, and it would have to work both in OpenGL and DX. The system does drop shadows, like you would use to make text in photoshop cast a shadow onto a background. A simple effect, but highly useful. Deux: There's no physics demo yet, but there will probably be one by tomorrow. |
| ||
| There was a module released which does those sort of shadows already. What I am after is a bit like a drop-shadow but drawn at an angle. Anyway, should soon know if it's possible :) |
| ||
| TonyG: A drop shadow at an angle? I'm not sure exactly what you mean. There is an angle parameter in my drop shadow stuff. My drop shadow stuff takes an angle and a distance from the sprite at which to draw a black semi-transparent copy of the sprite. If you also want the shadow image itself to be rotated as the angle changes, I'm not sure that would work very well for anything but a cylinder. If I wanted to cast a shadow from an isometric character, I'd probably render an animated shadow map and make a second sprite which is a child of the character, and synch the animation of the two. |
| ||
| The effect I am after is the same as in the Zombieblast sample. If your sprite system can't do it then I'll use that method. If you've seen it then I want to do something similar to the effect Gosse created here |
| ||
| I think what hes looking after is rendering a shadow like the terrain below had an angle. I'v been looking at what i need and i'm definitly going to buy your engin. I have three final questions (really!) tho, that will not change my decision but i'd like to know: 1) Is there somewhere i can read a full description of the liscences. 2) Can you move the sprites on the Z axis using paths? Lets say i want to make an explosion with particles, and i want said particles to move on Z so at one point they are in front of some sprites and over time they go behind the sprites. (as to create an illusion of depth even if the game is 2d) 3) How do the updates work? You send them via email or do we download them ourselves? thanks for the complete answers you've provided to my other inquiries! Smurftra |
| ||
| Ah, I found the zombieBlast demo you were talking about. Why didn't you say it was a BlitzMax sample? I never looked at any of those. :-) Yeah, what that is doing is rotating the shadow sprite before rendering. It would be trivial for you to add that ability to the sprite system. All you should need to do is make one field, and then access it in the Draw() function for the sprite to set the image angle. But I don't think I'll be implementing it, because it looks wrong. When the guy is facing east for example, his profile is very thin. And you see his shadow is very thin too because it's just a copy of him that is rendered. But that's wrong. It'd probably be a lot more noticeable if they weren't moving so much or you did it on some other object with a different shape like a car. It semi works for little guys and trees, but imagine you had a road sign pointing east. The shadow you'd get would point towards the west but it would not display the shape of the sign, it would be made using the profile view. You might be able to get a better effect if you offset the frame used to render the shadow so that when facing north, with a light pointing west, the outline of the guy facing east is used for the shadow. But that is too complicated and specialized to program into the system. What I would do is what I mentioned in my last post. Create animated shadow maps that match your objects and assign those to a child sprite which will follow the parent around. Then all you need to do is each frame set the child's animation frame to be the same as whatever the parent's is, and you can animate the parent however you want and the child will just match it's current state each frame. |
| ||
| Smurftra: 1. This page contains all the info on licenses: http://www.blitzbasic.com/logs/userlog.php?user=963&log=267 2. No, paths are 2D. Could you add a Z parameter to them? I imagine it wouldn't be too difficult. Paths are just points connected by line segments. You'd need to change the code that calculates the length of the segment, and the code that interpolates along a segment so that they take the Z coordinate into account... The only problem is that when I calculate the normals for the segments I store a normal which is perpendicular to the direction of the line segment, and such a direction does not exist in 3D. In short, it might require finessing the code a bit, but all the path stuff is self contained in a small type, so if you know a little math you should be able to figure it out. As for your explosion idea... Explosions are best done using the new physics stuff, not paths. Paths are for rolling marbles along, or enemy attack patterns. They're too much trouble to bother with when making an explosion. For explosions, use the physics system! All you have to do is put your debris around a pivot sprite, and then use ApplyField to push all the debris away with high velocity. Much simpler. You could alternatively animate position with the animation system which is kind of like a one segment path. That said though, 3D is not supported in the physics system either. But there is hope. Sprites do have an order parameter, which is effectivly a Z coordinate, and I might be easily persuaded to add an animation type which supports animating order. Then you would just use the physics system to make the explosion happen, and animate the order with the animation system. I guess I'd have to update order to take floating point values to do that but that's simple enough. Not sure why I didn't do that actually. The reason I didn't really support 3D in the system is it just adds a whole other level of complexity to things and most people would not make use of it. 3. I keep a list of emails of everyone who bought it and send the updates out via email. |
| ||
| This module is looking amazing to be honest. Pending a decent demo of the physics I will probably be buying a copy of this. I asked the same about zsprite, but out of interest are there any plans to add shader support to the system because that would be a very nice feature indeed. :) |
| ||
| There are no plans at this time to add shader support, but I'm not sure exactly what you mean by shader support either. A physics demo is in the works. The physics system is still in the design phase, so differnt ideas are being tested out. It's not going to change greatly, but I might add things like Blitz 3D's collision "types", ie, giving sprites an ID and allowing the user to specify that different ID's be checked against eachother auotmatically. Right now you have to manually call the collision function when you decide sprites have collided using any number of methods you could use. The problem is supporting things like 1D collisions as I am using with objects on a path. I don't want them to collide in 2D cause it could potentially screw things up. So it's a question of flexibility. Also working on additional features like making it easy to move an object back when they are interpenetrating so the physics don't explode. That's tricky though unless I give you specific collision shapes like Blitz 3D does and make you use those with the automatic collision stuff. Anyway, things will solidify as I put them to use in my own game and figure out what works best. |
| ||
| You mentioned animated fonts, has that been implemented ? |
| ||
| I haven't implemented a font system, though it is likely I will have to in the next month. I don't know if it will have any animation stuff built into it though. It might. The way the sprite system is set up though it would not be difficult for one to make their own simple text with sprites and use the animation system to animate it. |
| ||
| ok, I wouldnt mind ordering this, is it still available and supported ? If I click on order, your worklog is missing. |
| ||
| All the worklogs got messedup over the last few days. There have been quite a few threads about it. You will probably have to either email Swift, or simple wait and until the logs are sorted out |
| ||
| ok - thanks :) I emailed him. |
| ||
| what exactly makes this better then Max2D? if the animation commands only because most people can make animation functions and methods easily |
| ||
| there is physics too. That is what I want it for :) |
| ||
| The first link in the first post takes you to the "Remed" empty code. So you can see what it does. Its like all Mods here, they are nearly all easily done (no offence to mod makers). It comes down to wether you want to spend the time doing them youself. For example I bought for B3d, easytok, which was just a wrapper for a wrapper for tokamak, BUT it was worth the money, because although I could have written it myself. But 1) I didnt have too, 2) It worked. |
| ||
| exactly :) |
| ||
| Where's the demo shawn? |
| ||
| worklogs are still down, and I cannot order this system. |
| ||
| what exactly makes this better then Max2D? if the animation commands only because most people can make animation functions and methods easily Haha! This system took a month full time to write, and does way more than simply animate. And while yes, basic animation is simple, this system has an extremely powerful animation system. First off you can animate just about every single property of a sprite you'd want to... alpha, color, scale, rotation, position, etc. Second, you can animate them once, or make the animation loop. Or you can make it ping pong, playing forward then back. And you can do any of the above in reverse. You can also make the animation speed up or slow down as it plays using cosine interpolation or the recently added exponential interpolation. Furthermore, you can check to see when a particular object has finished animating a certain property or all properties, so you can trigger a new action. AND you can string animations together by setting a trigger time for the animation to begin at some point in the future. Then there's the whole parent-child system, where you can attach one sprite to another, and have that sprite affected by the parent. Or not. This is configurable per property. So you could hide the parent, and have the children hide with it automatically. Or you could move the parent and have the children move with it. Or rotate with it. Or change alpha with it. These changes are all realtive to the child's current state too, so if a child is 50% transparent, and you set the parent to be 50% transparent then the child will become 25% transparent. Of course you can disable this per child per property if you wish. So you could make a child that moves with a parent, but doesn't rotate or scale with the parent. There's also a path system, so you can create paths and then move sprites along them simply by animating the sprite's X position. Or move the sprite in the direction of the path's normal at a particular location by moving it in the Y direction, so you can make a sprite move in a sine wave along a path as well. I am using this sprite system to create my own games and I have been adding to it over time and improving upon it and it is quite safe to say that this system will save you months of work. If I want to make a menu fly onto the screen, with buttons on it, I can do this simply by creating the menu background sprite, creating the button sprites, parenting the buttons to the menu, and then positioning them relative to the menu. Then it's just a matter of telling the system to animate the position of the menu, and checking in a loop to see when all position animations for the menu have completed. This is the code the above involves. The code contains some stuff from my text system that uses my sprite system. I'll be giving that away with an update to the sprite system soon. This creates the menu:
' Delete player confirm dialog:
Image = MenuBackdrop.Create(7, 2)
Window_Delete = Sprite.Create(Image, ORDER_MENUITEMS)
Window_Delete.SetPosition(400, 300)
Window_Delete.SetShadow(DROPSHADOW_DISTANCE#, DROPSHADOW_ANGLE#, DROPSHADOW_ALPHA#)
Window_Delete.Hide()
Image = LoadImage("gfx\button-cancel.png")
Button_DeleteCancel = Sprite.Create(Image, ORDER_MENUITEMS, Window_Delete)
Button_DeleteCancel.SetPosition(-102, 136)
Button_DeleteCancel.SetShadow(DROPSHADOW_DISTANCE#, DROPSHADOW_ANGLE#, DROPSHADOW_ALPHA#)
Image = LoadImage("gfx\button-okay.png")
Button_DeleteOkay = Sprite.Create(Image, ORDER_MENUITEMS, Window_Delete)
Button_DeleteOkay.SetPosition(89, 136)
Button_DeleteOkay.SetShadow(DROPSHADOW_DISTANCE#, DROPSHADOW_ANGLE#, DROPSHADOW_ALPHA#)
Font1.Set()
TEXT_Warning = Text.Create("WARNING!", 0, -48, ORDER_MENUITEMS, Window_Delete, 0)
TEXT_ProgressLost = Text.Create("All progress for this player will be lost!", 0, -16, ORDER_MENUITEMS, Window_Delete, 0)
TEXT_AreYouSure = Text.Create("Are you sure?", 0, 32, ORDER_MENUITEMS, Window_Delete, 0)
And this is the loop that makes the menu and the buttons attached to it fly onto the screen, and then waits for that animation to finish: Select _State ' Show window, and trigger animation. Case 0 Window.Show() Window.AnimateX(800+Window.Width(), 400, 500, MODE_SLOWDOWN) _State = 1 ' Window zooming in. Case 1 If Not Window.Animating() _State = 2 EndIf In case you're wondering, MenuBackdrop.Create() in the above code could be replaced by an image being loaded that represents the menu's background. That function is not part of the sprite system and basically returns an image of a menu background which is a certain size by construcitng it from corners and straight peices loaded elsewhere. I have updated the link in my sig below to go to a copy of my worklog on my own server since Mark decided to take the workslogs down completely. Sorry it's not easy to read, the dummies that designed CSS probably didn't consider that people might actually want to SAVE webpages to read them later and that the CSS code wouldn't get saved with them. Oh and: The first link in the first post takes you to the "Remed" empty code. So you can see what it does. That code is way out of date. A ton of stuff was added since I made that. |
| ||
| ok, ordered. :) |
| ||
| Where's the demo shawn? ... |
| ||
| what demo ? |
| ||
| There's a demo here of the physics: http://www.blitzbasic.com/Community/posts.php?topic=59095 I never really made a great demo for it. I made one which showed some aliens rotating to show the parenting stuff in action, but that was it. I don't know where that one went off to. It wouldn't be worth the time and effort to create a demo for the system. I've told you what it can do, a demo would just show that in action. I can virtually promise you you would not be dissapointed with its capabilities. Lots and lots of folks have bought it, do you see any complaints? :-) |
| ||
| Within this very topic, sswift linked to a demo www.seamlesstexturegenerator.com/systems/Swift.Sprite.System.Demos.zip you will also find his physics demo in the physics discussion of the module. |
| ||
| So I did! |
| ||
| @Shawn I have tried to send you an email, but it bounced back. Do you have an alternative email address I could use? Thanks |
| ||
| scswift@...? If you sent to an adelphia address, where did you find that? People keep managing to find my old email address. Otherwise, try scswift@.... |
| ||
| I sent to your scswift@... address. I have just sent it again and I didn't get a bounce back. I don't know why it did the first time I sent it. Thanks |
| ||
| well, I am really glad I got this, it is awesome. Only issue I have right now, is on the physics simulation, it gets progrssively slower and jerkier as the objects begin coming to rest. I havent had time to go through the code just yet though. |
| ||
| Unfortunately, physics simulations like that are difficult to get stable. The physics stuff is still perfectly suitable for stuff like moving spaceships around and making them bounce off one another, but when you have a bouncing object resting on the ground like that the tiny changes from frame to frame can cause a simulation to explode unless everything is coded just right. You could also use the physics to make objects accelerate while they fall but then determine when they have collided with the ground and turn off the physics. That demo there is, by design, a worst case scenario. |
| ||
| Understood. I am happy I bought this, it is really going to come in handy. |
| ||
| Yeah I keep discovering more and more I can do with this sprite system! Its damned keen. I can "grow into" the functionality. It has tons of stuff I didn't use, but as I code more and more the function set is really robust. Of course, Shawn's help via email has been vital and timely! |
| ||
| Oh and: The first link in the first post takes you to the "Remed" empty code. So you can see what it does. That code is way out of date. A ton of stuff was added since I made that. I feel that you are telling me off for trying to be helpful. But anyway, you should really update that "Remed" code to be current, because it was a really good idea. |
| ||
| Why does everyone assume I'm telling them off lately? I was just informing you that it is out of date. That's all! I encourage you to point folks to that, but at the same time I don't want someone to think that comprises the whole current feature set. |
| ||
| Its probably not your fault (This time), Ive been being told off for rightious reasons for the past few days. (Messed up really badly at work). And probably read more into your post than was there. But I still think that the remmed code should be updated, maybe not to be "current", but at most two-three updates behind current. |
| ||
| Is the remmed code in your "online docs" up to date? PS: currently order is broken as worklogs are offline. You should perhaps host it on your page. |
| ||
| Totally off-topic but : "The main problem with Apple isn't their price but the yearly 130$ minor update to their OS" I prefer that to paying for antivirus software ;) |
| ||
| PS: currently order is broken as worklogs are offline. You should perhaps host it on your page. In sswifts sig it says this Important note! Due to an error with the worklogs, until further notice you must go to this page to find out about my systems, and how to order them. Sorry for the inconvenience. So you can order the system just fine. |
| ||
| "Is the remmed code in your "online docs" up to date?" I don't know what online docs you refer to, but likely the answer is no. See bottom of my sig for order page. |
| ||
| I have a question. My project is likely to require "sprites" that are made up of several images, owing to the lack of palette switching these days to do the dirty work for me. So there'd be several greyscale images that I'd apply colour to using SetColor to achieve the result, and each "frame" of the overall finished sprite would contain six or seven such images, carefully placed. From what I can gather, this should be possible using the parent-child system you've got set up, where I create six or seven sprites, designate the main one the "parent" and the rest follow suit. However, I'd like to know if your system has anything extra that would specifically cater to composite sprites such as the ones I've described, streamlining the process somewhat? A sprite type that allows for multiple images of independent colouring, rather than creating seven individuals? |
| ||
| You could create children of a parent and set the color of the children individually, and the children would move, scale, rotate, etc with the parent as one sprite. The parent could even be a sprite with no image... a "pivot" to use the B3D term. But there is no support for "composite images". The sytem won't create a new image for you and paste the other images into it with color shifts. I don't know why you would even want to do that when the parent-child setup would work just fine. I suppose you might be concerned about optimzation but I don't think it would be an issue. And if it was, you could always just build that image yourself and then stick it on a sprite. |
| ||
| Building an image and using that for a sprite wouldn't work so well as it'd need to be on the fly (there's far too many combinations to create them all during an initialisation phase). But having a pivot is something I never considered. Sounds good. |
| ||
| Swift, I noticed the sprite list is global. What if you have space game, where sprites exist in different sector? Wouldn't the sprite to sprite collision be in effect for the entire list? Also, is there a way to only draw a partial list of sprites; it might be more flexible if you could make multiple lists of sprites? Lastly, have you tested for memory leaks and compiled using super strict? Thanks |
| ||
| Sprite collision is something you handle yourself. The system provides functions to determine if two sprites have collided but you have to ask it if that is the case each frame and the test is done at that moment. So no, if you had a universe full of sprites, the system would not be checking collisions for sprites in other sectors, unless you in your own code were causing it to do that. And at this time there are no multiple lists of sprites or ability to draw partial lists of sprites. However, you can hide a parent and have all children hide with it. From an optimization standpoint I understand this isn't really the same thing though. Things internally are more complicated than a lot of people think. For example, to draw all the sprites each frame, they have to be sorted by order. Right now the list is sorted each frame. This (I think) is fast in general because BlitzMax's sorting function works quickly on a list which is already 99% correctly sorted. Now I could insert a sprite in the proper order in the list whenever the order is set. But how might that affect a later addition to the system like these multiple lists you want? I don't know. Also, if I do that, then I have to remember that the order of a sprite changes when you parent it to another sprite. And when a sprite's parent is parented to another sprite. So now I have to muck with the parenting code and do a recursive search for children to update them! Oh dear. And then what happens if I decide to scrap "order" and give sprites a "z" value instead to make things more clear, and then allow you to animate this Z value just as you would the X or the Y? Now I have to consider that with regards to any optimization of the order stuff as well. And what if I decide to change the system from a list of sprites to a tree where children are literally child nodes of the parents in said tree, so that when you hide a parent the system no longer has to consider any of the children? That throws another monkey wrench into the sorting, and now I've lost the ability to let you set a flag to show a child when the parent is hidden. So as you can see there is a TON of stuff that has to be considered and that is why there are no multiple lists yet, and why there may never be multiple lists. I don't want you to think I'm just being lazy. :-) If someone who's using the system has a suggestion for something like this and they want to go into detail about how they'd set it up then I'm more than willing to listen and to consider how it might affect other aspects and if it is something realistic to implement that won't make everything 100x more complex to manage, but nobody's volunteered to do that yet. :-) Anyway... If you wanted to have multiple sectors like that then there's nothing that would prevent you from maintaining your own array of lists of the objects in each sector and then clearing the main sprite list when the player moves from one sector to another and repopulating it with the new sprites. Of course if the player needs to be able to smoothtly transition from one sector to another this makes things more difficult, but really it still comes down to keeping track of where the objects in the universe are, and dynamically creating them around the player as needed. There is after all, anyway, no way for the system to know which sprites it can safely stop animating, so if you have tons of those offscreen sprites animating that is also going to bog the animation system way down cause it has to loop through all those and update them. (I had someone try to do some kind of complex 10000 part animation all at once shoving the whole thing onto the animation stack and he wondered why it was slowing down.) As for memory leaks and superstrict; to my knowledge there are no memory leaks. (So long as you remember to free your sprites when you are done with them!) And yes, it does support superstrict. |
| ||
| Hi Swift. Is this project still running? I don't see it on your order page. |
| ||
| old topic I know, but im interested in the system.. Swwift, the old demo link is broken. Can you supply me with a demo link ? I would like to see it in action if at all possible. |
| ||
| Okay, but I'll start a new thread since this one is full of old information. |
   |