Hype: The Time Quest Widescreen

[lk19]

You can drag-drop the game exe onto the wide-screen fix exe.

Yes this should work. But keep in mind, that you won't see any error messages / success messages then, because cmd closes as soon as the script terminates.
Alternatively, open cmd (do NOT double-click on widescreen_fix.exe) and navigate to the folder where widescreen_fix.exe resides (in cmd you do this using "cd"). Btw. here's a little life-hack that I learned way too late: If you open a folder in windows explorer and simply type "cmd" into the address bar, the command prompt will open DIRECTLY IN THAT FOLDER!
Once you have navigated to the correct folder, type "widescreen_fix.exe C:\Games\Hype\MaiDFXvr_bleu.exe" (or wherever your game is installed).

[PluMGMK]

If you open a folder in windows explorer and simply type "cmd" into the address bar, the command prompt will open DIRECTLY IN THAT FOLDER!

I never knew that! But I did know that you can Shift+Rightclick on a folder to get an "Open command window here" option!

[lk19]

I never knew that! But I did know that you can Shift+Rightclick on a folder to get an "Open command window here" option!

Nope, didn't know that Thanks! Though for me this only opens the Windows PowerShell. But who needs cmd anyway

[Thunder5torM]

lk19, i have other questions for you:

1- My version of the game by selecting New Game or Load Game aks for (original or virtual) CD.
The V3 widescreen fix you posted no: the game starts without: how you fixed that?

2- Like you writed in Readme of your V4 fix it's difficult to fix the game HUD (circle of weapons)?

[lk19]

1- My version of the game by selecting New Game or Load Game aks for (original or virtual) CD.
The V3 widescreen fix you posted no: the game starts without: how you fixed that?

As I mentioned in the readme, you need a no-cd-patched EXE-file to start with. The one that is available on the nGlide website is already patched and is known to work with both the English and the German version of the game (but e.g. not with the Spanish version). You can use that as a starting point for my patcher if it works for you.
It's weird that you seem to be able to start the game with your original EXE, and it only asks for the CD when you want to want to select "New Game" or "Load Save". All versions I know use SafeDisc copy protection, which should not even let you run the .exe in the first place (unless you are using Windows Vista or earlier and have the original CD in your disk drive).

2- Like you writed in Readme of your V4 fix it's difficult to fix the game HUD (circle of weapons)?

I don't quite understand your question. The placement of some HUD-elements (especially what I call the "MP-cirlce"... the thing around the spell-icon that indicates how much magic usage you have left) was difficullt to fix, but I hacked the code to make it look more or less right (except for the inventory screen, but that shouldn't be very noticable).

[deton24]

It's only about HUD positioning? Not textures being stretched?
In widescreen fixes for Rayman 2 we used to edit textures manually (in cnt archives - maybe they're editable via Rayman Control Panel) but maybe something has changed since then and there was some scaling factor found in binary.

[PluMGMK]

I never knew that! But I did know that you can Shift+Rightclick on a folder to get an "Open command window here" option!

Nope, didn't know that Thanks! Though for me this only opens the Windows PowerShell. But who needs cmd anyway

Ah yes, it replaces that option with a PowerShell one if you have that installed, which I guess everyone does now…

Yes this should work. But keep in mind, that you won't see any error messages / success messages then, because cmd closes as soon as the script terminates.

I guess you could add a "Press any key to exit" message to the end of the script?

[lk19]

It's only about HUD positioning? Not textures being stretched?
In widescreen fixes for Rayman 2 we used to edit textures manually (in cnt archives - maybe they're editable via Rayman Control Panel) but maybe something has changed since then and there was some scaling factor found in binary.

Well - yes - the 2D-HUD-elements also get stretched. But for me it's really not that big of a deal and right now I have no way of fixing it. In fact I haven't been able to do anything to he 2D-HUD-elements. I only fixed the position of the "MP-Circle" which - for some reason - is a 3D-element. One of the main reasons I left the game's internal x-resolution at 640 is because increasing it messes around with the positioning of the 2D-HUD-elements
I guess editing textures could be a way to do it. But I don't even know if Hype's CNT-files have the same format as Rayman2's

[lk19]

I guess you could add a "Press any key to exit" message to the end of the script?

Good Idea. If/when I make a new version of the patch (maybe incorporating the 60 FPS patch), I will add this. Thanks

[Crash267]

This game is looks cool is their any bosses in this game

[AlphaYellow]

Couldn't you figure out how to make this fix work with the D3D .EXE as well? The .EXE doesn't even seem to work, but I remember back in the days it used to work, maybe there is a bad code somewhere on it, probably something to do with SafeDisc, or maybe not. I'm just saying because with D3D, you get more advanced texture filtering like 16x AF which makes any game look WAY better, as you can see sharp textures much further ahead, rather than Glide's limited bilinear filtering, which is very distracting imo.

[lk19]

Couldn't you figure out how to make this fix work with the D3D .EXE as well? The .EXE doesn't even seem to work, but I remember back in the days it used to work, maybe there is a bad code somewhere on it, probably something to do with SafeDisc, or maybe not. I'm just saying because with D3D, you get more advanced texture filtering like 16x AF which makes any game look WAY better, as you can see sharp textures much further ahead, rather than Glide's limited bilinear filtering, which is very distracting imo.

Yeah, should be possible. And as your are saying - first step is to remove the SafeDisc copy protection (I think there are tools available for this).
Then it's a matter of searching all the relevant code in the other .exe file.. probably a lot of work - but definitely possible in my opinion. I might have a look at it, if I can find enough motivation

[AlphaYellow]

Take your time mate, hope it can be done something about it, if not, the Glide version works just fine too. I just finished recording a full walkthrough using your fixes and didn't have any issues at all at 1080p and solid 60 fps, even with the higher framerate of 60, everything ran smoothly and without any issues I'll post here the link as soon as it's up. I wonder if you could do a fix like this for Laura's Happy Adventures and Alex Builds His Farm as well, so the entire Playmobil game collection would be in widescreen and 60 fps!

[lk19]

Take your time mate, hope it can be done something about it, if not, the Glide version works just fine too. I just finished recording a full walkthrough using your fixes and didn't have any issues at all at 1080p and solid 60 fps, even with the higher framerate of 60, everything ran smoothly and without any issues I'll post here the link as soon as it's up. I wonder if you could do a fix like this for Laura's Happy Adventures and Alex Builds His Farm as well, so the entire Playmobil game collection would be in widescreen and 60 fps!

I finally did some work on the Direct3D EXE Disclaimer: This is not (yet) a widescreen or FPS-fix for the game! It is merely a different (and probably more flexible) way of running the game on modern computers.

The first step was to get an overview over the different versions of the game's EXE that exist. Even though I know there are possibly more versions (e.g. the Spanish EXE), I would like to distinguish the following 5 versions of the Hype executable:

• MaiD3Dvr_bleu.exe "V1" : The original Direct3D executable (dated Oct 29, 1999) that shipped e.g. with the English, French and German release of the game. I decrypted the SafeDisc-encrypted files of all three localized releases of the game and they are indeed completely identical!
• MaiDFXvr_bleu.exe "V1": The original Glide executable (dated Oct 29, 1999).
• MaiD3Dvr_bleu.exe "V2" : Dated Jan 26, 2000. This is from an official patch by UbiSoft, which – according to the readme – "corrects the Voodoo3 issues and some graphical D3D issues". The patch also came with a bunch of other replacement files (e.g. DLL-files), but as far as I can tell, they are only needed for SafeDisc to work (which doesn't work on modern Windows anyway) and none of them are needed if you are playing the game without the CD. In fact, you could remove all of them and the game will still run just as well. I do not know exactly what they changed from "V1". So far, I have only noticed a very subtle difference when it comes to video playback (see below).
• MaiDFXvr_bleu.exe "V2" : Dated Jan 26, 2000. Same as MaiD3Dvr_bleu.exe "V2", but for Glide.
• MaiDFXvr_bleu.exe "nGlide" : I call this the "nGlide" version, because it is available on the nGlide website. This is the version I have been using as a basis for my previous widescreen fixes! It already has the SafeDisc encryption removed and is patched so that the game runs without the disc in the drive.

In order to get the Direct3D version of the game to run, I first wanted to understand how exactly the "nGlide" EXE has been altered so that the game runs on modern systems. A quick comparison of the sizes of the decrypted EXEs showed me that the "nGlide" EXE is in fact based on the original "V1" of MaiD3Dvr_bleu.exe and not on the newer patch by UbiSoft. I then ran both of them through a decompiler and compared them byte by byte in order to determine the differences. Turns out that they are almost identical except for a few changes:

1. CD checks have been removed at 8 different places in the code.
2. The game no longer looks for ubi.ini in <WindowsFolder>\UbiSoft\, but instead expects it to be in <GameFolder>\UbiSoft\. This makes the game more "portable". Relevant code has been replaced in 3 different places.
3. A string has been changed from "%c:\GameData\World\Levels\fix.cnt" to ".\GameData\World\Levels\fix.cnt". This apparently has no impact since the game works either way.
4. A hard-coded floating point number in a function has been changed from 1.2 to 2.0. I have no idea what this function does, but I attached the debugger to it and played the game for a while. The code in question never got executed, so I guess it's not really important.

Since I figured that changes 3 & 4 were not important, I tried to apply 1 & 2 to the Direct3d EXE. In fact, I wrote a little Python-script that takes any version of the EXE (with SafeDisc encryption already removed) and implements changes 1 & 2 mentioned above.
This way, I got all four versions (D3D "V1" and "V2" as well as DFX "V1" and "V2") to work on my computer (using an appropriate wrapper for Glide / old DirectX)

Attached below, you can find the patched MaiD3Dvr_bleu.exe "V2" , in case you want to try it out yourself. Since the game is based on an old DirectX version, you will have to use a Direct3D-wrapper in order to run the game (much like the Glide-wrapper needed for the Glide version). Several ones will work, but I will once again recommend dgVoodoo2 (which – despite its name – is not only a Glide wrapper but also a Direct3D-wrapper). Simply copy the files DDraw.dll and D3DImm.dll from the folder MS\x86\ and dgVoodoo.conf and dgVoodooCpl.exe from the main directy to your Hype directory. Use dgVoodooCpl.exe to adjust the setting. Important: Under the "DirectX" tab, set "VideoCard" to "ATI Radeon 8500". Otherwise there will be graphical glitches as you can see in the screenshot below.

Hype_Graphics_Glitch.png (75.91 KiB) Viewed 1939 times

There are two additional things I would like to mention:

Video playback: Inside game window vs. child window
During my testing I found a little curiosity, which is the only difference between the different EXE versions ("V1" and "V2") I have found so far. In the config file ubi.ini, there is an option to determine wether the video files should play inside the game's main window or in a separate child window. If it is not already there, you have to add the line "ForceVideoMode=" under the [Hype - The Time Quest] section of ubi.ini. From debugging the EXE files, I know it can have three different values, whose behavior – strangely enough – depends on the version of the EXE.
ForceVideoMode=Default (or simply leaving out the line) : Always plays the videos inside the game's main window
ForceVideoMode=ChildWindow : Always plays the videos in a separate child window.
ForceVideoMode=DXMedia : Plays the video inside the main window for V1 of the EXEs (both Glide and D3D) and play the video in a separate window for V2... very strange!

How to fix problems with video playback / crash on startup:
The game only has three video-cutscenes: the logo (LOGO.AVI), the intro (HypeIntro.avi) and the outro (HypeConclusion.avi). They are all encoded using the Indeo-50 codec, which was quite common at the time. However, due to security concerns, Microsoft disabled the codec on modern Windows systems. The Glide version of the game (MaiDFXvr_bleu.exe) seems to have its own built-in decoder, so the videos still run fine. The Direct3D version (MaiD3Dvr_bleu.exe) on the other hand, relies on Windows functionality to play the videos. Depending on whether you run the videos inside the game-window or in a child-window (see previous section for details), you will either get only sound – no picture – or the game will crash. Either way, there are three ways to fix this:

• Method 1 (not really a fix, but prevents crashing): Turn off video playback by setting PlayVideo=0 in ubi.ini. Recall that ubi.ini must be placed in <GameFolder>\UbiSoft\ and NOT <WindowsFolder>\UbiSoft\, since we specifically patched the EXE to look for the ini-file in the game folder and not the windows folder!
• Method 2 (recommended): Convert the video files to use the Cinepak codec instead of Indeo-50. It works fine with both MaiD3Dvr_bleu.exe and MaiDFXvr_bleu.exe, and the codec is not disabled on modern Windows systems! In order to do this, download ffmpeg and run

  Code: Select all

  ffmpeg -i "OLD_FILE.avi" -c:a copy -c:v cinepak "NEW_FILE.avi"

  to convert the AVI-file. Note that Cinepak encoding is VERY SLOW, even on modern systems. Fortunately this only has to be done once I considererd providing the converted video files as a download, but then it occured to me that it would have to be done separately for every language...
• Method 3 (not recommended): Register the Indeo Video Codec following the instructions on https://www.pcgamingwiki.com/wiki/Windows (search the page for "Indeo"). Due to security issues, make sure to unregister the codec after playing the game (instructions are on the same page)!

Next step is to get the Widescreen and FPS fixes running on the Direct3D EXE

[Thunder5torM]

Hi lk19 and thanks for your job!
Thank you for writing such interesting and detailed information!

So in your Glide version are you able to see videos ingame?
I disabled them (PlayVideo=0) otherwise the game crashes.
As you will remember I'm a Win7 user: could be this the problem?

I also want to say that in my D3D starting the game 10 times, 4 times
i can see ingame videos: other times: audio only.

Also: this is my D3D version I've patched time ago for the 60 FPS:
https://www.mediafire.com/file/1akwphfu ... u.rar/file

[lk19]

Hi lk19 and thanks for your job!
Thank you for writing such interesting and detailed information!

So in your Glide version are you able to see videos ingame?
I disabled them (PlayVideo=0) otherwise the game crashes.
As you will remember I'm a Win7 user: could be this the problem?

I also want to say that in my D3D starting the game 10 times, 4 times
i can see ingame videos: other times: audio only.

Also: this is my D3D version I've patched time ago for the 60 FPS:
https://www.mediafire.com/file/1akwphfu ... u.rar/file

Yes, the Glide version plays the videos just fine. I am pretty sure that with Windows 10, the Problem is with the Indeo-Codec, since this is a known issue. Why with your D3D version on Windows 7 the video sometimes plays, and sometimes not... I don't know! Have you played around with the "ForceVideoMode=" parameter in ubi.ini? Remember that your ubi.ini should probably be placed in <WindowsDirectory>\UbiSoft, because your EXE is probably not patched to look for it in the game directory.

I plan to release a new version of the patch, based on the D3D-EXE, soon. Widescreen fix and FPS fix is already working, I just need to put everything together I will probably also provide a tool to patch the original EXE (works with both Glide and D3D) to work on modern systems (i.e. removing CD checks and searching for Ubi.ini in the game directory rather than the Windows directory). This way, people with other versions that do not work with the "standard" EXE (e.g. the Spanish version) can create their own EXE to use the widescreen fix on. All you have to provide is the EXE from your original copy of the game with SafeDisc encryption already removed (there are several tools available for this).
I will also make the process of patching the SNA-file to change the FOV (and the notrious wrong-FOV-after-time-travelling bug) easier, so you do not have to patch 9 different files separately anymore.

[lk19]

On a different note: I finally figured out, why the game usually runs at 48 FPS (which at first glance seems like an odd choice).

As I mentioned before, the game was originally supposed to run at 50 FPS. The timer in this game is based on milliseconds. The way it works is that it renders a new frame every ceil(1000/RefreshRate) milliseconds, where ceil() denotes the ceiling function, which rounds a decimal number x to the next integer greater than or equal to x.

Therefore, when you manually set the RefreshRate to 60, a new frame is rendered every ceil(1000/60) = ceil(16.67) = 17 milliseconds. This results in a framerate of 1000/17 ≈ 59 FPS. Setting the RefreshRate to 61 or 62 results in exactly the same actual framerate of only 59 FPS. Only setting the RefreshRate to 63 or greater results in a stable framerate above 60 FPS.

Now in theory, setting the RefreshRate paramter to 50 should result in a framerate of exactly 50 FPS since 1000 is evenly divisible by 50. However, whenever 1000 is an exact multiple of the RefreshRate, some tests have shown that rendering a new frame takes a millisecond longer than intended. This is either due to poor implementation or due to the timer not being 100% accurate.

For this reason, a new frame is not rendered every 1000/50 = 20 milliseconds, but instead every 21 milliseconds, which results in a framerate of 1000/21 = 47.62 ≈ 48 FPS.

[PluMGMK]

Ah, nice one figuring that out! It sounds somewhat familiar…

[lk19]

Ah, nice one figuring that out! It sounds somewhat familiar…

Haha, didn't know this already came up in a diffrent context . Turns out I wasn't quite right about the assumption with the ceiling function. In fact, the correct behavior is that a new frame is rendered every floor(1000/RefreshRate) + 1 milliseconds (where floor rounds the number DOWN). Here is the relevant part of the code (decompiled with GHIDRA):

Line 87 reads the current value of the game's timer in milliseconds (which is stored as an INTEGER).
Lines 88-93 subtract the value of the timer when the last frame was rendered (highlighted in red). In fact, only line 92 is relevant, but it looks like someone coded in an absolute value just to be safe.
Line 96 then checks if the number of milliseconds since the last frame was rendered (in yellow) is less than 1000/RefreshRate (in green). Since we have a fast computer, this is always the case (unless you set the refresh rate insanely high or pause the game), and thus the following lines are executed:
Line 97 converts the result of 1000/RefreshRate (green) to an integer by rounding it DOWN (_ftol() just truncates the decimal part).
Line 98 tells the thread to wait for floor(1000/RefreshRate) - NumberOfMillisecondsSinceLastFrameWasRendered.

Now in theory, this should lead to a new frame being rendered every floor(1000/RefreshRate) milliseconds. However, CPUs have clock speeds MUCH faster than 1 operation per milliseconds. Therefore, the game must have some logic to sync the actual CPU timing to the in-game timer (which only works in milliseconds). My guess is that this is where the extra + 1 millisecond comes from.. but that is only speculation

[lk19]

I found the reason why the game speeds up when you set the framerate too high. I thought this was a little weird, since the game's speed (i.e. how fast you run, how fast the animations play etc.) feels roughly the same if you set the framerate to 20 FPS compared to when you set it to 60 FPS. However, if you set the framerate much higher (e.g. 100 FPS), the game is noticably sped up!

First of all, the game's internal clock is based on the actual framerate, not on the value of RefreshRate (as I call it) that you set in the EXE. So you can set the value as high as you want as long as you limit the framerate externally (e.g. by activating vsync in dgvoodoo).
Secondly, the game often doesn't measure its framerate in frames per second (although the target RefreshRate value that you set can set in the EXE is measured in FPS), but in how many milliseconds it takes to render a frame. When it comes to the game's clock (which determines running speed, animation speed etc.), the game has a built-in floor value of 16 milliseconds per frame (~62.5 FPS) and a cap of 80 milliseconds per frame (~12.5 FPS). This means that if the actual framerate drops below 12.5 FPS, the game will slow down, and if it gets over 62.5 FPS, the game will speed up. It was, however, not difficult to find these values (16 and 80) in the code (see screenshot) and therefore disable the 62.5 FPS cap (or rather the 16 milliseconds per frame floor). I think I will include this hack as an optional, experimental feature in the next version of the widescreen fix + FPS fix

Ghidra_Screenshot.png (5.04 KiB) Viewed 1818 times