Sanctus.Sprite
Community Forums/Showcase/Sanctus.Sprite
| ||
Sanctus.Sprite is a tool for programmers and artists that allows them to have a better art pipeline. You first choose a image with more frames in it (one frame will work as well). Then you press the convert button which will optimize the animation for less memory usage. After that you can safly enter the animations you want and press save. It will generate a file that contains all the needed informations in a secure way, compressed and optimized. After that the code you have to write will look like this Import sanctus.sprite
Graphics 800,600
Global sprite:TSsprite = LoadSprite("test2.spr")
While Not KeyHit(KEY_ESCAPE)
Sprite.Draw(0,0)
Sprite.Update()
Flip
Cls
Wend
There are more functions but are not documented yet. This is not out yet as I'm still hunting bugs (none at the moment) and writing the help and documentation. After it will be released you will be able to buy it for only 10$ with PayPal. This is just the first tool/module from the sanctus framework. |
| ||
| Does it use blitz images to render, or does it use a single surface sytem? |
| ||
| blitz images. Instead of frames it uses more images to be able to use the optimization |
| ||
| You may want to look into that a bit more. I thought that blitz setup individual images already. Just internally. The solution you may want to investigate on these boards, is compacting your frames into larger single textures. You can then load in this one image and not have to switch your resources (your surfaces) in order to draw different frames. Your editor could also have options for: - automatically scaling your sprites down to fit all frames on one image. - generating different quality levels in one file (eg 128x128, 256x256, 512x512) in one file. Your lib could then decide what level of detail it should load from the package. - splitting frames on to multiple images - etc Also if I could offer some constructive criticism on the editor (considering you are looking to sell this for a nominal fee). It is a feature I added to an in-house editor I made a while back. When creating new animations you are able to choose individual frames in any order. Adding each frame one by one, drag-selecting frames to add or even copy and psate. You could then set delay times/alpha/scale/rotation/rgb effects for each frame. The library would then read out the frame information and do all the jiggery pokery behind the scenes. You could even go one step further and offer the ability to do stuff like tweening of filters/alpha. The ability to setup labeld "hot-spots" on the sprite. For each frame of animation you could adjust the position of said hotspot. Then in your lib you could reference the x,y of the labeled hotspot. Esepcialy helpful if you wanted to do stuff like hit-points, gun fire origins or even upgradeable spaceships. What about being able to set the center of the sprite. Not everything roates around the center. Being able to set the centre of each frame manually would give alot of control. hope that helps. |
| ||
| Well thanks for the ideeas. I'll have to finish talking about how I use images and frames as that's a special trick I've tought of and I don't really want to share it :). The center part would be great :) I'll add it. The other things are done partialy or on the todo list. |
| ||
| Cool :) glad to of helped. |
| ||
| I'll have to finish talking about how I use images and frames as that's a special trick I've tought of and I don't really want to share it :) That is what TImage does. And I think single surface is much faster. |
| ||
| "And I think single surface is much faster." It's not...at least not enough to dabble too much. I've done tests on a shite load of machines. On older machines it's faster for sure. On newer machines not that much faster. What really speeds up rendering regardless of method, is limiting your state changes. Alpha, blend mode, rotation, etc. THAT really can speed things up!!! |
| ||
| actually, I've found just the opposite MGE... In my tests single surface is quite a bit faster on newer hardware but not too much of an advantage on older hardware... at least that is what I found with my texpac stuff. since I was looking for improvement on older hardware this didn't help much. With that said though, my single surface image font is loads faster than blitz's realtime renderer on all hardware. (of course, being image based) |
| ||
| ? My newer tests were all based on Vista OS while the older tests were on XP machines. And I only ran tests that rendered 1000's of objects because that's what I was really interested in. My results were always the same. The greatest speed increases were on older machines. On newer machines the rendering was so fast anyway, the fps didn't jump that much if at all. ? ? Granted... all of my object rendering is currently single surface based..but that's because I spent 6 months last year writing it. But I'm using standard blitz image rendering more and more due to the fact that there is newer graphic drivers in development and I don't want to have to go back and redo everything when each new driver is released. :) |
| ||
| I am interested in the tests run and the results but how about starting a new topic in a Bmax section rather than Sanctus's showcase? |
| ||
| For one thing I don't care that much for the speed of the rendering. It's quite good. And anyway this is supossed to be for casual games which don't use all the hardware power. What I care for is to have a easy to use program where you define your sprite, animations, speed and so on with some optimization on the video memory (that's preey good btw). And as always I like my code to be simple to use. I've found and fixed some bugs and It's starting to work quite nice. |
| ||
| Interesting - ive been working on something similar myself.... - dont know if selling this kind of util is worth the bother, i have no plans to make money from mine - but then, i may never release it to the public or even complete it.. dont have a good track record ;) naywaze - goodlucK! :) |
| ||
| To be honest I've done this many times before but failed at some point or didn't include all the features I want. I plan to make a whole framework and this is just the first small tool |
| ||
| Using it at the moment for a little project at the moment for one of my clients. It appears to be very handy-dandy and I think it's 100% bug free. |
| ||
| I found some more bugs (really had to act like a idiot to find them). Added some minor features :) I think I'm going to wait to finish my Sanctus.Interface before releasing it as the interface will use the sprites and thus I might have to add some new things. Btw the interface will be based on skins and you will be able to have more of them in the same time and stuff like this. I will add a visual editor for the skins (currently they are hardcoded). What do you think about this? |
   |