I was wondering if it were possible on the NES to have a level that takes place on a monitor screen in game. I've included a screenshot below to clarify what I mean.
If not that way, is there any roundabout way to trick the NES to do it in a similar way without using sprites?
This should be possible if the background scrolls in 8/16 pixels increments (or if it doesn't scroll at all) in the horizontal direction at least.
Would not look very good though.
You can draw the screen in a way that left-right edges aren't visible, so you won't need sprites to cover the edges.
Would I be able to have the monitor sides as tiles and smooth pixel by pixel scrolling if I made the game not draw the sides of the display of the level itself?
I would be OK with horizontal scroll regions for the top and bottom of the screen where it stays in place and displays the top and bottom of the monitor, but I would prefer if I could have the sides of the monitor in question as well.
Well, perharps you could make prescrolled graphics for the edges, and update it in the nametable every frame. But in this case you have to deal with attributes clash (can be avoided it if only one palette is used for the whole screen, think sepia style), and scroll update area will be visible, which is certainly looks bad.
I suppose I'll try it with sprites first and if I get too much sprite flicker I'll just forgo the sides of the monitor.
A "monitor" screen with borders at left and right like the world map screens in Super Mario Bros. 3? That's certainly possible, though you'll lose a few sprites to drawing the border.
You'd have to use a column of sprites on each side of your "screen" to allow the game window to scroll smoothly, effectively reducing the sprites-per-scanline limit to 6. Also, except for the parts drawn with sprites, the sides of the screen would have to be flat. If those limitations don't bother you, go ahead.
Bregalad wrote:
This should be possible if the background scrolls in 8/16 pixels increments (or if it doesn't scroll at all) in the horizontal direction at least.
Would not look very good though.
For an idea of what this idea of Bregalad's would look like, here's a vid of something I worked on before:
http://blip.tv/slydogstudios/nes-homebr ... 00-5900509
Note that it's going by tile, so 8 pixels, not 16. The downside here is that each of these separate rows that move all keep the same attributes. This means you would have to move by 16, so moving each column over by two instead of one (16 instead of 8) to keep the attributes aligned. I think this would be too jumpy, personally.
Tokumaru's idea is probably the closest you could get, but as he said, it is very, very limiting also. It might even take too many sprites just trying to cover the sides so as to not leave you with enough to work with. It depends on the design of the overall game, I suppose.
Roth wrote:
Tokumaru's idea is probably the closest you could get, but as he said, it is very, very limiting also. It might even take too many sprites just trying to cover the sides so as to not leave you with enough to work with.
I wouldn't use sprites to cover the whole area though... most of it would be background tiles (which means you'd have to clear columns of tiles as the screen scrolls, but if you use an unrolled loop this shouldn't take away a lot of precious VBlank time), the sprites would be there just to mask the transition between the flat area and the game window, which could be off by up to 7 pixels.
Only the areas marked in red would have to be sprites. It's enough to draw some sort of trimming, and if you use 8x16 sprites there will be enough left for the game. There are certainly a number of undesirable limitations, but it might be possible to accommodate them in your design if you really need this effect.
For those keeping count, tokumaru's mockup uses 22 sprites, leaving 42 left for the rest of the game.
tokumaru wrote:
Roth wrote:
Tokumaru's idea is probably the closest you could get, but as he said, it is very, very limiting also. It might even take too many sprites just trying to cover the sides so as to not leave you with enough to work with.
I wouldn't use sprites to cover the whole area though... most of it would be background tiles (which means you'd have to clear columns of tiles as the screen scrolls, but if you use an unrolled loop this shouldn't take away a lot of precious VBlank time), the sprites would be there just to mask the transition between the flat area and the game window, which could be off by up to 7 pixels.
Only the areas marked in red would have to be sprites. It's enough to draw some sort of trimming, and if you use 8x16 sprites there will be enough left for the game. There are certainly a number of undesirable limitations, but it might be possible to accommodate them in your design if you really need this effect.
How does that work? I was sitting here thinking it was to cover the sides because the whole middle would be scrolling. Is there some kind of "nametable showing through in another nametable" trick that I don't know of?
Whenever the screen scrolls 8 pixels, a blank column would be written at the trailing edge (under the sprite column) and the column of newly visible tiles would be written at the leading edge (under the other sprite column).
Yeah, no trick. Like tepples said, just as a part of the level is about to appear from below the sprites on the trailing edge when the screen scrolls, that column is blanked out, so it becomes part of the border.
Another limitation I just thought of is that the border color would either have to be color 0 or be present in every palette.
Given all the limitations, I'd consider this for special parts of a game, but not the entire thing.
Not to be mean...but...
3gengames wrote:
And what's the fun in coding something trivial? Half of the fun is thinking of tricks to achieve things that aren't normally possible.
Agreed, but sometimes there's just a limit to it.
You want trivial? Change SNES to GBA. Use pure C code.
This thread is really interesting.
I belive corlenbelspar never said what mapper he aims at.Why not use MMC5 then? I mean, it may get rid of attributes problem at least.
Like tokumaru, I think it's good for some special part of game, but not for entire game.
Quote:
You want trivial? Change SNES to GBA. Use pure C code.
Not enough trivial for me.Change GBA to NDS and
Palib.Use C++(I think it's easier than pure C) or use
DS Game Maker to "make game with no programming required!".
Even better, design a mapper as complex as MMC5 that can automatically draw this border for you by swapping name tables at the edges. Problem solved!
MottZilla wrote:
Even better, design a mapper as complex as MMC5 that can automatically draw this border for you by swapping name tables at the edges. Problem solved!
Or just ship a decal with each cartridge that the user can cut-to-size-and-affix to their screen.
Quote:
Or just ship a decal with each cartridge that the user can cut-to-size-and-affix to their screen.
This awesome idea is what made the Vectrex such a success in the video game market! ;)
In today's world of cheap printers it might be an idea to have the user print it themselfs....getting pro cut outs made costs money. That being said...it's not actually a horrible idea.
You could also increase the size of the window in the screen and simply disable rendering in the left-hand column of 8 pixels, making this blank column the left edge of the monitor. The on the right side, you can use 8x16 sprites to cover the BG up. That would probably be about 8 to 10 sprites. The downside is that by making a disabled edge of the screen the side of the monitor, you lose the ability to add graphical detail to it, so you are stuck with just a column of color #0. Still an idea, and I thought I'd mention it.