Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Veroule]

I have been working away at this patch for a bit.  The purpose of it is to seperate the redraw from the actual gameplay.  Letting them run at different speeds where the redraw is actually slower making game play faster.  This is a patch to the DF exe itself and therefore carries larger risks to use then various utilities.

I am hoping a few people will try it out and let me know how well it works for different systems.  The issues I currently know with it: loading and saving games seem to be much slower, I haven't tested CMV recording or playing at all, saving may cause a crash, FPS_CAP in the ini doesn't always seem to be respected.

Now to the fun things, some screen caps of me playing around with the CopperBlazes summer of 69 save in the patched version.  Note my system is an impressive 1GHz Athalon with a whopping 384Mb of memory all of which are about 5 years old.    

Finally a link to the 0.8 version of the patch, please give it a try and let me know.
SpeedDFv0.8.zip

[Xgamer4]

Title screen FPS. 999.

Yeah, it doesn't really respect the ini files, does it?

~640 FPS when first creating a fortress when the cap is 100. Ah well, doesn't matter to me. Looks promising. Let me experiment a bit more.

[zac4213]

I uploaded it to my website, http://www.dfdsdesigns.net/SpeedDFv0.8.exe,  so you don't have to use crappy rapidshare.

[ July 12, 2007: Message edited by: zac4213 ]

[Veroule]

I am glad to see there is some interest already.  I think most of the problems will likely be linked to single flag that I couldn't quite figure out the purpose of.  Depending on the results you guys find I will likely try to really track it down.

I am pretty sure the cause of not repspecting the ini is that I had to borrow memory addresses related to the existing timing controls.  The first one I picked was overwritten in such a way that it caused rapid crashing.  From the amount of testing I did, the way I have it now will be able to be corrected.  It just requires that I track down all the spots where it is getting changed.  It took a fair bit of time for me to just track down whether the existing FPS counter was on the drawing or the game side.  So it will take a lot longer to track down all the causes of this problem, but I can probably find a few rather easily.

Mostly I want to make sure it is worth my time, and I have things headed in the right direction.

[4bh0r53n]

doesnt seem to work for me, keeps coming up with either "file not found" (even when i direct it to the correct one) or "your version is already patched" (ive tried this on all 5 instances of the current version of DF i have on my machine)

[Asehujiko]

You need to place it in the df root directory to "work".

[Darwithe]

Very cool from what I see of the way it should work. Unfortunately on my system it will run for around 9-15 seconds then jerk to a halt for 2 or 3 (sometimes as much as 30) before resuming. Unplayable that way. Just seeing that FPS of 2473 was worth the download thou ^_^

[utunnels]

Oh, faint.
I get only 10 fps or so (never pass 20, usually less than 5) in adventure game. I have a Celeron 1.8G CPU.

---*edited*---

Ah, not saying your patch.  

[ July 13, 2007: Message edited by: utunnels ]

[Toady One]

Doing the code changes led to a negligible change here.  If you have out-of-date drivers it might help more.

[Arnos]

...bummer, I was hoping to get a massive speed increase.

[Veroule]

I have really been delving into all the causes of the FPS_CAP not being respected.  It seems that the way I borrowed variable space is rather bad.  I do not plan to make a v.81 patch.  It would just be wrong to keep going down the current path.

In order to proceed with that path I would have find and then make changes all over the place.  My final goal in doing this is that I could actually produce a small set of changes to Toady in C++ psuedocode.  Close enough to his source code that he can make the same changes and see a large result.  The patch I produced doesn't even come close to actually doing that.

Instead I am aiming at seperating the gameplay from the keyboard polling routine now.  The redraw is already easy enough to seperate.  My new goal for a .9 patch is to make gameplay be the only item on the high resolution timer.  Keyboard polling should be fixed to about 66 times per second, depending on your key hold setting.  Redraws will be aimed to the 10 FPS that I keep claiming is enough.

It may be a while still before I reach that point, but the few replies here helped.  I especially appeciate that you looked at it Toady.  It means a lot to me.  When I actually get a stable and productive patch made I will post clear list to match the source (albiet based on the naming in the KQ source).

I more or less have to declare my v0.8patch a failure.  Zac4213 if you would like to establish some contact I certainely like avoiding rapidshare if possible.  I just can't say how long it will take me to really figure out what I think needs to be done.

[capgamer]

Really cool idea. I haven't tried out the patch yet, but I thought I'd provide yet another link to download it because I also hate Rapidshare with a passion: http://www.mediafire.com/?fwbnzyim50x

[zac4213]

Do you have MSN Veroule, If so, then my name on it is zac4213@walla.com.

[kein]

07/13/2007: Added option to set graphics refresh rate

Looks like Toady liked your idea, no need for this after next release  

[Veroule]

I have been tweaking around with enough more to figure everything out.  There is no way for me to really seperate of the keyboard polling into its own time frame.  Also from the screen shots in my first post you can tell that by itself isn't much of a time eater.

My final assessment is that Toady is right the speed gains will be rather small during play.  The dwarves activities really are the big time eater.  The change will help in the early game, but not as much later.

I will be posting up a new patch pretty soon.  I have to write it myself instead of using CodeFusion, because it will be configurable.  Currently I am play testing the patched version to make sure it is operating stablely.  The patch allows a ratio to be set between the game side and the redraw, and I will be making it so that ratio is adjustable.  I will also be trying to make it into an active memory patch so that it doesn't modify the file and can be adjusted during play.  I just have to look up all the needed debugging type controls to do it.