Strange key combination that's not in debugging key list...
Moderators: marionline, SDHawk
- sheamkennedy
- Liquid Metal Slime
- Posts: 1110
- Joined: Mon Sep 16, 2013 9:29 pm
- Location: Tama-shi, Tokyo, Japan
- Contact:
Strange key combination that's not in debugging key list...
I was just testing my game (on Mac) and happened to hold down Shift + Tab at the same time. My game almost doubled in framerate in an instant. I looked in the debugging key list online and did not see this key combination there. In my game I do have tab used as the "shoot" button... perhaps this has something to do with it. Either way it was a very strange discovery.
On a related note my game is way more fast-paced and awesome at the fastest framerate. Is there anyway to default my game to the faster framerate?
On a related note my game is way more fast-paced and awesome at the fastest framerate. Is there anyway to default my game to the faster framerate?
⊕ P E R S O N A L M U S I C: https://open.spotify.com/album/6fEo3fCm5C3XhtFRflfANr
â� C O L L A B M U S I C: https://dustpuppets.bandcamp.com/releases
â� C O L L A B M U S I C: https://dustpuppets.bandcamp.com/releases
- Bob the Hamster
- Lord of the Slimes
- Posts: 7658
- Joined: Tue Oct 16, 2007 2:34 pm
- Location: Hamster Republic (Ontario Enclave)
- Contact:
Huh. I did not know about shift+Tab debug keys myself.
When I want to mess with frame-rate I always use CTRL ALT + and CTRL ALT -
We do want to eventually allow changing the default frame-rate. I think the main reason we have not done so yet is because we wanted to add options to scale the built-in animations to compensate for changes in frame-rate... but maybe it is not important to have that feature ready first.
When I want to mess with frame-rate I always use CTRL ALT + and CTRL ALT -
We do want to eventually allow changing the default frame-rate. I think the main reason we have not done so yet is because we wanted to add options to scale the built-in animations to compensate for changes in frame-rate... but maybe it is not important to have that feature ready first.
- sheamkennedy
- Liquid Metal Slime
- Posts: 1110
- Joined: Mon Sep 16, 2013 9:29 pm
- Location: Tama-shi, Tokyo, Japan
- Contact:
Cool. That frame-rate option would be awesome!Bob the Hamster wrote:Huh. I did not know about shift+Tab debug keys myself.
When I want to mess with frame-rate I always use CTRL ALT + and CTRL ALT -
We do want to eventually allow changing the default frame-rate. I think the main reason we have not done so yet is because we wanted to add options to scale the built-in animations to compensate for changes in frame-rate... but maybe it is not important to have that feature ready first.
⊕ P E R S O N A L M U S I C: https://open.spotify.com/album/6fEo3fCm5C3XhtFRflfANr
â� C O L L A B M U S I C: https://dustpuppets.bandcamp.com/releases
â� C O L L A B M U S I C: https://dustpuppets.bandcamp.com/releases
opps! We forgot to update the debug keys documentation; fixed now.
I've been thinking very recently about this, and had the idea of having two settings: the 'normal' frame rate, and a frame rate modifier. Changing the frame rate would adjust the number of frames animations in everything properly. Adjusting the framerate modifier would be the same as what the debug keys currently do. I'm wondering whether the modifier should also cause the play time counter, "milliseconds" command, and sound effects to run/faster slower.
I agree that adjustable framerate is horribly overdue, so wanted to implement the frame rate modifier as a script command. It's trivial to implement (key repeat rate is already frame-rate-independent), and good enough for anyone not using normal hero and npc movement. (You can use scripts to adjust the rate modifier on entering and leaving battle, so could still use the battle system). Then we can add a real adjustable frame rate when we've worked out all the animation details. I think that if we enable a higher framerate before it's ready then it should be a different option.
Also, I seriously want to add an option to cause the screen to be repainted more frequently than the 'tick rate'. I find 18 fps really jarring when walkign around a map in a fullscreen game. Doing this is likely cause bad visual effects in games which use scripts to around things on-screen (think platformers and parallax layers). So I wanted to make it an option that you can enable in your game even if it's too much work to rewrite all your scripts for a different tick rate, and an option that players can try setting themselves when playing games.
Firstly James, I discussed the shift+tab debug key with you recently. Secondly, I vaguely remember that the speedcontrol debug keys were once Ctrl Alt +/- rather than Ctrl +/-, it but hasn't been that way since at least 2005.Bob the Hamster wrote:Huh. I did not know about shift+Tab debug keys myself.
When I want to mess with frame-rate I always use CTRL ALT + and CTRL ALT -
I've been thinking very recently about this, and had the idea of having two settings: the 'normal' frame rate, and a frame rate modifier. Changing the frame rate would adjust the number of frames animations in everything properly. Adjusting the framerate modifier would be the same as what the debug keys currently do. I'm wondering whether the modifier should also cause the play time counter, "milliseconds" command, and sound effects to run/faster slower.
I agree that adjustable framerate is horribly overdue, so wanted to implement the frame rate modifier as a script command. It's trivial to implement (key repeat rate is already frame-rate-independent), and good enough for anyone not using normal hero and npc movement. (You can use scripts to adjust the rate modifier on entering and leaving battle, so could still use the battle system). Then we can add a real adjustable frame rate when we've worked out all the animation details. I think that if we enable a higher framerate before it's ready then it should be a different option.
Also, I seriously want to add an option to cause the screen to be repainted more frequently than the 'tick rate'. I find 18 fps really jarring when walkign around a map in a fullscreen game. Doing this is likely cause bad visual effects in games which use scripts to around things on-screen (think platformers and parallax layers). So I wanted to make it an option that you can enable in your game even if it's too much work to rewrite all your scripts for a different tick rate, and an option that players can try setting themselves when playing games.
Last edited by TMC on Thu Feb 19, 2015 2:04 am, edited 1 time in total.
- sheamkennedy
- Liquid Metal Slime
- Posts: 1110
- Joined: Mon Sep 16, 2013 9:29 pm
- Location: Tama-shi, Tokyo, Japan
- Contact:
@TMC: Sounds awesome! I think some plotscript commands for changing the framerate at any given point in the game could be great too. Even the option to lower the framerate would be neat in some cases.
Also if framerate effects SFX then I see lot's of other potential... like making a glitchy software synthesizer program...
Also if framerate effects SFX then I see lot's of other potential... like making a glitchy software synthesizer program...
⊕ P E R S O N A L M U S I C: https://open.spotify.com/album/6fEo3fCm5C3XhtFRflfANr
â� C O L L A B M U S I C: https://dustpuppets.bandcamp.com/releases
â� C O L L A B M U S I C: https://dustpuppets.bandcamp.com/releases
- Bob the Hamster
- Lord of the Slimes
- Posts: 7658
- Joined: Tue Oct 16, 2007 2:34 pm
- Location: Hamster Republic (Ontario Enclave)
- Contact:
I believe you, but my memory is completely blank on the Shift+Tab subject. :)TMC wrote:Firstly James, I discussed the shift+tab debug key with you recently. Secondly, I vaguely remember that the speedcontrol debug keys were once Ctrl Alt +/- rather than Ctrl +/-, it but hasn't been that way since at least 2005.
And I stand corrected on the CTRL ALT +/- I must have just been doing ALT out of force of habit
That is pretty cool! And we could implement the modifier right away without waiting for the normal frame rate feature to be fully implementedTMC wrote: I've been thinking very recently about this, and had the idea of having two settings: the 'normal' frame rate, and a frame rate modifier. Changing the frame rate would adjust the number of frames animations in everything properly. Adjusting the framerate modifier would be the same as what the debug keys currently do. I'm wondering whether the modifier should also cause the play time counter, "milliseconds" command, and sound effects to run/faster slower.
I am inclined against the modifier altering the milliseconds command, although I see no problem with a separate modifer for that.
Also, adjusting sound effect speed sounds like something that would require a pretty big music_* backend overhaul
Sounds like a good plan to me :)TMC wrote: I agree that adjustable framerate is horribly overdue, so wanted to implement the frame rate modifier as a script command. It's trivial to implement (key repeat rate is already frame-rate-independent), and good enough for anyone not using normal hero and npc movement. (You can use scripts to adjust the rate modifier on entering and leaving battle, so could still use the battle system). Then we can add a real adjustable frame rate when we've worked out all the animation details. I think that if we enable a higher framerate before it's ready then it should be a different option.
That mostly went over my head, but I am sleepy, so that is my excuse. Sounds fine to me anyway :)TMC wrote: Also, I seriously want to add an option to cause the screen to be repainted more frequently than the 'tick rate'. I find 18 fps really jarring when walkign around a map in a fullscreen game. Doing this is likely cause bad visual effects in games which use scripts to around things on-screen (think platformers and parallax layers). So I wanted to make it an option that you can enable in your game even if it's too much work to rewrite all your scripts for a different tick rate, and an option that players can try setting themselves when playing games.
I'm really excited to hear that framerate is looking at being improved. IMO, it's the only thing in the engine as far as end results go that make it subpar at this time; "retro" pixel art is so in vogue these days that well made OHRRPGCE graphics are downright luxurious compared to a lot of hip indie games coming out.
Only thing is the choppy scrolling. I even think that getting a well made full game passed on Greenlight would be feasible if the scrolling were improved.
Only thing is the choppy scrolling. I even think that getting a well made full game passed on Greenlight would be feasible if the scrolling were improved.
- Bob the Hamster
- Lord of the Slimes
- Posts: 7658
- Joined: Tue Oct 16, 2007 2:34 pm
- Location: Hamster Republic (Ontario Enclave)
- Contact:
Speaking of which, I heard that JSH's Motrya just passed Steam Greenlight :)Foxley wrote:Only thing is the choppy scrolling. I even think that getting a well made full game passed on Greenlight would be feasible if the scrolling were improved.
I really hope he is able to get the motivation and sprite-art-help he needs to finish the last two chapters
Last edited by Bob the Hamster on Thu Feb 19, 2015 1:58 pm, edited 1 time in total.
Cool, I see that happened very recently.
What do you mean by scrolling? The scrolling of the map as you walk around, meaning the framerate?
I thought some more, and realised that we can actually just add a framerate option now without changing anything else. A script command to set a framerate modifier would still be useful I think (which is why I proposed it).
The reasoning:
Firstly, an option to set the framerate doesn't need to affect battles at first; that can be added once battles are updated to handle it.
This means that the following things need to be handled:
-tile animations
-walk animations
-npc/hero walk speeds
(We don't need to worry about slice movement, dissolving, or camera pans, as those are all scripted so you're responsible to pick the number of ticks yourself.)
The idea was to automatically scale the lengths of all these pauses when you change the framerate, but that's not absolutely necessary if we just print a warning for now.
Finally, the walk animation and the available walk speeds are unsuitable for higher frame rates, but again we can just print a warning that it's an experimental feature which you should avoid if you're making an RPG.
What do you mean by scrolling? The scrolling of the map as you walk around, meaning the framerate?
I thought some more, and realised that we can actually just add a framerate option now without changing anything else. A script command to set a framerate modifier would still be useful I think (which is why I proposed it).
The reasoning:
Firstly, an option to set the framerate doesn't need to affect battles at first; that can be added once battles are updated to handle it.
This means that the following things need to be handled:
-tile animations
-walk animations
-npc/hero walk speeds
(We don't need to worry about slice movement, dissolving, or camera pans, as those are all scripted so you're responsible to pick the number of ticks yourself.)
The idea was to automatically scale the lengths of all these pauses when you change the framerate, but that's not absolutely necessary if we just print a warning for now.
Finally, the walk animation and the available walk speeds are unsuitable for higher frame rates, but again we can just print a warning that it's an experimental feature which you should avoid if you're making an RPG.
- sheamkennedy
- Liquid Metal Slime
- Posts: 1110
- Joined: Mon Sep 16, 2013 9:29 pm
- Location: Tama-shi, Tokyo, Japan
- Contact:
@TMC: Nice! Will this happen soon? I think it would be great for what I'm doing now. I suppose I'd have to do some testing to make sure errors don't occur with my current setup too.
⊕ P E R S O N A L M U S I C: https://open.spotify.com/album/6fEo3fCm5C3XhtFRflfANr
â� C O L L A B M U S I C: https://dustpuppets.bandcamp.com/releases
â� C O L L A B M U S I C: https://dustpuppets.bandcamp.com/releases
It's in. I'd be interested in hearing from people using it. For example do you wish that "wait(x)" was denominated in 18ths of a second rather than frames? Probably we should just let people do a mass-replace of 'wait(' with 'wait18(' or whatever in their scripts, however waitms(milliseconds) and/or waitsec(seconds) commands would probably be nice to have.
That would be perfect for music and sound timing.TMC wrote:waitms(milliseconds) and/or waitsec(seconds) commands would probably be nice to have.
Last edited by Matokage on Sat Feb 21, 2015 4:12 pm, edited 1 time in total.
"I can't buy food with glory"
Actually it wouldn't be perfect. If you want to do accurate timing, then a sequence of such commands could still diverge because the errors add up; what you want is a "wait until(time)" command.
But all such commands are easy to implement using the existing "milliseconds" command.
But all such commands are easy to implement using the existing "milliseconds" command.
Code: Select all
script, wait until, ms, begin
while(milliseconds < ms) do (wait)
end
script, example, begin
variable(start)
start := milliseconds
# do something
wait until (start + 1000) # 1 second
# do something
wait until (start + 2600) # 1.6 seconds
end