The Dink Network

Just thought I'd remind everybody that tomorrow is the last day to submit your entry.

I'll have to scramble a little on my own entry, but it should be done in time.

Yep, and then we all have to play alternative hero mods for about 3 weeks! I could think of much worser ways to spend those weeks, though.

: Yep, and then we all have to play alternative hero mods for about 3 weeks! I could think of much worser ways to spend those weeks, though.

Dink Staff,

I was wondering, are the alternate hero dmod files that people submit for the contest reviewable or not. Just curious. The due date for Friday the 13th is kind of a bad luck charm to the developers. You should've made it like the 12th or the 14th. Oh well.

Anyways for dinkers that are making the alternate hero dmod, good luck and this may be a comeback to my 40+ day reviewing slump.

- DethLord

Yes, they will be reviewable like any other file.

The due date for Friday the 13th is kind of a bad luck charm to the developers. You should've made it like the 12th or the 14th. Oh well.

It is the 12th (here anyway) it has to be in before the 13th.

BTW, extra tip for anyone working on this:

If you're having trouble squeezing you're d-mod into 600KB, try using Redink1's FFCreate2 on the graphics, it made a big difference on mine.

: If you're having trouble squeezing you're d-mod into 600KB, try using Redink1's FFCreate2 on the graphics, it made a big difference on mine.

Or just don't use FFCreate at all

Another option is to create a less-complex title screen... it will compress much smaller. I fear I may have to do that...

: : If you're having trouble squeezing you're d-mod into 600KB, try using Redink1's FFCreate2 on the graphics, it made a big difference on mine.

: Or just don't use FFCreate at all

: Another option is to create a less-complex title screen... it will compress much smaller.  I fear I may have to do that...

I'm wrong, so sue me. I thought Paul meant that using FFCreate2 dir.ff files were smaller than FFCreate1 dir.ff files when zipped... while this is true, they're also smaller than the original bmps zipped, by a few KB. Cool.

Yeah, Dir.ff makes the total zip size bigger (99% of the time). Also lets not forget WinDinkEdit has a built in dir.ff program. The next problem with dir.ff is that it causes a proformance hit on the Dink editors and the engine.

--WC

: Yeah, Dir.ff makes the total zip size bigger (99% of the time). Also lets not forget WinDinkEdit has a built in dir.ff program. The next problem with dir.ff is that it causes a proformance hit on the Dink editors and the engine.

: --WC

FFcreate2 will make smaller file sizes than the ffcreate included with Dink. This is because the one included with dink also dir.ff's the ffcreate.exe while ffcreate does not.

--WC

My experience with ffcreate2 is that it helps scene transitions, fades etc when going from one screen to another screen that has new bmps. I get flash frames of the old/new screen between fades if I don't use ffcreate. Just my 2 cents

: My experience with ffcreate2 is that it helps scene transitions, fades etc when going from one screen to another screen that has new bmps. I get flash frames of the old/new screen between fades if I don't use ffcreate. Just my 2 cents

Yeah, I've had that too, but FFCreate2 doesn't always get rid of them, just most of the time.

: : My experience with ffcreate2 is that it helps scene transitions, fades etc when going from one screen to another screen that has new bmps. I get flash frames of the old/new screen between fades if I don't use ffcreate. Just my 2 cents

: Yeah, I've had that too, but FFCreate2 doesn't always get rid of them, just most of the time.

Ok, WC didn't understand.

Zipped FFCreate2 dir.ff: 166 KB

Zipped Raw BMP Files: 179 KB

I suspect this is because the ZIP format compresses files individually, and more compression can be squeezed out of BMPs that are all in the same file rather than split.

I was unable to test the original FFCreate, because it was trying to include the dir.ff file it was creating within itself.

Also, the reason why the screen doesn't flash when you use FFCreate2 is if you preload (or use) one seq in the dir.ff file, it will load all of the sequences in the dir.ff file into memory. And the flashing is caused by loading sequences into memory when the screen is faded down, as it will (briefly) display the image's pallete on the screen, I think.

: I suspect this is because the ZIP format compresses files individually, and more compression can be squeezed out of BMPs that are all in the same file rather than split.

How about the maximum compression option? Does it see any difference between individual bmp's and dir.ff?

: Also, the reason why the screen doesn't flash when you use FFCreate2 is if you preload (or use) one seq in the dir.ff file, it will load all of the sequences in the dir.ff file into memory.

If what you said is the truth, then it seems to me that PC's with less memory might have trouble if you squeeze a lot of bmp's into one single dir.ff. Or I completely miss the point...

Egad, this thread has certainly run amok

: How about the maximum compression option? Does it see any difference between individual bmp's and dir.ff?

Those numbers were calculated using the maximum compression, I think... (checks) yep, the Maximum according to Powerarchiver. There is an option for a DeFlate compression too... but that only reduced the original bmp graphics zip by 1 KB.

: If what you said is the truth, then it seems to me that PC's with less memory might have trouble if you squeeze a lot of bmp's into one single dir.ff. Or I completely miss the point...

You completely got the point. Reconstruction has terrible load times on slower computers because the graphics are in dir.ff format.

: : If what you said is the truth, then it seems to me that PC's with less memory might have trouble if you squeeze a lot of bmp's into one single dir.ff. Or I completely miss the point...

: You completely got the point.  Reconstruction has terrible load times on slower computers because the graphics are in dir.ff format.

Hmmmm... Pilgrim's Quest is going to need a fast computer. I'm making/testing it on a PIII 800 with GeoForce2 16MB... might have to test it on my old Pentium 200 MMX first before the public get to see it.

Yes, you are correct. if you have a ton of small graphics, it will compress more, but it you have a couple of big graphics (such as full screen bitmaps) it will compress less....or at least that is what I remember, my memory could be faulty here..

--WC