when ever i play a custom quest it always happens in like x2 speed. is there any way to slow it down?
Printable View
when ever i play a custom quest it always happens in like x2 speed. is there any way to slow it down?
If you are using version 2.10 then yes. just hit F1 to SLOWW IT DOWWNNN.Quote:
Originally Posted by kakashi401
If you are using any other version then.. unless you have debug mode on [you can also press F1] i have no Idea.
wow thx for the help!
Hello!
I work with ZC2.50 and also have a speed problem. But not every day and not everytime. And F1 doesn't solve the problem. :shakehead:
It starts yesterday, that Link walk a bit faster than normal. Not as highspeed as with F1, but too fast. Link goes faster, the strings in the caves runs faster, of course the enemys are also faster. The problem is also existing if I run 1st.qst, not only in my own quest. Restart the ZC Launcher doesn't help. :shakehead:
Today in the morning it works fine again, but now Link is on crack again.
If I press F2, it says 60/60, but this is like the normal speed with about 1,5 as multiplicator.
What can I do to solve this problem? Please help me.
PS: Sorry for my bad english. It isn't my native language.
Welcome To AGN enjoy toast and carpet.
You need to toogle VSYNC
I'm using Zelda Classic v2.50.2-win and Win10 Pro 64bit.
But I found out, what the problem was. It wasn't the game, it was the VLC player. Maybe hardware acceleration?
Without running VLC: 37-43/60 FPS
If VLC is running: 60/60 FPS
If someone else has a problem with a fast Link: Press F1 or turn off the VLC player. :thumbsup:
VLC?
What is your indicated CPU usage when you are running both, and what system CPU% does each use (see Task manager)?
Also, try the latest 2.53 Beta, instead of 2.50.2. it might not have the same issue, and I'd be curious to discover if that's the case.
@ZoriaRPG
The issue is resolved.
Please just drop it.
My Taskmanager:
https://abload.de/img/cpur0eja.png
2.53 Beta has the same "problem" => 60/60 FPS
What does frame_rest_suggest = 0 mean? Default is 2 (in 2.53 beta) or 1 (in 2.50.2).
But 1, 2 or 0 change nothing. Whatever I take: 60/60 FPS if VLC-Player is running.
frame_rest_suggest just gives back CPU if >= 1. This prevents 100% CPU usage; for example when streaming or recording/whatever. The problem is allegro timers are not uniform across all OS or Windows versions, and with every new version of Windows their "compatability layers" keep getting worse and worse.
The good news is that VLC is open source so I can dig around there if need be.
I'm confused though: Is the FPS too high or too low?
(PS1: ZoriaRPG, is _WIN32 macro set in your compiler settings, or just WIN32? [both should be])
(PS2: frame_rest_suggest you can just leave at 0. Probably should be made the default on WIN8/WIN10)
I thought that his FPS were dropping to ¬30 when VLC was either open, or running. It could have been the latter, and caused by a highly fragmented--or dying!!--HDD for all I know. I need more data fropm the OP, but he's using 2.50.2, not 2.53+, so it's not MSVC here--possibly elsewhere.
What file should I check for those definitions? I'm pretty sure that both are set, but I may as well verify that.
On the subject of framerate drops, apparently displaying the current FPS rate causes ZC Player to tank, and lose as much as 50% of its performance. I'm not yet sure why, as I haven't had time to look at it, but we'll need to eventually address some of these things, especially once I migrate the video bitmap to 32b OGL and start performing an intermediate blit--next version! (AL)
frame_rate_suggest = 0 is the default now, AFAIR.
I also need to rewrite the debug console, to use the newer w32 API, as when I compile using MSVC17/w10, it no longer works.
Thing is, that doesn't make sense. 40 FPS should be slower than normal, not faster. The framerate is linked to the game speed; there's no way for the game to be running faster when the framerate is lower.
it doesn't have any effect period.
he's trolling guys. just ignore him. It makes zero sense. :/
It is enough if VLC is in the task bar. It doesn't matter if a movie is playing or not.
No.
The problem isn't really solved, but since I know now that it is VLC player, I can turn it off. Then I don't have the problem. Because I didn't notice this at the beginning, so the question here in the forum. We can stop the discussion. It is good enough at it is.
Thank you. Sorry that I had a problem. :confused_white:
You welcome. Sorry I'm an asshole. :D
Project Settings->Preprocessor,
or, you can type this:
Seriously though, get back to me here. I need to know if that was set in the exact build that he tested. ;)Code:#ifndef _WIN32
#error "no disassemble. Johnny 5 is ALIVE!"
#endif
Ah. That's because ZC draws to the "screen" bitmap, which just happens to be really, really, slow if it is stored in gfx memory. Pro tip: Never draw to the 'screen' bitmap.
I'll check tomorrow, as I powered off my dev machine for the day; but he was using 2.50.something, not one of my builds, so I would have no way of knowing what ppc stuff was set.
You, or Saffith made all of those, but I'll ensure that it's set for 2.53, and above.
Wait...the FPS textout is drawn directly to the video bitmap, instead of blitting to framebuf? I didn't notice that... Who thought that'd be a good idea?
Every blit should be to a RAM bitmap, so that there is one, final blit to SCREEN at the end. That's how RAM/Video bitmaps work!! You only output directly to video bitmaps if you have real HWA, which absolutely nothing that I've worked on to any real extent has ever had (or usually needed) anyway.
Not something I've ever noticed. I don't think that happens on Linux, probably because of the software rendering.
Maybe that would help to explain the discrepancy, at least. Perhaps VLC is affecting DirectX or some other system state in such a way that the game runs faster than normal, but also makes it run a lot slower when the FPS display is enabled. Or... maybe the FPS counter is just wrong? It depends on Allergo calling fps_callback() at the right times, and I don't know how that works internally.
I've never run into this, either. In theory, based on the OP's explanation, it's Windows, or his GFX drivers that's muck with the Allero timers. I can't explain it, but I also can't explain how his instance of ZC is using < 30MB of RAM.
The screenshot of his taskman.exe doesn't look possible. Base 2.50, running 1st.qst uses 67MB.
I was looking at the Allegro timers, and I'd expect that, if this problem were genuine, that it'd be more commonplace on Win10.
It's nothing that I can fix in any case, as I can't duplicate it.