nanogui: Thread: Drawing modes

On Wed, 19 May 1999, Greg Haerr wrote:
> 	I'm pretty certain that we've got to implement the XOR modes, or the
> samples won't work.  (including the cool new one, world)

It seems to work okay, apart from crashing when you right click (the
co-ordinate calculations seem broken). What should it do better? I do
agree though that it would be nice to have different drawing modes, even
though most graphics libraries don't seem to bother with them.

> 	What is ClanLib?

http://www.clanlib.org/

It's a cool cross-platform game library. Not quite as polished as Allegro,
but it's portable to 'doze, X11, GGI, FBcon, SVGALIB, and some others too.
It's written in a combination of C++ and assembly, for optimum
difficulty-to-understand. It uses a nice library called Hermes which
converts things between different bit-depths extremely fast, especially
if you have an MMX processor.

--------------- Linux- the choice of a GNU generation. --------------
: Alex Holden (M1CJD)- Caver, Programmer, Land Rover nut, Radio Ham :
-------------------- http://www.linuxhacker.org/ --------------------

On Wednesday, May 19, 1999 2:28 PM, Alex Holden ####@####.#### wrote:
> On Wed, 19 May 1999, Greg Haerr wrote:
> > 	I'm pretty certain that we've got to implement the XOR modes, or the
> > samples won't work.  (including the cool new one, world)
> 
> It seems to work okay, apart from crashing when you right click (the
> co-ordinate calculations seem broken).

	The reason it crashes is because the bogl code miscalculates the
bogl_yes limit for text draws.  See my bogl library included in nano0.5 for the
fix.  It dies in bogl's assert because world tries to draw at ylocation 480.
I debugged all this in 0.5.


 What should it do better? I do
> agree though that it would be nice to have different drawing modes, even
> though most graphics libraries don't seem to bother with them.

	Well, any newer operating system like windows or mac uses XOR to
draw the rectangles when you play on the desktop.  So XOR is a must.  FYI, the
cool landmine program uses an XOR GC to do all sorts of trickiness.  Check it out.
I have all the sample programs, demo, landmine and world debugged in my submission.
I did it to allow them to be used as a reference port for driver writers, like you're doing...
Also, the demo program uses the ReadArea api when you rightclick in the top box.
This demonstrates readpixel, and that's why I added that.

Basically, I used the demo programs as the means to show me what I had to
add to the driver level.  I added everything until the demos fully worked, which
occured in 0.5pre1.  For instance, the AND and OR modes are still not implemented.


Greg

Greg Haerr ####@####.#### writes:

   On Wednesday, May 19, 1999 12:06 PM, Ben Pfaff ####@####.#### wrote:
   > This is where a generic any-bit-depth driver is especially valuable.

	   Is this what you're trying to do with the new bogl drivers using the variable
   byte-putting procedures?

Yes.

	   This is more what I was suggesting when I talked about trying to combine
   all the bogl 8/16/24/32 bit drivers into one, for maintainability.

Agreed.  I should note at this point that I didn't write the
variable-byte-width driver.  It's by ####@####.#### David
Huggins-Daines (sp?).  I do plan to maintain it.

Alex Holden ####@####.#### writes:

   On Wed, 19 May 1999, Greg Haerr wrote:
   > 	Don't get confused by the "read-modify-write" cycle that the EGA/VGA
   > controllers require for the damned hardware.  It think this is what 
   > you're looking at.  The EGA/VGA doesn't require an rmw cycle for XOR, it
   > requires it for all writes, and the SET, AND, OR, XOR stuff is
   > controlled in yet another hw register.

   Since you keep insisting that it is possible to get around the requirement
   to do RMW, I've looked hard for any code which demonstrates this, but I'm
   sorry to say I've been unable find any. As an example, here is an extract
   from __linear_putpixel8 (the basis of pretty much all operations on 8 bit
   linear devices- the other bit depths all seem to work the same way) from
   allegro:

He might be referring to one (or both) of two different things:

1. Under VGA planar (16-color) modes, there is hardware assistance for
   logical operations, which supports NOP, AND, OR, XOR at the
   hardware level.  You write the desired logical operation to a
   couple of bits in the VGA Data Rotate Register, then perform the
   operations like you would usually, and the device automatically
   does the desired logical operation.

   Unfortunately, you still need to do a read and a write, unless
   there's some clever combination of write mode and register settings
   that I'm missing right now.  You don't necessarily need to do a
   rmw, though: often, due to the VGA architecture, the following does
   just fine:
	volatile char *x;
	...set up registers...
	y = *x; *x = 0x42;
	...finish up...
   i.e., you don't care what gets read from the VGA, and you don't
   care what byte gets written to the VGA; the 0x42 above may be any
   arbitrary byte, which produces identical results.

2. Video RAM is often quite a bit slower than system RAM, so sometimes
   it's faster to keep `video RAM shadow' as a bitmap in system RAM.
   Then, to update the screen image, you rmw the bitmap and just do
   the write to video RAM (as opposed to a read and a write to video
   RAM and none to a bitmap): three memory accesses instead of two,
   but only one really slow memory access rather than two.
-- 
"Let others praise ancient times; I am glad I was born in these."
--Ovid (43 BC-18 AD)

Greg Haerr ####@####.#### writes:

	   I'm talking about the planar modes, which are a pain in the ass.
   I thought you were working on the vga16 driver, which uses the planar modes.
   In the planar mode, the hardware is setup the way I've been describing.

Yeah, but you still need two memory accesses, one to load the latches,
one to store them.  If you've got a fun magic way to avoid this, let
us know!

On Wednesday, May 19, 1999 5:21 PM, Ben Pfaff ####@####.#### wrote:
> Greg Haerr ####@####.#### writes:
> 
> 	   I'm talking about the planar modes, which are a pain in the ass.
>    I thought you were working on the vga16 driver, which uses the planar modes.
>    In the planar mode, the hardware is setup the way I've been describing.
> 
> Yeah, but you still need two memory accesses, one to load the latches,
> one to store them.  If you've got a fun magic way to avoid this, let
> us know!

	No, thats why the |= operator works so well, it generates a read followed
by a write bus cycle...



> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####
> 
> 

Greg Haerr ####@####.#### writes:

   On Wednesday, May 19, 1999 5:21 PM, Ben Pfaff ####@####.#### wrote:
   > Greg Haerr ####@####.#### writes:
   > 
   > 	   I'm talking about the planar modes, which are a pain in the ass.
   >    I thought you were working on the vga16 driver, which uses the planar modes.
   >    In the planar mode, the hardware is setup the way I've been describing.
   > 
   > Yeah, but you still need two memory accesses, one to load the latches,
   > one to store them.  If you've got a fun magic way to avoid this, let
   > us know!

	   No, thats why the |= operator works so well, it generates a read followed
   by a write bus cycle...

Now I'm really confused.  Isn't that still read-modify-write?  It's a
read, followed by modifying the data, followed by a write.  Maybe we
need some better definitions.  How do you define rmw?
-- 
"...In the UNIX world, people tend to interpret `non-technical user'
 as meaning someone who's only ever written one device driver."
--Daniel Pead

> Now I'm really confused.  Isn't that still read-modify-write?  It's a
> read, followed by modifying the data, followed by a write.  Maybe we
> need some better definitions.  How do you define rmw?

	You'e right.  I meant by EGA/VGA rmw that you can use the following
type code (yours) to access video ram.  Note, as you say, that the 0x42 doesn't
matter, as we're talking to latches.

volatile char *x;
	...set up registers...
	y = *x; *x = 0x42;
	...finish up...


	On "other" rmw, it just means that you read memory, modify it, 
and write it back, and the memory retains the written back value, not concerned
with hw latches...

Greg











> -- 
> "...In the UNIX world, people tend to interpret `non-technical user'
>  as meaning someone who's only ever written one device driver."
> --Daniel Pead
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####
> 
>