[Ohrrpgce] Feature: Secondary, stationary overlay

[Bob the Hamster]

On Wed, May 18, 2005 at 08:46:12AM +1200, TeeEmCee wrote:
> > The reason that the current overlay does not seriously slow down the map
> > drawing even when there are a large number of overhead tiles is because
> > the overhead tiles are non-transparent, so it can skip drawing them
> > completely on the first pass. You will notice (almost) no difference in
> > speed when "suspend overlay" is active.
> 
> What? I can't believe it.
> 
>  'DEBUG debug "drawmap"
>  drawmap mapx, mapy, 0, dpage
> ...
>  'DEBUG debug "drawoverhead"
>  IF readbit(gen(), 44, suspendoverlay) = 0 THEN drawmap mapx, mapy, 2, dpage
> 
> I don't see how drawmap is told not to draw overhead tiles the first
> time through.

Excellent question. It has to do with the third argument... and looking 
at the code now, you are right. it does not look right at all. I may be 
needlessly double-drawing overhead tiles.

*digs around in code, scratches head over assembly language*

Yep! There is a bug! The overhead tiles are currently being drawn twice, 
but they don't need to be.

  drawmap x, y, 0, page  ' draws all tiles regardless of overhead
  drawmap x, y, 1, page  ' draws only regular tiles
  drawmap x, y, 2, page  ' draws only overhead tiles

Fixed in subversion. This fix does actually seem to noticably improve 
speed in DosBox... although maybe that is just wishful thinking ;)

> > However, a transparent overlay would slow down the game almost as much
> > as having the screen covered with NPCs.
> 
> Even then, won't it require far less plotscripting, and be a generally
> easier way to do things?

Sure.

---
Bob the Hamster

> TMC
>  
> On 5/18/05, Bob the Hamster <Bob at hamsterrepublic.com> wrote:
> > The cost of another pass is not as great as the cost of actually
> > painting the tiles to the screen.
> > 
> > The reason that the current overlay does not seriously slow down the map
> > drawing even when there are a large number of overhead tiles is because
> > the overhead tiles are non-transparent, so it can skip drawing them
> > completely on the first pass. You will notice (almost) no difference in
> > speed when "suspend overlay" is active.
> > 
> > However, a transparent overlay would slow down the game almost as much
> > as having the screen covered with NPCs.
> > 
> > ---
> > Bob the Hamster
> > 
> > On Tue, May 17, 2005 at 01:56:55PM +1200, TeeEmCee wrote:
> > > Well, people would have to understand that it would be a slow feature,
> > > but in theory, couldn't one suspend overlay to simply counter the
> > > slowdown?
> > >
> > > Actually, how much would the slowdown depend on how many tiles are
> > > actually overhead, verses the cost of doing another pass? Can we
> > > expect much change if the overlay only draws a few tiles?
> > >
> > > TMC
> > >
> > > On 5/17/05, Bob the Hamster <Bob at hamsterrepublic.com> wrote:
> > > > On Tue, May 17, 2005 at 01:08:36AM +1200, TeeEmCee wrote:
> > > > > *jolts list (hopefully) back into discussion*
> > > > >
> > > > > Here's the idea:
> > > > >
> > > > > An extra layer (on a per map basis) above overhead tiles but below
> > > > > textboxes, strings, etc could be used by designers to display icons
> > > > > and useful info such as current weapon, or bars for status
> > > > > indications. I think this would be a pretty cool feature, and prevent
> > > > > alot of pain caused by trying to do this with npc's. People could even
> > > > > put black bars at top and bottom for a wide screen effect :D
> > > > >
> > > > > After the regular overlay is drawn, a second overlay could easily be
> > > > > added with another drawmap call in displayall with transparency. The
> > > > > second overlay could be stationary by using fixed map coordinates, or
> > > > > even using special 16x10 scroll and pass arrays (The memory could come
> > > > > out of limiting the size of any maps with this feature to 31840
> > > > > instead of 32000).
> > > >
> > > > Although I agree that would be cool, I would be concerned that it would
> > > > result in pretty serious slowdown, especially in DosBox, where
> > > > screen-drawing is the speed bottleneck.
> > > >
> > > > > I think not using special arrays would be preferred, because it adds
> > > > > bloat, but otherwise people have to set aside an area of the map for
> > > > > the overlay, where tiles with O set are drawn, but this definitly
> > > > > makes manipulation with plotscripting easier.
> > > >
> > > > Keeping data in separate arrays is only a few bytes more bloaty than
> > > > hacking the data into one existing array-- and the simpler code would
> > > > make up for those few bytes.
> > > >
> > > > > Now, what would be really cool would be the ability to specify some
> > > > > npc's to be drawn over this layer (mouse cursors, prehaps?)
> > > > >
> > > > > Related, I'm wondering why, throughout the code, instead of simply
> > > > > using the commands setpassblock and readpassblock (which are in the
> > > > > assembly code, and just need to be added to allmodex.bi), instead
> > > > > scroll() is swapped with pass() and the commands for reading/writing
> > > > > maptiles are used.
> > > > >
> > > > > TMC
> > > >
> > > > do setpassblock and readpassblock get used at all? *checks* Oh, yes. I
> > > > see that they are not used. I am not sure if I had a reason for doing
> > > > that or not. Using them would be worth it if it results in simpler code
> > > > overall.
> > > >
> > > > ---
> > > > Bob the Hamster
> > > > _______________________________________________
> > > > Ohrrpgce-motherhamster.org mailing list
> > > > ohrrpgce at lists.motherhamster.org
> > > > http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
> > > >
> > > _______________________________________________
> > > Ohrrpgce-motherhamster.org mailing list
> > > ohrrpgce at lists.motherhamster.org
> > > http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
> > _______________________________________________
> > Ohrrpgce-motherhamster.org mailing list
> > ohrrpgce at lists.motherhamster.org
> > http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
> >
> _______________________________________________
> Ohrrpgce-motherhamster.org mailing list
> ohrrpgce at lists.motherhamster.org
> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org