Hi! So I decided to play Hype once again, and I was wondering if it was possible to play it in widescreen mode. So I picked up where this thread ended, and tried to figure out things for myself.
I think I have made some substantial progress, and I will take some time to explain the technical details, in case anyone wants to expand on my work. Also, I apologize in advance, if some of my solutions don't seem very elegant. This is the first time I've ever done any disassembly or debugging.
First of all, I started with the modified MaiDFXvr_bleu.exe from the nGlide website (
http://www.zeus-software.com/files/ngli ... _patch.zip). I used nGlide as a Glide wrapper for reasons that will become apparent later on (and because it works rather nice with Hype).
The first location, where the resolution is set is really not that important to us. As far as I can tell, it mainly affects a few "if" conditions later on. We'll leave them unchanged. Anyway, let's give them a name:
InitResY = 480 : Address 00406612 (integer, 4 bytes)
InitResX = 640 : Address 00406617 (integer, 4 bytes)
The next location (starting from Adress 0049D3D4) is, where the Glide rendering window is created. This can be divided into three cases, depending on InitResX:
Case 1: If
InitResX ≥ 800, then create a 800x600 window (Mode=8)
Case 2: If 800 >
InitResX ≥ 640, then create a 640x480 window (Mode=7)
Case 3: If
InitResX < 640, then create a 512x384 window (Mode=3)
Now you might be wondering, what the "modes" mean. Glide actually uses pre-defined resolutions (see first post here:
http://www.zeus-software.com/forum/view ... f=11&t=813). Unfortunately none of them are widescreen.. more on that in a bit.
After that, the game decides what the actual resolution of the action inside the window is. This is also nested into a similar distinction of cases as before. Since we are always in case 2, I will only name these values here:
RealResX = 640 : Address 00475621 (integer, 4 bytes)
RealResY = 480 : Address 0047562B (integer, 4 bytes)
If the real resolution is larger than the render window, it will crop the image, if it is smaller, then Glide will add black bars. These black bars are part of the render window and DO NOT get stretched out by nGlide (this is the problem that Automaniak005 successfully fixed using SWRU).
Here is where a nice change to the Glide API, done by the creator of nGlide, comes in handy (see the previous post with the resolution modes for details): Instead of passing a 1 byte integer to Glide, one can instead pass a custom resolution represented by a 4 byte integer! All you have to do is concatenate the two 2 byte integers representing the y- and x-resolution. So if, e.g., we want 640x360, we can simply pass Mode=0x01680280 instead of Mode=0x07 to the glide API! I decided to keep the x-resolution at 640 (the resolution can be set to your screen's resolution in the nGlide configurator anyway), because changing it to anything else messes with the position of the numbers on screen (i.e. the number of arrows, or any numbers in the inventory), rather than just messing with the position of the MP-circle (which always happens when changing resolutions). In case 2, the byte defining the video-mode is found at address 0049D41B. Since you cannot simply replace 1 byte with 4 bytes in a binary file, here's what I did:
I replaced the instruction to push 0x07 with a jump into the "NOPs" block after the current function. Unfortunately, this was too far away for a near jump, so I had to use a short jump. This meant that I also had to remove the following function call. Then, after the jump, I pushed 0x01680280. Now there weren't enough NOPs left, to re-insert the function call that we deleted AND jump back. So I inserted another jump to the NOPs-block right before the current function. There I re-inserted the deleted function call and then jumped back to where we were. I know this sounds kind of hacky, but I didn't know any other way of doing it. Anyway - the 4 bytes that ultimately determine the size of the render window are now at address 0049d516! Also I changed
RealResY to 360.
At this point, we almost have a fully working widescreen solution, except that the FOV is too small and the MP-circle's vertical placement is wrong: it is positioned too low so that you can only see a few pixels of it, but most of it is offscreen. Bear in mind though, that the horizontal position of the MP-circle is correct! This will be important later on.
Now for the FOV-fixes: I actually made two versions of it (just like the Rayman 2 fixes):
Version 1 (glitchy, disappearing objects at the edges):
This is just the idea that Manu270891 suggested in the initial post: At address 005c1108 there is a float (4 bytes) with value 1.0. Simply change this to 0.75! Interestingly enough, there is also a double (8 bytes) at 005c1110
that seems to do exactly the same thing. You can even combine them!
Note that this solution actually fixes the vertical placement of the MP-circle, but messes up the horizontal position. I did find a hack to move the MP-circle by a fixed amount, but with that I can only align it for one of the three magic types. Due to the 2D HUD-elements being stretched, it doesn't fit for the other two. In the end, I decided to leave it as it is, because at least it is onscreen and within the HUD region, so it doesn't obstruct the gameplay.
Version 2 (no glitches,
Update: I managed to change the FOV permanently without editing fix.sna. See my latest post! but requires Cheat Engine,
at least until someone figures out how to unpack and, more importantly, re-pack the file fix.sna ):
Doing a lot of debugging with Cheat Engine, I actually managed to find the FOV value in the memory that you can use to obtain non-glitchy widescreen mode! Turns out that for Hype its default value is 1.5 rather than 1.2 (Rayman 2). I will describe how to find it at the end of this section. Now everything would be perfect, if it wasn't for the MP-circle being offscreen. Remember how I told you that at least its horizontal placement was correct.. we can now actually use a hack to move it up by a fixed amount and even stretch it, so that it fits all three magic symbols perfectly! The function that draws the MP-circle (which btw. is a 3D object) starts at address 00439e50. The referenced values that it uses to compute the position of the circle are all shared with other functions, so that changing them messes up other parts of the HUD. Therefore, I replaced the references with references to the next NOPs-block and defined new values there. They are:
MPverticalShift = -53.0 : Address 0043a345 (float, 4 bytes)
MPstretch = 15.0 : Address 0043a349 (float, 4 bytes)
Play around with them if you don't think the circle fits the magic symbols perfectly yet.
For the Rayman 2 FOV value, I found out (although this was probably already known) that it gets written into the game's memory at the very first loading screen. The original value can be found in the file fix.sna. So if you decode that file (using one of the tools available in this forum) change the FOV value in there (file-offset 13670 btw.), and then encode it again, you get a permanent non-glitchy FOV fix without the need for Cheat Engine. I would love to have the same for Hype, but its fix.sna uses a different format. It seems it is packed, rather than encoded. Raymap already comes with an unpacker for Hype's files, so I just loaded the game into Raymap and it created a fix.dmp for me. In this unpacked fix.sna, I already identified the FOV value. Unfortunately, I have no means of re-packing it, and my programming skills are not good enough to write a re-packer myself based on the Raymap code.
So any help here would be appreciated 
Finally, here's the byte sequence to look out for in Cheat Engine:
00 00 C0 3F 01 00 00 00 00 00 00 00 00 00 00 00 01 00 00 00 FF 00 00 00
If you get several results, use the first! The good thing is that this value gets loaded into memory at the very start of the game and then isn't changed. If you edit it in Cheat Engine, you will only see the effect after the next loading screen (just load a save). Now we can change 00 00 C0 3F (=1.5) to a new FOV value. I think the formula is 2*ATAN(TAN(1.5/2)*3/4*r), where r is the desired aspect ratio. So for r=16/9, I get 1.786, which seems to yield the same FOV as the glitchy version of the FOV fix.
So that's it. I attached the two versions of the widescreen fix I created (unfortunately only 16:9 so far)
A few notes:
- If your game crashes regularly, try selecting the Vulkan renderer in nGlide, rather than DirectX. For me, using DirectX, the game crashed very often (almost unplayable), but with Vulkan, it never crashed once! Another advantage of Vulkan is that you can use Alt+Return to activate window mode, and then actually Alt+Tab out of the game without it crashing! Unfortunatly, the notorious Windows 10 update to version 2004 seems to break this functionality (the screen freezes, when you try to Alt+Tab).
- If you need to turn off the videos (for me they play just fine), but changing ubi.ini in \Windows\UbiSoft doesn't do anything for you, try creating a folder UbiSoft in the Hype folder and move ubi.ini there (this worked for me). However, the dll files in \Windows\UbiSoft are still required at this place in order for the game to start properly.
)