[bug solution] state 8000: wrong frames

[SparK]

[/endofsencelessdiscussionthatwillendinaflamewar]

Also silva has made a CFG for the exe to add a new state: 4000, works like state: 8000 but doesnt have the +140 frames.

by +140 frames you mean +7 rows, right? XD

hmm... where silva publishes his .exes? or he only tells us how to do it instead of publishing results too?
I think I will install my debuggers and decompilers again and give a try at HEXing... usually I use them to make cracks only.

[off]
about flame war, no worries, we won't fight, it was far from becoming a flame war :P we speak like that because we are not good in english

[Silverthorn]

by +140 frames you mean +7 rows, right? XD

Actually, no. LF2 simply adds 140 to the pic-number specified in each frame when "state: 8xxx" has been involved. How you achieve the alternative pics does not really matter. You can, for example take this:

DC-Code: file(0-59): sprite\sys\aeron_0.bmp w: 79 h: 79 row: 10 col: 6 file(60-139): sprite\sys\aeron_0.bmp w: 1 h: 1 row: 80 col: 1 #place-fillers #alternative pics start here

Basically, the numbers in the file()-part just give a little overview for humans. The computer will instead calculate the pic-numbers itself by working with the row/col-values. Now, since we want to optimize loading-speed, I used a width/height of 1px, so that as less RAM as possible is being used.

How exactly you handle the buffers is pretty free, but it's generally good to do something like that. Best would be to add a comment that this is a buffering-part ;)

As for the released executables, please have a look into the HEX-section of LFE. You might stumble over some pretty useful things :)