/vr/ - Retro Games

I would like that very much

>Do you think there's demand for things like updated versions of NES/SNES games that are made to run in widescreen like with Excitebike on the 3DS?
>Would you buy it?
Nope and nope.

>>2346280
Kinda this. I think widescreen is fine, but that doesn't warrant me to fudge out extra money for it, so I wouldn't buy it, unless there's more to it like the re released widescreen sonic games on phones and consoles.

I'd actually be interested in reading a technical discussion of how feasible this is for most games.

>>2346259
most 8 bit and 16bit game only render garbage, if anything, outside of the viewable area, I'm not aware of any games that actually render anything worth seeing, it doesn't work the same way as 3D games do.

>>2346259
If anything im against it. Some of the older games' charm was limited sight. Like in super Mario world, how would I know where the key holes to different levels are if a widescreen hack gives me too much of the puzzle. But I guess if a game doesn't have things like that itd be alright.

It'd reprogramming the entire game. It's not like a PC game where you might be able to do a little hack and trick it into displaying widescreen using its rendering engine, these games literally do not have the capability to output widescreen.

I don't think so, widescreen changes how the games play especially for platformers. There's important reasons why things like Wario Land Shake It on the Wii force 4:3 for the game screen.

>>2346259
>kick shell to the side of the screen
>it disappears

>>2346349
It seems like I couldn't be harder than making Genesis games 3D, but even that took professional effort

>>2346259
Widescreen has two problems:
>game logic changes (enemies spawn/despawn immediately when offscreen, which enemies are actively moving, etc)
>game drawing (area outside the screen in VRAM has garbage in it/is used for other things)

The first problem is more of an issue than the second (the second is a bit of an issue with some of the Game Gear -> SMS conversion hacks for things like Sonic Triple Trouble).

>>2346416
Shells in SMB1 can keep going a fair bit outside the screen before they stop existing.

I made a similar thread about this months ago with a technical demonstration but it got deleted quickly. Hrm.

But anyway, yeah it would be possible, but kinda hard. There's no single solution and it would have to work with game-by-game basis. Example: SMW.

1. Construct a special emulator or write a plugin (or a lua script maybe?) that constantly reads all RAM and ROM, and depending on what's loaded, renders stuff out of the ordinary SNES resolution bounds. SNES is 256 x 224, so additional "back" and "front" sections of 72px width have to be made for the 16:9 ratio.
2. For the hack to work, a specially-crafted XML file would be placed in the same folder as the ROM. Essentially it would consist of the instructions on _how_, _what_ and _under what conditions_ should shit be rendered outside the true emulation window.
3. No XML file found = no 16:9 trick. Incomplete XML file present = incomplete widescreen emulation.

See pic related. A good chunk of level is loaded to the RAM, and the viewport is somewhere around the middle of the level. The hack would read and understand the RAM addresses "this is Yoshi's Island 3 / therefore use the assets from its respective graphics page", "the viewport is at x:y / therefore render the missing parts of the level accordingly", "sprite ID "checkerboard" is loaded already but not onscreen / therefore render it anyway out-of-bounds and move it as it should", "background layer is at x:y / therefore render its missing parts out-of-bounds, behind the top layer"

So, in short, heavy, scripted processing in real-time.


Technically there could be an even easier way that would work with any game at all but I don't think it would be as easy as I think: program a new emulator from the ground-up that renders everything at maximum: no viewport at all, just full namespace of all layers on top of each other all the time, just cropped accordingly. I'll post a demo of this later.

>>2346803
just read my post, wow - that sounds a bit incomprehensible/rushed
I'll post the other demo later today, it should be easier to understand

>>2346259
The resolution outputted by a lot of retro consoles is completely fixed. not to mention a lot of programming decisions are made based on proximity or position in the viewing area, which would require many mechanics needing to be completely rewritten.

>>2346803
if you had to write a special emulator or plugin for this then why not just write the code needed for this to work into the emulator or plugin it's self or have the emulator or plugin generate the file, rather than having to have to manual place the file yourself for every single game?

>>2346840
>>2346803
also, I might add wouldn't this add a lot of extra processing that would make it so you would need a rather powerful computer for the game to be playable? Though a debugging emulator would be able to constantly scan the RAM and ROM, but like I said, it would take a massive amount of processing power to pull it off.

>>2346840
>have the emulator or plugin generate the file
How would the emulator know where the level data is? Or where the sprite data is? It's different for every game. SMW just happens to be documented to hell and back.

>>2346842

>rather powerful computer for the game to be playable
Not really I guess. Maybe I overstated the "needs to constantly read RAM and ROM", because you'd really have to scan for all the stuff that's needed. Namely the level data and the sprite data.

okay, >>2346803 here.
Tried to make a demo video but NO$SNS always stretches the goddamn VRAM viewer to stupid proportions. Couldn't find a screenshot of it either, but it's essentially identical to the BGB's VRAM viewer in pic related.

Basically, most shit is already rendered out-of-bounds. It's just a matter of extending the visible area a bit to the left and right. According to NO$SNS's OAM viewer, most sprites are also loaded before they come on screen too.

I dunno, this sounds way easier than it probably is, but just seeing the border move over the level tilemap as you run along the level, it just seems really easy to program.

>>2348748
fug, forgot pic

>>2346259
>>2346371
It's not such a bad idea. Some games were not carefully made with scrolling issues in mind, like Basewars, it had horrible annoyances when you were fielding and the ball went into the outfield and were left clueless about where the controllable member of your team is. I think there would be agreement that that game would benefit from a wider field of view.

>>2348752
You know, even better, maybe have the special emulator / plugin to display the whole goddamn VRAM page and you could crop it however you like. Total full size, 16:9, 16:10, etc.

https://www.youtube.com/watch?v=HQ6fIwA6Ml0
Something like this is apparently possible, and it looks like what >>2348752 is all about.

>>2346365
BZZZZZZT!

It depends on the actual game, but rendering more of a level than is viewable is in no way uncommon for the NES. For the NES, under NROM, you really only get 2 'screens' of data in memory at a time and you can really only update a few columns of that data at a time in between screen updates (this is why full screen updates typically cause the screen to blank to black for a few frames). Try firing up Super Mario Bros in FCEUX and checking out the Name Table Viewer. See how that updates as you move along the X axis. It's keeping 2 screens of data in memory at all times -- the viewable screen, plus the next 'screen' width from your current location.

Some games use the extra 'screen' for things like storing the HUD. If the HUD is on the bottom of the screen, then when it gets to that line, it swaps to the next 'screen' of data in memory so that it draws the HUD from that point on instead of level data. For example, Tiny Toon Adventures does this.

>>2351164
Here's screenshots to show what I'm talking about

>>2351178
The reason the Tiny Toon stuff 'looks' like garbage at the bottom is because those tiles are meant to reference a different set of data. Once it hits the raster line where the HUD is drawn, it swaps out the background tile data for the HUD data. The data / name table in memory then looks like pic related until the tiles are swapped back to draw the level data again at the start of the frame.

>>2351164
Wow, that's some interesting shit.