Robert Wilkinson wrote: > My machines a 166 pentium. > > Wincoupe needs a faster machine than this, needs a zimmer frame to get > around in this machine.
hehe! Try using fullscreen mode and making sure the 'accurate mode 3' option is disabled. That will use 320x240 mode which requires no image stretching, so it's the fastest it'll go! Not sure how it'll compare to the speed of the DOS version under the same conditions tho. With the 'accurate mode 3' option enabled it uses 640x480 which requires the 2x1 generated image to be vertically doubled by the display driver. Unfortunately you can't see the window title bar in fullscreen mode to know the speed, so you'll have to guess how well it's running - on-screen display is coming soon to solve that! What the maximum framerate do you get on the startup screen with the 1x1 window size and the 'frame skipping' set to 'none'? It's unfortunate that the only 2 machines I use are a PII-400 in work (S3 video card with no hardware help) and a (dual) Celeron 550 at home (TNT video card *with* hardware help). With the 1x1 window I get 167fps in work and ~307fps at home, so I hoped it would be ok on something like a P166 even tho I hadn't tried it out! I can't get it to drop under 50fps under any conditions at home! The frame skipping tries to make up the extra time to keep the underlying speed the same, but if the screen blits are taking far too long it can't quite compensate enough! Slow blits also make the keyboard less responsive as it's possible for keys to have been released before the keyboard scan sees then (and using keyboard buffering only leads to lagged keys which are awful in games!). I've (possibly contraversially?) removed the dirty line checking from the memory and video code, as the frame skipping and high resolution updates made things too complicated. About the only drawback is that you no longer get a speed boost when no video, palette or border changes are made in a frame, but the frame skipping should cover those cases unnoticably anyway when things are running below normal speed. I reckon most SAM software didn't really benefit from it anyway, and it also resulted in more of a speed fluctuation during use. With the tests removed all memory writes are a bit faster which benefits things as a whole. The only loss I can think of are possible inter-line 'pixel effects', done by writing data to the screen close to the raster position (not including VMPR, border and palette changes which are still done accurately). The undrawn part of each line is still updated at the end of the line to ensure to sure that they're not more than 1 line behind - without this it magically removes the star field from some demos! > Looks very good though. :-) It's getting there! Si
