Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature] Widescreen 16:9 Support #36

Open
rikimbo opened this issue Jul 21, 2021 · 2 comments
Open

[Feature] Widescreen 16:9 Support #36

rikimbo opened this issue Jul 21, 2021 · 2 comments

Comments

@rikimbo
Copy link
Contributor

rikimbo commented Jul 21, 2021

I know the intent of Omnispeak is to stay as true to the original as possible, which had a game resolution of 320x200 meant to be played in a 4:3 aspect ratio. I really like the way Omnispeak looks when it scales the game for 4:3 currently. That said, would it be possible to optionally turn on support for a widescreen 16:9 aspect ratio?

Note that I don't mean strictly stretching the 320x200 game resolution to fit a 16:9 screen. Rather, I mean changing the game resolution to 427x200, which will give the correct pixel size when scaled to a 16:9 aspect ratio.

@sulix
Copy link
Owner

sulix commented Jul 21, 2021

I guess I wasn't the only person to watch LGR's video of RigelEngine this morning. :-)

I've changed my mind about whether or not I want to do this a few times, mostly for the technical reasons below. I'll at least try to look into it some more, though it's complicated enough to get right (and I'm sufficiently busy), that I doubt I'll get to it very soon.

Basically, implementing "real widescreen" like this certainly isn't impossible, but it is not trivial with some of the way omnispeak works. In particular, there's a fair few hardcoded values which relate to the screen resolution (and, perhaps more importantly the "buffer" resolution). Ultimately, I think making these variable would be a good thing, but there are likely to be a number of consequences which will need thinking through:

  • The graphics backends would need to transition away from a DOS-video-mode based system to allow arbitrary resolutions (and the DOS/EGA backend would need to still be able to force 320×200). I
  • There's a bunch of code in the game which disables enemies when they are a certain distance outside the visible area, and things like the camera would need to be adjusted: both of which would break compatibility for demos.
  • We'd also need to check for any levels which are too thin and handle that properly. The High Scores screens, for instance, are too small, and the BLOCK tile border would be visible in a naïve implementation here. Even if we disabled it for the high scores (i.e., for demos), maybe there are mods which have sufficiently tiny levels.

One option — which might make some of these sorts of enhancements easier — would be to have a different ID_RF backend which is a bit more "modern", but less accurate, and not need some of the optimisations which make this a bit harder. I'm not sure that's the best way to handle it, though, so I'll think on this…

@rikimbo
Copy link
Contributor Author

rikimbo commented Jul 22, 2021

I guess I wasn't the only person to watch LGR's video of RigelEngine this morning. :-)

Funny you should say that. You're right on the money there. I have been playing RigelEngine for a while but seeing the LGR footage on his ultra-wide monitor got me thinking about this again!

There's a bunch of code in the game which disables enemies when they are a certain distance outside the visible area, and things like the camera would need to be adjusted: both of which would break compatibility for demos.

I actually noticed this in RigelEngine too, at least in an earlier version. Enemies would be on-screen but didn't actually start moving until they were in the "4:3 space" of the screen. It was a little distracting if you noticed it, but not that bad. I suppose for something like the Mad Mushroom, it would be pretty noticeable.

We'd also need to check for any levels which are too thin and handle that properly.

I play the Vorticons series using Commander Genius at a game resolution of 427x200 with 16:9 aspect ratio, and the early huts in the first episode are like that, since they are meant to be the width of one screen (320 wide). In Commander Genius they end up pushed to the left of the screen, with the rest of the space being black. It doesn't look great (it'd be better if it was centred), but it works just fine.

For the Galaxy series, the level that comes to mind is the last part of the Cave of the Descendents, where you jump up the platforms to the council member. I hope I'm remembering this right, but I think that's meant to fit in the width of the screen. If so, that would be a good test case.

I realize it's kind of a big ask. Thanks for giving it some space in your head. :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants