Jump to content
IGNORED

Benefit of the Window Plane?


Kirk_Johnston

Recommended Posts

Because the window plane takes up part of plane A anyway, and I presume you could alternatively simply not run any scroll code for the scanlines on the part of the screen where you want a HUD without using this built-in window plane feature, what is having the window plane built into the system at some hardware/firmware level actually doing to, I guess, save processing time or whatever? Is the main benefit of this window plane [in general/typical use] more relevant if you're doing a vertical HUD down the left or right sides of the screen, where, I presume, it would be a little more hassle and process-costly making sure that it never scrolled off the screen unintentionally? I think most/all older systems could do static HUDs on part of the screen without a dedicated window plane, so I'm just trying to figure out what having the window plane actually brings to the table [in general/typical use], such that Sega even thought to add it as a standard feature in the first place.

Edited by Kirk_Johnston
Link to comment
Share on other sites

I can only speak for myself and my 3 homebrews Code Eliminator, Game Panic 2 and War in the Machine.  It made it very easy to make a status bar without worrying about sprites blocking stats or the score.  Making a status bar out of sprites would eat into the horizontal sprite pixel budget that I would rather use for more enemies and projectiles.   It made it easy to delineate what planes are used for what.  In WITM I always knew plane B was for the background, plane A was for tile based huge bosses and the Window plane was for stats.  Less mental juggling with trickier techniques made building the game engine tolerable.

Link to comment
Share on other sites

1 hour ago, Gemintronic said:

I can only speak for myself and my 3 homebrews Code Eliminator, Game Panic 2 and War in the Machine.  It made it very easy to make a status bar without worrying about sprites blocking stats or the score.  Making a status bar out of sprites would eat into the horizontal sprite pixel budget that I would rather use for more enemies and projectiles.   It made it easy to delineate what planes are used for what.  In WITM I always knew plane B was for the background, plane A was for tile based huge bosses and the Window plane was for stats.  Less mental juggling with trickier techniques made building the game engine tolerable.

Because plan A was used for the huge bosses but the window plane also uses any part of plane A where the status bar appears (so you can't put any normal plane A background visuals in the same place as a status bar that's done by using the window plane), does that mean the window plane automatically handles any potential display issues with the huge bosses moving into that status bar area of the screen by presumably keeping the status bar in front of the boss tiles at all times as default, or did you simply make sure your huge bosses never moved into the area where the status bar would be anyway, avoiding any potential display issues there, so you effectively split plane A into two separate parts that never overlapped (the status bar at the top or side of the screen done via the window plane and the huge bosses below or to the side of that use the remaining part of plane A that is available)?

 

Regarding the sprites potentially blocking stats or the score, could you not have just made sure all sprites were drawn on top of plane B but behind plane A, or is there a reason they have/had to be above plane A, which means the window plane becomes almost essential in this kind of scenario if you don't want the sprites to visually overlap the status bar like you said?

Edited by Kirk_Johnston
Link to comment
Share on other sites

Not really an expert and not the best at communication.  So, forgive me :)

 

In my experience the Window plane was always the most foreground plane.  Never used the transparency color in any of the tiles on the Window plane to make darn sure nothing would show through.  So, the background scrolled.  The tile based boss scrolled.  Neither messed with the status bar and score on the Window plane.

Link to comment
Share on other sites

1 hour ago, Gemintronic said:

Not really an expert and not the best at communication.  So, forgive me :)

 

In my experience the Window plane was always the most foreground plane.  Never used the transparency color in any of the tiles on the Window plane to make darn sure nothing would show through.  So, the background scrolled.  The tile based boss scrolled.  Neither messed with the status bar and score on the Window plane.

Yeah, so it seems to work that it basically automatically "tells" [in code somewhere] the area of plane A that is used for the status bar to take everything into account with possible visual overlap issues [with any other tiles in plane A, if the background is being moved around, and any sprites and that kind of thing] and just makes sure nothing else displays over that part of the screen where the status bar is being shown. A useful feature and ability to be able to sacrifice part of plane A in order to simplify things around drawing static status bars above everything else and take away some of the hassle of having to do all the code and checks for this manually.

Edited by Kirk_Johnston
  • Like 1
Link to comment
Share on other sites

28 minutes ago, Gemintronic said:

My problem is that I haven't figured out a way to have multiple Window plane areas instead of a section far north, south, east or west.  Say, if I wanted to create a Super Gameboy style border.  Could use up plane A or B just for that but that seems wasteful.

From what I gather, I don't think you can use it beyond the sections you mentioned (although there's probably some way to take advantage of or hack it to do more, maybe, which someone with a deeper understanding of Genesis that I might be aware of). I think that's one of the limitations that comes at the cost of the convenience that it offers.

Edited by Kirk_Johnston
  • Like 1
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...