Project NLFFG

[A-Man]

@empirefantasy (Click to View)

no shadow and no gravity

well pretty poor options. first there should be a tag called "shadow", so you can choose which shadow are you going to use or none. coz a big bug of lf2 is that knife have the same shadow with a big attack like fire explosion.

They're enough to cover what wasn't covered. I haven't got simple shadows yet (they're really just circle images which will be spawned on the nearest ground under the character) which WILL be affected by the "width" property of an object and probably other factors like how far the object is from the ground (the circle shadow should get smaller the farther you are). But what's more advanced than that, and what the A-Engine supports are dynamic shape-accurate shadows with shadowmaps. Now I am sure a knife and a big attack will have fairly different shadows .

even thought there are y_acc and y_vel (if its not yet it must be), I think there should be values for gravity. well since there is an y_acc, we know that gravity is an acceleration. So in fact there is no need of such kind of tag. lets say we want to make 3 frames with gravity, so we just use the y_acc value. anyways maybe for higher acuity and easy-using putting making this tag more functional would be good.

while gravity and acceleration are completely indistinguishable, they're different. I'd expect a tag called "gravity=" to overwrite the stage's denoted gravity value, so while what "y_acc=" can do is what "gravity=" can (with the help of variables), I am still keeping "y_acc=" for the sake of consistency (there is y_vel too, of course). I'll get a "gravity=" tag for frames per your request! Though the |IGNOREGRAVITY| switch shall remain because it can be used in the .a file's (== .dat file's) header to have the object ignore gravity in all frames by default which is very useful.

Same applies for friction. As we know every object have it's own friction (lf2 object or bg area).

Yes, sir!

in bmp part (if there will be one ).

lol, yes, there will be one. Though since the engine can load more than the .bmp format (.pngs and various other types I haven't thoroughly investigated), it becomes the "img part"

object .a files general structure (Click to View)

Code:

{pre} #optional stuff
{/pre}

{init} #more optional stuff
{/init}

{main_loop} #even more optionals for doing crazy awesome stuff
{/main_loop}

{info}
#walk speed ..etcetc
[img] # image files
 sheet[dir="filedirectory" rows= columns= width= height= color_key=r,g,b separator=1] #1 px separator (default is 0)
[/img]

[mdl] # 3d models
[/mdl]

[snd] # sound files
[/snd]
{/info}

[f=0]
 img=0 center=x,y delay=1 #..etcetc  
[/f]

[f=1]
 mdl=1 center=x,y,z delay=1 #..etcetc  
[/f]

So for high practically I suggest to put a priority level on tags such as gravity. So if I want to quick modify any object I can just put a gravity=0/no gravity with a high level and so the whole object become without gravity. or let's say in a system with 10 levels of priority 0 lowest, I can have frames with different gravity levels. say some frames with level 1 and some others with 4 and some other with 7. now if I want to quit grav in some frames (which I have consider that don't need that much gravity and have marked them low in priority) I just put gravity=0 with priority 6 on the top of the file and so only those frames with p7 will "survive" the change. Or maybe an advanced concept would be to write in which frames this priority tag will be applied. so lets give an example frames_where_apply= 10-12 14-20 220-500

Hey, that's not bad. It gave me a neat idea of implementing this. I will look into it and let you know of what I've done.
Though, I need to mention that what you said about gravity especially is pretty applicable using existing stuff. You can set a default gravity value for everything in a universal file called "system.a". Then comes the stage files, in which you can specify a new value of gravity that overrides the system.a file's. With the new "gravity=" tag you suggested earlier, one can override the stage's and the system.a's values if he wants to.

There is also the {pre}{/pre} tag which you can use (if you're careful) to set up nice hacks that makes changing overall properties of your character easier. That was actually inspired by the C-family languages' (though it's also available for some other languages too) preprocessor directives. For example, simply put, before the .a file is parsed, it can let you perform find-and-replace text operations in it, even allowing regular expressions for smarter use .

how do u think?

Good ideas!

I was wondering, for spriters willing to contribute, if this style is manageable or not. Faker is sticking to his vow and is not posting here, but I've got his word that this is what's manageable for him.

Edit: Do you mean you condemn the pixel art style altogether, or do you mean to say you just hate working with it?