1. Re: David Cuny's editor/GUI
Rob Craig wrote:
> ...Anyway, if you can send me step-by-step instructions
> for observing the polygon bug, I'd be happy to investigate it.
You can rest a bit easier. Looking at the problem more closely, I'm sure
that the fault is all mine. I'll go into tedious detail here in the hopes
that someone more familiar with VGA cards can help me out here.
The easiest way to observe the error is to use the following file:
-- START OF JUNK.EX
include d_msgbox.e
message_box( "Test", "I'm first" )
-- trace(1)
message_box( "Test", "I'm second" )
message_box( "Test", "I'm third" )
-- END OF JUNK.EX
The first message box appears fine, but those that follow are "messed up".
Now run it again, but un-comment the trace() command. Notice that the colors
for the trace window only show white and gray. Press 'q' to exit the trace
window, and the second dialog appears - this time the colors are correct.
The code that botches up the screen colors turns out to be in my function
graphic_screen_restore(), in SCREEN.E. I'll explain the code later:
------------------------------------------------------------
procedure graphic_screen_restore( sequence s )
-- restore graphic screen from buffer, and release memory
object ptr, offset, bytes, index
ptr = s[1]
offset = s[2]
bytes = s[3]
hide_mouse()
-- prepare video memory for writing
index = 0
for i = 0 to 3 do
Output( 2, #3C4 ) -- write planes
Output( power(2,i), #3C5 ) -- all which plane
mem_copy( VGA_ADDRESS+offset, ptr+index, bytes )
index = index + bytes
end for
free( ptr )
show_mouse()
end procedure
------------------------------------------------------------
If I comment this out, there are no problems with the video. Obviously this
is where the error is.
The above procedure writes back the 4 planes of video memory that I had
stored in a prior function, graphic_screen_save():
------------------------------------------------------------
function graphic_screen_save( sequence s1, sequence s2 )
-- save a VGA graphic screen, return pointer to buffer
object ptr, offset, bytes, index
hide_mouse()
-- add one more line if not first line
-- this takes care of title bars
if s1[1] > 1 then
s1[1] = s1[1] - 1
end if
-- offset
offset = (s1[1]-1) * 80 * cTall
-- bytes
bytes = ((s2[1]+1) * 80 * cTall ) - offset
-- allocate memory for 4 planes
ptr = allocate( bytes * 4 )
-- prepare video memory for reading
index = 0
for i = 0 to 3 do
Output( 4, #3CE ) -- read planes
Output( i, #3CF ) -- which plane
mem_copy( ptr+index, VGA_ADDRESS+offset, bytes )
index = index + bytes
end for
show_mouse()
return { ptr, offset, bytes }
end function
------------------------------------------------------------
Mode 18 is a bit of a pain - you have to address each of the planes
seperately. The problem does not appear in the 256 color mode that most
people are writing their games in. In the higher modes, the video memory can
be addressed linearly.
So what exactly is the problem? I have correctly saved each plane in memory.
When it comes time to restore them, I write each one of them back:
for i = 0 to 3 do -- write planes 0 to 3
Output( 2, #3C4 ) -- telll card a plane write is coming up
Output( power(2,i), #3C5 ) -- select a video plane
The problem is, when the loop is exited, only the last video plane written
to (#3) is active.
When trace() is called, the problem is still apparent - only white and gray
colors appear - those colors assigned to the plane #3. But when trace() is
exited, some call fortuitiously re-activates *all* the planes again.
Can anyone suggest the correct output() to the video card to re-activate all
the planes?
Thanks!
-- David Cuny
