A New Visual Experience In Emulated Games

[jonai]

Hello,

i made a few example pictures at the bottom to show what I mean.

The most emulators render their images whithin the range of the native resolution of the emulated system.
But if you use this method on a device that has a bigger resolution than the emualted system (for example the screen of the Pandora)
then won't lose quality on the one hand, but on the other hand you do not USE the whole screen.


Here a Picture in the native resolution in snes9x
LoZ-320x240.png


It would look like this on a actual Pandora screen...
LoZ-800x480-noscale.png


Some people like to (or hate to) scale the image up to the resolution of the target system. In this case more of the screen is used but because the
aspect ratio of the target screen is another one than the emulated one, there is still unused screen space!!
LoZ-800x480-scaledup__64c.png


Now hear comes an idea that was not implemented in any emulator I know of but I think it is worth to mention it.
It is just useful for games that use some kind of scrolling or movement in screen ranges. (shooters, RPGs, Jump'n Runs, Fighting Games, ...)

An better solution in my opinion would be something like this:
use the as much of screen without loosing screen space.
LoZ-800x480.png


Another example of this method with a the Emerald Hill Zone stage of Sonic the Hedgehog 1, for Picodrive
Sonic1_800x480.png


I assume that this method of displaing the game images is very possible in different emulators, on a per system/per game basis
because of the following reasons.

1. If it is a sprite based 2d game, all needed information (graphics sprites, level design, algorithms to generate the world etc.)
are already stored inside the rom, and are loaded into the RAM of the emulated system.
They would be just used in another way then it was intended, since it is an software implementation of the emulated game, you can change
every aspect (for example changing VALUES inside the RAM that store position information etc.)

2. On a 3d geometry based game (for example playstation games) all required information is already there, it would have to be rendered with
a larger visible range of the virtual 'camera' of the game (for example a widescreen version of 'Zelda Ocarina of Time' exists if I am not mistaken).

In my opinion it is not an argument to say that it is much effort for only a limited quanttity of games, because there were and currently are already
hacks of emulators or even the game roms itself to make them playable/better playable on various systems.
(Final Fantasy VIII hack of ePsx, and Snes9x hack of 'Star Ocean' graphics pack comes to mind...and the already mentioned widescreen hack of Ocarina of Time.)


possible implementations of this in emulators like:

Snes9x
PicoDrive
gngeo (As far as I understand the NeoGeo uses strips instead of sprites, so it should be possible to show more strips than it was intended...)
VisualBoyAdvance
FCUltra (the NES emulator used sprites)

Psx4Pandora>
>-->3d rendered with a larger range of visibility of the camera.
Mupen64Plus>



To see how it would look like on my Pandora I made these graphics and watched them on the Pandora, it loosks better in my opinion.
I also rendered a Video with Blender to look like it would be animated, thats where the Emerald Hill Zone screenshot is from.




I want to collect some thoughts of users of emulaters, and maybe even some words of people that are more in emulation than I am.
Words from developers of emulators would be also helpful, because I think that this method would have to be implemented in other ways on a
per game and per system basis.

Am I the only one who is thinking about this?? Because I did not found much in other forums or with goolge regarding this topic.
If You know any resource regarding this topic I would be happy I You could post it here.



Thank You for Your attention.

 

[lobski]

I thought widescreen hacks, especially pixelixel ones are impossible on emulators?

 

[bzar]

Would be nice, but I think it's borderline impossible. The rom doesn't give you enough information to do smart view scaling like this.

 

[Aninhumer]

It's not that simple, in order to do this you'd basically have to reverse engineer an entire game.
That would be a phenomenal amount of work and by the time you've done that there's little point using an emulator anyway.
And even then that would only be one game out of hundreds for a system.

Basically, just because you see a seamless world in the games does not mean that's what's actually happening in the system running it.
When you move along the level, the game removes information about what's behind you from the memory to save space, it also probably does not bother working out what any enemies in bits you can't see are doing. The levels may also be carefully designed so that only a certain number of different tile sprites are ever on screen, so they can get rid of the ones they don't need.

The only way you could actually do what you're talking about, is somehow understanding the original code and rewriting it to use a larger screen.

EDIT: In the case of 3D games, the graphics are handled differently which may make widescreen mods possible, although by no means guaranteed.

 

[bce23w]

Good idea for ports, but practically impossible for emulation.

Although! Rather than smart scrolling, you could do something ridiculous like have one of the nubs control the "viewscreen," moving the viewable area around the scaled-up original display.

 

[craigix]

Something has been on my mind for a while about this, how does Sonic use the whole iPhone screen? It's just emulated right? I had a look at it once and it looked like it was running at the iPhone res. I've thought about it for a while and I can't figure out how they did it unless sonic renders a lot more of the level than we see at the usual resolution - or was it just using a good filter when I saw it?

 

[hedwards]

Something has been on my mind for a while about this, how does Sonic use the whole iPhone screen? It's just emulated right? I had a look at it once and it looked like it was running at the iPhone res. I've thought about it for a while and I can't figure out how they did it unless sonic renders a lot more of the level than we see at the usual resolution - or was it just using a good filter when I saw it?

I'm not sure about the iPhone version, but Sega has rewritten large parts of the graphics handling code when they bring the games to new platforms. I believe that it's similar to what Nintendo did with Super Mario Allstars. They rewrote portions of the code to give "better" graphics and sound. Which is why I think the Super Mario that came with it is so creepy.

 

[mafia-man]

I think I read somewhere there was an overdraw area around the screen, kind of a prep area for sprites etc, if that could be accessed then it could be possible to fill a screen. Though that would depend entirely on the game.

 

[jonai]

It's not that simple, in order to do this you'd basically have to reverse engineer an entire game.
That would be a phenomenal amount of work and by the time you've done that there's little point using an emulator anyway.
And even then that would only be one game out of hundreds for a system.

Basically, just because you see a seamless world in the games does not mean that's what's actually happening in the system running it.
When you move along the level, the game removes information about what's behind you from the memory to save space, it also probably does not bother working out what any enemies in bits you can't see are doing. The levels may also be carefully designed so that only a certain number of different tile sprites are ever on screen, so they can get rid of the ones they don't need.

The only way you could actually do what you're talking about, is somehow understanding the original code and rewriting it to use a larger screen.

EDIT: In the case of 3D games, the graphics are handled differently which may make widescreen mods possible, although by no means guaranteed.

Could be there a more general implementation of that on the /per emulator level??
I imagine the Legend of Zelda example above:
1. I open the first window of the emulated game, it renders normal in Snes9x.

2. I open a second instance of Snes9x on my Pandora and place the emulator Window "under" the first window of Snes9x
in the second window I go one screen south with Link, then i disable the Tile-Layer of of the sprite that shows
link and the HUD-element screen. Then I input a GameShark Code to make Link invincible in this Snes9x emulator
window, and another code to make him pass through solid walls.
Then I enable the Input of "both" Snes9x screens at the same time, so I can walk and make input in both screens
but see a bigger used screen
space.
I repeat step two with the rest of the unused screen space with as many Snes9x instances as the Pandora can handle.


Just an idea. This could be implemented in software, because it uses the emulator in the way it was intended, and not the game in the way it was not intended.


Is it really that impossible on 'every' emulated system??

 

[Aninhumer]

Could be there a more general implementation of that on the /per emulator level??
I imagine the Legend of Zelda example above:

1. The first window of the game renders normal.

2. I open a second instance of Snes9x on my Pandora and place the emulator Window "under" the first window of Snes9x
in the second window I go one screen south with Link, then i disable the Tile-Layer of of the sprite that shows
link and the HUD-element screen. Then I input a GameShark Code to make Link invincible!
Then I enable the Input of "both" Snes9x screens at the same time, so I can walk and make input in both screens but see a bigger used screen space.

This would mean if the invisible Link walks into a wall in one of the other screens, they would go out of sync and ruin the effect.

EDIT: And you can't just use a noclip cheat because then when you DO walk into a wall, the other screen WON'T stop.

 

[jonai]

Could be there a more general implementation of that on the /per emulator level??
I imagine the Legend of Zelda example above:

1. The first window of the game renders normal.

2. I open a second instance of Snes9x on my Pandora and place the emulator Window "under" the first window of Snes9x
in the second window I go one screen south with Link, then i disable the Tile-Layer of of the sprite that shows
link and the HUD-element screen. Then I input a GameShark Code to make Link invincible!
Then I enable the Input of "both" Snes9x screens at the same time, so I can walk and make input in both screens but see a bigger used screen space.

This would mean if the invisible Link walks into a wall in one of the other screens, they would go out of sync and ruin the effect.

EDIT: And you can't just use a noclip cheat because then when you DO walk into a wall, the other screen WON'T stop.

You are right, this would require the other emulator windows of Snes9x to give feedback to the other windows if the 'run into wall' or other conditions are met (there are triggers in the RAM anyway), but that would require again game specific code.
Maybe a combination of game specific code and specific multi threaded emulation would work. I will test this with a fork of Snes9x which supports Tool Assisted Runs.


I would be very thankful If You could post additional Ideas for implementations in other games (Shooters maybe??) or problems with the implementation, or anything that has to do with the topic. For example that info of liquidphantom about the overdraw area was new to me
Thank You for that one.
If You have any additional ideas or critique be my guest


About possible implementations in 3d games, There is just a finite amount of games where this is possible/useful so if it got implemented than these could benefit from it. So its not wasted effort even for just one game. In my opinion.

 

[WizardStan]

I think I read somewhere there was an overdraw area around the screen, kind of a prep area for sprites etc, if that could be accessed then it could be possible to fill a screen. Though that would depend entirely on the game.

But then you would lose the overdraw. The edge of the screen would go black as you walked towards it and then suddenly poof in the next set of tiles for the overdraw. I don't think the wider screen would be worth the side effect.

 

[itsmyusername]

your idea is great! but i just thought...

if your idea worked, i "think" it won't on some scenes of some games, like the psx games always use animation scenes, which don't have map at all, and i guess those scenes are just videos playing.

and another thing, some game maps like the map of a zelda game, like if your character landed on coordinates that is assigned to another map(which you'll see though you're still a map away from it. because the screen is now wider), the screen will move. i think that will kinda feel awkward that you haven't finished walking to a part of map that is still seen on the screen, will eventually move though you still see it.

and i "think" some other games would not be that that exciting if you're seeing what's not supposed to be seen. like mario, you'll be seeing enemies... that must be hidden, for a more exciting game.

and some other games are just really fixed to fit their native screen, and you'll see no map no matter what move you do to see it. its just, there's really nothing to see. like, if you're like inside a house in a pokemon game, no matter what move you do, there's really no map to see.

 

[Tempel]

and i "think" some other games would not be that that exciting if you're seeing what's not supposed to be seen. like mario, you'll be seeing enemies... that must be hidden, for a more exciting game.

This is important. These games were designed with a specific screen size in mind. It depends on the game, but being able to see beyond the borders that the game designer intended could really screw things up. As a bit of a ludological purist, I would likely play all games at original resolution (but scaled up as much as practical; I am not so much a visual purist).

 

[itsmyusername]

This is important. These games were designed with a specific screen size in mind. It depends on the game, but being able to see beyond the borders that the game designer intended could really screw things up. As a bit of a ludological purist, I would likely play all games at original resolution (but scaled up as much as practical; I am not so much a visual purist).

yeah, i'm kinda a game purist too, that's why my comment is kinda not liking this topic's idea..

anyways, great idea jonai!

 

[gibberish]

i thought nulldc supported this feature in some games. isn't it called "extra geometry" or something like that? i seem to remember i had it working in soul calibur a long time ago, though i could be mistaken.

 

[Adventus]

I think, in general, this idea is only possible in games where there is significant HLE-ing of the graphics hardware, any system which writes directly to the framebuffer would most likely look wrong (ie SNES, GBA, PSX, etc). It is possible, to a degree, with N64.... I have to use a modified projection matrix and scissor tests. You'll still get missing geometry at the edges if CPU is used for culling, but some games might look alright. Rice_video already has support for this.

 

[Exophase]

Even then it'll only work to a certain extent, because even if the CPU isn't doing frustum culling it'll still be doing some sort of scene graph culling usually. It probably wouldn't open things up to the extent jonai is asking for for the SNES games - not that you'd usually want to.

 

[DaveC]

Hello,

i made a few example pictures at the bottom to show what I mean.

The most emulators render their images whithin the range of the native resolution of the emulated system.
But if you use this method on a device that has a bigger resolution than the emualted system (for example the screen of the Pandora)
then won't lose quality on the one hand, but on the other hand you do not USE the whole screen.

Thank You for Your attention.

Won't work. Most of these systems relied on the timing and position of the electron raster beam of the TV for timing of scrolling, sprites etc.

It only works on N64 because you can output polygon rendering separate of the raster timing.

 

[1magus]

Having unused screen space does not bother me at all. Interesting idea but it would probably be riddled with bugs.