NES emulator hack that might be interesting

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

NES emulator hack that might be interesting

Justin-2
I ran across this hack today that is I thought might be interesting, though probably not generalizable on Vice.  Still.. kind of a cool way to use the real estate on a wider aspect modern display with an old console and maybe food for thought.

https://arstechnica.com/gaming/2018/08/widenes-emulation-expands-nes-scenes-past-the-usual-sd-screen-borders/

smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: NES emulator hack that might be interesting

Rhialto
On Thu 30 Aug 2018 at 14:54:15 -0400, Justin wrote:
> I ran across this hack today that is I thought might be interesting,
> though probably not generalizable on Vice.  Still.. kind of a cool way
> to use the real estate on a wider aspect modern display with an old
> console and maybe food for thought.
>
> https://arstechnica.com/gaming/2018/08/widenes-emulation-expands-nes-scenes-past-the-usual-sd-screen-borders/

I read that too (or actually the original blog post via another
reference), and I could not escape the impression that I had read
pretty much the same thing years ago. But the blog post is undated so
maybe it is simply a few years old.

-Olaf.
--
___ Olaf 'Rhialto' Seibert  -- Wayland: Those who don't understand X
\X/ rhialto/at/falu.nl      -- are condemned to reinvent it. Poorly.

signature.asc (465 bytes) Download Attachment
smf
Reply | Threaded
Open this post in threaded view
|

Re: NES emulator hack that might be interesting

smf
In reply to this post by Justin-2
It wouldn't be directly applicable to vice because (apart from vsp,
which is rare in games) you have to move the data around manually, there
isn't a handy equivalent to PPUSCROLL.

But you could detect screen scrolling by comparing how the data in
memory is moving around.

I think he's missing a trick as well. With modern cpus you have enough
spare processing power to save stae, fast forward the emulation to see
what data will scroll on screen & then restore the state. That gives you
a problem for dying, but you can always add optional cheat codes while
it's fast forwarding.

On 30/08/2018 19:54, Justin wrote:

> I ran across this hack today that is I thought might be interesting, though probably not generalizable on Vice.  Still.. kind of a cool way to use the real estate on a wider aspect modern display with an old console and maybe food for thought.
>
> https://arstechnica.com/gaming/2018/08/widenes-emulation-expands-nes-scenes-past-the-usual-sd-screen-borders/

Reply | Threaded
Open this post in threaded view
|

Re: NES emulator hack that might be interesting

MiaM
Den Thu, 30 Aug 2018 21:56:55 +0100 skrev smf <[hidden email]>:
> It wouldn't be directly applicable to vice because (apart from vsp,
> which is rare in games) you have to move the data around manually,
> there isn't a handy equivalent to PPUSCROLL.

It could however be implemented in Amiga emulators. Commodore but not
8-bit :)

The trouble is how to know beforehand where the screen starts/stops
vertically. Horisontally it's more or less just to have a look at the
modulo registers, except that you might get garbage to the left of the
"official" screen on the first line and to the right of the last line,
and you can't really tell where one line ends and the next starts so
you could see some horisontal wrap in the extended screen area.
 
> But you could detect screen scrolling by comparing how the data in
> memory is moving around.
>
> I think he's missing a trick as well. With modern cpus you have
> enough spare processing power to save stae, fast forward the
> emulation to see what data will scroll on screen & then restore the
> state. That gives you a problem for dying, but you can always add
> optional cheat codes while it's fast forwarding.

One problem is that you won't be able to know how computer generated
characters behave if they either have some random element to them or if
the player interacts with them in any ways.

I think that for a C64 or similar, you'll have to write code specific
to every game to make it work perfectly. Otherwise for a game like
Boulder Dash you could get the map and the emulator could remember how
the map looks like off screen, but not be totally sure what happens with
the computer controlled dynamic stuff.

For some games, like Scramble type games, the playable area is really
wide, so there is a question of how much screen should be displayed.
For that kind of game there isn't much reason to show that much either
though.



--
(\_/) Copy the bunny to your mails to help
(O.o) him achieve world domination.
(> <) Come join the dark side.
/_|_\ We have cookies.

smf
Reply | Threaded
Open this post in threaded view
|

Re: NES emulator hack that might be interesting

smf
On 31/08/2018 17:28, Mia Magnusson wrote:
> It could however be implemented in Amiga emulators. Commodore but not
> 8-bit :)

Amiga adds further complexities

http://codetapper.com/amiga/sprite-tricks/shadow-of-the-beast/

http://codetapper.com/amiga/sprite-tricks/brian-the-lion/

http://codetapper.com/amiga/sprite-tricks/jim-power/

> The trouble is how to know beforehand where the screen starts/stops
> vertically. Horisontally it's more or less just to have a look at the
> modulo registers, except that you might get garbage to the left of the
> "official" screen on the first line and to the right of the last line,
> and you can't really tell where one line ends and the next starts so
> you could see some horisontal wrap in the extended screen area.

modulo registers wouldn't normally change, just the bit plane pointers.

You'd only ever be able to grab out of memory what is actually displayed, which is why you need to time travel into the future while virtually pushing the joystick to find what data is coming up.

> One problem is that you won't be able to know how computer generated
> characters behave if they either have some random element to them or if
> the player interacts with them in any ways.

They'll normally be sprites. But it'll be best guesses, you won't ever
have that much change in the character map but the changes will look
glitchy.

Although these would likely be a problem....

https://www.youtube.com/watch?v=mW4w32UihGE

https://www.youtube.com/watch?v=SiCxXMquPKs

> I think that for a C64 or similar, you'll have to write code specific
> to every game to make it work perfectly.

Yeah, personally I'd probably do that and get bored after one game...

> For some games, like Scramble type games, the playable area is really
> wide, so there is a question of how much screen should be displayed.

I believe the answer is, "enough to fill a 16:9 monitor".



Reply | Threaded
Open this post in threaded view
|

Re: NES emulator hack that might be interesting

David Holz-2
In reply to this post by smf
On 08/30/2018 01:56 PM, smf wrote:
> It wouldn't be directly applicable to vice because (apart from vsp,
> which is rare in games) you have to move the data around manually,
> there isn't a handy equivalent to PPUSCROLL.
>
> But you could detect screen scrolling by comparing how the data in
> memory is moving around.

Yeah, it would have to start over and not use any of these NES ideas.

In a naive approach, you could simply looking at the entire screen's
displayed characters (including tracking raster splits), and compare
them to the prior frame, testing 9 one-character scroll directions
(including no scroll).  Wherever there is a strong match, then assume
the screen scrolled in that direction and shove the edge of the screen
into the back buffer that way.  You could also detect static areas of
the screen, which tend to be raster splits.

If this is too slow, you could just check the outer edges of the screen
with the prior frame, looking at 1 column/row further in, but this might
generate more false positives.  But I believe you could reduce the
checks to just a few row/column checks to achieve pretty confident results.

Reply | Threaded
Open this post in threaded view
|

Re: NES emulator hack that might be interesting

MiaM
In reply to this post by smf
Den Fri, 31 Aug 2018 18:17:51 +0100 skrev smf <[hidden email]>:

> On 31/08/2018 17:28, Mia Magnusson wrote:
> > It could however be implemented in Amiga emulators. Commodore but
> > not 8-bit :)
>
> Amiga adds further complexities
>
> http://codetapper.com/amiga/sprite-tricks/shadow-of-the-beast/
>
> http://codetapper.com/amiga/sprite-tricks/brian-the-lion/
>
> http://codetapper.com/amiga/sprite-tricks/jim-power/

Oh, yes, that would need a lot of game specific work.

(Tbh I almost stopped playing games before the Amiga days).

> > The trouble is how to know beforehand where the screen starts/stops
> > vertically. Horisontally it's more or less just to have a look at
> > the modulo registers, except that you might get garbage to the left
> > of the "official" screen on the first line and to the right of the
> > last line, and you can't really tell where one line ends and the
> > next starts so you could see some horisontal wrap in the extended
> > screen area.
>
> modulo registers wouldn't normally change, just the bit plane
> pointers.

Yes, but the modulo registers is the source of how wide the actual
bitmap is.

> You'd only ever be able to grab out of memory what is actually
> displayed, which is why you need to time travel into the future while
> virtually pushing the joystick to find what data is coming up.

True, by making the game view everything viewable you'd know where the
limits are.

> > One problem is that you won't be able to know how computer generated
> > characters behave if they either have some random element to them
> > or if the player interacts with them in any ways.
>
> They'll normally be sprites. But it'll be best guesses, you won't
> ever have that much change in the character map but the changes will
> look glitchy.

In some cases sprites, but for example in Boulder Dash there is so much
that can change that my impression is that it's only the user
controlled character that's a sprite. I might be wrong. Afaik in the
game logic everything is placed in a map that would work fine on a
computer which only has programmable char set and no sprites or hires
modes. Sprite for the main character is afaik only used to make
everything else scroll smoothly when the main character moves around
making the screen scroll.

> Although these would likely be a problem....
>
> https://www.youtube.com/watch?v=mW4w32UihGE
>
> https://www.youtube.com/watch?v=SiCxXMquPKs

The two different depth levels? Yeah, you'd run out of data to display
at the far ends. That would "only" be a cosmetic issue, or are both
depth levels used by the game logic?

> > I think that for a C64 or similar, you'll have to write code
> > specific to every game to make it work perfectly.
>
> Yeah, personally I'd probably do that and get bored after one game...
>
> > For some games, like Scramble type games, the playable area is
> > really wide, so there is a question of how much screen should be
> > displayed.
>
> I believe the answer is, "enough to fill a 16:9 monitor".

Good point, and while someone might be at it, there could aswell be
modes for the rare super wide monitors (or rather TVs, intended for
those who like movies as much as we like Commodore stuff).


--
(\_/) Copy the bunny to your mails to help
(O.o) him achieve world domination.
(> <) Come join the dark side.
/_|_\ We have cookies.

Reply | Threaded
Open this post in threaded view
|

Re: NES emulator hack that might be interesting

Groepaz
> In some cases sprites, but for example in Boulder Dash there is so much
> that can change that my impression is that it's only the user
> controlled character that's a sprite. I might be wrong. Afaik in the
> game logic everything is placed in a map that would work fine on a
> computer which only has programmable char set and no sprites or hires
> modes. Sprite for the main character is afaik only used to make
> everything else scroll smoothly when the main character moves around
> making the screen scroll.

iirc its all characters :) but indeed, somewhere in memory you can find a map
that you can just display (given the right gfx data) as a scaled down version

--

http://hitmen.eu                 http://ar.pokefinder.org
http://vice-emu.sourceforge.net  http://magicdisk.untergrund.net

If you look at scrollback and the last 30 lines are from you ... please shut
up
<Moloch/Arkanix Labs>





smf
Reply | Threaded
Open this post in threaded view
|

Re: NES emulator hack that might be interesting

smf
In reply to this post by MiaM
On 02/09/2018 16:06, Mia Magnusson wrote:
> Yes, but the modulo registers is the source of how wide the actual
> bitmap is.

The modulo register tells you what data to skip at the end of each
scanline, so if each scanline is contiguous in memory then it's 0.

Often the modulo register is used to interleave the bitplanes, which
allows you to blit bobs in one operation rather than one per bitplane.

You can't really assume anything about the data that is skipped, it
might be data that is about to be scrolled onto the screen or it might
be garbage.

> In some cases sprites, but for example in Boulder Dash there is so much
> that can change that my impression is that it's only the user
> controlled character that's a sprite.

boulderdash is a pretty extreme example, everything is characters and I
think it runs physics for off screen data.

There is no guarantee a game will hold the data in memory in a way that
you could easily extract, so there are going to be compromises & some
games will work and others not.

> The two different depth levels? Yeah, you'd run out of data to display
> at the far ends. That would "only" be a cosmetic issue,

Aren't all the issues going to be cosmetic?

I'm not quite sure how the parallax code works in those two games. It
might leave the background layer characters in the same place and only
move the foreground layer characters, or it might move all characters
and redefine the font so the background characters stay in the same
place. Both will cause display issues, the former may additionally
confuse the AI that determines whether you have scrolled,

> Good point, and while someone might be at it, there could aswell be
> modes for the rare super wide monitors (or rather TVs, intended for
> those who like movies as much as we like Commodore stuff).

I reckon it would be too distracting on a 21:9 tv. It's supposed to
replace the weird stretching on either side of the screen on a 16:9
monitor, you aren't really supposed to notice it's even there. But with
a monitor that is almost double the width of an 80's tv then it's going
to be too obvious.

I can barely even look at ps1 games on a modern tv, due to the pixel size.



Reply | Threaded
Open this post in threaded view
|

Re: NES emulator hack that might be interesting

MiaM
Den Sun, 2 Sep 2018 22:20:36 +0100 skrev smf <[hidden email]>:
> I can barely even look at ps1 games on a modern tv, due to the pixel
> size.

My "modern" flat screen TV displays the 40 column graphics of a C64 in
4:3 mode, while it displays the 80 column RGB output of a C128 in 16:9
irrc. Pretty neat.


--
(\_/) Copy the bunny to your mails to help
(O.o) him achieve world domination.
(> <) Come join the dark side.
/_|_\ We have cookies.

smf
Reply | Threaded
Open this post in threaded view
|

Re: NES emulator hack that might be interesting

smf
On 03/09/2018 20:52, Mia Magnusson wrote:
> My "modern" flat screen TV displays the 40 column graphics of a C64 in
> 4:3 mode, while it displays the 80 column RGB output of a C128 in 16:9
> irrc. Pretty neat.

TV's try to remember the last aspect ratio you used for each resolution.

I assume you would be able to display them both in 4:3, both in 16:9 or
even a weird wide screen mode where the middle is kept at the correct
aspect ratio but the edges are stretched.

However aspect ratio isn't what I meant at all. Even displaying in 4:3,
a 40" tv makes the pixels look much blockier than the old 14" tv/monitor
I used to use.