Just wanted to congratulate you guys! Figure you only get reports of bad stuff. Something, somewhere, has improved dramatically between May 23rd's nightly and now.
I was experimenting with the old "blink an image a bunch of times to make it seem transparent" trick (and was called a monster for my efforts!) in tandem with the new FPS options. In May 23rd's nightly, the technique was not effective at all: The framerate was inconsistent as my script flickered the image on and off, causing it to be visible or invisible for a few ticks in a row, periodically shattering the effect.
In tonight's nightly (and maybe others!) it holds right on 59.8 fps (I assume the missing .2 is a result of the wait in my script) flawlessly doing the old-school technique.
Dunno if it's an optimization in rendering, script processing or what, but it's damn good work guys!
Feature Report
Moderators: marionline, SDHawk
That's nice to hear; I did try to improve it two months ago. Still room for improvement. I guess you're using gfx_directx, which should hopefully now stick to a steady 60fps without dropping or adding frames. If you stare at the flickering for a while, do you ever see any occasional pauses?
gfx_sdl runs at 62.5fps for me, which means it's going to add extra frames, unfortunately noticeable as pauses in the flickering. SDL 1.2 doesn't have any way to get vsync, but I can at least make it happen less often by trying to actually hit 60 instead of 62.5==1000/16.
Displaying 59.8 instead of 60 may due to the FPS counter not measuring exactly the right interval of time, or maybe it really is dropping frames. It's not due to your scripts unless you're occasionally doing heavy processing.
gfx_sdl runs at 62.5fps for me, which means it's going to add extra frames, unfortunately noticeable as pauses in the flickering. SDL 1.2 doesn't have any way to get vsync, but I can at least make it happen less often by trying to actually hit 60 instead of 62.5==1000/16.
Displaying 59.8 instead of 60 may due to the FPS counter not measuring exactly the right interval of time, or maybe it really is dropping frames. It's not due to your scripts unless you're occasionally doing heavy processing.
Last edited by TMC on Fri Aug 07, 2015 7:34 am, edited 2 times in total.
My script is:
And I'm using gfx_directx.dll with V-Sync turned on. turning it off boosts FPS to 62.4 with a semi-predictable "pulse" of pauses. With it on, it's at 59.8 occasionally boosting to 59.9 briefly.
Whether or not there's occasional pauses is a little tricky to address: In the two minutes or so I watched there was exactly one noticeable incident where it stayed "on" just a little too long. Whether or not that was lag from somethin else my computer was doin, I dunno. The effect isn't entirely believable, it's stisll very obviously flickering, but then again that's the way it always did work.
Code: Select all
plotscript,GhostTest,begin
addhero (0)
addhero (0)
addhero (0)
loadslicecollection (0)
variable (ghost)
Ghost := lookupslice (1)
while (true)
do (
if (GetSliceVisible (Ghost))
then (SetSliceVisible (Ghost,off))
else (SetSliceVisible (Ghost,on))
wait (1)
)
endWhether or not there's occasional pauses is a little tricky to address: In the two minutes or so I watched there was exactly one noticeable incident where it stayed "on" just a little too long. Whether or not that was lag from somethin else my computer was doin, I dunno. The effect isn't entirely believable, it's stisll very obviously flickering, but then again that's the way it always did work.
Thanks. I also created a testcase that makes it very obvious when a frame is skipped/added or when it's tearing.
I've now fixed it to run at 60 instead of 62.5 fps when using a backend other than gfx_directx. (The problems I was describing in IRC were due to me having disabled compositing in window manager's settings. Opps!)
I've now fixed it to run at 60 instead of 62.5 fps when using a backend other than gfx_directx. (The problems I was describing in IRC were due to me having disabled compositing in window manager's settings. Opps!)