Time Gate: Knight's Chase

2020-07-10 02:00:29 pm

Quote:

I'm not sure what you mean by "good enough"

by that I meant the minimum to not feel laggy or slow anymore. still there are a bit of lags but this is expected. I looked at the intro video and I also paid attention to the music tempo. Also the lags for the control, with 30k there is a latency when I press the keys

Quote:

would you even want to use those tricks then if you knew someone else can't run the game at all?

Actually it's the opposite, it's more easy to setup the tricks when the game is slow, the pause buffering would be almost frame perfect. for the catapult trick, I make zero mistake with a low cycle

Quote:

The value that we could acceptably use will go up over time though

that's my concern too, it would be perfect if we can use a virtual machine with the same conf for every runner, but I don't know if it's something we can do.

Quote:

Looks like the sound will crackle during the arrest cutscene even at 50k cycles. 70k makes the laser room in the museum (the one where you crawl) slower

yes that is part of "good enough", I start to experience those crackles above 60K, but since we skip the video cutscene in the game, it's not a big deal. I've never experience a specific slowness in the first lazer room. With 90k, I can heard different music tempo between the game and the inventory menu.

Quote:

Can you provide me with a save file to the part of the game that's the laggiest?

yes here is link with the save files: https://drive.google.com/file/d/1ERM3VQHffQHfIWRtYvY2KPPbsjqM29qS/view?usp=sharing
- SAVE0: right after setting up the glitch while following the monk, there are some lag while switching between camera angles
- SAVE1: pushing the cross
- SAVE2: the hospital right after picking the gem from the old crazy templar cell. the fight with those 2 guard might the most laggy moment of the game
- SAVE3: right before splashing Juliette, it's one of the longest in game cut scene

if you interested, here is a link for all the save files for each segments: https://drive.google.com/file/d/1AqG81JvwjKGoKopaslaF0K_Zf_6R0xvT/view?usp=sharing

[quote]I'm not sure what you mean by "good enough"[/quote]
by that I meant the minimum to not feel laggy or slow anymore. still there are a bit of lags but this is expected. I looked at the intro video and I also paid attention to the music tempo. Also the lags for the control, with 30k there is a latency when I press the keys

[quote]would you even want to use those tricks then if you knew someone else can't run the game at all?[/quote]
Actually it's the opposite, it's more easy to setup the tricks when the game is slow, the pause buffering would be almost frame perfect. for the catapult trick, I make zero mistake with a low cycle

[quote]The value that we could acceptably use will go up over time though[/quote]
that's my concern too, it would be perfect if we can use a virtual machine with the same conf for every runner, but I don't know if it's something we can do.

[quote]Looks like the sound will crackle during the arrest cutscene even at 50k cycles. 70k makes the laser room in the museum (the one where you crawl) slower[/quote]
yes that is part of "good enough", I start to experience those crackles above 60K, but since we skip the video cutscene in the game, it's not a big deal. I've never experience a specific slowness in the first lazer room. With 90k, I can heard different music tempo between the game and the inventory menu.

[quote]Can you provide me with a save file to the part of the game that's the laggiest?[/quote]
yes here is link with the save files: https://drive.google.com/file/d/1ERM3VQHffQHfIWRtYvY2KPPbsjqM29qS/view?usp=sharing
- SAVE0: right after setting up the glitch while following the monk, there are some lag while switching between camera angles
- SAVE1: pushing the cross
- SAVE2: the hospital right after picking the gem from the old crazy templar cell. the fight with those 2 guard might the most laggy moment of the game
- SAVE3: right before splashing Juliette, it's one of the longest in game cut scene

if you interested, here is a link for all the save files for each segments: https://drive.google.com/file/d/1AqG81JvwjKGoKopaslaF0K_Zf_6R0xvT/view?usp=sharing

LotBlind

2020-07-11 08:07:03 am

I found this thread. I had no idea GOG sets 80k cycles for Little Big Adventure! We seriously need someone who knows more about computers and DOS (and has time to look into these things). I'm not really that type myself.

So I guess the cycles count isn't such a problem after all then. So long as they're fixed. I think we can start to prioritize performance then, which also ties in with A/V quality (always important on SDA). We don't want huge distortion in the music which is actually really good BTW. Vachey hadn't lost his touch. Still, by SDA rules you could even turn the music off. I'm planning to do that with AitD but that's mainly because many segments will be so short that the music would be constantly changing or starting over. I agree that cutscenes are not important since they're cut from the run.

Google Drive has recently changed: You now have to manually change the link type so it allows anyone to access the file with just the link alone, if that's what you wanted. You should have something in your email that lets me access those files?

I found [url=https://forum.speeddemosarchive.com/post/official_dosbox_settings_discussion_topic.html]this thread[/url]. I had no idea GOG sets 80k cycles for Little Big Adventure! We seriously need someone who knows more about computers and DOS (and has time to look into these things). I'm not really that type myself.

So I guess the cycles count isn't such a problem after all then. So long as they're fixed. I think we can start to prioritize performance then, which also ties in with A/V quality (always important on SDA). We don't want huge distortion in the music which is actually really good BTW. Vachey hadn't lost his touch. Still, by SDA rules you could even turn the music off. I'm planning to do that with AitD but that's mainly because many segments will be so short that the music would be constantly changing or starting over. I agree that cutscenes are not important since they're cut from the run.

Google Drive has recently changed: You now have to manually change the link type so it allows anyone to access the file with just the link alone, if that's what you wanted. You should have something in your email that lets me access those files?

arnaud33200

2020-07-11 10:01:40 am

Quote:

We seriously need someone who knows more about computers and DOS

maybe NHG would know know something? we can ask him. Same I just got into Dosbox since april

Quote:

So I guess the cycles count isn't such a problem after all then. So long as they're fixed.

So you can confirm we can set the following rules?
- play on GOG or Stream version
- update DOSBox cpu settings to "core=simple" and a fixed value for "cycles"

Quote:

We don't want huge distortion in the music which is actually really good BTW

I agree, the game has nice musics! using CTRL-F11 & CTRL-F12 to change the cycles, we can find a max fixed cycles number before the music and in-game cut scene slow down

Quote:

You should have something in your email that lets me access those files?

Sorry I forgot to enable access to "anyone with the link". I gave you access to the file

-----

I was wondering, can you share the default dosbox conf file from GOG?

LotBlind

Edit history:

LotBlind: 2020-07-11 10:32:58 am

2020-07-11 10:24:19 am

If someone else finds the game to be too loud, you can simply add this line to the _timegate_single.conf file (before where the game is launched): mixer master 20:20. That changes left and right channels to 20%. I couldn't work out how to do the same with the music, though. The manual has that command explained under "mixer". Looks like because it's MIDI music, you can adjust it from the synthesizer itself (if you have a custom synthesizer like VirtualMIDISynth like I do). I can't see another way to adjust just the game's volume without touching the system volume. The game doesn't seem to remember what settings you left it on either.

One way to know how much lag there is (without having a lagometer like AitD) is to look at how far the PC moves whenever you start moving. Looks like normally when you run, the shortest distance you can cover is 68 (you can see this in the "offset" counter that shows the offset from the last time the actor moved). When the game slows down, this value goes up to 136 etc. To get the character to run perfectly smoothly in the first lag save, looks like you'd need closer to 70k. The music is way too slow at that point. The same can be said of the other save files. The music stays at the right tempo up till 50k. At 55k I can already hear it slowing down. Can you confirm that? If it's the same with you, I think 50k would probably be the best value to pick. The cutscenes are still going to be wrong but you'll skip them anyway. And yes, just in case, playing on the GOG or Steam version is smartest. core = simple... tigrou, can you comment on this again? The default is auto but you're saying we should go with "simple" because it's more stable? But if we choose "auto" it might use the dynamic core which is marginally faster, right?

Lag snapping: Nevermind, the first part works but the second one doesn't.

NHG doesn't know anything about anything other than how to execute some single-segment runs. Which he does very very well of course.

If someone else finds the game to be too loud, you can simply add this line to the _timegate_single.conf file (before where the game is launched): mixer master 20:20. That changes left and right channels to 20%. I couldn't work out how to do the same with the music, though. The [url=https://www.dosbox.com/DOSBoxManual.html]manual[/url] has that command explained under "mixer". Looks like because it's MIDI music, you can adjust it from the synthesizer itself (if you have a custom synthesizer like VirtualMIDISynth like I do). I can't see another way to adjust just the game's volume without touching the system volume. The game doesn't seem to remember what settings you left it on either.

One way to know how much lag there is (without having a lagometer like AitD) is to look at how far the PC moves whenever you start moving. Looks like normally when you run, the shortest distance you can cover is 68 (you can see this in the "offset" counter that shows the offset from the last time the actor moved). When the game slows down, this value goes up to 136 etc. To get the character to run perfectly smoothly in the first lag save, looks like you'd need closer to 70k. The music is way too slow at that point. The same can be said of the other save files. The music stays at the right tempo up till 50k. At 55k I can already hear it slowing down. Can you confirm that? If it's the same with you, I think 50k would probably be the best value to pick. The cutscenes are still going to be wrong but you'll skip them anyway. And yes, just in case, playing on the GOG or Steam version is smartest. core = simple... tigrou, can you comment on this again? The default is auto but you're saying we should go with "simple" because it's more stable? But if we choose "auto" it might use the dynamic core which is marginally faster, right?

Lag snapping: Nevermind, the first part works but the second one doesn't.

NHG doesn't know anything about anything other than how to execute some single-segment runs. Which he does very very well of course.

arnaud33200

Edit history:

arnaud33200: 2020-07-11 11:30:20 am

2020-07-11 11:30:13 am

Quote:

At 55k I can already hear it slowing down. Can you confirm that?

FYI, My computer (tower) is running on a i7-5820K CPU @ 3.30GHz (Windows 10 Pro)

I did some music tempo test in the ticket office room (where we pick the catapult), I used this online tool: http://www.beatsperminuteonline.com/
when I use "core=simple" tempo start to slow down after 80k (108 bpm) and goes down to 102 bpm with 95K cycles. for 75k and below I got 110 bpm all the time.
When I use "core=normal", the tempo starts toslow down at 70K cycles (102 bpm) and goes down to 96 bpm with 75k cycles. for 65k and below, it's always 110 bpm

did you try without using "VirtualMIDISynth"?

Quote:

NHG doesn't know anything about anything other than how to execute some single-segment runs. Which he does very very well of course.

I see, indeed he is a good runner!

LotBlind

2020-07-13 08:53:34 am

You're right in thinking the special MIDI font uses more CPU power. I don't think I'll uninstall the midi synth for this though: it requires deleting some registry values too. I don't really have time to do more testing (I even got the game to stop working even after reinstalling by just trying a different sound setting! Sorting that out.). Is it really such a problem if the framerate drops a bit in a few areas? You have a gaming PC (like me), but do we really have a reason to limit accessibility for those that don't? What about 60k? If you choose a setting that someone else with a reasonable CPU can't run it on without problems, we will have to let them lower the cycles, which might make some tricks easier for them than you.

Maybe you should switch back to core = auto or whatever it was before and let's use as many default settings as possible? None of the other settings listed in that DOSBox thread mention anything about core = simple, so let's assume it's not a problem until proven otherwise (well, a lot of them also recommend MAX % settings which are obviously tied to CPU speed so...).

Sorry, I don't know how much better I can do here!

You're right in thinking the special MIDI font uses more CPU power. I don't think I'll uninstall the midi synth for this though: it requires deleting some registry values too. I don't really have time to do more testing (I even got the game to stop working even after reinstalling by just trying a different sound setting! Sorting that out.). Is it really such a problem if the framerate drops a bit in a few areas? You have a gaming PC (like me), but do we really have a reason to limit accessibility for those that don't? What about 60k? If you choose a setting that someone else with a reasonable CPU can't run it on without problems, we will have to let them lower the cycles, which might make some tricks easier for them than you.

Maybe you should switch back to core = auto or whatever it was before and let's use as many default settings as possible? None of the other settings listed in that DOSBox thread mention anything about core = simple, so let's assume it's not a problem until proven otherwise (well, a lot of them also recommend MAX % settings which are obviously tied to CPU speed so...).

Sorry, I don't know how much better I can do here!

arnaud33200

2020-07-13 12:35:52 pm

I think you didn't see my message: I was wondering, can you share the default dosbox conf file from GOG?

Quote:

Maybe you should switch back to core = auto or whatever it was before and let's use as many default settings as possible?

I just tried the game on my old laptop I got from 2010 (Pentium Dual-Core T400 2.2GHz).
- using "core=simple", I have to lower the cycles down to 40K to have a normal music tempo
- using "core=auto", I can run the game smoothly, using "cycles=auto" I can see the average cycles number display is a bit above 100k,

So yeah I feel having "core=auto" would be better, works well with older computer. maybe we set a fixed cycles to 100k or 90k? My fastest computer has an average of 350k cycles when set to auto.
I also compare the cemetery segment run (it's mostly running) for both computer with the same "cycles=90000": I have the same time for both (1:55)
Maybe we can have a confirmation from Tigrou before finalizing the decision?

LotBlind

2020-07-14 01:33:36 pm

I can't share that file right now because the game is completely broken (I can't properly reinstall it so I don't have the original files, only the edited ones) and I've just been sent something very generic as to how repair it. I don't think there was anything very different in it anyway.

I asked tigrou to comment on this again.

LotBlind

2020-07-16 12:26:08 pm

Here's what tigrou said:

Quote:

Take a look at the page I posted : https://www.dosbox.com/wiki/Dosbox.conf#core_.3D_simple_.7C_normal.7C_dynamic_.7C_auto

For protected mode games (like Time Gate) auto = dynamic. If you fix number of cycles, dynamic will behave almost same way as simple/normal regarding emulation speed (eg: how much time a room transition take).
Differences are:
- less stable, might crash some games (if Time Gate never crash in that mode that's fine)
- more efficient, CPU usage reported in task manager should be lower.
- less precise (you ask to execute 40000 instructions every ms but in reality it might execute a little bit more, eg : 40257)

I have done some benchmarks with AITD1 :

Code:

core = simple
11000 cycles : 350 ms
40000 cycles : 96 ms
80000 cycles : 47 ms
250000 cycles : 29 ms (*)

core = dynamic
11000 cycles : 353 ms
40000 cycles : 96 ms
80000 cycles : 47 ms
250000 cycles : 14 ms
500000 cycles : 7 ms (**)
800000 cycles : 7 ms (*)

(*) should be faster but it hit the limit. My CPU usage reach 12.5% which is max, and game became laggy
(**) it's faster than cycles = max, but remember that one keep 10% as safe margin

If you ignore timings above 80000 (which are too much) it's exactly the same times. I don't see how the game could be smoother with auto (as Arnaud reported), unless his CPU can reach cycles he set (eg: 80000) in simple/normal mode.

If I plot the values measured above in a chart, (cycles vs performance) it correlates and follow a perfectly linear relation. This is until you hit maximum host CPU can give (it will cap). Red line is the limit imposed by simple/normal.

CPU usage @ 80000 cycles :
Code:

dynamic : 1 - 2%
simple/normal : 2 - 7%

It seems dynamic is roughly 3 - 4 times more efficient

TLDR; dynamic does not seem to give an unfair advantage vs simple/normal. it is much more efficient.
cycles should be fixed. max or auto gives advantages to someone with fast CPU.

So core = auto (which sets it to dynamic) is more efficient and if it doesn't cause crashing, using it doesn't cause a problem in terms of fairness. So that doesn't have to be touched. The cycles thing is still a question that doesn't have a simple answer but I still don't get why you have to go absolutely as high as you can? I think we need to choose a fair medium. What about 80k cycles then? That would make it the same as Little Big Adventure which seems like a safe bet. It seems people run Descent on 100k to make it smooth but I can't imagine this game has to do as much graphics calculation.

Here's what tigrou said:

[quote]Take a look at the page I posted : https://www.dosbox.com/wiki/Dosbox.conf#core_.3D_simple_.7C_normal.7C_dynamic_.7C_auto

For protected mode games (like Time Gate) auto = dynamic. If you fix number of cycles, dynamic will behave almost same way as simple/normal regarding emulation speed (eg: how much time a room transition take).
Differences are:
- less stable, might crash some games (if Time Gate never crash in that mode that's fine)
- more efficient, CPU usage reported in task manager should be lower.
- less precise (you ask to execute 40000 instructions every ms but in reality it might execute a little bit more, eg : 40257)

I have done some benchmarks with AITD1 :

Code:

core = simple
 11000 cycles : 350 ms
 40000 cycles :  96 ms
 80000 cycles :  47 ms
250000 cycles :  29 ms (*)

core = dynamic
 11000 cycles : 353 ms
 40000 cycles :  96 ms
 80000 cycles :  47 ms
250000 cycles :  14 ms
500000 cycles :   7 ms (**)
800000 cycles :   7 ms (*)

(*) should be faster but it hit the limit. My CPU usage reach 12.5% which is max, and game became laggy
(**) it's faster than cycles = max, but remember that one keep 10% as safe margin

If you ignore timings above 80000 (which are too much) it's exactly the same times. I don't see how the game could be smoother with auto (as Arnaud reported), unless his CPU can reach cycles he set (eg: 80000) in simple/normal mode.

If I plot the values measured above in a chart, (cycles vs performance) it correlates and follow a perfectly linear relation. This is until you hit maximum host CPU can give (it will cap). Red line is the limit imposed by simple/normal.

CPU usage @ 80000 cycles :
Code:

dynamic : 1 - 2%
simple/normal : 2 - 7%

It seems dynamic is roughly 3 - 4 times more efficient

TLDR; dynamic does not seem to give an unfair advantage vs simple/normal. it is much more efficient.
cycles should be fixed. max or auto gives advantages to someone with fast CPU.[/quote]

So core = auto (which sets it to dynamic) is more efficient and if it doesn't cause crashing, using it doesn't cause a problem in terms of fairness. So that doesn't have to be touched. The cycles thing is still a question that doesn't have a simple answer but I still don't get why you have to go absolutely as high as you can? I think we need to choose a fair medium. What about 80k cycles then? That would make it the same as Little Big Adventure which seems like a safe bet. It seems people run Descent on 100k to make it smooth but I can't imagine this game has to do as much graphics calculation.

arnaud33200

Edit history:

arnaud33200: 2020-07-16 01:15:11 pm

2020-07-16 01:13:14 pm

I've compared the dosbox config files of GOG and Steam:
| param | Steam | GOG
| ---------------------- | ------------------------- | -------------------------
| version | SVN | 0.74-2-2
| output | openglnb | overlay
| cycles | auto | max %25
| prebuffer [mixer] | 20 | 80

--------------------

I think the prebuffer has no impact on the game. same for output=overlay, it just make the game graphics more darker and feel a bit more smooth.
I tried to compare the time between different output using avidemux, It's the same for every part

arnaud33200

2020-07-16 01:18:00 pm

Quote:

I think we need to choose a fair medium. What about 80k cycles then?

yes sounds good to me and it makes sense! I was about to suggest keeping 75k since I used that in my last run but I'm also ok with 80k.

what about "output=openglnb" or "output=overlay"? it doesn't change anything right? just the way it look?

tigrou

Edit history:

tigrou: 2020-07-17 02:14:51 am

tigrou: 2020-07-17 02:06:08 am

tigrou: 2020-07-17 02:03:14 am

2020-07-16 01:38:38 pm

I just realized this thread had a second page. I was surprised nobody replied after my last post Grin

About output : I think it does not matter. You should use whatever works the best for you.
prebuffer : It only affect sound. I would leave it to default. Large values will cause sound lag. short values reduce delay but increase CPU usage and might result in distorted sound if CPU can't follow.

arnaud33200

2020-07-16 02:06:54 pm

so let's all agree on "core=auto" and "cycles=80000"?

tigrou

2020-07-17 02:16:30 am

core = auto (which is same as core = dynamic with Time Gate) sounds good to me.
AFAIK it does not gives unfair advantage with someone with a fast CPU.

On the other hand it gives a 3-4x performance boost (in average).
This means someone able to run Time Gate @ 30000 cycles with core = normal should be able to run it @ 80000 cycles with dynamic as well.

To make it clear : core = dynamic does not mean to adjust something over the time like cycles = auto. dynamic vs normal is about using an interpreter vs a dynamic recompiler.

arnaud33200

2020-07-17 12:10:35 pm

got it! for the GOG / Steam version, the dosbox conf has "core=auto", but you are right, it's technically "dynamic".

I found many improvements, I will be able to save more than 1 minutes on my run. I think I will record a new run soon when I found the good time.

I haven't figured out any good tricks to cancel the animation while entering the stairs, it would save 1 or 2 seconds for each stairs action!
Next big improvement would be able to go through a door at the tower (after cemetery) that would save more than 30s!

LotBlind

2020-07-17 03:45:38 pm

tigrou, don't forget that output had a big impact on my performance. Remember when I told you whenever AitD uses the shake effect, there was a massive slowdown on some settings compared to others? Looks like this game doesn't use that effect though. There were also small differences that I noticed in other parts though. The setting that was fastest during shaking wasn't the fastest outside of it I think. I guess whichever setting is the fastest should be used and I hope that's okay...

arnaud: That door you're trying to pass through... there might be a way. It's called collision clipping. Try reading what it says in the guide. In order to understand it fully, you should start by reading the paragraph that starts "Every actor is initially stored in the objects array...". And for the fast stairs, did you try space turns yet? Those no longer worked when pushing at least, but maybe they still work at other times.

Yeah, let's use those settings. I'll put it in that thread.

tigrou

Edit history:

tigrou: 2020-07-18 05:04:11 am

tigrou: 2020-07-17 04:22:16 pm

tigrou: 2020-07-17 04:21:16 pm

2020-07-17 04:20:14 pm

yes output can have an impact on performance but it should not give advantage to someone that has a better config (unlike cycles=max or auto).

Some info about output from vogons.

arnaud33200

2020-07-18 10:52:05 am

Quote:

yes output can have an impact on performance but it should not give advantage to someone that has a better config

Should we allow runner to change the output conf? or it should be the default from GOG or Steam?

Quote:

That door you're trying to pass through... there might be a way. It's called collision clipping

yes there is a way actually, I just found a glitch but it's not a collision clipping. I found that going up to start the "Follow Berwal" cut scene, I can open the menu at the right moment to allow inventory access for the rest of the cutscene. right before entering the secret door, I can drop an item to change my trackmode from "FOLLOW" to "MANUAL". part of the cutscene, William's Y size become -1500, so while I'm free to move anywhere, I can clip through everything!

Because the cut scene is too long, I would loose 20s in my run, but If I run to the last level, I can skip a big part ... but one closed door blocks me to continue after splashing Juliette. but yeah same, there might be a way to go through that door using a collision clipping, that would save more than 3 minutes in the run! I will do some research.

check here:

Quote:

And for the fast stairs, did you try space turns yet?

The only items "INHAND that has no associated SPACE action" are the bucket (out of the trigger zone) and the plates, so I wasn't able to do it yet. I tried the snap right before splashing Juliette, it's a bit faster. I'm not sure if I don't do it properly or if the game developer did a fix for that.

[quote]yes output can have an impact on performance but it should not give advantage to someone that has a better config[/quote]
Should we allow runner to change the output conf? or it should be the default from GOG or Steam?

[quote]That door you're trying to pass through... there might be a way. It's called collision clipping[/quote]
yes there is a way actually, I just found a glitch but it's not a collision clipping. I found that going up to start the "Follow Berwal" cut scene, I can open the menu at the right moment to allow inventory access for the rest of the cutscene. right before entering the secret door, I can drop an item to change my trackmode from "FOLLOW" to "MANUAL". part of the cutscene, William's Y size become -1500, so while I'm free to move anywhere, I can clip through everything!

Because the cut scene is too long, I would loose 20s in my run, but If I run to the last level, I can skip a big part ... but one closed door blocks me to continue after splashing Juliette. but yeah same, there might be a way to go through that door using a collision clipping, that would save more than 3 minutes in the run! I will do some research.

check here: https://youtu.be/QVp1ijYOTeU

[quote]And for the fast stairs, did you try space turns yet?[/quote]
The only items "INHAND that has no associated SPACE action" are the bucket (out of the trigger zone) and the plates, so I wasn't able to do it yet. I tried the snap right before splashing Juliette, it's a bit faster. I'm not sure if I don't do it properly or if the game developer did a fix for that.

LotBlind

2020-07-18 12:06:05 pm

Like I said, my experience with output modes is if I use the default one (which is really arbitrary; they're meant to be cosmetic), the game runs much much much slower in some parts (like 50% the regular speed) and doesn't really match what you would have expected when playing on an old computer. I never asked NHG which setting he used. The second thing is, SDA is more happy to accept any settings (that don't affect the category) when it's options that are available either in-game OR through an external config utility like the one used for changing graphics modes. It makes it feel more like those settings were meant to be changed. That's why it feels like the runner should be allowed to choose. Also it's a question of A/V quality: nobody wants to watch a run where a part of it runs at 50% speed. Of course that may not be the case here but still.

Actually I don't know how we'd feel if you chose a mode that actually puts the graphics through a filter of some kind. Not everyone is a fan of those kinds of graphics (including me most of the time). Those modes are probably slower anyway though.

So yeah, I think we should allow changing the output mode.

Cutscene skip: Right, retaining inventory control is very useful in AitD as well for getting out of states where you don't have control. Indeed there is often just one frame when it works.

If you need to do something in the inventory but you time it so you're also just about to hit a door, you may be able to make the door open at the same time as doing something else (like dropping something). I don't think you ever dropped anything in the run. Also it might be frame-perfect. I don't remember.

Like I said, my experience with output modes is if I use the default one (which is really arbitrary; they're meant to be cosmetic), the game runs much much much slower in some parts (like 50% the regular speed) and doesn't really match what you would have expected when playing on an old computer. I never asked NHG which setting he used. The second thing is, SDA is more happy to accept any settings (that don't affect the category) when it's options that are available either in-game OR through an external config utility like the one used for changing graphics modes. It makes it feel more like those settings were meant to be changed. That's why it feels like the runner should be allowed to choose. Also it's a question of A/V quality: nobody wants to watch a run where a part of it runs at 50% speed. Of course that may not be the case here but still.

Actually I don't know how we'd feel if you chose a mode that actually puts the graphics through a filter of some kind. Not everyone is a fan of those kinds of graphics (including me most of the time). Those modes are probably slower anyway though.

So yeah, I think we should allow changing the output mode.

Cutscene skip: Right, retaining inventory control is very useful in AitD as well for getting out of states where you don't have control. Indeed there is often just one frame when it works.

If you need to do something in the inventory but you time it so you're also just about to hit a door, you may be able to make the door open at the same time as doing something else (like dropping something). I don't think you ever dropped anything in the run. Also it might be frame-perfect. I don't remember.

arnaud33200

2020-07-18 12:20:07 pm

Quote:

Indeed there is often just one frame when it works.

in this glitch it's super easy to get the right frame, just buffer the ENTER key by keeping the ENTER key down during while William is walking down the stairs.

Quote:

you may be able to make the door open at the same time as doing something else (like dropping something)

interesting! I will try that Smiley

Quote:

I don't think you ever dropped anything in the run

I do it for the follow the monk glitch and the plates in the kitchen with the 2 evil monks

tigrou

Edit history:

tigrou: 2021-07-14 12:49:17 pm

tigrou: 2020-07-19 09:22:45 am

tigrou: 2020-07-19 09:15:49 am

tigrou: 2020-07-19 07:38:17 am

tigrou: 2020-07-19 07:37:43 am

tigrou: 2020-07-19 07:06:20 am

tigrou: 2020-07-19 06:39:48 am

tigrou: 2020-07-19 06:19:27 am

tigrou: 2020-07-19 06:14:31 am

2020-07-18 02:38:02 pm

@LotBlind :
If I remember well, output=ddraw and shaking would increase your CPU usage a lot, is that right ?
I have tried on my machine and whatever output I use, I have 0% CPU usage for DOSBox with or without shaking (cycles = 11000)
Does it only happen when recording ?

LotBlind

2020-07-19 10:32:27 am

output: No, it happens without recording as well.

surface: all settings <1%
overlay and ddraw: still <1%, scroll and shake 16%
opengl and openglnb: still <1%, scroll and shake 2%

arnaud33200

2020-07-19 04:04:44 pm

I realized we can use this follow Berwal glitch more early in the game, right after doing the follow the monk glitch we can access to the tower.
We would be able to skip many part of the game (hospital, torture, cemetery, ...) and save more than 8 minutes!
But same, either I don't have the right items to continue the game properly or I'm getting blocked by a closed door.
I'm continuing to search for other possibilities, at this point we have access to many rooms.

I tried to open the door same times as doing something else but doesn't work :/
The door I try to open or go through is usually open by a trigger while pushing a cross.
I tried drop items, changing room to change the slot number of the door but no success
Maybe I can collect more items before entering this room?

LotBlind

2020-07-20 07:14:00 am

If it wasn't fixed, collision clipping requires three things that you're colliding with to have a lower slot than the one that you're trying to pass through. They can be any actors.

tigrou

Edit history:

tigrou: 2020-07-22 03:31:33 am

tigrou: 2020-07-22 03:31:07 am

tigrou: 2020-07-21 01:13:00 pm

tigrou: 2020-07-21 01:12:42 pm

tigrou: 2020-07-21 12:56:56 pm

tigrou: 2020-07-21 12:56:37 pm

tigrou: 2020-07-21 12:55:32 pm

tigrou: 2020-07-21 12:55:25 pm

tigrou: 2020-07-21 08:54:34 am

tigrou: 2020-07-20 01:44:50 pm

tigrou: 2020-07-20 01:44:40 pm

tigrou: 2020-07-20 01:24:30 pm

tigrou: 2020-07-20 01:24:13 pm

tigrou: 2020-07-20 01:23:16 pm

tigrou: 2020-07-20 01:13:13 pm

tigrou: 2020-07-20 01:12:55 pm

tigrou: 2020-07-20 01:12:46 pm

tigrou: 2020-07-20 01:12:31 pm

2020-07-20 01:04:40 pm

output/renderer : here is what I found out :

DOSBox is optimized in a way that it refresh display only when needed (not as fast as possible) and where needed (only lines that have changed since last frame). When you are playing AITD1, most pixels are static and game is far from running at fullspeed. DOSBOX will only refresh a small portion of the screen at a low frame rate.

When screen is shaking, since all pixels are moved every frame, this force the whole display to be refreshed as fast as possible (usually 70Hz, same as emulated VGA card). This is the worst case scenario.

@LotBlind : for a reason that I don't know, overlay/ddraw are slow on your machine (they use more CPU than what it supposed to be). Since shake put them on stress (as explained above) CPU usage is high. I have tried on an old laptop from 2009 (Intel Core 2 Duo SP9400) that does not have dedicated GPU (it use Intel GMA 4500 which is crap). CPU is always 0-2% regardless settings (static sv scroll vs shake). Something must be wrong on your side. Are video drivers up to date ?

EDIT : could you run this tool (press ignore if it ask to install direct play) and checks if you have DDSCAPS_OVERLAY
I suspect your video card does not have hardware support for it and so it runs overlay in software.

output/renderer : here is what I found out :

DOSBox is optimized in a way that it refresh display only when needed (not as fast as possible) and where needed (only lines that have changed since last frame). When you are playing AITD1, most pixels are static and game is far from running at fullspeed. DOSBOX will only refresh a small portion of the screen at a low frame rate.

When screen is shaking, since all pixels are moved every frame, this force the whole display to be refreshed as fast as possible (usually 70Hz, same as emulated VGA card). This is the worst case scenario.

@LotBlind : for a reason that I don't know, overlay/ddraw are slow on your machine (they use more CPU than what it supposed to be). Since shake put them on stress (as explained above) CPU usage is high. I have tried on an old laptop from 2009 (Intel Core 2 Duo SP9400) that does not have dedicated GPU (it use Intel GMA 4500 which is crap). CPU is always 0-2% regardless settings (static sv scroll vs shake). Something must be wrong on your side. Are video drivers up to date ?

EDIT : could you run this [url=http://www.tommti-systems.de/temp/DXCapsViewer.rar]tool[/url] (press ignore if it ask to install direct play) and checks if you have [url=https://i.imgur.com/LGNyaHU.png]DDSCAPS_OVERLAY[/url]
I suspect your video card does not have hardware support for it and so it runs overlay in software.