Rayman Pirate-Community

Hi! I would like to play Hype: The Time Quest on widescreen. Just like Rayman 2 and Tonic Trouble, Hype: The Time Quest is another title based on the UbiSoft OpenSpace engine and it was released after those two games. These are the three main differences:
1- It only runs at 640x480, there isn't any resolution selector ingame or the launcher. This issue can be solved through dgVoodoo, but only for 4:3 resolutions.
2- It has two exe files, one for the DirectX renderer ("MaiD3Dvr_bleu.exe") and another for the Glide renderer ("MaiDFXvr_bleu.exe").
3- These exe files are different for each version of the game (I own the Spanish version, and the exe files aren't the same for the English version).

I already managed to modify the FOV for the no-cd patched spanish exe files (both DirectX and Glide), it works just like the Tonic Trouble Fix:
1- Find the third match on the DirectX exe or the fourth match on the Glide exe for "0000003F 0000803F".
2- Replace it with:
a) 5:4 -> "8888883F".
b) 25:16 -> "0E745A3F".
c) 16:10 -> "5555553F".
d) 15:9 -> "0000503F".
e) 16:9 -> "0000403F".
f) ~21:9 -> "0000103F".
Original FOV:

Modified FOV (16:9):


Unfortunately, I can't modify the resolution ingame to another one that matches the correct aspect ratio (like the Tonic Trouble fix) or distort the image stretching it vertically so the Wrapper stretches horizontally it again (like the Rayman 2 fix). Considering the game runs at 640x480, the hex string for this resolution should contain "80020000" (640) and "E0010000" (480). For value conversion I used Cryptii. I managed to find a Hex String that appears to modify the aspect ratio for the DirectX renderer exe. Modifying this hex string makes the game crash at the initial UbiSoft logo, but the logo looks stretched, covering the whole monitor instead of just the 4:3 portion of it:
1- Find the first match on the DirectX exe for "E0010000 68 80020000".
2- For 16:9, replace it with "D0020000 68 00050000".
a) "D0020000" means 720 and "00050000" means 1280. 1280x720 is the smallest standard 16:9 resolution, upscaling on old games should always be done through dgVoodoo to maintain the HUD size.
3- For other aspect ratios, use Cryptii to find the correct values, always using the smallest resolution.
4:3, doesn't crash:

16:9, crashes:


Could anyone help me finish this fix? Considering other OpenSpace engine games have Vert- behavior with resolutions with wider aspect ratios than 4:3, the FOV fix should be enough, just like this:



Thanks everyone!

Am I correct in assuming all you have left is to stretch the game to widescreeen? If so, DgVoodoo has that option.

RayCarrot wrote: Tue Apr 28, 2020 2:02 pm Am I correct in assuming all you have left is to stretch the game to widescreeen? If so, DgVoodoo has that option.

No. The Rayman 2 fix works this way. First, the image is strectched vertically editing 0000B905 offset. Then, the wrapper (dgVoodoo/nGlide) stretches the image horizontally, so you get a Vert- Image. Then, the FOV is edited with the 0009C498 offset, which gives a perfect Hor+ widescreen image. I need the offset to vertically stretch the game, so then the wrapper stretches horizontally again, because I already have the offset for the Hor+ fix.

Can you try to post your thread here?
https://www.wsgf.org/phpBB3/viewforum.php?f=64

Maybe they will find out something yet.

I've contacted with Automaniak005 who is a Polish YouTuber specialized also in making widescreen mods.
That's what I just got from him:

Once again I've looked into this game, and somehow I managed to get to the proportion, but the result is not entirely satisfactory.

https://www2.zippyshare.com/v/KfLoIWQT/file.html

The highest resolution that Hype supports in Glide mode is 800x600.
D3D mode did not start at all, and Glide mode started to work after downloading that patch:
http://www.zeus-software.com/files/ngli ... _patch.zip
so without upscaling you cannot do that.

Someone could say that I just set 800x450 (16:9) in this zippyshare file - except that Glide, as a driver, supports a limited amount of resolution, so the game starts in a 800x600 window with a large black band at the bottom.

Therefore, you need to start the game in a 4:3 window so that the black bottom of the window does not fit the screen. Here, dgVoodoo will be useful.
There, of course, you should set the window mode, and the best scaling method in this case is Stretched, keep 4:3 Aspect Ratio if you want to play movie cutscenes in the original proportions (but then we need to copy also the ddraw.dll from the dgVoodoo's "MS" folder, because cutscenes are played in DirectX mode).

In the Glide tab, enter a resolution with a 4:3 aspect ratio, which width will be the same as our target resolution (e.g. I want to set 1920x1080, I enter 1920x1440). This step is best done at the end before closing the dgVoodoo configurator, because the program can automatically erase the entered resolution.

Before starting the game you will need a program that (if possible) forces the positions and dimensions of the windows to cover the border and perfectly set the image of the game. I use Scott's Window Resizing Utility http://www.scottandmichelle.net/scott/program/swru.html

After starting the game, we open the program, look for a process called H, and we use the trial and error method to determine negative coordinates that will allow to adjust the window accordingly. At first, the window may resist the changes made, but after a few position changes, we should take control.

Issues

Everything would be cool, if there wasn't one interface problem - when the hero gets the first magic spell, a circle showing the energy that can be used to perform it, instead of surrounding the icon of the spell (which, in contrast to the circle has been stretched), appears somewhere in the center of the image.

At present, I have no ideas to solve this problem, and the modification in its current state is not satisfactory for me to [...] so I leave it to [you] in case a solution will be found, or if someone won't mind the problem.

We should also hold our horses with ultra widescreen resolutions, because at 16:9 aspect ratio, the disappearance of the elements on the sides is admittedly barely noticeable [similarly like in Rayman 2 without Cheat Engine changes].

In case of more issues with this game, see this video: https://www.youtube.com/watch?v=2VsI2ILlGnI but use dgVoodoo instead.

deton24 wrote: Sun Jun 14, 2020 9:21 pm I've contacted with Automaniak005 who is a Polish YouTuber specialized also in making widescreen mods.
That's what I just got from him:

Once again I've looked into this game, and somehow I managed to get to the proportion, but the result is not entirely satisfactory.

https://www2.zippyshare.com/v/KfLoIWQT/file.html

The highest resolution that Hype supports in Glide mode is 800x600.
D3D mode did not start at all, and Glide mode started to work after downloading that patch:
http://www.zeus-software.com/files/ngli ... _patch.zip
so without upscaling you cannot do that.

Someone could say that I just set 800x450 (16:9) in this zippyshare file - except that Glide, as a driver, supports a limited amount of resolution, so the game starts in a 800x600 window with a large black band at the bottom.

Therefore, you need to start the game in a 4:3 window so that the black bottom of the window does not fit the screen. Here, dgVoodoo will be useful.
There, of course, you should set the window mode, and the best scaling method in this case is Stretched, keep 4:3 Aspect Ratio if you want to play movie cutscenes in the original proportions (but then we need to copy also the ddraw.dll from the dgVoodoo's "MS" folder, because cutscenes are played in DirectX mode).

In the Glide tab, enter a resolution with a 4:3 aspect ratio, which width will be the same as our target resolution (e.g. I want to set 1920x1080, I enter 1920x1440). This step is best done at the end before closing the dgVoodoo configurator, because the program can automatically erase the entered resolution.

Before starting the game you will need a program that (if possible) forces the positions and dimensions of the windows to cover the border and perfectly set the image of the game. I use Scott's Window Resizing Utility http://www.scottandmichelle.net/scott/program/swru.html

After starting the game, we open the program, look for a process called H, and we use the trial and error method to determine negative coordinates that will allow to adjust the window accordingly. At first, the window may resist the changes made, but after a few position changes, we should take control.

Issues

Everything would be cool, if there wasn't one interface problem - when the hero gets the first magic spell, a circle showing the energy that can be used to perform it, instead of surrounding the icon of the spell (which, in contrast to the circle has been stretched), appears somewhere in the center of the image.

At present, I have no ideas to solve this problem, and the modification in its current state is not satisfactory for me to [...] so I leave it to [you] in case a solution will be found, or if someone won't mind the problem.

We should also hold our horses with ultra widescreen resolutions, because at 16:9 aspect ratio, the disappearance of the elements on the sides is admittedly barely noticeable [similarly like in Rayman 2 without Cheat Engine changes].

In case of more issues with this game, see this video: https://www.youtube.com/watch?v=2VsI2ILlGnI but use dgVoodoo instead.

Hi there!

Thanks for your answer! I've tried using your exe with the .sdb patch applied, and while the menu launches, when I start a new game, the game crashes. The menu shows with the black bottom bar you mentioned, but I cannot get in-game. I think this happens because you patched the exe for another version of the game (I only own the spanish edition of the game), so I would like you to share the changes you made to the exe file. Thanks!

There are different addresses for each binary version.
Don't know how long it would take to adapt all the changes into new binary.
Because it might more or less require reversing the game again and providing just your exe to easily rewrite all changes won't do the trick, because these addresses won't exist, I would persuade you to use regular (English?) version of the game.

If you want to contact with Automaniak005 anyway, just leave your comment below one of his videos as you did in the past. He answers pretty quick.

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.

Chapeaux bas. That's impressive.
Great thanks.
I'll let know Automaniak about this, if he still reads comments on YT, and also our support team specialized in OpenSpace Engine.
Greetings

Really interesting read, especially the bit about fiddling around with nop blocks! Very nice work! Your solution may be hacky, but it works, and it seems robust. Reminds me of all the hacking I did on Rayman Designer late last year (which mostly involved hanging extra functions off the very end of the EXE's code section and inserting calls to them in the original code).

This is some pretty amazing stuff! I was never even sure as to whether you could run Rayman 2 in widescreen without cheat engine, but it's pretty nice that you can do this too. It never seizes to amaze me as to how talented Rayman fans actually are.

Here's an update: So I figured out how to do the non-glitched FOV fix without editing fix.sna!
Doing a lot of pointerscanning in Cheat Engine, I actually managed to find a pointer to the FOV value's location in memory that seems to be quite reliable AND that is working at quite an early stage of the game's starting sequence (probably right after the memory gets allocated).
The pointer is: [[880f34] + 0] + 41CF28
I also managed to find the function that loads everything from external files (such as fix.sna) into memory. This is the function starting at address 00401e00. If you use a debugger to go through it using "step over" (otherwise it'll take years to get through all the file-reading), you can see that this is pretty much what most of the first "UbiSoft" loading screen at the beginning of the game does At some point during this function, the FOV value gets written. However, the only thing that really matters is that at the end of the function, the FOV value is already written, and the pointer to it is working! So that's where I decided to insert some assembler code to change the FOV (also, this function only gets called once, so the code that we add doesn't get executed a billion times).

I recalled what PluMGMK said about appending additional functions at the end of the EXE's code sections. So I looked there, and realized that right after the last "Return" command (byte code C3), there was a bunch of zeros between addresses 005bf4ea and 005bf5ff (this corresponds to offsets 1BE8EA to 1BE9FF in the .EXE file). Since its still part of the code section (so read-only) and a bunch of zeros is not likely to be executed, I thought inserting code in there shouldn't interfere with the rest of the executable (@PluMGMK please correct me if I'm wrong!).

So here's what I did: Fortunately, at the end of the "loading-screen-function", there were enough NOPs left after the return command to insert a jump right before it. Here's the assembler code that I put in the zeros block at the end of the code section:
PUSH EAX <-- save the current EAX value
MOV EAX, dword ptr [0x00880f34] <-- look at the base address of the pointer and save the pointed-to address in EAX
MOV EAX, dword ptr [EAX] <-- look where the new address points to, again save it in EAX
ADD EAX, 0x41cf28 <-- add 41cd28 to get the final address of the FOV value
MOV dword ptr [EAX], 0x3fe49ba6 <-- Write the new FOV value (1.786)
POP EAX <-- restore the previously save EAX value
JMP 0xffe42bc0 <-- Jump back to the point right before the return command

So far, this seems to be working well. I don't know a lot about the structure of binary files, so I'm not sure if replacing the zeros at the end of the code section broke anything (so far everything seems fine). Also I'm not an expert on memory allocation, so I'm not sure how reliable the pointer is (so far it has worked.. even after restarting the computer a couple times).

I attached the result. Maybe I'll try other aspect ratios in the future. At the moment, I'm quite happy with the 16:9 solution that I have

Great thanks!
Your findings may be also very useful for widescreen patches for other OpenSpace games.
Good work.

Automaniak:

Congratulations to the author of the mod, for fixing the biggest problem - poorly positioned interface elements and finding a way to increase the field of view without objects disappearing problem. Unfortunately, I will not be able to bring anything to the topic, because the nop, jump or push instructions themselves are pretty high-grade stuff for me, and so much more, creating tools for converting files.

However, I don't understand why the author of the post said that I was only "trying" to fix the black band problem at the bottom of the game window, since I wrote that the image could be customized with SWRU (Scott's Window Resizing Utility). The solution may not be convenient, but it is still a solution.

By the way, it seems the author found a way to set the field of view in Rayman 2 without having to use the Cheat Engine. If I have time, I will see if this works for Donald Duck: Goin 'Quackers.

Thanks a lot to everyone It's great to see that my efforts are being appreciated!

I don't know if Automaniak actually reads this, but when I said that they were "trying" to fix the problem with the black borders, I never meant to say that they didn't succeed. I changed the original post so it should be clear now. Sorry if it sounded wrong! In fact, if it wasn't for Automaniak's widescreen tutorials for openspace games on YouTube, I probably wouldn't have tried to create my own widescreen fix in the first place!

In my first attempt to create a widescreen fix, I tried something similar. I used reshade in combination with some magnifying shader to achieve a similar result. The downside of this is that it only works with the directX video backend, but as I mentioned before Hype+nGlide+DirectX crashes a lot on my computer. On the other hand Hype+nGlide+Vulkan+reshade doesn't work for me at all..
The good thing about this fix is that it doesn't rely on the changes that Zeus, the creator of nGlide, made to the Glide API. So in theory, it should also work with other Glide wrappers such as dgVoodoo-

Yes. And maybe in dgVoodooo it won't crash like in nGlide. Who knows.

FYI, Vulkan is supported in the newest versions of Reshade 4.x. Make sure you have the newest version and make sure that Reshade works in other Vulkan games in your system. Sometimes global hook installation is needed.

I recall that I had a problem with nGlide's Vulkan backend in Rayman 2 too. I think it happened on the game launch during resolution enumeration, it showed white screen and I needed to wait ~1 minute, and it launched. But it could have been patched in nGlide, I don't remember now.

In the Glide tab, enter a resolution with a 4:3 aspect ratio, which width will be the same as our target resolution (e.g. I want to set 1920x1080, I enter 1920x1440). This step is best done at the end before closing the dgVoodoo configurator, because the program can automatically erase the entered resolution.

Do we still need to follow this (or for nGlide maybe creating custom resolution in GPU driver panel to make such resolution show up) or maybe forcing normal 16:9 resolution e.g. FHD will be enough now?

Using SWRU is still necessary?

I'd like to write a short widescreen with FHD instruction on PcGamingWiki.
Step by step if really necessary.

deton24 wrote: Sun Feb 14, 2021 8:27 pm Do we still need to follow this (or for nGlide maybe creating custom resolution in GPU driver panel to make such resolution show up) or maybe forcing normal 16:9 resolution e.g. FHD will be enough now?

Using SWRU is still necessary?

I'd like to write a short widescreen with FHD instruction on PcGamingWiki.
Step by step if really necessary.

No, none of this is necessary anymore once you replace the executable file with the one I uploaded! In the nGlide configurator, simply select any resolution you want (e.g.1920x1080 for FHD)

I would like to stress once more that this works exclusively with nGlide, and not other glide wrappers.

Feel free to link to this on PcGamingWiki, but please test the solution first, especially the last version that I did. I want to make sure it works for everyone, not just for me

Nice! I would say that instead of jumping back to the original ret, you could just insert another ret right there. Doesn't really matter though.
I'm not as familiar with the Windows PE format as the PMW1 format (which is what the Rayman Designer EXE is in), but I'd say you're right about being able to replace those zeros. They're probably there to pad it out to a page boundary. (I think zeros as code would just be "add al, [eax]" over and over, which will just cause an invalid page fault sooner or later. )

Wow. That's even better than I thought.
So now, it would be nice to just calculate and edit values for other ARs, and maybe find 50FPS lock workaround for for the full joy.
Thanks

PS. I already edited the page yesterday before you wrote, but it's not any separate launcher which previously caused some problems in Tonic Trouble indeed, so I trust that just binary works and since it's pretty well documented.

deton24 wrote: Mon Feb 15, 2021 10:06 am So now, it would be nice to just calculate and edit values for other ARs

I will do that, once I have the time The main work here is to move the magic-energy-circles into the right position! Note that I intend to keep the internal x-resolution at 640. So for aspect ratios that cannot be written as 640/y, where y is an integer, I will probably have to round y to the nearest integer. In this case you can either set nGlide to "Aspect correction", in which case there will be tiny black bars on two sides of the screen (probably hardly noticable), or you can set it to "Entire Screen" in which case the the image will be a tiny bit distorted. Either way.. as a user of the patch you will probably not even notice it!

, and maybe find 50FPS lock workaround for for the full joy.

I'm not sure this is a good idea. As far as I know, old games often use frame-based timing, so increasing the FPS will either speed them up or cause other glitches. As far as I can tell, Hype runs at 60FPS in the menus and 48FPS ingame. I DID manage to find the function that causes the frame cap in the menu (its a function of the Glide API called "grBufferSwap"). I turned it off, and the framerate in the main menu and inventory screen went up to almost 1000. However, navigation in the menus was really hard at this point. I have no idea what caps the framerate at 48 ingame, but as I said, I'm not sure it's a good idea to turn it off

There are a few more things one could try, but I currently do not intend to do, because I'm quite happy with the result as it is:

1. Increase the INTERNAL x-resolution (I called it RealResX in my initial post) to anything above 640. As Automaniak said before, you can easily set it to, let's say, 800x450. However, there seems to be a limit. Whilst 1072x603 still works (don't ask me why I tried this), an internal resolution of 1280x720 (and anything above that) will crash the game on startup! As far as I can tell, a low internal resolution doesn't have a significant impact on the image quality, since the 3d image gets handled by nGlide anyway (which uses your screen's native resolution, or whatever you want). The only thing I noticed when I decreased the internal resolution to 320x180 is that the background images in the menus and loading screens get downscaled, so they become quite pixelated.
   Anyway.. if you change the internal x-resolution to anything other than 640, you will not only have to deal with the position of the magic-energy-circle, but you would also have to adjust the placement of all numbers on screen (such as the no. of arrows). Therefore, I decided to keep it at 640
2. Adjust the 2d HUD elements to the aspect ratio. With the current solution all HUD- and menu elements simply get stretched. This will probably look quite ugly at ultra-widescreen aspect ratios, such as 32:9 (I tested 21:9, and it didn't look too bad though). So I guess there must be a way to move HUD elements around, or edit the graphics files to un-stretch them. For me, this isn't really an issue

Thanks for the reply.

In Rayman 2, 2D HUD elements for each aspect ratio can be corrected by editing certain textures in textures.cnt by changing their proportions properly.
If Rayman Control Panel opens this texture.cnt file, then that's only matter of proper PNG editing.

If you're curious how it's done, see the mod in my signature. Maybe proportions will match and/or resolution.
After modifying, sometimes using textures sync feature is required if the resolution is bigger.
I know that some things needed to be updated in RCP to support Tonic Trouble, but who knows, maybe it will work.