I plan to contribute here, especially as I want to greatly grow Flare's bestiary.
I also intend to step up my game a bit with my next monsters. I want to make sure my models are good enough to drop right into a 3D game.
Anyone work extensively with using 3D creatures in games? It would be nice to have various guidelines and best practices. E.g. avoid feature X because it doesn't export to most formats, or make sure the model is oriented a certain way.
It makes sense. I agree with the reason, but the implementation is a bit sprawling.
Much of the excitement over Flare is with portable linux gaming devices, where performance is a major concern. I'm not sure if changing the game to 60fps adds enough to alienate this group.
I like the idea of making all animations ms-based instead of frame-based. I want to revisit this later. Please hold off on new code on this for now; I'll get in contact with you on a later version when I'm thinking about making this change.
Ok. I'll have to experiment. RPG maker style games use square base tiles (32x32), but in this 3/4ths perspective the base would be rectangular (32x16 for example). I'm not sure the best way to handle this (when rendering side tiles, put two tiles together? stretch the perspective?).
I think the enemy sprites and spell effects should work without change.
If you're talking about the tileset sprites, sure I'll make some time to render those another way. What dimensions should the floor tiles be (e.g. 32x32 square?).
The results of blitting operations vary greatly depending on whether SDL_SRCAPLHA is set or not. See SDL_SetAlpha for an explaination of how this affects your results. Colorkeying and alpha attributes also interact with surface blitting, as the following pseudo-code should hopefully explain.
if (source surface has SDL_SRCALPHA set) {
if (source surface has alpha channel (that is, format->Amask != 0))
blit using per-pixel alpha, ignoring any colour key
else {
if (source surface has SDL_SRCCOLORKEY set)
blit using the colour key AND the per-surface alpha value
else
blit using the per-surface alpha value
}
} else {
if (source surface has SDL_SRCCOLORKEY set)
blit using the colour key
else
ordinary opaque rectangular blit
}
johndh: yes! Can't wait to try these out in-game.
I plan to contribute here, especially as I want to greatly grow Flare's bestiary.
I also intend to step up my game a bit with my next monsters. I want to make sure my models are good enough to drop right into a 3D game.
Anyone work extensively with using 3D creatures in games? It would be nice to have various guidelines and best practices. E.g. avoid feature X because it doesn't export to most formats, or make sure the model is oriented a certain way.
johndh: If you get stuck with the script let me know.
Nice work!
Note that you probably want to keep the angle of the light source the same for the entire sprite sheet, right now it's rotating for each direction.
It makes sense. I agree with the reason, but the implementation is a bit sprawling.
Much of the excitement over Flare is with portable linux gaming devices, where performance is a major concern. I'm not sure if changing the game to 60fps adds enough to alienate this group.
I like the idea of making all animations ms-based instead of frame-based. I want to revisit this later. Please hold off on new code on this for now; I'll get in contact with you on a later version when I'm thinking about making this change.
I'm taking a look at the code now.
Can you explain the need for this trigger and action system? How does it relate to framerate?
Ok. I'll have to experiment. RPG maker style games use square base tiles (32x32), but in this 3/4ths perspective the base would be rectangular (32x16 for example). I'm not sure the best way to handle this (when rendering side tiles, put two tiles together? stretch the perspective?).
I think the enemy sprites and spell effects should work without change.
If you're talking about the tileset sprites, sure I'll make some time to render those another way. What dimensions should the floor tiles be (e.g. 32x32 square?).
Note that what happens with the Alpha depends on both the source and destination surfaces.
From the SDL documentation:
The results of blitting operations vary greatly depending on whether SDL_SRCAPLHA is set or not. See SDL_SetAlpha for an explaination of how this affects your results. Colorkeying and alpha attributes also interact with surface blitting, as the following pseudo-code should hopefully explain.
if (source surface has SDL_SRCALPHA set) {
if (source surface has alpha channel (that is, format->Amask != 0))
blit using per-pixel alpha, ignoring any colour key
else {
if (source surface has SDL_SRCCOLORKEY set)
blit using the colour key AND the per-surface alpha value
else
blit using the per-surface alpha value
}
} else {
if (source surface has SDL_SRCCOLORKEY set)
blit using the colour key
else
ordinary opaque rectangular blit
}
manwesulimo2004, there isn't, but I should probably start keeping such a list.
Pages