[Ohrrpgce] Feature: Secondary, stationary overlay

[Bob the Hamster]

On Tue, May 17, 2005 at 02:03:09PM -0400, Mike Caron wrote:
> > I know nothing about using extended memory in QuickBasic, but I know it
> > is theoretically possible. It would have to be XMS and definitely NOT
> > EMS due to horrible horrible compatability problems that EMS introduces
> > (and even then, XMS might cause compat problems too, I don't really
> > know)
> 
> EMS... XMS... I never get them right. I'm refering to the big open
> memory space that is commonly thought of as "reg-u-lar memory" by
> non-techies.

That is protected mode memory, or 32-bit memory.

EMS(older) and XMS(newer) are both methods for 16-bit real-mode programs 
to get access to more memory. Neither of them is the same as the 
regular/32-bit/protected-mode memory that sane programmers use these 
days.

I have a few old DOS games that I really like that use EMS, the most 
notable example being Betrayal at Krondor (which is actually freeware 
now) But getting the thing to run any way other than "Restart In DOS 
Mode" on Windows 98 is near-hopeless (although  I have high hopes that 
someday DosBox will be cool enough to run it.)

XMS is pretty compatable, and would be the only thing worth looking 
at for the OHRRPGCE, although even that ventures further down the path 
of "why not just re-wite the thing in another language" that I am 
willing to tread myself at this moment.

> > Actually, the tile graphics are not stored in conventional memory, they
> > are stored in VGA memory, which although limited in its own ways, does
> > not count against the 640k real-mode DOS limit.
> 
> I know, but I mean we should have an off screen buffer for this. It
> would be slow to copy from system to video memory, but the
> possibilities are nigh endless.

Probably not any slower than the current method of copying from one page 
of VGA memory to another page of VGA memory (and maybe faster for 
DosBox, since the OHR's extremely non-standard Mode-X is a burden for 
DosBox's VGA emulation)

---
Bob the Hamster

> On 5/17/05, Bob the Hamster <Bob at hamsterrepublic.com> wrote:
> > On Tue, May 17, 2005 at 01:21:57PM -0400, Mike Caron wrote:
> > > Say, couldn't we make an array in extended memory (or some
> > > non-conventional memory bank) and draw all the tiles there, etc. and
> > > then draw from that?
> > 
> > I know nothing about using extended memory in QuickBasic, but I know it
> > is theoretically possible. It would have to be XMS and definitely NOT
> > EMS due to horrible horrible compatability problems that EMS introduces
> > (and even then, XMS might cause compat problems too, I don't really
> > know)
> > 
> > Actually, the tile graphics are not stored in conventional memory, they
> > are stored in VGA memory, which although limited in its own ways, does
> > not count against the 640k real-mode DOS limit.
> > 
> > ---
> > Bob the Hamster
> > 
> > > On 5/17/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
> > > >
> > >
> > >
> > > --
> > > Mike Caron
> > > Final Fantasy Q
> > > http://finalfantasyq.com
> > _______________________________________________
> > Ohrrpgce-motherhamster.org mailing list
> > ohrrpgce at lists.motherhamster.org
> > http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
> > 
> 
> 
> -- 
> Mike Caron
> Final Fantasy Q
> http://finalfantasyq.com