It is currently Mon Dec 18, 2017 5:31 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 21 posts ]  Go to page 1, 2  Next
Author Message
PostPosted: Mon Nov 21, 2016 12:00 pm 
Offline
Formerly WheelInventor

Joined: Thu Apr 14, 2016 2:55 am
Posts: 1135
Location: Gothenburg, Sweden
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?


Attachments:
File comment: lighter design
morskoj boj wide.bmp
morskoj boj wide.bmp [ 30.12 KiB | Viewed 2448 times ]
File comment: preferred design
morskoj boj.bmp
morskoj boj.bmp [ 30.12 KiB | Viewed 2448 times ]

_________________
http://www.frankengraphics.com - personal NES blog
Top
 Profile  
 
PostPosted: Mon Nov 21, 2016 12:09 pm 
Offline
User avatar

Joined: Fri Nov 19, 2004 7:35 pm
Posts: 3969
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.

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


Top
 Profile  
 
PostPosted: Mon Nov 21, 2016 1:07 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10172
Location: Rio de Janeiro - Brazil
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.


Top
 Profile  
 
PostPosted: Mon Nov 21, 2016 1:58 pm 
Offline
Formerly WheelInventor

Joined: Thu Apr 14, 2016 2:55 am
Posts: 1135
Location: Gothenburg, Sweden
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. :)

_________________
http://www.frankengraphics.com - personal NES blog


Top
 Profile  
 
PostPosted: Tue Nov 22, 2016 4:26 am 
Offline
Formerly WheelInventor

Joined: Thu Apr 14, 2016 2:55 am
Posts: 1135
Location: Gothenburg, Sweden
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...


Attachments:
morskoj boj_spriteuse.bmp
morskoj boj_spriteuse.bmp [ 30.12 KiB | Viewed 2311 times ]

_________________
http://www.frankengraphics.com - personal NES blog
Top
 Profile  
 
PostPosted: Tue Nov 22, 2016 8:20 pm 
Offline

Joined: Thu Aug 20, 2015 3:09 am
Posts: 298
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.


Top
 Profile  
 
PostPosted: Tue Nov 22, 2016 8:42 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5899
Location: Canada
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.


Top
 Profile  
 
PostPosted: Wed Nov 23, 2016 6:35 pm 
Offline

Joined: Wed Mar 09, 2005 9:08 am
Posts: 348
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... ;)


Top
 Profile  
 
PostPosted: Wed Nov 23, 2016 7:09 pm 
Offline
User avatar

Joined: Fri Nov 19, 2004 7:35 pm
Posts: 3969
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.

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


Last edited by Dwedit on Wed Nov 23, 2016 7:54 pm, edited 1 time in total.

Top
 Profile  
 
PostPosted: Wed Nov 23, 2016 7:12 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5899
Location: Canada
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"?


Top
 Profile  
 
PostPosted: Thu Nov 24, 2016 3:44 am 
Offline

Joined: Tue Oct 06, 2015 10:16 am
Posts: 610
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.


Top
 Profile  
 
PostPosted: Thu Nov 24, 2016 5:04 am 
Offline
User avatar

Joined: Mon Jan 03, 2005 10:36 am
Posts: 2983
Location: Tampere, Finland
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.

_________________
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: kkfos.aspekt.fi


Top
 Profile  
 
PostPosted: Thu Nov 24, 2016 7:42 am 
Offline
User avatar

Joined: Fri Nov 19, 2004 7:35 pm
Posts: 3969
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.

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


Top
 Profile  
 
PostPosted: Thu Nov 24, 2016 7:55 am 
Offline

Joined: Wed Mar 09, 2005 9:08 am
Posts: 348
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)


Top
 Profile  
 
PostPosted: Thu Nov 24, 2016 8:09 am 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10172
Location: Rio de Janeiro - Brazil
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.


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

All times are UTC - 7 hours


Who is online

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