It is currently Fri Sep 20, 2019 1:46 pm

All times are UTC - 7 hours



Forum rules





Post new topic Reply to topic  [ 28 posts ]  Go to page 1, 2  Next
Author Message
PostPosted: Sat Aug 17, 2019 3:18 am 
Offline
User avatar

Joined: Wed Oct 22, 2008 9:27 pm
Posts: 117
I've been toying around with Derkoun's fork this week. Does anyone think there is an optimal width for widescreen output of a 256x240 system? I'm leaning towards 480, as it is 1/4 of HD and will scale evenly (4x) to it with no pixel warping.

I have some technical questions as well:
-Does a wider draw distance decrease the game's internal fps? If so, would the overclocking option negate this?
-Can games that drew at 224 height be hacked to draw at 240 and take full advantage of PPU vertical resolution?
-Can vertical draw be expanded past 240 or is that a hard cap?

Here's some screenshots of 480x270 (if it were possible):

Attachment:
480x270_2x.png
480x270_2x.png [ 90.01 KiB | Viewed 1030 times ]

Attachment:
ff480x270_2x.png
ff480x270_2x.png [ 92.93 KiB | Viewed 1030 times ]

Attachment:
lttp480x270_2x.png
lttp480x270_2x.png [ 24.26 KiB | Viewed 1030 times ]


Top
 Profile  
 
PostPosted: Sat Aug 17, 2019 3:48 am 
Offline
User avatar

Joined: Sun Sep 19, 2004 9:28 pm
Posts: 4208
Location: A world gone mad
0. "Derkoun's fork" means what? A fork of what? Who is Derkoun? What is the fork? Why are these details omitted as if we can read your mind? Is this the HD mode 7 fork whose code/model got brought into bsnes? If so, okay, that sheds some light on things, but the way that works is not the way you (apparently?) think it works.

1. I literally don't know how extending horizontal res would work.

You didn't just increase the resolution (read: 256x240 or 256x224 "stretched" to a wider/taller resolution -- this is 100% doable but it isn't what you're talking about), your mockups essentially increase the actual "playfield size" (read: magically thought the SNES would have the PPU memory to do this (it doesn't, nor can it be extended in a won't-break-existing-games compatible way)).

The SNES, screen-map-wise, only has capability for either 1 (single-screen), 2 (two screens placed either horizontally or vertically next to one another), or 4 (four-screen) screens. The more screens you use, the more PPU RAM is used. Regardless of how the memory is utilised -- which is important -- the actual SNES can still only visibly render/display a single screen worth of all of that memory. Hence, 256x240 or 256x224. I urge you very very strongly to open up a SNES game in bsnes or some other emulator with a debugger and take a look at the PPU RAM. Try bsnes-plus (Debugger -> S-PPU -> Tilemap viewer) or Mesen-S (Debug -> Tilemap viewer, and turn on scroll overlay). Now load up Super Mario World or some other game. Please do this. PLEASE. I think once you see how the memory is used you will begin to understand why this can't be achieved. I can't even imagine how scrolling would work if this was even attempted...

Next, I'll bring up this fact, because I'm sure you will mention it: the SNES's pseudo-hi-res mode doesn't "extend the amount of PPU RAM" either, it works through some pixel-doubling trickery and requires particularly "nuanced" use (which is why it isn't used in 99% of games out there. I do not care about the count-on-one-hand numbers which do; many of those use it only for title/transition screens. It's a gimmicky feature). So if you're thinking about that avenue, don't. :-)

Next, the PPU would have to be able to draw that many more horizontal pixels (scanlines are effectively longer) in addition to more scanlines (taller vertical resolution). It would completely screw up every single timing aspect of the console, and underlying games that rely on timing trickery would fail. It would throw everything off. I don't see how overlcocking could relieve this either.

The only way I could see this being done is through some massively revamped model of HD packs, and it would probably take people years to do for a single title/game.

Finally, pause and think about this for a moment. Pretend what you want was possible. Are you still playing the same game as original? Do you think this experience will be better, and if so, why? Could it not just as feasibly and subjectively be a worse experience? (I prefer to play games more or less how they were intended/designed, which is why I'm pretty anti-HD-pack and other such things. The mode 7 HD extension is an interesting edge case that happens to work due to the nature of mode 7's math, IIRC. byuu, please correct me if I'm wrong.)

2. Increasing from 224 to 240 -- that is, effectively, increasing from PAL resolution to NTSC resolution -- might be doable except we're back to the timing discussion. *I* can't see this being feasible, but folks more familiar with hardware at lower levels might have ideas. My vote is no, this can't be done without each game being changed/tweaked (this is why PAL games that have NTSC ports, or vice-versa, often had to be changed in several ways -- not just 50Hz vs. 60Hz nuances).

3. Effectively answered by #1 and #2 combined.

Can I ask what your actual SNES development experience background is? These questions are very strange to me, as in "dreamy floaty but seemingly without familiarity of the underlying hardware". If you don't have any, I really urge you to dive in and get some!


Top
 Profile  
 
PostPosted: Sat Aug 17, 2019 5:10 am 
Offline
User avatar

Joined: Wed Oct 22, 2008 9:27 pm
Posts: 117
This is not about Mode 7. Maybe someone else can explain it better, but it's apparently possible for an emulator to support wider output and come with per-game patches that can enable it. It takes months to create said patch instead of the years it would take writing an opensource engine.

Quote:
Finally, pause and think about this for a moment. Pretend what you want was possible. Are you still playing the same game as original? Do you think this experience will be better, and if so, why? Could it not just as feasibly and subjectively be a worse experience? (I prefer to play games more or less how they were intended/designed, which is why I'm pretty anti-HD-pack and other such things. The mode 7 HD extension is an interesting edge case that happens to work due to the nature of mode 7's math, IIRC. byuu, please correct me if I'm wrong.)


Yeah, sorry, I'm not an ultra-purist when it comes to expanding view distance. It's funny, because I have no problem with chunky pixel art, but that cramped view distance hasn't aged well. It's a dramatic improvement to see more world, far more than any other trick or filter employed thus far. Also, I'll take a new experience any day when I've already played the old one 20 times.

By the way, ever played a game that got made for Genesis and SNES? 25% wider draw distance on the Genesis.


Top
 Profile  
 
PostPosted: Sat Aug 17, 2019 6:02 am 
Offline
User avatar

Joined: Mon Jan 23, 2006 7:47 am
Posts: 205
Location: Germany
FitzRoy wrote:
Does a wider draw distance decrease the game's internal fps? If so, would the overclocking option negate this?
It most probably would. Unless the hack is doing something weird like using emulator-specific registers to control the emulator directly, which would create the possibility to basically do anything you want. (IIRC at some time byuu was talking about a hack that used an external program to play audio files a la MSU1?)

FitzRoy wrote:
Can games that drew at 224 height be hacked to draw at 240 239 and take full advantage of PPU vertical resolution?
Technically possible.

FitzRoy wrote:
Can vertical draw be expanded past 240 239 or is that a hard cap?
Nothing's a hard cap if you want to break compatibility with real hardware and change the game's screen rendering code and the emulator.

koitsu wrote:
I literally don't know how extending horizontal res would work.
Any game has a virtual camera (a pair of screen coordinate) that is used by the game's screen rendering code. By temporarily stopping the game's logic and repositioning the virtual camera, a hack could fill a larger screen with static backgrounds. (Dynamic backgrounds / characters would be difficult though.) All this extra rendering would need to be done with the emulator's "overclocked screen rendering" to keep the original framerate.

koitsu wrote:
the SNES's pseudo-hi-res mode doesn't "extend the amount of PPU RAM" either, it works through some pixel-doubling trickery and requires particularly "nuanced" use (which is why it isn't used in 99% of games out there. I do not care about the count-on-one-hand numbers which do; many of those use it only for title/transition screens. It's a gimmicky feature).
Well, it's useful to display kanji (e.g. used by Seiken Densetsu 3).

koitsu wrote:
Are you still playing the same game as original? Do you think this experience will be better, and if so, why? Could it not just as feasibly and subjectively be a worse experience?
Having played Jazz Jackrabbit 2 back in the day with different resolutions, I agree with that. Higher resolutions showed much more of the environment and felt/played quite different.

_________________
My current setup:
Super Famicom ("2/1/3" SNS-CPU-GPM-02) → SCART → OSSC → StarTech USB3HDCAP → AmaRecTV 3.10


Top
 Profile  
 
PostPosted: Sat Aug 17, 2019 6:45 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 21595
Location: NE Indiana, USA (NTSC)
FitzRoy wrote:
By the way, ever played a game that got made for Genesis and SNES? 25% wider draw distance on the Genesis.

A lot of cross-platform games run in H32 mode on the Genesis so as not to either A. create more resizing cleanup work for the artists or B. exceed 24 Mbit. (Sega reportedly didn't like making 32 Mbit cartridges.) Pinocchio and Pac-Attack are among them. I had previously suggested making H32/H40 switchable so that the display would appear closer to the same size in H32 mode on a 4:3 TV vs. H40 on a 16:9 TV.

Now if you want to make a more-or-less authentic widescreen mode for games designed to run on NTSC VDPs with 256x224 to 256x240 pixel output, I recommend 352 by 224.

To help understand how I came up with this, I'll start by explaining the existing horizontal display timing for H32 picture generators in 4:3 NTSC:

- By Rec. 601 definition, the clean aperture of each field is 704/13.5 = 52.148 microseconds wide by 240 scanlines tall. (The commonly quoted 720 figure includes eight samples of hblank on each side to recenter the signal later.)
- TMS9918 dot clock is 945/176 = 5.3693 MHz
- Clean aperture is (704/13.5)*(945/176) = 280 dots wide, exactly

Thus for the TMS9918 family (ColecoVision, SG-1000, MSX), its successors (Master System and Genesis VDP in H32 mode), and Nintendo and Hudson Soft PPUs that it inspired (NES, TG16, and Super NES), the 4:3 picture is 280x240 pixels including 24 pixels of side border, with a pixel aspect ratio of 8:7.

Assuming you want to keep the same pixel aspect ratio on 16:9, you'll need 4/3 times as many pixels, which amounts to 373.33. You'd end up simulating a 315/44 = 7.1591 MHz dot clock rate, as on the TurboGrafx-16's H42 mode, and you'd have 336 or 352 visible pixels per scanline. So each scanline would start rendering 40 or 48 pixels early, and it would continue 40 or 48 pixels late.

352x224 at 8:7 PAR would give a display aspect ratio of 88:49 or 1.7959:1 or 16:8.9. When scaled to common HDMI resolutions, it would fill these fractions of the picture:

- 664x448 on 704x480
- 1206x672 on 1280x720
- 1810x1008 on 1920x1080

This leaves a bit of border so that the TV can crop off the overscan area. (Yes, TV programming is still produced under the assumption of an overscanning TV, nominally an early-adopter 1080i CRT HDTV.)

_________________
Pin Eight | Twitter | GitHub | Patreon


Top
 Profile  
 
PostPosted: Sat Aug 17, 2019 7:46 am 
Offline
User avatar

Joined: Wed Oct 22, 2008 9:27 pm
Posts: 117
But the point of any widescreen patch would be to improve the game's presentation on modern displays, yes? And that's the fullscreen result I'm trying to explain. 99% of TVs and Monitors sold today are 1920 or double that. Shooting for exact 16:9 of the drawn area seems worse than shooting for a pixel width that isn't quite 16:9, but scales perfectly to the 1920 standard.

(a) If I take a 398 wide image and scale it by 4.82 to 1920, there are no black bars, but there are distorted pixels.
(b) If I take a 398 wide image and scale it by 4 to 1592, there are no distorted pixels, but there is letterboxing+pillarboxing(windowboxing).
(c) If I take a 480 wide image and scale it by 4 to 1920, there is letterboxing, but no distorted pixels. There is also more viewable area.

In my testing, it seems that (c) is the best. It only results in letterboxing, and avoids worse fates in pixel distortion or windowboxing.


Top
 Profile  
 
PostPosted: Sat Aug 17, 2019 10:26 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 21595
Location: NE Indiana, USA (NTSC)
Graphics in these classic games are drawn for the non-square pixels. The bumpers in Pinball, Samus's morph ball form in Metroid, and the magnifying glass in Dr. Mario are drawn with more pixels vertically than horizontally. This is to let them appear as circles on the TV after the PPU has stretched them.

Some games dynamically stream a map's tiles to VRAM as the camera moves through a level, such as Haunted: Halloween '85 and its sequel. In these games, it will already be harder to fit all the tiles for a given screen into VRAM for 352, let alone 480.

_________________
Pin Eight | Twitter | GitHub | Patreon


Top
 Profile  
 
PostPosted: Sat Aug 17, 2019 12:02 pm 
Offline

Joined: Mon Mar 27, 2006 5:23 pm
Posts: 1524
koitsu: these are real screenshots from bsnes-hd, not mock-ups.

Obviously it's emulator-only, but with a scanline renderer, it's doable.

The screen maps are 512x512, so drawing eg 400x224 instead of 256x224 is just a matter of starting a bit earlier and stopping a bit later. For sprite coordinates, they range from 0-511, so treat -71 to -1 as the new left edge, and 256-327 as the new right edge.

The difficulty is that games aren't updating the tilemaps where it thinks it doesn't matter, nor is it updating sprites on the edges of the screen that it considers offscreen. So you can sometimes get good screenshots as above when the stars align, and sometimes you can't and it's gibberish.

If a ROM hacker were to spend a few weeks per-game, they could update the game logic to treat the screen as being larger and load more of the tilemaps. Throw in some emulator-only new PPU registers to control edge cases (say a game that packs multiple rooms into the same tilemap, hiding them by spacing them just out of view, eg Zelda 3 does this -- so you'd add some registers to force-clip the widescreen areas there and such), and you're good.

As with every enhancement, there's going to be people that love it, and people that hate it. People are welcome to their opinions, but it's pointless to argue about it. Purists can run higan, or configure bsnes to run exactly like higan. And fans can enable all the game-altering enhancements they want. It's doable, so we're doing it.

Here's another one to entice/upset people, by the way: true color 24-bit HDMA gradient effects. This is also a real screenshot, not a mock-up ;)


Top
 Profile  
 
PostPosted: Sat Aug 17, 2019 1:55 pm 
Offline

Joined: Mon Apr 01, 2019 2:34 pm
Posts: 3
On to topic of what width in regards to aspect ratio, one thing to consider would be that all content made visible in widescreen would be purely visual. So, if someone wants to display the games with a 4:3 tile/sprite ratio but still get widescreen, that would be doable with some cropping of the final image.

That is, assuming the patch author doesn't enable normal (on-screen) sprite logic in widescreen for platformers/shmups/etc. IF that's even possible, which is an entire can of worms itself that has bigger questions than dealing with aspect ratios.

Anyway, I think it would generally be better to use whatever width would best map out to widescreen while maintaining a 1:1 PAR, so either preference can be satiated. Or the hacker could "just" make two versions. I'll admit I am biased 100% towards square pixels, because I think it's far too inconsistent between what games actually have content made with 4:3 in mind, let alone all their content, but just my two cents.


Top
 Profile  
 
PostPosted: Sat Aug 17, 2019 2:01 pm 
Offline
User avatar

Joined: Sun Sep 19, 2004 9:28 pm
Posts: 4208
Location: A world gone mad
byuu wrote:
koitsu: these are real screenshots from bsnes-hd, not mock-ups.

Obviously it's emulator-only, but with a scanline renderer, it's doable.

The screen maps are 512x512, so drawing eg 400x224 instead of 256x224 is just a matter of starting a bit earlier and stopping a bit later. For sprite coordinates, they range from 0-511, so treat -71 to -1 as the new left edge, and 256-327 as the new right edge.

The difficulty is that games aren't updating the tilemaps where it thinks it doesn't matter, nor is it updating sprites on the edges of the screen that it considers offscreen. So you can sometimes get good screenshots as above when the stars align, and sometimes you can't and it's gibberish.

Okay, so this is exactly what I tried to cover in my discussion of screen sizes (1, 2, 4). This is entirely per-game. The screenshots are what I would call false advertising, as its giving people misleading/false impressions on a general basis. Effectively romhacking efforts to cater to this design would require deep game engine code be revamped to use 4-screen or "more nuanced" 2-screen. Effort (read: human time) put in to such works would easily exceed that of the benefits. I'll mark this convo as another one to ignore, respectfully.

P.S. -- I notice there are sprites in those screenshots. Sprites X coordinate can only range from 0-511 (it's an 8-bit number where the 8th bit is stored in a different portion of OAM RAM), while Y coordinates can only range from 0-255 (single byte). There's some stuff that doesn't even use the 8th bit of X (range capped to 0-255). Look forward to seeing how people "solve" that.


Top
 Profile  
 
PostPosted: Sat Aug 17, 2019 2:11 pm 
Offline
User avatar

Joined: Mon Jan 23, 2006 7:47 am
Posts: 205
Location: Germany
koitsu wrote:
false advertising
byuu wrote:
every game will require manual reprogramming work

_________________
My current setup:
Super Famicom ("2/1/3" SNS-CPU-GPM-02) → SCART → OSSC → StarTech USB3HDCAP → AmaRecTV 3.10


Top
 Profile  
 
PostPosted: Sat Aug 17, 2019 2:28 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 8564
Location: Seattle
AxlRocks wrote:
I'll admit I am biased 100% towards square pixels, because I think it's far too inconsistent between what games actually have content made with 4:3 in mind, let alone all their content, but just my two cents.
US SNES pixels are always 8:7 PAR (unless they're 4:7, hush you pedant). That things were not redrawn for PAL is not an argument that PAR can be ignored, or at least not an argument that pixels can be made narrower.

SNES pixels are also never nearest neighbor horizontally. SDTV just doesn't have enough bandwidth. So optimizing for an integer scale ratio horizontally is doubly inaccurate.

The smaller the amount of faked overscan, the easier the ROM hacker's task will be. There's good reasons to pick 336x224 with an 8:7 PAR.



The alternative argument is that the amount of achievable fake overscan will depend on the game, so let the ROM hack choose its output width.


Top
 Profile  
 
PostPosted: Sat Aug 17, 2019 8:29 pm 
Offline

Joined: Mon Mar 27, 2006 5:23 pm
Posts: 1524
Quote:
Okay, so this is exactly what I tried to cover in my discussion of screen sizes (1, 2, 4).


If the game scrolls horizontally, then it's using a 512-width or higher tilemap, and can potentially be hacked to support widescreen.

You can try this feature yourself now, good screenshots like above can be made in most games. In Super Mario World the backgrounds almost always work in widescreen; the problem is the sprites don't process in the new widescreen areas.

Quote:
This is entirely per-game.


I said as much.

Quote:
Effort (read: human time) put in to such works would easily exceed that of the benefits.


Possibly. We've had zero takers so far. Then again, MSU1 took a few years to get going, too. It'll be up to other hackers if it's worth doing, and then up to other gamers if it's worth using. It's not up to you or me. DerKoun already made his own fork of bsnes that allows this. People are already using it, bugs and all.

Quote:
P.S. -- I notice there are sprites in those screenshots. Sprites X coordinate can only range from 0-511 (it's an 8-bit number where the 8th bit is stored in a different portion of OAM RAM), while Y coordinates can only range from 0-255 (single byte). There's some stuff that doesn't even use the 8th bit of X (range capped to 0-255). Look forward to seeing how people "solve" that.


I already answered this.


Top
 Profile  
 
PostPosted: Sat Aug 17, 2019 8:58 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 21595
Location: NE Indiana, USA (NTSC)
byuu wrote:
If the game scrolls horizontally, then it's using a 512-width or higher tilemap, and can potentially be hacked to support widescreen.

Even Kirby Super Star, which uses what appears to be a 248-pixel-wide scrolling window?

_________________
Pin Eight | Twitter | GitHub | Patreon


Top
 Profile  
 
PostPosted: Sat Aug 17, 2019 9:42 pm 
Offline
User avatar

Joined: Wed Oct 22, 2008 9:27 pm
Posts: 117
tepples wrote:
Graphics in these classic games are drawn for the non-square pixels. The bumpers in Pinball, Samus's morph ball form in Metroid, and the magnifying glass in Dr. Mario are drawn with more pixels vertically than horizontally. This is to let them appear as circles on the TV after the PPU has stretched them.


Reality is more messy than you think. Take it from someone who has done full library testing of both systems. If you catalogued every drawn symmetrical object in every NES/SNES game, the number of times it was drawn symmetrically would probably be the majority. I can give you some brief examples on the SNES: planets in the Axelay intro, planets on the Gradius III title, items in the LttP inventory:

Attachment:
zelinv.png
zelinv.png [ 1012 Bytes | Viewed 768 times ]


I've even seen games where the background artists did corrective drawing, but sprite artists didn't. In the Space Megaforce intro, the planet is drawn asymmetrically, but then ingame, the large space station pods are drawn symmetrically.

Bottom line, most artists ignored the 17% stretch because it was a perceptibly minor issue due to the small resolution and square tile sizes. And since modern displays all use square pixels now, there no sense in trying to argue for an outputted image that is a mixture of square and rectangular pixels. It looks like crap and trying to mask it away with blur just makes it worse.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 28 posts ]  Go to page 1, 2  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: 93143 and 5 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group