Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Weird Art.ini coding (If I ever meet those coders...)
#1
I was bored and decided to try and add something to the art coding corrections Cannis was doing for the UMP (started here).
I have hardly any art coding experience, so I set up a test:
a SHP file where each frame contains a number in 250px tall font, equal to the frame's index. So frame #0 contains "0", frame #1 contains "1", etc.
Then, added this art code (only relevant bits to save space) :
Code:
[CAD]
Start=1
End=8
LoopStart=3
LoopEnd=5
LoopCount=-1
Rate=50

[CAD_A]
Image=CAD
Start=0
End=10
LoopStart=0
LoopEnd=9
LoopCount=-1
Rate=50

[CAD_B]
Image=CAD
Start=5
End=6
LoopStart=3
LoopEnd=9
LoopCount=-1
Rate=50

Then, assigned these as active anims to GAPILL, NASAM, and GAGAP respectively, so there was no interference between them.

I was rather surprised by the results...
Code:
CAD : "1 2 3 4 3 4 3 4 ..."
CAD_A "0 1 2 3 4 5 6 7 8 0 1 2 3 4 5 6 7 8 0 1 2 3 4 5 6 7 8 ..."
CAD_B "5 6 7 8 3 4 5 6 7 8 3 4 5 6 7 8 ..."

If I'm interpreting this correctly, then:
  • Start= determines the 0-based index of the first frame to play on the first loop of the animation.
  • End= determines the amount of frames to play in the first loop of the animation. (If this pushes the first loop beyond LoopEnd, it will be truncated not to exceed it.)
  • LoopStart= determines the 0-based index of the first frame to play in a non-first loop of the animation.
  • LoopEnd= determines the 1-based index of the last frame in a non-first loop. (The first loop will never cross beyond this frame.) (This would render a ton of Cannis' proposed changes incorrect, so I am rather confused.)

Can anyone confirm / deny these theories?

Worth playing: 1 | 2 | 3
Reply
#2
I will look it in GAMEMD.EXE Smile
ARM forever - x86 sucks!


Reply
#3
Cannis' changes work. I implemented them myself and I've tested it.
LoopEnd seems to be 0-based like everything else. I've added my own stuff in there and it runs that way for me with no display issues or jumpy frames.
I'm what Willis was talkin' about.
Reply
#4
* DCoder is an idiot.

OK, scratch that Cannis part, his changes actually work exactly as my interpretation suggests they should...

Sooo, this thread is here only to document Westwood's irrational coding style. YET AGAIN. Mad

Worth playing: 1 | 2 | 3
Reply




Users browsing this thread: 1 Guest(s)