Redrawing the desktop background in AES

C and PASCAL (or any other high-level languages) in here please

Moderators: exxos, simonsunnyboy, Mug UK, Zorro 2, Moderator Team

User avatar
Smonson
Atari nerd
Atari nerd
Posts: 48
Joined: Sat Feb 20, 2016 9:45 am
Location: Canberra
Contact:

Redrawing the desktop background in AES

Postby Smonson » Wed Sep 21, 2016 12:40 pm

Hi guys.

I hope this isn't a silly question. I've just started out with writing some basic programs for windowing in AES, and I ran into a strange problem. I don't know much about it all yet, so it is probably something really obvious.

When I move a window, sometimes there is corruption left on the background image that is redrawn by AES. Example:
Image
In this case I have moved the lower right window up and to the left slightly and a black background is repainted in its wake.

This seems to be happening because I have called vsf_interior(vhandle, 1) in my WM_REDRAW event handler to set a solid fill style for repainting my window contents. When the exposed desktop is repainted, AES also paints it with the same solid fill style rather than the usual 50% grey pattern. If I call vsf_interior(vhandle, 3) instead, then the desktop is filled using one of the predefined fill styles.

I don't know of a way to find out the existing fill style settings, so as far as I know changing it back to its original setting may not be possible.

What do other people do to resolve this situation?

User avatar
Eero Tamminen
Atari God
Atari God
Posts: 1540
Joined: Sun Jul 31, 2011 1:11 pm

Re: Redrawing the desktop background in AES

Postby Eero Tamminen » Wed Sep 21, 2016 6:22 pm

Smonson wrote:I don't know of a way to find out the existing fill style settings, so as far as I know changing it back to its original setting may not be possible.


http://toshyp.atari.org/en/00700a.html#v_opnwk

User avatar
Smonson
Atari nerd
Atari nerd
Posts: 48
Joined: Sat Feb 20, 2016 9:45 am
Location: Canberra
Contact:

Re: Redrawing the desktop background in AES

Postby Smonson » Thu Sep 22, 2016 10:03 am

Thanks for the hint Eero... but I don't understand what the relevance of v_opnwk() is to this problem.

User avatar
exxos
Hardware Guru
Hardware Guru
Posts: 4933
Joined: Fri Mar 28, 2003 8:36 pm
Location: England
Contact:

Re: Redrawing the desktop background in AES

Postby exxos » Thu Sep 22, 2016 10:39 am

I've got the same problem, though not looked at it for months.. Though I think you have to define the clipping area of both the background window and foreground window for the AES to refresh properly. There is a function to do it, but it looked complicated so never actually attempted it.
4MB STFM 1.44 FD- VELOCE+ 020 STE - Falcon 030 CT60 - Atari 2600 - Atari 7800 - Gigafile - SD Floppy Emulator - PeST - various clutter

http://www.exxoshost.co.uk/atari/ All my hardware guides - mods - games - STOS
http://www.exxoshost.co.uk/atari/last/storenew/ - All my hardware mods for sale - Please help support by making a purchase.
http://ataristeven.exxoshost.co.uk/Steem.htm Latest Steem Emulator

User avatar
Smonson
Atari nerd
Atari nerd
Posts: 48
Joined: Sat Feb 20, 2016 9:45 am
Location: Canberra
Contact:

Re: Redrawing the desktop background in AES

Postby Smonson » Thu Sep 22, 2016 11:26 am

That's interesting Exxos! I copied my event handler's redrawing (and thus clipping) algorithm from the book "ATARI ST Application Programming" from Datatech Publications. So the clipping of each of my windows is the intersection of the redraw area rectangle (returned as part of the WM_REDRAW event from evnt_mesag) and each rectangle from the wind_get() rectangle list.

A characteristic of this behaviour is it only happens in specific circumstances: when the two windows overlap, and the top window is moved toward the other window. So you can come toward it from any of the four corners.

User avatar
jfl
Atari Super Hero
Atari Super Hero
Posts: 821
Joined: Tue Jul 18, 2006 10:55 pm
Location: Liège, Belgium
Contact:

Re: Redrawing the desktop background in AES

Postby jfl » Thu Sep 22, 2016 11:58 am

Smonson wrote:When I move a window, sometimes there is corruption left on the background image that is redrawn by AES. Example:
Image
In this case I have moved the lower right window up and to the left slightly and a black background is repainted in its wake.

This seems to be happening because I have called vsf_interior(vhandle, 1) in my WM_REDRAW event handler to set a solid fill style for repainting my window contents. When the exposed desktop is repainted, AES also paints it with the same solid fill style rather than the usual 50% grey pattern. If I call vsf_interior(vhandle, 3) instead, then the desktop is filled using one of the predefined fill styles.

It looks like your vhandle is actually the handle of the desktop, so what you are observing is normal. You need to open a virtual workstation which will give your application its own handle to use with its windows. Look up v_opnvw() (with a 'v' before the 'w').

Cheers,
JFL
Jean-François
GEMDict – GEMClip

User avatar
Smonson
Atari nerd
Atari nerd
Posts: 48
Joined: Sat Feb 20, 2016 9:45 am
Location: Canberra
Contact:

Re: Redrawing the desktop background in AES

Postby Smonson » Thu Sep 22, 2016 1:07 pm

I think I get you. I'm already using v_opnvwk() to get the virtual workstation handle, but it's returning 1 for the handle which is exactly the same as the physical screen ID (from graf_handle()). They should be different IDs, right?

Code: Select all

    screen_phandle = graf_handle(&gr_wchar, &gr_hchar, &gr_wbox, &gr_hbox);
    screen_vhandle = open_vwork(screen_phandle);
    printf("Screen phandle is %d\n", screen_phandle); // returns 1
    printf("Screen vhandle is %d\n", screen_vhandle); // returns 1


Code: Select all

// this is nicked straight out of the book
int16_t Application::open_vwork(int16_t phys_handle)
{
    int16_t work_in[11];
    int16_t work_out[57];
    int16_t new_handle;
    int16_t i;

    for (i = 0; i < 10; i++) {
       work_in[i] = 1;
    }
    work_in[10] = 2;
    new_handle = phys_handle;
    v_opnvwk(work_in, &new_handle, work_out);
    return new_handle;
}

peterlane
Atari maniac
Atari maniac
Posts: 94
Joined: Tue Mar 05, 2013 2:44 pm
Contact:

Re: Redrawing the desktop background in AES

Postby peterlane » Thu Sep 22, 2016 2:42 pm

I haven't come across this specific problem, and the desktop looks after itself in my own programs. In my code (based on Cmanship), I have the following:

Code: Select all

void open_vwork (void) {
        int i;
        int dum;

        app_handle = graf_handle (&dum, &dum, &dum, &dum);   
        work_in[0] = 2 + Getrez ();                         
        for (i = 1; i < 10; work_in[i++] = 1);
        work_in[10] = 2;
        v_opnvwk (work_in, &app_handle, work_out);           
}


Notice how work_in[0] is set. Apparently setting it to 1 can cause problems in some situations.

Note: I use the value of app_handle for VDI calls to draw in the window: that might be worth checking. These different handles can be confusing.

Can you share your complete code?

You might want to look at my guide to GEM programming in C. You will need to alter the examples a bit if you are not using AHCC. See http://peterlane.info/gemguide/html/index.html. Sample programs and a pdf are available from my website http://peterlane.info/firebee.html. I've tested these programs on an STe and Firebee.
Peter Lane
Firebee | STE (4Mb, TOS 2.06)
http://peterlane.info/firebee.html

ThorstenOtto
Captain Atari
Captain Atari
Posts: 152
Joined: Sun Aug 03, 2014 5:54 pm

Re: Redrawing the desktop background in AES

Postby ThorstenOtto » Thu Sep 22, 2016 5:17 pm

I think your redraw problem has already been answered.

For the other question
> I don't know of a way to find out the existing fill style settings, so as far as I know changing it back to its original setting may not be possible

You can use vqf_interior which will return the fill attributes currently in use.

User avatar
Eero Tamminen
Atari God
Atari God
Posts: 1540
Joined: Sun Jul 31, 2011 1:11 pm

Re: Redrawing the desktop background in AES

Postby Eero Tamminen » Thu Sep 22, 2016 8:06 pm

Smonson wrote:Thanks for the hint Eero... but I don't understand what the relevance of v_opnwk() is to this problem.


Sorry, I somehow remembered that it returned in the arrays the default values instead of setting the specified default ones.


Smonson wrote:I'm already using v_opnvwk() to get the virtual workstation handle, but it's returning 1 for the handle which is exactly the same as the physical screen ID (from graf_handle()). They should be different IDs, right?


Looking at EmuTOS code, yes it seems like that, and that 1 is hardcoded as physical workstation number.


peterlane wrote:Notice how work_in[0] is set. Apparently setting it to 1 can cause problems in some situations.


work_in[10] is the coordinate type setting. 1 is reserved (invalid) value. Valid values are 0 for normalized coordinates, and 2 for raster coordinates.


ThorstenOtto wrote:You can use vqf_interior which will return the fill attributes currently in use.


Those will be the ones set by application at workstation open call, or one overridden later, not the system defaults that Smonson was originally asking about. The system defaults might be set also into system line-A structure, but using that doesn't sound very reliable/portable...

User avatar
Smonson
Atari nerd
Atari nerd
Posts: 48
Joined: Sat Feb 20, 2016 9:45 am
Location: Canberra
Contact:

Re: Redrawing the desktop background in AES

Postby Smonson » Fri Sep 23, 2016 3:34 am

Thanks for all the replies and information, guys! I have quite a few things to try tonight after work.

Peterlane, your GEM programming guide has been invaluable to me in getting to this point. I've been re-reading it extensively. Thanks again for putting that work together.

Can you share your complete code?


Sure, I've put it on github: https://github.com/smonson78/ataricc/blob/master/app_window.cpp
But I have to apologise for the fact that it's very rough and some things are not traditional. I've previous been criticised for using vanilla GCC instead of m68k-atari-mint, so I didn't want to get into another coding style style argument.

I saw a note about work_in[0] in the tos.hyp online docs, but I didn't understand it and it contradicted the ATARI ST Application Programming book. I will see if this solves the problem tonight.
work_in[0] Number of the device driver as entered in the ASSIGN.SYS file; the following apply for the screen: x = 2 + Getrez()


ThorstenOtto, I couldn't find vqf_interior but I did see vqf_attributes mentioned on tos.hyp - perhaps this is what you meant. It does return the current fill attributes. This is exactly what I was looking for! Thank you very much for the pointer. If nothing else works, this will surely fix the problem by ensuring that my event handler leaves the settings unmodified when it exits.

Eero Tamminen, I thought the values passed in opn_vwk() were used to set the default fill attributes, rather than return them. This is a case of vague documentation (on tos.hyp), but I'll investigate this tonight and see what I can find.

I was actually looking for the current fill attributes, rather than the default ones. The reason being that I would be able to change the attributes for my redraw handler, then change them back to their original values on exit.

Thanks again for all the help. I'll let you know how I go... :)

User avatar
Smonson
Atari nerd
Atari nerd
Posts: 48
Joined: Sat Feb 20, 2016 9:45 am
Location: Canberra
Contact:

Re: Redrawing the desktop background in AES

Postby Smonson » Sat Sep 24, 2016 12:09 pm

Alright. I've been playing with this all day, and the reason for the strange behaviour is a bug in my vdi() call, which I implemented in inline assembly. The reason it misbehaves is because I didn't think to add "memory" to the clobbered registers list. So GCC was caching variables that had been modified by system calls.

Code: Select all

void vdi()
{
  __asm__ __volatile__
  (
    "move.l %0,%%d1\n\t"
    "move.w #115,%%d0\n\t"
    "trap #2\n\t"
    : /* outputs */
    : "p"(&v) /* inputs */
    : "d0", "d1" /* clobbered regs */ // this should have had "memory" in it
  );
}


I had a look at how GEMLib has done it and they're saving not only d0, d1 and memory, but also d2, a0, a1, and a2. It's unclear to me if this is necessary... tos.hyp states that the ROM routines save all registers.

peterlane
Atari maniac
Atari maniac
Posts: 94
Joined: Tue Mar 05, 2013 2:44 pm
Contact:

Re: Redrawing the desktop background in AES

Postby peterlane » Sat Sep 24, 2016 1:27 pm

Smonson wrote:
Can you share your complete code?


Sure, I've put it on github: https://github.com/smonson78/ataricc/blob/master/app_window.cpp


I was just writing a reply, but I see you seem to have found a fix in your assembler code. I hope that resolves the problem.

Just for the record, when I run my own example program, with no other programs/accessories active, I get screen_phandle (from the call to graf_handle) as 1, and screen_vhandle (after the call to v_openvwk) as 2.

Smonson wrote:The reason being that I would be able to change the attributes for my redraw handler, then change them back to their original values on exit.


BTW, I don't believe you need to revert attributes to their original state for background programs/desktop. Within your own program, you may need to ensure you have the right values set for different window redraws. I assume GEM has a separate attribute set for each virtual workstation.
Peter Lane
Firebee | STE (4Mb, TOS 2.06)
http://peterlane.info/firebee.html

User avatar
Smonson
Atari nerd
Atari nerd
Posts: 48
Joined: Sat Feb 20, 2016 9:45 am
Location: Canberra
Contact:

Re: Redrawing the desktop background in AES

Postby Smonson » Sat Sep 24, 2016 2:00 pm

Peter, it was thanks to your code that I was able to find it. I began with the source for your CLOCKS demo program, ported it across to use my AES libs and then modified it to do the same sequence of VDI calls in the redraw handler that I am using. At the addition of vdi_interior() on a certain line the effect was reproduced. That narrowed it down a lot and I was able to study the disassembly from there. :)

Just for the record, when I run my own example program, with no other programs/accessories active, I get screen_phandle (from the call to graf_handle) as 1, and screen_vhandle (after the call to v_openvwk) as 2.


That's a side-effect of the same problem. GCC had no reason to think that the value of contrl[6] had changed in open_vwk(), so that bit got optimised out:

Code: Select all

   ...
   vdi_control[6] = *handle;
   vdi();
   *handle = vdi_control[6];
   ...


BTW, I don't believe you need to revert attributes to their original state for background programs/desktop. Within your own program, you may need to ensure you have the right values set for different window redraws. I assume GEM has a separate attribute set for each virtual workstation.


I agree, it just seemed a likely explanation for the fact that I could apparently control the fill style for the desktop's redraw handler. The fact that it didn't affect anyone else was a contradiction of that evidence, but I didn't have a clue what else it could be. I'm a bit surprised my program worked as well as it did with such a major bug in it. All part of the fun.

Thanks for taking the time to look into it, everybody who responded.

User avatar
Eero Tamminen
Atari God
Atari God
Posts: 1540
Joined: Sun Jul 31, 2011 1:11 pm

Re: Redrawing the desktop background in AES

Postby Eero Tamminen » Sat Sep 24, 2016 5:23 pm

Smonson wrote:Eero Tamminen, I thought the values passed in opn_vwk() were used to set the default fill attributes, rather than return them


Sorry, if I was unclear. I was saying that after checking docs, I saw I had remembered wrong. I.e. you were right. :-)


Social Media

     

Return to “C / PASCAL etc.”

Who is online

Users browsing this forum: No registered users and 1 guest