game-editor.com

UPDATED TO BETA 5.0

beta 5.0, now has the First f what will be a series of sprite effect's availiable in future versions, this is only a test run
to tryout,

TO USE: Instead of selecting export rotated ( as in previous versions) select EXPORT DISSOLVED
IT creates a spritesheet (spritesheet only, no single files) of your sprite slowly dissolving.. a simple first example, but as I said it is simply a preview/test of upcoming features..
let me know if you like the idea of a sprite FX creator ?


attached is a sample spritesheet created by the program.
if you don't want to download the program.. just download the sheet and try it..




I have deleted previous versions to save space on the server, however if you have problems with beta 5.0 I can repost an older copy.
please see notes at last post for current details.
PS: I really would love to have some guys test this for me




original beta 1 posts>>
This is a beta copy of a spritesheet maker I am working on using rotation code by game-a-gogo and pyrometal.
note: the name is just a working title and will probably change...


I am posting it now, because, I have to do a major rewrite to enlarge the array functions that handle the bitmaps ....which may take some time . but, at the moment it is "usable" for anyone who needs to make a quick and dirty set of rotated sprites for game testing.

I have NOT yet worked out how to export the sprites sheet (I still need to figure out how to write a bitmap header, but the data is already in an array ready to write out).

At the moment, however, you can do a "screen grab" of the results, and crop it to a spritesheet in any graphics application, so it should be useful as is.

current status
- bitmaps must be 24bits uncompressed

- defaults to 32 rotations on a 8*4 grid - this will be easy to change
and it will soon allow options for different rotation numbers/grid sizes etc

- it can load any sized bitmap (but has an error if over 100pixel high or wide...probably something easy to fix.)

- bitmaps should be in the same directory as the exe..
but, paths can be added if you know them - if so.. you need to use a double slash
ie: d:\\flowers\\flower.bmp (I will fix that as well, so it only needs single slashes)

-images that are wider then they are high will be padded out automatically
but images that are taller then they are wide... will not be... this is why I need to rewrite it

- rotation works best on even numbered sprites ie 20*80 not 21*81
Odd numbered widths are padded out to even numbers - but, i also need to do the rewrite to pad out uneven heights

-currently you have to exit and restart to load a new bitmap... this is also part of the rewrite and will be fixed

some upcoming features
-export to spritesheet (grid)
-export to individual files ie: bitmap001.bmp, bitmap002.bmp, bitmap003.bmp etc.
-ability to nudge the sprite left right up down in order to get the center of rotation where you want it - rather then the default center
- and.... some other stuff

and when I get a handle on all that, I will be looking into scaling sprites, and doing a similar applications for that

and anti-aliased rotations ( tho i will probably have to steal that code from somewhere else )

let me know what you think of the idea

feral

ps: the font used is by pyrometal (I hope that is OK pyro? )

PPS: if anyone else is already working on something like this ...sorry... let me know..

now with scaling...

(not using draw_from)

click pic to enlage

the scaled 'cars' are upside down compared to the preview pic... but, i just am too tired now to change the line of code needed ..

just thought you would like to know, I can now export scaled sprites too ..

feral

another update - this time a joyous discovery

I originally wrote my scaling algorithm to scale down sprites

after all thats the best way to get good results - start with a nice big clear picture and scale downwards...

but, i was fiddling with the code, and I just accidentally plugged in the wrong numbers.. and wow, surprised myself, as I thought scaling upwards should have resulted in missing pixels.. after all, the code I wrote wasn't meant to do it.. it wasn't meant to scale up at all...

but



wooo hoo.. I love it when things like this happen...
cheers
feral

dunno if anyone is following this thread.. but i will have a major update in the next day or two..

I have finished the BMP routines and can now load/rotate/scale in any number of steps,

and can save the resulting bitmaps to disk, and import back into GE as sprites

It works with any imported 24bit bitmap, in any size upto approx 300 by 300 pixels

it should work higher, obviously, but, i must have used an int or char when i should have used a double or something...

all previous bugs such as not being able to use odd sized or uneven numbered bitmaps have been fixed..

unfortunately I now have to do another complete rewrite to fix some file handling routines

in the meantime, I really need to know if any one has worked with PNG's or TGAs, as the next step is to include alpha channels and anti-aliasing, (I can do AntiAliasing with Bitmaps, but would be better with alpha....)

sorry for asking , but I wasted almost 2 days trying to find the bitmap info I needed on the stupid "so full of junk" internet,
so any 'real' info would be nice..

update soon..

cheers
feral

BETA 2.0 UPDATE see first post for executable

I need some beta testers please

I am just about to finish off the spritesheet section ( see notes below) but would like to start checking everything else is working ok, and get any feedback if possible, as i may have to do another major rewrite and would like to get everything done at once this time.

I need to find out if
a/ there any bitmaps that do not work well
b/ there is any more error checking I need ( ie: can you click on things you shouldn't etc)

what it should do
1. upload almost any sized bitmap - it will then
a/PAD out the bitmap so it can be rotated well, ( ie: should be even numbered pixels)
b/PAD out the bitmap to maximum required to fit the image in diagaonally when it rotates
( ie: does not trim corners off as image rotates
2. rotate in as many frames as needed ( to fill a 360 degree turn)
3. export a series of numbered bitmaps into the directory it is placed in
4. perform most error checking (except file overwrites - see below)

NOTE: the padding is created using the data from the topmost left pixel, ie: if the image has a transparency color - all the padding is converted to the transparent color - in the future if I do PNG's/TGA's, all the padding will be "real" transparent data (alpha channel).
However, if the image does not have a transparent surrounding - the padding will still be the top left most pixel.. in the next version you will be able to pick a framing/padding color if desired..

To use: Follow the on-screen "steps" - if they don't make sense please let me know....

after creating a series of sprites I would recommend opening up GE and loading them as a animation to see the complete end results

WARNING: currently it overwrites files without checking - so place it in its own directory and COPY test bitmaps to the same directory

NOTE: if you ask for an uneven number of "frames" you will get a warning - this is meant for spritesheets as they work best with even numbers (but sprite- sheets not yet implemented) so you can ignore the warning here..

current issues

1. you cannot "restart" a session by loading in a different file... you need to reboot the application to load a new file (sorry).

solution - I am just not clearing all the flags properly - so should be fixed by next beta version

2. does not AS YET make sprite sheets , so those check boxes can be ignored.

solution - I have an array now holding the spritesheet data, I just have to write it out to a bitmap ( easy now I know how , the spritesheet export should be fixed next beta version

3. problem with dialogue boxes, if you press return in the "export filename box" the "import filename box" thinks you are pressing return in its box... not sure how this works ?

UNKNOWN solution- any ideas on how to have multiple text entry boxes on the same screen all using the return key to change ? ie: on key down event= return key => do script

4. currently overwrites files (should be ok by next revision)

anything else .....please tell me.... or ask.......even simple things ..... I want this to be as friendly as possible.
,
thanks in advance
feral
PS: as soon as i get this one right. I can do the scaling version very quickly, as I built this one to serve both purposes... so if this works the scaling one should be a snap !

Used it to make a ripoff of Asteroids. It actually looks pretty good! And a heckuva lot faster than doing it in photoshop!

Arrow keys to move, Space to fire, Enter to start.
After a score reaches a certain level, the shield and autofire can be use by pressing the alt key.

DST wrote: And a heckuva lot faster than doing it in photoshop!

yeah, a heap faster even if the end result is not as good, it is still a good tool for rapid development and preliminary work... I can't tell you how many hours i spend in photoshop on graphics, only to decide later they are not what I wanted.. at least with something like this i can knock them out , then later simply change my mind and knock out another lot.. this is the main reason i wanted to do this, to save all that time, so i can concentrate on actual coding, until the game is finished--then do the good final set of graphics in photoshop (tho i am hoping to improve this app a lot in the future so that the results should be good enough for most games without photoshoping at all.. )

anyhow.. DST, any suggestions to improve it ?

feral

well the first and most obvious one would be transparency. For most games, alpha works but it requires a lot out of the software and there's always a remaining matte, it seems.

I know traditional games do not use antialiasing, therefore no matte, but I think more and more, with the way modern tools like PS and Gimp handle resizing and filters, antialiasing ends up on just about everything.

The first time i rendered that spaceship, i had a white background and it looked rather crappy. Then i changed it to a black background and it looked good, but only because i was in space. What if i were in the clouds?

I guess I just like transparency. I hate alpha. I always have. I always try to get rid of things i feel are extra steps in any process, so I name him player1 instead of Player_1 and of course, using transparency in multilayer images makes assembling them, reassembling them, trying different things with them...much easier, in my opinion.

Aside from transparency, the sprite sheet, of course, which you already mentioned, but I'd like to point out how handy a feature this really is, because GE is so exacting when it comes to animating a sprite sheet, any alignment issues result in a useless animation. While PS and others have alignment tools, they're really rather stupid in the way the work, and only give you a perfect alignment if you're already really close to start with. And again, cut copy paste in PS and what do you get...no space on the edges, and you gotta realign it and enlarge the canvas. Your auto canvas size feature is pretty nice, i dont' gotta worry about canvas size,,...

Which i was gonna ask, how does it determine how large a canvas needs to be to rotate the image?

DST wrote:Which i was gonna ask, how does it determine how large a canvas needs to be to rotate the image?

sizing

The way I size the "padding" is to take the diagonal of the bitmap from top left to bottom right. ie: the largest longest line through the bitmap then becomes the diamter of the "circle" the bitmap rotates in..

this way IF the image has any data in the corners of the bitmap , then the diagonal is the maximum area it needs to turn in.

try loading in a small photo (ie: completly filled with color) to see this effect

note:
future versions MAY actually take into account blank space, ie: if there is no data in the corners of the picture the diagonal ( or resulting padding) could be smaller...

BUT. At the moment actually allowing the user to have excess blank space helps, as it allows them to center the sprite on the bitmap before importing, ie; they may have the sprite high up on the bitmap and a lot of blanks space below..

why ? well...what this means is when the sprite rotates it rotates around the center of the bitmap.... and not the sprite... so if you want the centre of the rotations changed you need to adjust the sprites position on the bitmap.

for example think of a soldier carrying a big gun in a topdown view..


If you center the soldier on the bitmap so his body is in the centre of the bitmap, he will appear to spin around waving the gun... whereas if you simply dump the sprite in, with no extra padding, he will then rotate around the center of the bitmap, and appear to be running around the gun....

HINT: This is a tip to users, before using make sure the point of your sprite you wish to be the center of the rotation is in the center of the bitmap, even if you need to pad it out..

If that doesn't make sense let me know and i will post an example

feral

GE Spriter Beta 3 now with spritesheets

if you now select the single file option ( spritesheet) the output will be a single bitmap gridded up evenly into frames containing each rotation ready to import into GE as a single framed file.

The application will automatically select the "squarest" filled sheet for you ..... where every frame contains a picture. ie: no blank frames

for example a 7 frame sheet need to be exported as a 7 by 1 sheet, because a 2 by 4 sheet would have to contain a blank frame. note all prime numbers will result in a single row sheet because of this

a 12 frames sheet could be exported as a 2 by 6 or as a 3 by 4 ... the program will automatically select the "squarest" sheet choice... so will give you a 3 by 4 frames sheet

hope that makes sense... later I will allow the choice between different combinations (if available)... AND the choice to have blank frames if a squarer sheet is desired ( particularly when some prime numbers,
for example 79? would result in a file 79 frames wide, and only 1 frame tall..)

nothing else is new in this beta, but as it is working I thought it would be useful now... and also i need feed back on any changes/desired features/bugs etc etc


also please test as many bitmaps/different sizes etc as you can and let me know any bugs, or if certain bitmaps do not work very well...

note: in the next revision, or so, I am planning to implement many of the other changes listed in previous posts, and also the option to start at a certain angle and move only selected frames ( ie: not always start at original spot and move 360 as it is..

have fun
feral

DST wrote:Which i was gonna ask, how does it determine how large a canvas needs to be to rotate the image?

i just reread this question, although i think i have answered it above...

but if you are asking how i get the GE "canvas" actors the right size... well, I don't as I only use the canvas to display the pixel array on screen for the previews.. so the two "canvas's" on screen are simply what ever size i thought looked good..

the pixel array is used to create the bitmaps..

feral

DST wrote:well the first and most obvious one would be transparency. For most games, alpha works but it requires a lot out of the software and there's always a remaining matte, it seems.

sorry DST, not exactly sure what you mean here ?

The program uses the bitmaps first pixel to create the padding so it should be transparent in GE ?

I agree creating antialised sprites with alpha blending can be a nightmare.. as the "edges" with alpha blending "bleed" into your game depending on the original background of the sprite....

antialiasing can be done with-out alpha blending tho as it only "mixes" the colors of neighboring pixels - it is when the application tries to blend to the background that is a problem - there is technique I use in photoshop that allows me to alpha blend/anti-alias without touching the outer edges of the sprite...(no bleeding but leaves the original jaggies around the edges) - let me know if thats what you need.

anyhow... the next step in this program is to do antialiased bitmap rotations (pixel blending as it rotates, to remove some of the "jaggies") but this will not use alpha blending at this stage so they won't "bleed.."

if i get around to using TGA or PNGs then I can use alpha channels for semi transparent sprites ( thinks ghosts etc) note GE can do this, but only as a whole ie: the entire sprite jchanges to the same tranparancy, whereas alpha blending could allow a semitransparent "ghost" to hold a solid weapon in the same sprite

anyhow.. let me know exactly what you want next re: transparencies

feral

Here's a demo character i made for endless cathedral; to make things easy, i designed it in its own file instead of loading a full game every time to test it.

Its a snake where the sections follow each other and rotate properly.

The sprites were rotated using the sprite maker, but i had a lot of problems with the padding color.

Since these images were black and white, it seemed to have a hard time picking the right color. I was using about a 80% grey for the background, since i wanted them to be pretty nice in EC. It kept padding them with about a 60% grey, and i'd have to dump the file and start again.

The ones in this version had a red background, because it kept doing that to me.

I made the background an 80% grey with about 5% red. Still had a problem.

Bumped the red up to 15% and it added the correct color that time.

Probably not many images come thru here that are black and white, so now you know.

Just grab the Head and drag it around.

DST wrote:
The sprites were rotated using the sprite maker, but i had a lot of problems with the padding color.

DST, I just PM'd you re: these issues...

And, cool demo... very nice effect

feral

version beta 3.a notes

I have just uploaded a slightly updated beta to fix a problem DST point out. ( it also includes some new ,but unfinished' work on scaling.

I had forgotten that the bitmaps are read upside down and back-to front when i wrote the routine to select the top LEFTmost pixel as the transparency/fill color... as a result it was picking the bottom left pixel, which in most cases would be the same anyway .. but.. all fixed now..

the scaling part is unfinished and has a minor bug in the number of frames it creates ( sometimes 1 more then requested)
and it also does not yet export files, but rather simple previews them on screen.

if you want to try it out
1. the scale from and scale to numbers are in percentages ie: 10 = 10 % of original size
so smaller then 100 shrinks, larger the 100% enlarges
2. you can only go upwards - in other words the from size must be smaller then the to size ( this will be fixed later)
3. you will have to enter a name in the export file box even tho it does not yet export...

hope to have the scaling finished soon for testing.

feral