insert grafic functions

Hello, I have no experience with grafic functions. Is their a possibility to insert grafic functions like call DRAW_LINE_BETWEEN@(IX1,IY1,IX2,IY2,ICOL) into the gray field opend with i=winio@(%ca.....) without border?

winapp 0,0
program test 
include<windows.ins>
integer*4 i
i=winio@('%ca[Berechnung der interpolierten HOAI Werte]&')
i=winio@('%bg[grey]&')
i=winio@('%20nl%nlEnd of window&')
i=winio@('%nl%nl')
end

Thanks Johann

Johann,

No, it isn't part of Clearwin.

Possible close approximations to what you want are as follows:

1. Do part of the window, then use %bx to draw a 3D horizontal line

2. Choose to create a status bar

3. Use a bitmap as window background, or import a bitmap the full width of the window.

I have used 1. a lot, but was disappointed by 2. Option 3. seemed to me to demand too many big bitmaps.

4. Introduce a big, borderless, %gr area, and draw on that.

Eddie

DRAW_LINE_BETWEEN@ is a ClearWin+ routine for drawing to a %gr region in a call to winio@.

Here is my example using %bx:

      WINAPP
      PROGRAM LINEACROSS
      INCLUDE <WINDOWS.INS>
      IA=WINIO@('%ca[Test horizontal line]&')
      IA=WINIO@('Text shown above the line&')
      IA=WINIO@('%bx&', 2.0D0)
      IA=WINIO@('%nlText shown below the line%2nl&')
      IA=WINIO@('%bt[Exit]')
      END
      RESOURCES
      1 24 default.manifest

Eddie

Hello Eddy, thank you for your example, this is a good idea. In the meantime I tried another solution as follows:

winapp 0,0
program test 
include<windows.ins>
integer*4 i,k,ivalue
common/ba/ivalue
external func
ivalue = 0
i=winio@('%ca[Test für Grafikausgabe]&')
i=winio@('%bg[grey]&')
i=winio@('%ta%gr[grey,rgb_colours]&',200L,200L)
do 10 k = 10,120,10
10 CALL draw_line_between@(10,10,50,k,'[black]')
i=winio@('Right end of grafic window&')
i=winio@('%ffBelow end of grafic window&')
i=winio@('%2nl k = %^10rd&',ivalue,func)
i=winio@('%10nl%nlEnd of window&')
i=winio@('%nl%nl')
end
integer*4 function func()
include <windows.ins>
integer*4 ivalue
common/ba/ivalue
write(*,*)ivalue
func = 2
endend

But in the short time, I found no possibilty to change the grafic dynamically after the input. Perhaps you can help me. Thanks

Johann

Hi Johann,

I think I misunderstood your original question (and so did Paul) - I thought that you wanted a separator in an ordinary window.

What your example shows is that you want to draw a graphic in a borderless region with the same background colour as the rest of the window, and you want to update it. That is always done in a %gr region (or %dw or %og).

winapp
program test 
include<windows.ins> 
integer*4 i,k,ivalue, iHandle 
common/ba/ivalue, iHandle 
external func, Kreuz
ivalue = 0 
i=winio@('%ca[Test für Grafikausgabe]&') 
i=winio@('%bg[grey]&') 
i=winio@('%ta%`gr[grey,rgb_colours]&',200L,200L, iHandle) 
do 10 k = 10,120,10 
10 CALL draw_line_between@(10,10,50,k,'[black]') 
i=winio@('Right end of grafic window&') 
i=winio@('%ffBelow end of grafic window&') 
i=winio@('%2nl k = %^10rd&',ivalue,func) 
i=winio@('%10nl%nlEnd of window&') 
i=winio@('%nl%nl%^bt[Kreuz]', Kreuz) 
end 
integer*4 function func() 
include <windows.ins> 
integer*4 ivalue, iHandle 
common/ba/ivalue, iHandle
write(*,*)ivalue 
func = 2 
end func

integer*4 function Kreuz() 
include <windows.ins> 
integer*4 ivalue, iHandle 
common/ba/ivalue, iHandle 
IA = Select_Graphics_Object@ (iHandle)
CALL DRAW_FILLED_RECTANGLE@ (0, 0, 200, 200, RGB@(255, 255, 255) )
CALL DRAW_FILLED_RECTANGLE@ (0, 90, 200, 110, RGB@(255, 0, 0) )
CALL DRAW_FILLED_RECTANGLE@ (90, 0, 110, 200, RGB@(255, 0, 0) )
Kreuz = 2 
end Kreuz

Here I have taken your original code hacked to produce a red cross on a white background in your %gr area if you press the Kreuz button. You need select_graphics_object@ with the %gr region handle if you have multiple %gr areas simultaneously. Here the update is in response to a button press. It could be done by other means. If the graphics object (%gr) is no longer visible, the Select.... call returns an error code.

Eddie

Quoted from Bartl

But in the short time, I found no possibilty to change the grafic dynamically after the input.

Eddie was faster than me...

Just put the code for updating the %gr in some callback function (button, keypress, ...).

Simple but poorly commented Tetris example using multiple %gr areas and Off-screen buffer for drawing

Sorry, it's a little bit unfinished... I am currently trying to write a simple two player network game using FTN95, Clearwin+ and .NET framework.

I wanted to be first!

Putting your creation of graphics in line with all the other WINIO@ calls is OK when it is simple, but looks clumsy if the image is complex. A better strategy is to put the graphics creation in the callback to a %sc format code.

If your %gr area was a bit smaller (200x200 is large for what I will suggest) AND there were a limited range of pictures you wanted to display, then you could use the IMPORT_IMAGE@ routine, and import images of rather complex detail.

Eddie

Quoted from LitusSaxonicum

Putting your creation of graphics in line with all the other WINIO@ calls is OK when it is simple, but looks clumsy if the image is complex. A better strategy is to put the graphics creation in the callback to a %sc format code.

I wanted to keep it out of the %sc callback. The idea was to be able to change a game state on the fly, and I didn't wanted to duplicate the drawing code.

However, the timer callback should be modified to draw the image only once (maybe by adding a WAIT-state for waiting the player input without doing any drawing). Also, it should only refresh the display when necessary.

Jalih,

If you want to hang screen redraws onto a timer %dl, then the delay has to be quite small. The screen redraw routine then has to operate from a set of variables, some of which are changed by user interaction such as button presses, and in a game, some of which (parameters) are changed by the time-dependent aspects of the game itself.

I prefer to call my screen redraw routine after every user action. This demands an initial draw before there is any interaction - and that is via %sc. My screen redraw routines tend to be quite long, as they contain options that may not be executed every time, just as my graphics callbacks have lots of code to cater for all possible click combinations, including some that are screen location specific.

Eddie

Quoted from LitusSaxonicum

If you want to hang screen redraws onto a timer %dl, then the delay has to be quite small. The screen redraw routine then has to operate from a set of variables, some of which are changed by user interaction such as button presses, and in a game, some of which (parameters) are changed by the time-dependent aspects of the game itself.

I ment something like:

    integer function timer_func()
      integer :: i

      ! Default to window update
      timer_func = 1

      select case(gamestate)
        case(INTRO)
          i=select_graphics_object@(g_handle) 
          i=import_image@('splash',0,0)
          status = '*** INTRO ***'
          gamestate = WAITSTATE
        case(WAITSTATE)
          ! No window update necessary 
          timer_func = 2
        case(NEWGAME)
          call init_newgame()
          call reset_keys()
          gamestate = RUNGAME
          ! No window update necessary 
          timer_func = 2
        case(GAMEOVER)
          status = '*** GAME OVER! ***'
          gamestate = WAITSTATE
        case(RUNGAME)
          status = '*** RUNNING ***'
          ! Game loop can run at full speed and update everytime
          call gameloop()
        case(PAUSED)
          status = '*** PAUSED ***'
          gamestate = WAITSTATE
      end select

    end function timer_func

Timer delay has to be small anyway to handle smooth keyboard input and to give necessary resolution for counters used in game timing.

Hi Jalih,

I went away and read your Tetris code. Your timer delay is 1/60 sec, and of course you need this approach because even with no user interaction, the blocks keep falling. In my programs, nothing happens until the user selects a control - more like a game in which the computer and the user take turns.

Your code is elegant and effective. I might not do things the same way. For example where you have a keyboard monitor, and process the small number of key options, I would probably associate a keyboard accelerator %ac with my controlling keypresses. I would not make use of buffered display, but write things to the screen immediately. And so on. Not necessarily better, but an alternative way to do things.

It is almost certain that the original poster was not thinking of anything as sophisticated as your Tetris game!

Eddie

Quoted from LitusSaxonicum

It is almost certain that the original poster was not thinking of anything as sophisticated as your Tetris game!

I wrote a simple but still quite nice example for the original poster:

Analog clock using ClearWin+

Feel free to add resize capability...

EDIT: fixed clock hands...

EDIT: added resize capability myself... 😃

EDIT: added filled polygon hands and hour numbers to the clock frame

Hi, thank you very much for all comments, it's very interesting. Due to all comments I found exact that what I want, see following code as example:

winapp 
program test 
include<windows.ins> 
integer*4 i,ix1,iy1,ix2,iy2, iHandle 
common/ba/ix1,iy1,ix2,iy2, iHandle 
external ienter
ix1 = 20	! values as example
iy1 = 20
ix2 = 150
iy2 = 100
i=winio@('%ca[Test für Grafikausgabe]&') 
i=winio@('%bg[grey]&') 
i=winio@('%`gr[grey,rgb_colours]&',300L,200L, iHandle)
CALL DRAW_FILLED_RECTANGLE@ (0, 0, 300, 200, RGB@(182, 182, 182) )
i=winio@('%ff%2nl x1 = %10rd&',ix1)
i=winio@('%ta y1 = %10rd&',iy1)
i=winio@('%2nl x2 = %10rd&',ix2)
i=winio@('%ta y2 = %10rd&',iy2)
i=winio@('%nl%nlChange grafic with ENTER&')    
i=winio@('%ac[Enter]' ,ienter )
end 
integer*4 function ienter() 
include <windows.ins> 
integer*4 ix1,iy1,ix2,iy2, iHandle 
common/ba/ix1,iy1,ix2,iy2, iHandle 
iHandle = 0
IA = Select_Graphics_Object@ (iHandle) 
CALL DRAW_FILLED_RECTANGLE@ (0, 0, 300, 200, RGB@(182, 182, 182) )
CALL DRAW_RECTANGLE@ (ix1,iy1,ix2,iy2, RGB@(0, 0, 0) )  
call draw_characters@('Test',((ix1+ix2)/2-10),((iy1+iy2)/2),RGB@(0, 0, 0))
ienter = 2
end ienter

It is a great forum, thank you.

Johann

ENTER is OK, but you can update your rectangle with a callback to each %rd:

i=winio@('%ff%2nl x1 = %10^rd&',ix1, ienter ) 
i=winio@('%ta y1 = %10^rd&',iy1, ienter ) 
i=winio@('%2nl x2 = %10^rd&',ix2, ienter ) 
i=winio@('%ta y2 = %10^rd&',iy2, ienter ) 

I tried %co[check_on_focus_loss] but it was better without. Rather than the 'invisible' use of the ENTER key, you would be better having a button, set as the default, marked something like 'Update' (aktualisieren?) with the ienter callback function, i.e.

i=winio@('%`^bt[aktualisieren]', ienter)

as this would be closer to Windows norms and would select in the same way.

Eddie

Hi Eddi, a very good solution, thank you.

It seems that all my ideas can be realized.

Johann

jalih: good job, and by the way your clock is nice advertisement for Clearwin. As well as the source text is the best school by learning on examples. I remember how 20 years ago i was jealous when my colleague among scientific works was also programming nice looking Rolex watch with crystals using Pascal while i with my Fortran couldn't even think about something like this.

Hi, I only can agree. I was surprised about the simple code for the clock, it’s a very good example and a great help for further developments.

For me simple examples are the greatest help. Thank you.

Johann

I have had a quick look at the 'Test für Grafikausgabe' sample which I agree is very useful.

A minor correction is that the call to select_graphics_region@ would be suspect if it were not redundant. The handle should be set before calling winio@ with %gr otherwise it will use the random value that the handle has at that point (which may well be zero). As you probably know already, with only one graphics region, you don't need to provide the handle - ClearWin+ sets it to -1 internally.

It is interesting to note that you can draw to the graphics region before completing the winio@ statements. In all these years I have never tried or thought of doing that!

I remember writing in a thread 'When is a handle not a handle?' about the difference between the functions that RETURN a handle, and the functions that need a handle TO BE SUPPLIED. Paul's note reminds me that this distinction is somewhat blurred, as %gr operates perfectly adequately without a user-supplied handle if there is only one %gr, but really needs user-supplied handles if there is more than one %gr.

I suppose that it never hurts to give a handle an initial value!

Eddie