[Ohrrpgce] Feature: Secondary, stationary overlay

[Bob the Hamster]

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