OpenEuphoria

2. Re: Rob: Reply about OW 1.4 full-screen issue

• Posted by Vincent <darkvincentdude at yahoo.com> Feb 22, 2006
• 488 views

Robert:

I built a small "Hello World" program in C and compiled using the same compiler
and linker options as EMAKE. I took out one thing from OBJFILES.

FILE C:\EUPHORIA\bin\ec.lib

I compiled it and the program ran in windowed mode. So that makes me think that
there is something in "ec.lib" that is causing Open Watcom to start full-screen?


Regards,
Vincent

4. Re: Rob: Reply about OW 1.4 full-screen issue

• Posted by Vincent <darkvincentdude at yahoo.com> Feb 22, 2006
• 489 views
• Last edited Feb 23, 2006

Robert Craig wrote:
> 
> Thanks.
> 
> I'm not saying that all DOS C programs compiled by OW1.4 will
> go to full screen.
> 
> I identified about 5 different points during the interpreter
> start-up and/or final cleanup which each force it to full screen. 
> If I remove all of them, it won't go to full screen. The trouble is, 
> I can't remove them all. They all do something useful, if not essential.
> 
> What do they have in common? They are all calls to the Watcom
> graphics library. e.g. _getvideoconfig(), _gettextposition(),
> _setactivepage, set_visualpage, _outtext. Most of them will 
> eventually be needed by the Euphoria program, even if they 
> are somehow removed from the startup. For instance, _outtext
> is used when you try to print something on the screen.
> 
> Even if this full-screen annoyance were resolved,
> the only thing OW1.4 has going for it, is a DOS time()
> function that is always fast. With 10.6 the time()
> function can also be fast if you call tick_rate().
> Most programs couldn't care less if time()
> takes a millisecond instead of a microsecond. It normally
> isn't used inside performance-critical sections of code.
> It's just used to measure elapsed time, for benchmarking
> or something. 
> 
> The other advantage, I suppose, is the warm and fuzzy 
> feeling of being up to date with the latest version of Watcom.
> I've established that I can easily have that feeling.
> I just have to type two commands:
>    move watcom watcom10.6
>    move openwatcom watcom
> 
> Thanks for looking into this issue.
> I'm not worried about it anymore.
> 10.6 works fine. 
> I'll investigate OW1.5 whenever it comes out.
> 
> Regards,
>    Rob Craig
>    Rapid Deployment Software
>    <a href="http://www.RapidEuphoria.com">http://www.RapidEuphoria.com</a>

Thats fine. Relax, no need to get all upset over it. I'm not trying to pressure
you to use it. I was just trying to figure it out why it was occuring.

So basically you are saying that it's a problem with the Open Watcom graphics
library? So all the routines you use cause it to switch to full screen mode?

Should I report this to the Open Watcom development team as a bug report? 

If it's in fact a problem and nobody reports it, then it will likely persist in
OW 1.5 and later. So I feel obligated to report it if you consider it improper
operation.


Regards,
Vincent

6. Re: Rob: Reply about OW 1.4 full-screen issue

• Posted by Vincent <darkvincentdude at yahoo.com> Feb 24, 2006
• 519 views

Well I reported it to them and replies just kept on coming (popular thread). The
Open Watcom maintainer Michal Necasek needed alot of convincing to accept that
they are different.

He and others said that the new Watcom graphics library makes calls to VBE (Vesa
Bios Extention) functions that may trigger full-screen under NTVDM.
He basically said that major modifications would need to be made in the graphics
library to "fix" this. So he really isn't willing to play with it, but welcomes
any changes others make in it; but messing with this could break backwards
compatability with all the Open Watcom versions down to 11.0c.

One person pointed this link to me:
http://support.microsoft.com/?scid=kb%3Ben-us%3B812681&x=9&y=14

All interesting ideas. But then some people reported the full-screen problem
with Windows 98 (doesnt use NTVDM), so that may completely invalidate their
diagnosis; I'll test this on my Windows 98 laptop.

What I found interesting in the 11.0c release notes is this:

The graphics library now performs the VESA test before testing for
vendor specific graphics cards. This fix is intended to broaden
the number of graphics cards that are supported.

I'm thinking that maybe this has something to do with it.

Anyway, there seems to be a few solutions to the problem.
You can use the latest Open Watcom and the 10.6 graphics library and it will
produce windowed DOS programs. You can also ofcourse also use Watcom 10.6
altogether.

However despite the full-screen issue, there seems to be some fantasic
advantages with the newer Open Watcom graphics library.

1) Support for many many more graphics cards in SVGA+ mode.
2) Support for *alot* more video modes: upto 1600x1200 @ 32 bit color!
3) Bug fixes and video caching optimizations.

So basically putting the full-screen issue aside, you could very easily extend
DOS Euphoria's pixel graphics to true 32 bit color and super high UXGA resolution
and have support for the vast majority of graphic cards.

So there are choices here to make if you switch to OW in the future. You can
either avoid the full-screen issue or greatly enhance DOS Euphoria's pixel
graphics feature.


Regards,
Vincent

8. Re: Rob: Reply about OW 1.4 full-screen issue

• Posted by Igor Kachan <kinz at peterlink.ru> Feb 24, 2006
• 497 views

Robert Craig wrote:

> 
> Vincent wrote:
> > 

[snip]

> > 1) Support for many many more graphics cards in SVGA+ mode.
> > 2) Support for *alot* more video modes: upto 1600x1200 @ 32 bit color!
> > 3) Bug fixes and video caching optimizations.
> > 
> > So basically putting the full-screen issue aside, you could very easily
> > extend
> > DOS Euphoria's pixel graphics to true 32 bit color and super high UXGA
> > resolution
> > and have support for the vast majority of graphic cards.
> > 
> > So there are choices here to make if you switch to OW in the future. You can
> > either avoid the full-screen issue or greatly enhance DOS Euphoria's pixel
> > graphics
> > feature.
> 
> Thanks a lot for all your work on this.
> This is very interesting information.
> For now I'll stick with 10.6, but you've given me 
> a better idea of the pros & cons.

Hello Robert,

See please code below, it works more than x20 faster with ex_r.exe,
compiled using licensed code and OW1.3 or OW1.4, than with official
ex.exe 2.5. 

I have noticed this thing just now, I never tested
this code on speed, with official ex.exe too.

On ex_r.exe I have 0.879 .. 0.930  sec,
on ex.exe   I have 22.36 .. 22.41  sec.

The machine I use is P4 1.8Gz, nVIDIA videocard.

---draw_01.ex program

-- draw.e lib by Igor Kachan using RDS archive libs.
-- 24.02.2006

sequence vc,lines, color
integer  border, width, height, first, last, row

global procedure init_fill_r()
   vc=machine_func(13,0)--M_VIDEO_CONFIG
     width=vc[5]--VC_XPIXELS
    height=vc[6]--VC_YPIXELS
end procedure

procedure Fill(integer x, integer y)
    object line
    integer xb, xe

    row = y-first+1
    line = lines[row]
    
    xb = x
    while 1 do 
          if not xb or line[xb] = border then exit end if
         xb-= 1 
    end while
    xb+= 1
    
    xe = x+2
    while 1 do 
          if xe > width or line[xe] = border then exit end if
          xe+= 1 
    end while
    xe -= 1
    
    lines[row][xb..xe]=border   -- block them!

      pixel(color[xb..xe],{xb-1,y})

    if y>0 then         -- check line above
	if y-1<first then
	    line = get_pixel({0,y-1,width})
	    lines = prepend(lines, line)
	    first -= 1
	else
	    line=lines[y-first]
	end if
	for i=xb to xe do
	    if line[i] != border then
		Fill(i-1, y-1)
		line=lines[y-first]     -- update!
	    end if
	end for
    end if
    if y<height-1 then  -- check line below too
	if y+1>last then
	    line = get_pixel({0,y+1,width})
	    lines = append(lines, line)
	    last += 1
	else
	    line=lines[y-first+2]
	end if
	for i=xb to xe do
	    if line[i] != border then
		Fill(i-1, y+1)
		line=lines[y-first+2]   -- update!
	    end if
	end for
    end if
end procedure -- Fill()

procedure fill_r
    (
    integer x,  -- start point, horizontal coordinate
    integer y,  -- start point, vertical coordinate
    integer pc, -- paint color
    integer bc  -- border color
    )
    -- fills area outlined by border color with paint color
    -- screen edges are also (default) borders

    if get_pixel({x,y})=bc then
	return      -- exit immediately if start point on border
    end if
-- position(20,1) ?{x,y}
    -- save for use by Fill()
    border = bc
     color = repeat(pc, width) -- solid color
     lines = {get_pixel({0,y,width})}
     first = y
      last = y
      Fill(x,y)
end procedure -- fill_r()

function case_la(integer c, object x)
-- convert Latin atom or sequence to upper or to lower case
 integer d d='a' - 'A'
 if c then return x - (x >= 'a' and x <= 'z') * d
      else return x + (x >= 'A' and x <= 'Z') * d end if
end function -- case_la()

procedure error(integer i, integer t)
  position(1,1)
   if i=1 then
puts(1,"bad operator - " & t & '\n' &
       "               ^ in line S of function Draw(S,X,Y,C)."&
       "\npress Enter to exit program.\n")
elsif i=2 then
puts(1,"bad syntax - " & t & '\n' &
       "             ^ in line S of function Draw(S,X,Y,C)."&
       "\npress Enter to exit program.\n")
  end if
  --i = getc(0)
 abort(i)
end procedure

global function Draw(sequence S,atom X,atom Y,integer C)
integer sx,sy,sv,x,y,p,z,L,t,a,d,I,k,u
sequence s s={}
for i=1 to length(S) do
	t = S[i]
	a = find(t,"CcBbNnUuDdLlRrEeFfGgHhMmPp0123456789+-,; ") 
      if not a then
	  error(1,t)
      else 
	  if t != ' ' and t !=';' then s &= t end if
      end if
end for
s = case_la(0,s)
L = length(s)
d = 0
I = 1
while 1 do
  p = 0
  x = 0 
  y = 0
 sx = 0
 sy = 0
 sv = 0
  t = 0 
  
  if I<=L -- interpretation of a comand
   then u= s[I]
       if not find(u,"cbnudlrefghmp") then error(2,u) end if
    
       if u='c' then k='C'                    -- color
    elsif u='b' then p='B' I+=1 u=s[I]        -- go to
    elsif u='n' then p='N' I+=1 u=s[I] end if -- come back
       
    if find(u,"defghlru") then k = 'D' end if -- moving/drowing --
    if find(u,"ghl") then x =-1 end if -- left-down/left-up/left
    if find(u,"efr") then x = 1 end if -- right-up/right-gown/right
    if find(u,"ehu") then y =-1 end if -- right-up/left-down/down
    if find(u,"dfg") then y = 1 end if -- down/right-down/left-down
    if find(u,"du")  then x = 0 end if -- up/down
    if find(u,"lr")  then y = 0 end if -- left/right
    if u='m' then k = 'M' d=1 a=1 t=1 end if -- to point
    if u='p' then k = 'P' d=1 a=1 t=1 end if -- paint
--  {-1,1} * n -- to do
    I+=1
 
       if k='M'
       or k='P'
     then z=2 -- 2 numbers command parameter
     else z=1 -- 1 number command parameter
   end if
 
      for i=1
       to z -- 1 or 2 numbers of command parameter
       do
       if d=1
       or d=2
     then
       if I>L
     then exit
   end if u=s[I]
       if u='+'
     then t= 1 a=2 I+=1 -- new coordinate is more than old one
    elsif u='-'
     then t=-1 a=2 I+=1 -- new coordinate is less than old one
   end if -- on +/-
   end if -- on d
	     while  1 -- values of comand parameters 
		do  u = s[I] 
		if  u>= '0'
	       and  u<= '9'
	      then  u-= '0'
		if  d = 1 
	      then sx = sx * 10 + u -- 1st half
	     elsif  d = 2
	      then sy = sy * 10 + u -- 2nd half
	      else sv = sv * 10 + u -- single parameter
	    end if  I+= 1
		if  I > L
	      then exit
	    end if
	     elsif  u = ',' -- delimiter of a pair
	      then  d = 2  t = 1  I+=1
	      else exit
	    end if         
	 end while -- end of values
       if d=1
     then sx *= t
    elsif d=2
     then sy *= t
   end if
  end for -- on 
   end if -- on I < L -- interpretation is finished
   
 ----------------------- execution of a command
	     if k='C'-- command 'C'
	   then C=sv -- set up a color
	  elsif k='P'-- command 'P'
	   then fill_r(X,Y,sx,sy) -- filling an area 
	  elsif k='D'-- command 'D'
	   then z=sv
	     if not p -- without a prefix
	   then pixel({C},{X,Y})
	    for i=1
	     to z
	     do X+=x Y+=y  pixel({C},{X,Y})
	end for
	  elsif p='B' -- go without drowing
	   then
	    for i=1
	     to z
	     do X+=x Y+=y
	end for
	  elsif p='N' -- drow and come back
	   then pixel({C},{X,Y})
	    for i=1   -- by pixels
	     to z
	     do X+=x Y+=y pixel({C},{X,Y})
	end for
	    for  i = z -- come back
	     to  1
	     by -1
	     do  X-=x Y-=y
	end for
	 end if k=0 
	  elsif k='M' -- command 'M'
	   then x=sx y=sy
	     if a=2
	   then
	     if not p
	   then machine_proc(2,{C,0,{{X,Y},{X+x,Y+y}}})  X+=x Y+=y
	  elsif p='B'
	   then X+=x Y+=y
	  elsif p='N'
	   then machine_proc(2,{C,0,{{X,Y},{X+x,Y+y}}})
	 end if    
	 end if
	     if a=1
	   then
	     if not p
	   then machine_proc(2,{C,0,{{X,Y},{x,y}}}) X=x Y=y
	  elsif p='B'
	   then X=x Y=y
	  elsif p='N'
	   then machine_proc(2,{C,0,{{X,Y},{x,y}}})
	 end if    
	 end if 
	 k=0 d=0 a=0 end if
	     if I>L then exit end if
   end while -- end of interpetation and execution of the string S
  return {X,Y,C}
end function

procedure next(integer a)
  while get_key()=-1 do end while
  if a then clear_screen() 
  puts(1, "any key to proceed ... \n") 
  end if
end procedure  

object ok

ok=machine_func(5,261)
init_fill_r()
atom T

constant 
Ukg  = "R  3F 1R 2f1r1d1r 3c3e1u2 h1L1u1h1L2H 1l" &
       "6 c1 4g1l2 g2l1 g2d2g2u1e2r1c10e1r2e1r3",
cros = "bu1nu3f1nr3g1nd3h1nl3br1",
UUU  = "m150,240c12m+170,+0c3m200,20",
VVV  = "be9 c2 nm-19,+15 c3 m-15,+19 c12 l4 u100 m 320,290"

puts(1, "any key to proceed ... \n") 

ok = Draw(Ukg, 320,100,15)  next(1)
ok = Draw(cros,320,300,10)  next(1)
ok = Draw(UUU,  200,20,15)  next(1)
     pixel(14,{310,280})
ok = Draw(VVV, 320,280,14)  next(1)
ok = Draw("d3r5br5r5br5nu5nd5r5",50,50,15)  ? ok
ok = Draw("d30r30u30l30br5bd5p2,14",250,250,14) next(1)

puts(1, "the test of speed now ...") 
T=time()
   for j=0 to 600 by 60 do
      for i=1 to 600 by 2 do
	 ok = Draw(Ukg,20+i,80+25*sin(i)+j,12)
      end for
   end for
T=time() - T
position(2,30)
? T

next(1)

ok = machine_func(5,-1)

--- end of draw_01.ex program

I think you'll like OW1.4 more with this example
to go away from your old very good
but obsolete now 10.6.

Yes, there is some minor risk about old archive packages,
but what to do?

Regards,
Igor Kachan
kinz at peterlink.ru

10. Re: Rob: Reply about OW 1.4 full-screen issue

• Posted by Robert Craig <rds at RapidEuphoria.com> Feb 25, 2006
• 497 views

Igor Kachan wrote:
> Robert Craig wrote:
> > Vincent wrote:
> > > 
> 
> [snip]
> 
> > > 1) Support for many many more graphics cards in SVGA+ mode.
> > > 2) Support for *alot* more video modes: upto 1600x1200 @ 32 bit color!
> > > 3) Bug fixes and video caching optimizations.
> > > 
> > > So basically putting the full-screen issue aside, you could very easily
> > > extend
> > > DOS Euphoria's pixel graphics to true 32 bit color and super high UXGA
> > > resolution
> > > and have support for the vast majority of graphic cards.
> > > 
> > > So there are choices here to make if you switch to OW in the future. You
> > > can
> > > either avoid the full-screen issue or greatly enhance DOS Euphoria's pixel
> > > graphics
> > > feature.
> > 
> > Thanks a lot for all your work on this.
> > This is very interesting information.
> > For now I'll stick with 10.6, but you've given me 
> > a better idea of the pros & cons.
> 
> Hello Robert,
> 
> See please code below, it works more than x20 faster with ex_r.exe,
> compiled using licensed code and OW1.3 or OW1.4, than with official
> ex.exe 2.5. 
> 
> I have noticed this thing just now, I never tested
> this code on speed, with official ex.exe too.
> 
> On ex_r.exe I have 0.879 .. 0.930  sec,
> on ex.exe   I have 22.36 .. 22.41  sec.
> 
> The machine I use is P4 1.8Gz, nVIDIA videocard.

I also have a P4 1.8GHz with nVIDIA video card.

Yes, your SVGA demo runs much faster with ex.exe built with
OW 1.4 than with 10.6. And with 10.6 I had to add: use_vesa(1), 
and it still hung up a couple of times.

However, when I tried VGA (mode 18) the speed was the same.

This is useful information.
Maybe you'll eventually convince me to switch.
For now, translator users can use OW1.4 to get much faster 
SVGA graphics than with the interpreter. Their programs 
might run correctly on more graphics cards too.

Regards,
   Rob Craig
   Rapid Deployment Software
   http://www.RapidEuphoria.com

12. Re: Rob: Reply about OW 1.4 full-screen issue

• Posted by Vincent <darkvincentdude at yahoo.com> Feb 25, 2006
• 473 views

Igor Kachan wrote:

> Any one can use bilingual ex_r.exe to get faster
> interpretation for SVGA just now, so the problem
> is not that urgent and you have some time for better
> testing of OW_1.4..1.x, Rob.

Sounds good. What I'll probably do is build and use my own version of official
Euphoria v3.0 interpreters using Open Watcom v1.4 and my free upgrade v3.0 C
back-end source code. Open Watcom v1.5 may have LFN support (not sure yet) and
plenty of other new features and improvements. Robert might become more
interested with that and use it for Euphoria v3.1. We'll have to see how
everything plays out.

> To Vincent: I use just 2 calls of time() in that test,
> so there is almost nothing to do with time() in that program,
> it is not a multitasking one.

Yes... I did a test afterwords and SVGA modes perform 22x faster when compiled
with Open Watcom v1.4 verses Watcom v10.6. As I've mentioned earlier, the newer
graphics library can go beyond SVGA and 256 colors.

> Regards,
> Igor Kachan
> kinz at peterlink.ru


Regards,
Vincent