ZDoom

OK, on a second look at your post, I see what you were trying to say, but it unfortunately is not that easy. You could easily write in replacements for every actor in Decorate with their frame durations altered, but then you'd be asking ZDoom to replace every actor in the map with these new versions on the fly. That's just not something it's designed to do. Far easier in fact to just scale the existing frame durations at runtime, or play with the tic timer which is what Spidey's patch did.

Ok, before I go away, notice the part about "replaces", and Dehacked's specialty in doing so, also to states: in this case making all used frames take longer. I know normal Dehacked or Bex only have access to stock frames, and so on.

[quote="printz"]If I go too far with guesswork, just tell me to stop.[/quote]
Yeah, please do.

But instead of being an asshole and leaving it at that, I will tell you why your assumption was flawed:

.deh is nothing more than an old-school DECORATE file that replaced monsters and states instead of defining new ones. Its format was also drastically different, because it was created by a program that actually altered the compiled Doom binary directly (from Vanilla Doom, before the source code ever was released), instead of current day DECORATE that is easily editable by hand. In order to create a DEH file properly, you had to edit the options given to you directly by the program's interface, otherwise you would easily override something that you shouldn't and cause abnormal effects in gameplay. The reason for this was because you could only REPLACE existing frames and sprites and monsters or items - you could not create new ones.

So there's no such thing as a "turbo" or "slow-mo" .deh file - all it is is its redefining each of the monster states to allow the monsters to move at different speeds than what was defined before.

I don't have programming expertise on ZDoom, I don't. If I go too far with guesswork, just tell me to stop.

....


I don't think you have any idea what you're talking about.

Could DEH files be loaded dynamically? Or something equivalent that can affect all used frames instead of only creating thing types, like Decorate does? Because then, it would be very simple: just load a DEH file opposite to TURBO.DEH and you get slo-mo.

@Gez: Individual actors wouldn't need variable tic rates, and there's no need to change how often a DObject calls its Tick method. Instead, within that method, the object would check to see if it is being slowed and, if so, if the current tic is one that should be skipped based on the speed. If that's the case, all logic and movement is skipped for that actor this tic.

It's not as perfect as spidey's solution that actually adjusts the timer, but it should be a workable compromise.

// Variable game timer [BHS]
int TicAdjust;

int I_SetTicAdjust(int a)
{
  const min = -TICRATE+1; const max =  TICRATE*4;
  TicAdjust = (a < min ? min : (a > max ? max : a));
  return TicAdjust;
}
int I_GetTicAdjust() { return TicAdjust; }

//
// I_GetTime
// returns time in 1/35th second tics (adjusted by TicAdjust)
//

int I_GetTimePolled (bool saveMS)
{
  if (TicFrozen != 0)
  {
    return TicFrozen;
  }

  // cheap way to handle seizure-inducing effects of interpolation with adjusted tic count
  if (TicAdjust) { R_ResetViewInterpolation (); }
  
  DWORD tm = SDL_GetTicks();
  if (saveMS)
  {
    TicStart = tm;
    TicNext = Scale((Scale (tm, TICRATE + TicAdjust, 1000) + 1), 1000, TICRATE + TicAdjust);
  }
  DWORD r = Scale(tm - BaseTime, TICRATE + TicAdjust, 1000);
  
  return r;
} 

The main reason I'm not going to do a full patch -- bugs. I'd have to figure out why lowering the tic rate when the game clock isn't running causes the game to freeze. I'd have to fix the problem where speeding up the tic rate causes the player to be displaced (as seen in the video). I'd have to add netcode, test for bugs, etc. -- especially if this is ever meant to be more than a cheat. I didn't bother adapting the interpolation code either; it could probably fixed to work with adjustable tics but it was quicker just to disable it while tics are adjusted. If someone else wants to do all that stuff, though, this might be a good jumping off point.

[quote="Gez"]... Making the ticrate a variable is trivial; a search and replace can do most of the required work. ... [/quote]

Actually, I didn't even have to do that... I managed to leave TICRATE alone everywhere, and just modify the timer in i_system. I think this is pretty much everything I changed, besides the addition of a few ccmds to call I_SetTicAdjust and inclusion of r_main.h so I could turn off interpolation.

[code=php]// Variable game timer [BHS]
int TicAdjust;

int I_SetTicAdjust(int a)
{
  const min = -TICRATE+1; const max =  TICRATE*4;
  TicAdjust = (a < min ? min : (a > max ? max : a));
  return TicAdjust;
}
int I_GetTicAdjust() { return TicAdjust; }

//
// I_GetTime
// returns time in 1/35th second tics (adjusted by TicAdjust)
//

int I_GetTimePolled (bool saveMS)
{
  if (TicFrozen != 0)
  {
    return TicFrozen;
  }

  // cheap way to handle seizure-inducing effects of interpolation with adjusted tic count
  if (TicAdjust) { R_ResetViewInterpolation (); }
  
  DWORD tm = SDL_GetTicks();
  if (saveMS)
  {
    TicStart = tm;
    TicNext = Scale((Scale (tm, TICRATE + TicAdjust, 1000) + 1), 1000, TICRATE + TicAdjust);
  }
  DWORD r = Scale(tm - BaseTime, TICRATE + TicAdjust, 1000);
  
  return r;
} [/code]

[quote="SoulPriestess"] and using normal world physics would improve it greatly[/quote]


I doubt that very much. Technically perhaps but the screwy physics are one of the fundamental traits that make Doom what it is.

[quote="Gez"]The easiest way would be to ditch the entire simu, save and netgame codebase and rewrite it from the ground up. Definitely easier than hacking the existing code to make it do what it was never designed to do.[/quote]
If you think about it, that's not that hard. The only real thing that you would need that wouldn't make sense to make from scratch is the enemy code (since that's only executed once per object pointer) and existing actor definitions - as well as ACS, which can run on its own tic rate... but if you can make it choose its own tic rate then who cares?

Anyway, a game engine is nothing more than a renderer, some entity/actor definitions, some physics code, controllers (Human and AI), and something to tie it all together. With this, Doom can be rewritten from the ground up a little more easily than most people would say. The physics code is grade-school - and using normal world physics would improve it greatly, the renderer is already there - although it's an overwhelming clusterfuck, it can still be used - BSP nodes and all.

However, a prospect such as this would probably require a branch away from ZDoom proper - because since ZDoom aims to be compatible with previous mods, the change proposed here might be too drastic and may cause some mods to fail, especially those that depended on the old code.

And before any of you start saying "that's impossible, she doesn't know what she's talking about," I've made games with merely a 1GHz Athlon and QuickBasic. The renderer code would be the biggest obstacle, and there's nothing to stop the use of the one that's already in place - or even making a new one.

Save/load? No problem. Demos? Write the net code - they go hand in hand.

[quote="HotWax"]How many times does someone need to provide code patches that accomplish the "impossible" 10 minutes after someone says it's impossible before someone gets the hint?[/quote]
I didn't say it was impossible, I said it needed to massively rewrite the engine code.


The engine is written so as to have the same ticrate for everything. Actors, scripts, and so on. Every DObject calls Tick() every tic. For what you want, DObject needs to be given a variable corresponding to its own ticrate, and the engine needs to sort the DObjects by their ticrate so as to activate them at the proper time.

Making the ticrate a variable is trivial; a search and replace can do most of the required work. Giving each object its own ticrate -- basically what is needed to have some monsters affected by slomo and some not -- is definitely not that easy since the design must be rethought at a fundamental level.


Let's not forget that, as well as the core simulation system (making stuff move and react), you'd have to rewrite the save/reload code, the demo code, and the netcode too, since they too make assumptions about the ticrate. With a variable, but universal, ticrate, you can still have the savegame and demo work -- great for tool-assisted demos. The netcode should still work as well if every computer keeps using the same ticrate, so there's just some synch code to add there. (Might also want to serialize the ticrate in the savegame code, by the way. All that isn't hard.) It's pretty much useless, IMO, but it's easy.

Making it variable on an object-basis? Now that's a clusterfuck in the making. The easiest way would be to ditch the entire simu, save and netgame codebase and rewrite it from the ground up. Definitely easier than hacking the existing code to make it do what it was never designed to do.

[quote="Gez"][quote="Ghastly_dragon"]Could a flag be added that makes the actor immune to slow-motion? It could also be applied to the player with the powerup, like CantSeek.[/quote]
No, because what Spidey did applies to EVERYTHING. He made it so that the ticrate is a variable, rather than a constant. There is no way of having different ticrates for different actors, though, save from rewriting the whole engine with this design spec in mind.[/quote]
How many times does someone need to provide code patches that accomplish the "impossible" 10 minutes after someone says it's impossible before someone gets the hint?

I'm not suggesting this would be trivial. Quite the opposite. That doesn't mean it's impossible. One method of accomplishing it that I can think of off the top of my head is to stay at the full 35 tics but have the monster AI routines skip every other tic (for 50% speed; more/less depending on scale). This would allow the player and items and whatever else to operate at normal speed while the monsters seem to move and react more slowly. There would be difficulties with this, such as script timing and the like, but I don't think it would be anything insurmountable.

In coding, it's never a matter of what [i]can't[/i] be done, it's simply how difficult it would be and whether someone with the know-how has the time and desire to do it.

[quote="HotWax"]Exactly as I expected. A bit choppier, but not so choppy that it's crippling unless you go for some ridiculous value like 1 tic-per-second.

Now the [i]real[/i] challenge would be making the player move at normal speed while the enemies move in slo-mo.[/quote]
Giving the player slow-mo like that already grants him the benefit of a faster reaction time versus enemies.

[quote="Ghastly_dragon"]Could a flag be added that makes the actor immune to slow-motion? It could also be applied to the player with the powerup, like CantSeek.[/quote]
No.

No, because what Spidey did applies to EVERYTHING. He made it so that the ticrate is a variable, rather than a constant. There is no way of having different ticrates for different actors, though, save from rewriting the whole engine with this design spec in mind.

And that is why I think that this feature is funny 10 minutes, and never used anymore once the novelty wears off.

I've never been so happy about the prospect of throwing out a gross DECORATE/ACS hack before.