Magic spells graphics
you could also say "move a bunch of particles from a to b", maybe even leaving smoke trails etc. to theoretically all that stuff could be done by the particle system (excluding the "concentrating on spell" animation, of course). but since we don't have one now (and certain kinds of effects still look better hand-drawn anyways, imho) that shouldn't keep you from creating anything.
i made a lot of bewutiful particle effects when i were coding quick basic as a child.
the particles for our engine could have the following propertys:
-color
-x, y and z position
-x, y and z vector
-movement_randomnes (posibility of random changes of the x, y and z vector)
-gravity (how much it is affected by gravity. 1 = falling normal, 0.2 would mean slowly floating downwards, -0.5 would mean that it would ascend to the sky)
-half_life_time (chance to disappear during every frame)
every frame the following things happen to each particle:
1. a random number between 0 and the half_life_time is calculated (if !(rand()%half_life_time)). if it is 0 the particle is deleted.
2. the gravity is subtracted from the y vector.
3. an amount of rand()%movement_randomnes - movement_randomnes/2 is added to each of the vectors.
4. each of the vectors is added to the position
5. if the z position is lower than 0 (touched ground) or higher then the max height (touches imaginary sky) the particle is deleted.
6. position of the particle is determined (x = x, y = y - z / 2)
7. particles are rendered during the sprite rendering loop to make sure that they fit together with the sprites
a particle emitter could do nothing but creating a random ammount of particles with random colors and random vectors at one position. everything in between preset limits of course. the attributes could be:
// physical propertys
-min_particles, max_particles
-particle_randomnes
-particle_gravity
// color
-min_red, max_red
-min_green, max_green
-min_blue, max_blue
// start vector
-start_angle_horizontal
-end_angle_horizontal
-start_angle_vertical
-end_angle_vertical
-min_power_x, max_power_x
-min_power_y, max_power_y
-min_power_z, max_power_z
the particles for our engine could have the following propertys:
-color
-x, y and z position
-x, y and z vector
-movement_randomnes (posibility of random changes of the x, y and z vector)
-gravity (how much it is affected by gravity. 1 = falling normal, 0.2 would mean slowly floating downwards, -0.5 would mean that it would ascend to the sky)
-half_life_time (chance to disappear during every frame)
every frame the following things happen to each particle:
1. a random number between 0 and the half_life_time is calculated (if !(rand()%half_life_time)). if it is 0 the particle is deleted.
2. the gravity is subtracted from the y vector.
3. an amount of rand()%movement_randomnes - movement_randomnes/2 is added to each of the vectors.
4. each of the vectors is added to the position
5. if the z position is lower than 0 (touched ground) or higher then the max height (touches imaginary sky) the particle is deleted.
6. position of the particle is determined (x = x, y = y - z / 2)
7. particles are rendered during the sprite rendering loop to make sure that they fit together with the sprites
a particle emitter could do nothing but creating a random ammount of particles with random colors and random vectors at one position. everything in between preset limits of course. the attributes could be:
// physical propertys
-min_particles, max_particles
-particle_randomnes
-particle_gravity
// color
-min_red, max_red
-min_green, max_green
-min_blue, max_blue
// start vector
-start_angle_horizontal
-end_angle_horizontal
-start_angle_vertical
-end_angle_vertical
-min_power_x, max_power_x
-min_power_y, max_power_y
-min_power_z, max_power_z
when you are reading the developer mailing list you should already know that i started developing the particle engine on my own.
a little improvement at the concept: the emitter will be set up with minimum and maximum hue, saturation and intensity of the color of the created particles, not the rgb values. the reason is that the hsi color model allows much more beautiful effects when using random values for one or two of the parameters.
a little improvement at the concept: the emitter will be set up with minimum and maximum hue, saturation and intensity of the color of the created particles, not the rgb values. the reason is that the hsi color model allows much more beautiful effects when using random values for one or two of the parameters.
i believe the particle engine should be used to supplement the spell graphics, not take the place of them. We haven't seen what you are doing yet though so don't take that too seriously yet.
For the fireball c&c... the last frame looks like a bat. And if we don't call it the Fire Bat Spell, it might be bad (not that i'm against a fire bat spell. i think it'd be pretty cool). Try making it circular. Here's how i did it...
PS- When you're making stuff like that, don't do it on white. You'll end up making the image look really good on white, but then the object is used in game where the background is hardly ever white. If you constantly rotate the background color while you're drawing and shading you can make the object look good on any background (which is optimal). If you don't want to go to the work to make it look good on every background, at least make the background green when you're making it. Why? Well, in most games the most occuring floor tile will be grass. Grass is green. So making it look good on green will allow you to modify your object to one color (which is easier in most cases) while you are keeping most players from noticing your object does not look good on other backgrounds. Until they hit the other backgrounds, that is.
For the fireball c&c... the last frame looks like a bat. And if we don't call it the Fire Bat Spell, it might be bad (not that i'm against a fire bat spell. i think it'd be pretty cool). Try making it circular. Here's how i did it...
PS- When you're making stuff like that, don't do it on white. You'll end up making the image look really good on white, but then the object is used in game where the background is hardly ever white. If you constantly rotate the background color while you're drawing and shading you can make the object look good on any background (which is optimal). If you don't want to go to the work to make it look good on every background, at least make the background green when you're making it. Why? Well, in most games the most occuring floor tile will be grass. Grass is green. So making it look good on green will allow you to modify your object to one color (which is easier in most cases) while you are keeping most players from noticing your object does not look good on other backgrounds. Until they hit the other backgrounds, that is.
i think the combination of static sprite animations and dynamic particles will have the best results.
particles can't create a fireball that looks as good as a hand-pixeled one. but a hand-pixeled fireball that flys across the screen and leaves a trail of sparks which float around randomly for a while makes it even cooler.
by the way: the engine already works and produces some quite cool effects. i'll just do a little bit more code improvement and documentation.
a little demo program (for win32, my apologizes to all penguin petters and apple eaters. but don't worry. the particle engine itself is portable. just my personal test program is written in winapi):
http://www.crushnet.org/TempFiles/tmw/Particle.exe
here a screenshot. despite that it looks much cooler when animated:
particles can't create a fireball that looks as good as a hand-pixeled one. but a hand-pixeled fireball that flys across the screen and leaves a trail of sparks which float around randomly for a while makes it even cooler.
by the way: the engine already works and produces some quite cool effects. i'll just do a little bit more code improvement and documentation.
a little demo program (for win32, my apologizes to all penguin petters and apple eaters. but don't worry. the particle engine itself is portable. just my personal test program is written in winapi):
http://www.crushnet.org/TempFiles/tmw/Particle.exe
here a screenshot. despite that it looks much cooler when animated:
Ultim aye your right ^^ but i dont draw with any background
i work in transparency but in Tilestudio (where i did the fireball) saved the image setup (all 6 frames) in a row and added teh white background since its standard.
And yes i will use the desert and grass tiles when working on them in the map editor since its possible to do that and see the object (the fireball in this case) ontop the real tiles we will use.
TileStudio is powerful even tho it doenst look like it.
ooh and Ultim the last frames i say it again were only added to bring an end to the spell (since when making it didnt know of the particle engine thingy).
I have also been working on paper on a ice bolt.
And i have played with ym thought regarding what should happen with your sorroundings when casting a spell and i came ot think of the "target circle" that Elvenprogrammer did (i think it was he) and that maybe something like that could work for casting magic where water swirls around the characters feet while casting a water elemental spell and fire when he casts fire elemental spells. It will look something like he draws out teh water element from his surroundings which imo would be pretty neat. just an idea tho
i work in transparency but in Tilestudio (where i did the fireball) saved the image setup (all 6 frames) in a row and added teh white background since its standard.
And yes i will use the desert and grass tiles when working on them in the map editor since its possible to do that and see the object (the fireball in this case) ontop the real tiles we will use.
TileStudio is powerful even tho it doenst look like it.
ooh and Ultim the last frames i say it again were only added to bring an end to the spell (since when making it didnt know of the particle engine thingy).
I have also been working on paper on a ice bolt.
And i have played with ym thought regarding what should happen with your sorroundings when casting a spell and i came ot think of the "target circle" that Elvenprogrammer did (i think it was he) and that maybe something like that could work for casting magic where water swirls around the characters feet while casting a water elemental spell and fire when he casts fire elemental spells. It will look something like he draws out teh water element from his surroundings which imo would be pretty neat. just an idea tho
Let em tell da' king
Da the east belongs to Morglum
Da east belongs to da orcs
Da east is green
Da the east belongs to Morglum
Da east belongs to da orcs
Da east is green
- Modanung
- Grand Knight
- Posts: 1719
- Joined: 20 May 2005, 15:51
- Location: Groningen, The Netherlands
- Contact:
I think these floor-sprite-effects are best to be used as part of the spell effect, not as the target.Ultim wrote:The different marker for each element of spell seems kinda extravagant. Will the user really key in to it, or mostly ignore it?
Nice work Crush, when will it support (alpha-layered) bitmap-particles?
If you're looking for 3D FOSS games be sure to check out LucKey Productions on itch.io
you mean transparent particles? it already does. WinAPI just can't display it. as i said the engine just delivers the x, y and z position and the r, g, b and alpha color value of the particles. it's up to the programmer of the graphic engine to interprete these values. my little winapi test engine just ignores the alpha value because it's not possible to make alpha transparent pixels in winapi without too many cpu intensive calculations. in opengl we can just leave that part to the graphic processor.Modanung wrote:Nice work Crush, when will it support (alpha-layered) bitmap-particles?
when you mean sprite particles: the graphic engine can ignore the color value of the particle and just display a sprite instead. i have a pointer to a sprite as a member of the particle structure. but i'm too lazy atm to dig through the tmw sourcecode to find how you identify sprites. so i just implemented it as a void* (NULL means: there is no sprite, display a pixel with the given rgba color). you can easily change it to an int or OurSpriteClass* or however you identify sprites.
- Modanung
- Grand Knight
- Posts: 1719
- Joined: 20 May 2005, 15:51
- Location: Groningen, The Netherlands
- Contact:
Yes I meant sprite particles. To me (as well as ktm it seems) that's the same.
If you're looking for 3D FOSS games be sure to check out LucKey Productions on itch.io
some (horrible) zelda caps (sorry, but i have no means of "correctly" capturing console output right now ): file (might go down in a few days, inform me if you need the file if you're too late)
notice how the "flame" sprites rotate a little and get scaled up, then rapidly shrink down and fade to black after they pass the biggest part of the flame? also included, some more-or-less subtle usage of transparent dust effects when the player is rolling around, or throwing things, a comparision shot to the standard sprite method (from a part of the game running on the gameboy advance), an impressive "woodfire" and a mediocre fireball effect.
notice how the "flame" sprites rotate a little and get scaled up, then rapidly shrink down and fade to black after they pass the biggest part of the flame? also included, some more-or-less subtle usage of transparent dust effects when the player is rolling around, or throwing things, a comparision shot to the standard sprite method (from a part of the game running on the gameboy advance), an impressive "woodfire" and a mediocre fireball effect.
i think the change of the fire sprites is a premade sprite animation, not a particle effect.
my engine can easily be modified to calculate the position of animated sprites (remember: it does nothing but deliver coordinates. how to interprete these is up to the graphic engine). but before it can do so we need animated sprites at all which (as far as i know) aren't supported yet by the graphic engine.
my engine can easily be modified to calculate the position of animated sprites (remember: it does nothing but deliver coordinates. how to interprete these is up to the graphic engine). but before it can do so we need animated sprites at all which (as far as i know) aren't supported yet by the graphic engine.