(09-29-2025, 09:58 PM)sharangad Wrote: [ -> ]@jxeboy, what would you say the vertical field of view is as an angle? It should be somewhere between half of 30 to 45 degrees. I don't think you can work it out from the resolution. I'm trying to find out where the game sets up its projection. If I can tweak it at the source, it may be possible to find do anamorphic widescreen in a 640x480 view. I need to find the angle in there. It's not computed anywhere, I tracked all the trig functions, so it should be hardcoded (I hope). The cotangent of half this angle is needed, assuming, it works with a fixed horizontal size instead of a vertical one. Find the cotangent and where it's used, find the fixed horizontal range. it could also be inverted with a fixed vertical view and a horizontal angle. In either case it needs to be found.
Current the viewport projection is set to a 4:3 view, zooming in is a cheap fix and there's a limit as to how effective it would be, also it would limit the precision of the zoomed in view's coordinate range.
Im not sure how to calculate what the current vertical field of view is, but based on my experience with other sims 35 - 45 sounds correct. It might be possible to calculate if we know the length between two lines that are painted on the track and can calculate when they would converge in view
I have discovered (with SKs help) that it is possible to change the pacing distance of the AI on pace laps and cautions. This allows for more space between rows
The value by default is '240000' (80A903) and is located at the following addresses in the EXE:
Dos32: 0x9F585
Rend32: 0x5B455
Windy: 0x590FA
Changing it to 720000 (80FC0A) for example to triple the spacing (maybe realistic for a high-speed oval):
![[Image: spacing.png]](https://i.postimg.cc/jSDqQF1m/spacing.png)
![[Image: spacing2.png]](https://i.postimg.cc/1XVMKPpt/spacing2.png)
Unfortunately it appears I had this wrong! These offsets do move where the cars spawn, but they go back to their original spacing once they start moving
@jxeboy, do you know whether "widescreen windy" modified the viewport clipping or the projection matrix or both. I still haven't found the projection matrix. It's probably moot at this point since there's a turbo charged Windy which does full screen, but I'd still like to know.
(10-14-2025, 04:35 AM)sharangad Wrote: [ -> ]@jxeboy, do you know whether "widescreen windy" modified the viewport clipping or the projection matrix or both. I still haven't found the projection matrix. It's probably moot at this point since there's a turbo charged Windy which does full screen, but I'd still like to know.
I don't know all of the tricks hatcher used, but at a high level the game is actually rendering multiple game windows with different camera angles that get stitched together. For his 16:9 I believe it is rendering 4 separate 640x480 game windows and stacks them side by side to create the 1280x720 resolution (1280x960 and then it crops the bottom), or for 24x9 its two side by side to make the picture 1280x480.
There is then another render which does the mirrors and a final render which applies the game Hud on top of everything
Luckily the core game framerate for the base game on a modern system is typically over 1000 frames a second, so its possible to brute force re-render multiple windows to make the appearance of widescreen. But on my system where it was running around 1,200 fps before the patch, it can be around 200 fps now with all the renderers
That is of course game engine framerate, the visible framerate is always 30 no matter what unless using a tool like lossless scaling to add frames
(10-15-2025, 02:27 AM)jxeboy Wrote: [ -> ] (10-14-2025, 04:35 AM)sharangad Wrote: [ -> ]@jxeboy, do you know whether "widescreen windy" modified the viewport clipping or the projection matrix or both. I still haven't found the projection matrix. It's probably moot at this point since there's a turbo charged Windy which does full screen, but I'd still like to know.
I don't know all of the tricks hatcher used, but at a high level the game is actually rendering multiple game windows with different camera angles that get stitched together. For his 16:9 I believe it is rendering 4 separate 640x480 game windows and stacks them side by side to create the 1280x720 resolution (1280x960 and then it crops the bottom), or for 24x9 its two side by side to make the picture 1280x480.
There is then another render which does the mirrors and a final render which applies the game Hud on top of everything
Luckily the core game framerate for the base game on a modern system is typically over 1000 frames a second, so its possible to brute force re-render multiple windows to make the appearance of widescreen. But on my system where it was running around 1,200 fps before the patch, it can be around 200 fps now with all the renderers
That is of course game engine framerate, the visible framerate is always 30 no matter what unless using a tool like lossless scaling to add frames
That's a pretty clever trick to generate a widescreen view! Might be a bit difficult to do with the rendition edition, especially when the framerate is already struggling with a full set of cars,
Sorry for the lack of updates, but recurring flu and thunderstorms made life a bit difficult.
Found the matrix offset and it works for 16:9 (video later) but the cockpit graphics have to be replaced like before. 32:9 is harder to do because 9/32 is less than 0.5 the game shrinks the horizontal field of view. The matrix kludge actually needs dosbox to do some work (unknown int 0x10 call while indy is running) to update the matrix.
Swapping one of the aspect coefficients makes it work perfectly for 16:9. Swapping both works for everything but the view is vertically truncated for anything wider than 4:3.
(10-21-2025, 05:28 PM)sharangad Wrote: [ -> ]Sorry for the lack of updates, but recurring flu and thunderstorms made life a bit difficult.
Found the matrix offset and it works for 16:9 (video later) but the cockpit graphics have to be replaced like before. 32:9 is harder to do because 9/32 is less than 0.5 the game shrinks the horizontal field of view. The matrix kludge actually needs dosbox to do some work (unknown int 0x10 call while indy is running) to update the matrix.
Swapping one of the aspect coefficients makes it work perfectly for 16:9. Swapping both works for everything but the view is vertically truncated for anything wider than 4:3.
Hoping you are back in good health! Appreciate all that you are doing Sharangad.