This page is a mirror of Tepples' nesdev forum mirror (URL TBD).
Last updated on Oct-18-2019 Download

Technical viability of this game design

Technical viability of this game design
by on (#183206)
So i'm apparently all about submarines this year.

Here's a quick sketch of an adaption of the russian electro-mechanical arcade machine called "morskoj boj" (literal translation "sea war") - that's whatthis thread was about. It plays somewhat like game b on Radar Mission for Game Boy, but with more focus on timing torpedo launches correctly and being careful with your meagre resources.

This is a rough outline for the periscope view. Half the point is the limited view. The twin sights would be sprites. So would enemy ships, so they are limited to one or maybe two entities per row, which is about right for capturing the feel of the original cabinet game.

When you reemerge to periscope view, your point is fixed, and you 360-scan your surroundings. Thus, the view needs to scroll. That's also how you aim.

The blatant problem here is how i would go about masking the view to the eliptic shape of the periscope while having a crolling background. I'm thinking about overwriting with blacks tiles
if enough far on the edges and and line it with 1 column of black sprites on each side. That means at least half of the 'per row' bandwidth is used up just for that. Then again, it's not a game where enemy sprites are all over you.

Including one preferable layout design-wise, and one which isn't as troublesome (but still - troublesome).

Do you think this is even feasible?
Re: Technical viability of this game design
by on (#183208)
You'd need to update the tiles at the edges.
For rectangular-like edges, you could use one sprite per side to hide an 8px wide strip of background, and that would be sufficient to hide the scroll updates. That leaves you with 6 sprites per scanline.
For round edges, you'd need one solid 8px black sprite, and another curved-edge sprite, then another two sprites on the other side. That leaves you with 4 sprites per scanline.
Alternatively, make the edges scroll with the view and snap back every 8 pixels, that uses no sprites and looks stupid, but may be good enough.

But with a screen that simple, with solid blue for the bottom and solid sky for the top, you might be able to get away with a background that doesn't scroll at all. A movable water line can be done easily with timed horizontal scrolling to switch between two nametables.
Re: Technical viability of this game design
by on (#183210)
It looks like everything you can see through the periscope, save for the water and the sky, is made of sprites, so you could get away with not moving the background at all. If you draw the periscope's border without using color 0, you can draw the sky using color 0 and put all sprites behind the background, meaning they'll only show where there's sky.

The problem is if you need to show sprites in front of the water as well as the sky, since you can only have 1 color 0. It should be possible to change color 0 to another color mid-frame, but that can be a bit tricky. The alternative would be to put high-priority sprites where the periscope meets the water so they'd mask any sprites that go outside of the periscope's view.
Re: Technical viability of this game design
by on (#183211)
tokumaru wrote:
It looks like everything you can see through the periscope, save for the water and the sky, is made of sprites, so you could get away with not moving the background at all.


Good idea! I think this might be a problem, though: The original has a few rocks/banks/islands protruding from the water not seen here. They do 'move' in and out of view when you rotate the scope.

Rocks or the like would in my mind be bg just as sea/sky. In the original, targets are always on the horizon and do always go behind rock formations. I'm not sure if i'd want to keep that 100% true yet but it would help if i get your idea right (because of colour 0).

Do you concider the dual sights sprites or part of bg?

The sea: I think there needs to be a sense of scanning, so if the bg doesn't scroll, the characters in memory must pixel-shifted accordingly when pressing left/right, to provide a sense of movement. I might even want to animate waves, but that's an extra. Gameplay first.

Torpedo lines in water: Not sure how i'd go about it just yet. I guess sprites.

Another feature i might want add is that different missions would have different conditions. That would mean day, night w full moon, starless night, maybe cloudy/foggy, providing different levels of cloaking from destroyers and varied ease of seeing convoy ships. Also an extra, but it would mean a certain level of sky detail. The sky should be no problem, though.


dwedit wrote:
A movable water line can be done easily with timed horizontal scrolling to switch between two nametables.


Pardon me, i'm not sure i got that. Especially the 'timed' part and how it correlates to switching?

Quote:
For rectangular-like edges, you could use one sprite per side to hide an 8px wide strip of background, and that would be sufficient to hide the scroll updates. That leaves you with 6 sprites per scanline.


Which should be the case, if i'm sticking to something close to the original, where enemies/targets would always appear within that frame of rows. 6 would be enough for 1-3 ships simultaneously on the same rows depending on size, distance and orientation. :)
Re: Technical viability of this game design
by on (#183244)
Here's an assessment on masking with sprites over bg, with the twin sights included.
The right column counts sprites per row use, exluding enemy sprites. Even for the four rows that really count, that's no good...
Re: Technical viability of this game design
by on (#183285)
Those totals blow the 64 sprite limit right out of the water. :shock: You can draw blank tiles on the BG for coarse scroll and have only four sprites on every line, but even then, you still don't have enough sprites total.

Can you widen the viewport so that the four "important" rows have no visible mask, like in the first image you posted? You could scroll just them and leave everything else stationary. That's 2 sprites per line for the sights, and only on those four rows.
Re: Technical viability of this game design
by on (#183286)
I think Tokumaru's suggestion to use colour 0 for the sky and water, and then do a mid-screen palette change is a very practical approach. You can save all your sprites for the objects (-1 if you use sprite 0 hit instead of an IRQ for timing), and you could even raise and lower the water level, which would be very cool for a submarine game.
Re: Technical viability of this game design
by on (#183364)
Changing BG0 to switch from sky to water is a neat idea, but you do need to make sure you fit your code as tight as possible in the hblank. Make it a bit too early and you'll see the PPU regs access as garbage graphics. Too late, and you will end up with scrolling glitches. You need to get all these steps as
1) Turn off BG and sprite rendering using $2001
2) Write palette address to $2006 (though high byte can be latched before step (1)
3) Write palette color to $2007
4) Restore scroll position using $2006 and $2005 writes. (as it is a fixed yscroll location with no xscroll, you can probably get away with writing $2006 only and skip the highest fine Y-scroll bit)
5) Turn on BG and sprite rendering using $2001

And even with all those steps carefully optimised, there is the final gotcha: Any midscreen palette change will corrupt the sprites being fetched for the next line. May not actually matter in the image you posted, as none of the sprite candidate objects are actually visible where the sky and water meet. But worth considering if you have any plans to show sprites where you do the midscreen palette change - they will be garbage on the next rendered scanline.

So yeah, mid-screen palette updates totally suck on the NES and you need to be aware of the severe limitations. Blarrg's awesome Consistent frame synchronization method may be of use to lessen them, but would also add complexity to your code. And if you do go down this route of midscreen palette updates, be sure to test it on the real thing, or at least on whatever emulator is now closest to mimicking all the real hardware's wonderful quirks... ;)
Re: Technical viability of this game design
by on (#183366)
Still think you're best off with the static screen, and faking any scrolling with sprites or even software sprites if needed.

Edit: I think we could use better mockups, showing more different kinds of things that could be on the screen.
Re: Technical viability of this game design
by on (#183367)
Bananmos wrote:
And even with all those steps carefully optimised, there is the final gotcha: Any midscreen palette change will corrupt the sprites being fetched for the next line. May not actually matter in the image you posted, as none of the sprite candidate objects are actually visible where the sky and water meet. But worth considering if you have any plans to show sprites where you do the midscreen palette change - they will be garbage on the next rendered scanline.

Hmm, I was not aware that it corrupts sprites. (I must admit I've never tried.) Did we document this anywhere? Is there a thread where this is discussed? I know turning off rendering before pixel 240 on a visible line can cause corruption the next time sprites are enabled. Are you talking about the same thing, or is there an additional effect here?

Bananmos wrote:
Blarrg's awesome Consistent frame synchronization method may be of use to lessen them, but would also add complexity to your code.

That's probably going too far. :P

Edit: Though, if the problem is that disabling rendering also disables sprite rendering (which is needed to render sprites on the next line), maybe as an alternative, instead of enabling all rendering, just enable BG for the top line of the water, and then enable sprites on the next line (by which point it should have done one full cycle of sprite evaluation?) Basically would make the top line of water look "opaque"?
Re: Technical viability of this game design
by on (#183379)
There are threads, but I don't remember where, sorry, not very useful. I remember looking this very thing up here, and deciding against because of the sprite corruption.
Re: Technical viability of this game design
by on (#183380)
rainwarrior wrote:
Edit: Though, if the problem is that disabling rendering also disables sprite rendering (which is needed to render sprites on the next line)

That's indeed the problem. The sprite evaluation is active in one way or another almost all the way through the scanline, during cycles 1..320: https://wiki.nesdev.com/w/images/d/d1/Ntsc_timing.png. When rendering is disabled, all of those operations are skipped.
Re: Technical viability of this game design
by on (#183385)
I'd say NOPE to any kind of mid-screen palette changing. Extremely tight timing requirements, and the effect could be done by switching something else (pattern table, nametable, etc.) in the middle of the screen without artifacts.
Re: Technical viability of this game design
by on (#183386)
Yep... emphasis bits to darken the background comes to mind - although the color change quite subtle, and affects everything rendered (may not be a problem depending on the game's design)
Re: Technical viability of this game design
by on (#183387)
Dwedit wrote:
I'd say NOPE to any kind of mid-screen palette changing. Extremely tight timing requirements

I completely agree that mid-screen palette changes are the devil.

Quote:
and the effect could be done by switching something else (pattern table, nametable, etc.) in the middle of the screen without artifacts.

But then you can't have both the sky and the water use color 0, so you lose the easy masking effect.

Bananmos wrote:
Yep... emphasis bits to darken the background comes to mind - although the color change quite subtle, and affects everything rendered (may not be a problem depending on the game's design)

I thought of that too. If the OP doesn't need complete control over the colors, he could try looking for a good combination of background color and emphasis bits that results in decent colors for the sky and the water. This would be the simplest way, no doubt. The fact that sprites would also be affected by the emphasis bits might not be a big problem if they don't need to cross the water/sky threshold. IIRC, the NES has a black that isn't affected by the emphasis bits, so at least the border can remain consistent.
Re: Technical viability of this game design
by on (#183389)
Oh, looks like there's an playable web version of the original arcade game here

Pretty cool technology... these pre-microprocessor arcade games have always fascinated me, as the effort to create the game logic makes any retro-development of even the early CPUs look like child's play in comparison. And I still find it incredible that the 1974 Wild Gunman was probably the first FMV arcade game.

Anyway, looks like the original arcade game has a very distinct split between sky and water, so I'd say go with the colour emphasis bits solution for splitting...
Re: Technical viability of this game design
by on (#183397)
tokumaru wrote:
IIRC, the NES has a black that isn't affected by the emphasis bits, so at least the border can remain consistent.
(tangent) Colors $xE and $xF are blacks that are unaffected by emphasis. All eight are the same black as color $1D if emphasis is off, but $1D is affected by emphasis.
Re: Technical viability of this game design
by on (#183399)
Bananmos wrote:
Oh, looks like there's an playable web version of the original arcade game here
That's the museum where i took notes. :) The web version is pretty faithful, apart from from the scope being too fast-moving and less precise via mouse (and some other minor details like sound and light) That's something to concider when trying to translate the feeling of rotating manually to d-pad.

AFAIK the title "Morskoj Boj" was used for a number of games, including "battleship" and a board game. A 2 player "co-op or compete" version of the arcade game was named "Torpednaja Ataka" (pretty self-explanatory title).
Quote:
Anyway, looks like the original arcade game has a very distinct split between sky and water, so I'd say go with the colour emphasis bits solution for splitting...


That's my reasoning too, after reading the discussion. I'm still on the fence if i want to keep that aspect true or add a little variation, like they did in Radar Mission. I suppose it could look good enough as long as no ship is intersecting the sky/water line, or as long as the intersecting colour is black.
Quote:
Pretty cool technology... these pre-microprocessor arcade games have always fascinated me

They had plenty of that in their collection, for historical reasons. Mixed parts of mechanical, discrete, and just sometimes microprocessor topologies. I could upload a photo report in the general section if anyone's interested.
tokumaru wrote:
I thought of that too. If the OP doesn't need complete control over the colors

A distinct feature of the arcade version is that the sky quickly fades to dark-red for about a second when something is hit. But emphasis may help with that, too, either by damping non-reds in the sky or changing bg0 to red-ish and damp reds in the water (which should be a little more dynamic, animation-wise and atari 2600 style). It's worth trying out at least!
Quote:
IIRC, the NES has a black that isn't affected by the emphasis bits, so at least the border can remain consistent.
+
lidnariq wrote:
(tangent) Colors $xE and $xF are blacks that are unaffected by emphasis. All eight are the same black as color $1D if emphasis is off, but $1D is affected by emphasis.

My understanding is that NES "empasis" is subtractive rather than true additive emphasis. If that's the case, is there enough colour value to subtract from $1D for the eye to detect a difference? Not that it matters if $xE and $xF are excluded, but for the sake of knowing.
Dwedit wrote:
I'd say NOPE to any kind of mid-screen palette changing.

Yeah, that's super-far beyond my confidence level, to begin with. :shock:
Also, i only have two PAL units to do hardware tests on.
rainwarrior wrote:
and you could even raise and lower the water level, which would be very cool for a submarine game.

I had this in mind and had hoped to find an easy way to do this! Besides diving/surfacing, a sinusoid function with varying amplitude applied to sprites and emphasis timing would yield a good sense of weather conditions (and bleed slightly into the domain of perception based game/difficulty mechanics) as the submarine should bob along rough waves when @ periscope depth.
rahsennor wrote:
Can you widen the viewport so that the four "important" rows have no visible mask, like in the first image you posted? You could scroll just them and leave everything else stationary. That's 2 sprites per line for the sights, and only on those four rows.

That seems to be the only viable option for using sprites as masks. However, after reading this very helpful discussion, it seems i can get closer to what i want with BG masking sprites.
Re: Technical viability of this game design
by on (#183400)
WheelInventor wrote:
My understanding is that NES "empasis" is subtractive rather than true additive emphasis.
From an RGB point of view, that's mostly accurate. Each emphasis bit will shift the full set of colors in the YUV/YCbCr colorspace towards its own specific coordinate. Combinations of bits are not purely linear.


Quote:
If that's the case, is there enough colour value to subtract from $1D for the eye to detect a difference?
This is where the analog-ness of CVBS (composite) makes everything a big fat hairy mess.

On many CRT TVs, $0E black isn't "no light". But it is the darkest that the signal is ever supposed to be.

Using $1D as the background color and turning on emphasis will either be "blacker than black", causing the blacks to look "richer", or it might will tickle the dynamic range compression and make every other color brighter, or both. Plus it might also tickle the same problem as using color $0D, causing a loss of hsync in some TVs.
Re: Technical viability of this game design
by on (#183402)
Bananmos wrote:
Yep... emphasis bits to darken the background comes to mind - although the color change quite subtle, and affects everything rendered (may not be a problem depending on the game's design)

That's a good idea!
Re: Technical viability of this game design
by on (#183403)
My TV can even display 0D (blacker than black) with emphasis bits set as a shade distinct from the other blacks.