It is currently Tue Jun 19, 2018 11:07 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 39 posts ]  Go to page Previous  1, 2, 3  Next
Author Message
PostPosted: Sat Mar 02, 2013 1:09 pm 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7436
Location: Chexbres, VD, Switzerland
Yes, since Simon has to be maked "horizontally" when he enters the door, this trick can't be done by abusing 8-sprite per line limit.
Castlevania does it by placing high priority sprites in front of Simon, but behind the background, therefore the wall is still visible.
This technique could be called "sprite priority reversal" or something like that. Quite a few NES, SNES and GBA games uses this trick (not only Castlevania).

This technique uses only 2 sprites instead of 8 so I can only think it has advantages. I wonder why they didn't use this one in Simon's Quest instead - but then again the sequel is inferior to the original on almost every possible aspect.

Quote:
Why is it 99% of nesdev threads go off-topic by about post #4?

Because it's full of active and passionate people. Forums who are dead and unfrequented does not go off topic, except when there is a spammer that comes post his shit that doesn't get removed because the mods don't even go there any longer.


Top
 Profile  
 
PostPosted: Sat Mar 02, 2013 1:51 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 6342
Location: Canada
Quote:
Why is it 99% of nesdev threads go off-topic by about post #4?


The thread was entirely on-topic until this post. The OP directly brought up the sprite limit issue, and has since asked more questions about it which are being answered.

...sorry for continuing the off-topic discussion.


Top
 Profile  
 
PostPosted: Sat Mar 02, 2013 2:59 pm 
Offline
User avatar

Joined: Sun Sep 19, 2004 9:28 pm
Posts: 3387
Location: Mountain View, CA
Bregalad wrote:
Yes, since Simon has to be maked "horizontally" when he enters the door, this trick can't be done by abusing 8-sprite per line limit.
Castlevania does it by placing high priority sprites in front of Simon, but behind the background, therefore the wall is still visible.
This technique could be called "sprite priority reversal" or something like that. Quite a few NES, SNES and GBA games uses this trick (not only Castlevania).

Ah you're right -- I just tested it. Chances are what I'm remembering is from the days of earlier/older emulators where the sprite priority stuff wasn't implemented (emulated) correctly. In these cases Simon always walked in front of the door. I really should just bow out and let you guys comment on things instead of opening my old, often incorrect, mouth. :-)


Top
 Profile  
 
PostPosted: Sat Mar 02, 2013 4:15 pm 
Offline

Joined: Fri Mar 01, 2013 6:31 pm
Posts: 6
That's an in-depth description for a hack, tepples. Nevertheless, thanks for the insight, though I'm math retarded.

>The games listed above (by multiple people) are the ones I know of, with the addition of one:

Ah! That's okay. No doubt there are others, but I think I'll leave it on unaware of the anomalies it will cause. As long as it's few and not many.

I'll go off-topic here. I was wondering, all older games are 4:3 ratio and all modern games are 16:9, but the data to expand most older games to widescreen is available in-game. Isn't it possible to hack, say, Super Mario Bros. into a natural 16:9 game rather than stretching it? Like what modern HD ports of games are doing. They're able to naturally make the games 16:9 because the data is there, except for anything involving video. Or not, correct me if I'm wrong. :P

But if it's possible, how much effort would it take to do so?


Last edited by Mr. Blah on Sun Mar 03, 2013 11:28 am, edited 1 time in total.

Top
 Profile  
 
PostPosted: Sat Mar 02, 2013 4:52 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 6342
Location: Canada
Well, most NES games tend to be doing a lot of work "just off screen".

To make them 16:9 it's not like you can just display the background tiles that are sitting in VRAM currently. You'd need to reimplement the game (on a non-NES platform) and adjust everything that deals with whether the edges of the screen are. For instance, there's no way on an NES game to specify a sprite that is outside of the 4:3 screen.


Top
 Profile  
 
PostPosted: Sat Mar 02, 2013 5:08 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 20160
Location: NE Indiana, USA (NTSC)
The visible portion of the NTSC NES or Super NES picture is 256x224 with 8:7 pixel aspect ratio, or 256/224*8/7 = 1.31:1 display aspect ratio, close to the 4:3 of classic CRT SDTVs. I can think of two ways to get closer to the desired 1.77:1 DAR of HDTVs without compromising proportion: expand the visible area to 336x224 or crop to 256x164.

Zooming in
PocketNES, an NES emulator for Game Boy Advance, had to squeeze the screen into 240x160 pixels. It had a scaled mode that would compress 213 lines into 160, looking much like what you get when you stretch the standard NES picture to fill an HDTV. It also had an unscaled mode that would follow a location in the NES's RAM that stores the vertical coordinate of the player character and pan the entire emulated display up and down based on this position.

Ports of NES games to Game Boy use essentially the same technique, often with a rearrangement of the status bar to open more space for the action. These include Balloon Kid (GB port of Hello Kitty World for Famicom with all the Sanrio trademarks filed off) and Super Mario Bros. Deluxe. And in some cases, the status bar is made transparent and overlapping part of the playfield, as in Super Mario Advance 4 (GBA port of Super Mario Advance 3).

Zooming out
The NES background display can be set to 512x240 pixels ("horizontal arrangement" or "vertical mirroring") or 256x480 pixels ("vertical arrangement" or "horizontal mirroring"). Scrolling operates by updating the part of the background plane that's offscreen with tiles that will soon become visible.

Image
Animation of updating in Super Mario Bros.


Games using vertical mirroring, such as Super Mario Bros. or Contra, may allow a cheap modification to support widescreen operation. Running the PPU at four pixels per CPU cycle instead of three would allow drawing an extra 40 pixels of background on each side totaling 336x224. Games that make their updates near the edge of the screen, rather than in the center of the offscreen part of the plane, will need to be modified. And as rainwarrior mentioned, sprites will pop in and out of visibility as they go through the extended background.

There is one slight inaccuracy in the animation above: Super Mario Bros. is actually well behaved in this respect, updating in the middle of the offscreen area rather than near the edge.


Top
 Profile  
 
PostPosted: Sat Mar 02, 2013 6:25 pm 
Offline

Joined: Fri Mar 01, 2013 6:31 pm
Posts: 6
>Well, most NES games tend to be doing a lot of work "just off screen".

What kind of work? Preparing code and loading it from the VRAM?

You're very knowledgeable with your consoles/handhelds, tepples. Expanding sounds like the better option, but that's probably an illusion.

In that case, you'd have to be desperate for portability when you're aware of that and still use PocketNES.

>Scrolling operates by updating the part of the background plane that's offscreen with tiles that will soon become visible.

Yes, that's why I was initially thinking it should be possible. The data for horizontal exists, but for some vertical and all stationary games it wouldn't be possible. Like racing games or puzzle games. Is this correct?

>And as rainwarrior mentioned, sprites will pop in and out of visibility as they go through the extended background.

Why's this? Imperfect extending?

Modifying the PPU is all it takes?


Top
 Profile  
 
PostPosted: Sat Mar 02, 2013 6:50 pm 
Offline
User avatar

Joined: Wed Apr 02, 2008 2:09 pm
Posts: 1149
Quote:
Yes, that's why I was initially thinking it should be possible. The data for horizontal exists,

I wouldn't say that. In my game, I only update 8 pixels passed the border. And the leftmost eight pixels that ARE on the screen are hidden (because they're "wrong"), so the resolution is still only 256 pixels. Even if my game were capable of drawing more off screen horizontally (right now it has that ability vertically), you'd still only be able to extend by 8 or 16 pixels because I'd do things in roughly the same way. (If not clear, I only draw one tile past the border vertically even though I could technically do an entire screen. I would only do one tile horizontally even if I could technically do the entire screen horizontally.).

Most games do it like this. It's pretty rare to draw far enough passed the border to do what you're asking.

Even in a game that does draw more as far as background tiles, you still run into an issue with sprites.

They can't be drawn offscreen horizontally. A value of 0 for a hardware sprite's X position is pixel aligned with the left border. A value of 255 is 1 pixel on the right of the screen. You can't do more or less than that. So if the screen is longer than 256 pixels, all the space is inaccessible with the way sprites are mapped. Making a hardware sprite have two bytes for horizontal position could be done, but no existing game would make use of it. They all expect and use one byte.

Edit: NES hardware can be extended via mappers or whatever else, but there's no way I can think of to do this without hacking each individual game you want to extend. Reading again maybe that's what you want to do. I'd say good luck, hacking is a lot of work.

_________________
https://kasumi.itch.io/indivisible


Top
 Profile  
 
PostPosted: Sat Mar 02, 2013 7:44 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7216
Location: Seattle
It's also worth noting that the PAL NES and Dendy native aspect ratio already stretches the screen to look like a letterboxed ≈3:2 DAR. (precisely 1.478613̅)


Top
 Profile  
 
PostPosted: Sat Mar 02, 2013 7:57 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10513
Location: Rio de Janeiro - Brazil
Increasing the horizontal resolution of NES games is much, much harder than getting rid of sprite flicker. Only a handful of games counted on sprites being dropped, but ALL of them counted on the screen being 256 pixels wide.

Like has been said, sprite coordinates are 8-bit, so the highest possible X coordinate of a sprite is 255. If you extend the screen past that, no sprites could ever be in the extended area, unless the emulator was modified to support 9-bit sprite coordinates, and the ROM was hacked to use this feature.

Concerning the background, even though horizontally scrolling games have data to show in the extended area, most games weren't coded to keep more than 1 screen worth of backgrounds active in the PPU. Some games didn't even have that option, because they arranged the VRAM available for backgrounds as a 256x480-pixel area (as opposed to 512x240, which is the other possible configuration), so they didn't have any extra space horizontally. Super Mario Bros. 3 is a good example of such game. All of these games would need to have their background rendering code heavily hacked. This would need to be done for each game individually, it can't be done at the emulator side.

Even if you hacked game by game, there are certain things that would be hard to adapt. For example, what to about boss fights that happen in locked screens? Will there be invisible walls keeping sprites in the center of the screen or will they be able to use the extra space? What if the mechanics of the fights depend on the layout of the background?


Top
 Profile  
 
PostPosted: Sat Mar 02, 2013 8:08 pm 
Offline

Joined: Fri Apr 29, 2011 9:44 pm
Posts: 267
Here is a thought. Is there any way to heuristically deduce that a sprite overflow is intentional or not? If its intentional then hide the sprites, if not, then show them. Obviously wouldn't work in all games, but is there a way that would work for many?


Top
 Profile  
 
PostPosted: Sat Mar 02, 2013 8:41 pm 
Offline
Formerly 65024U

Joined: Sat Mar 27, 2010 12:57 pm
Posts: 2261
I'd guess 8 blank sprites in a row/behind background with the same Y+X coord would work. I put all 8 sprites in my projects right on top of each other.


Top
 Profile  
 
PostPosted: Sat Mar 02, 2013 8:44 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10513
Location: Rio de Janeiro - Brazil
Zelex wrote:
Is there any way to heuristically deduce that a sprite overflow is intentional or not?

If there are a bunch of sprites using the same tile index and the same Y coordinate, I'd say the chances of them being used to cause an overflow are pretty high.


Top
 Profile  
 
PostPosted: Sat Mar 02, 2013 9:55 pm 
Offline
User avatar

Joined: Fri Nov 19, 2004 7:35 pm
Posts: 4050
Gremlins 2 uses sprite overflow masking in a cutscene, and doesn't put them at the same X position, but they do use the same tile and Y coordinate.

_________________
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!


Top
 Profile  
 
PostPosted: Sat Mar 02, 2013 11:01 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10513
Location: Rio de Janeiro - Brazil
Same tile and same Y coordinate could just be one or more moving platforms though...


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

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 7 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