exxos's Atari, Amiga & retro forum

I thought that something gets corrupted when the window goes outside of the visible screen area. Sometimes it acts up after a couple of moves and others 30+. But when trying Hatari with a big resolution, moving the window within the visible area causes it to get nuts after 6 moves.

I think it must be the menu which goes nuts for some reason while moving the window. Maybe your supposed to freeze the menu while moving the window or something :shrug:

EDIT:

Nope, freezing the AES during the move still screws up. :(

Wondering if there is some special event will processing the menu. Because currently it only processes the menu items as a whole. I mean when something is clicked on the GB6 window, I can check it was actually that window which was clicked on and correlate if a button was clicked on in that window. But for the menu, there does not seem to be anything to specify what menu in what program was actually clicked on :shrug:

Looking through those old things called books. One mentions opening a virtual work station. But doesn't really say why.

https://freemint.github.io/tos.hyp/en/v ... l#v_opnvwk

I mean I thought when GEM opens a window, that was the work area. :shrug:

exxos wrote: 21 Dec 2022 17:03 Looking through those old things called books. One mentions opening a virtual work station. But doesn't really say why.

https://freemint.github.io/tos.hyp/en/v ... l#v_opnvwk

I mean I thought when GEM opens a window, that was the work area. :shrug:

If I vaguely remember, the physical/virtual workstation is for the sake of sharing the hardware. GEM/VDI owns the only "physical" work station, and programs request a "virtual" one to do as if they were alone.

sporniket wrote: 21 Dec 2022 20:59 If I vaguely remember, the physical/virtual workstation is for the sake of sharing the hardware. GEM/VDI owns the only "physical" work station, and programs request a "virtual" one to do as if they were alone.

Yeah there was some odness like that in one of the books I was reading earlier. Something to do with making applications work on various machines.

Oddly I cannot even work out how the original GB4 handled window moves etc. does not seem to be anything related to it at all.. Will keep digging as it must be in there somewhere...

Had a quick look and realised I don't seem to need to call obj_draw every time.. Just set the locations. But its caused some odd AES issues with the redraw function, it seems to randomly lose the object and clear the window. There could be bugs in my redraw routines but the odd "random menu clicking" chaos remains.

There is what looks like a function in GB4 to save the screen. To tired to look into it. But maybe your supposed to save the screen so the AES can redraw from that screen.. Only its totally missing in my code.. Will look more tomorrow.

I think this is correct, but still things go nuts :(

I can move the window a couple of times and then it goes blank and starts going nuts. I have taken out the redraw events for the time being as well.

Think I am going down the proverbial rabbit hole with all this somehow :roll:

I started stripping out the Hisoft window functions and is replacing them directly with AES functions. so now my main window opens up fine which it did previously anyway. But now I am stuck because there does not seem to be any obvious way of actually moving a window. The function before was a "WINDOW LOCATE" which is a Hisoft function. But I cannot pass the AES handle to it as it just says bad channel number. Before I would open up a window with Hisoft functions and get the "ID" but obviously this does not match the AES handle. I was trying to avoid swapping between the 2 to rule out some confusion going on.

What few examples I can find in my examples folder for Hisoft, it is confusing because it all mixes up the functions which them further gets mixed up because of the HGK toolkit functions. A lot of it is down to redrawing the window contents after it has moved, but there does not seem to be any way of actually moving it in the first place. The only thing I could do is to close the window and just simply reopen it that the new location. But this does not really seem to be like a good thing to do :roll:

It does not help when TOS104 Behaves differently than XaAES.

In TOS104 moving the window if you pixels in any direction works fine. It messes up when you moved slightly off screen and moved back the entire screen goes white. Which is down to the redraw routine.

XaAES Behaves a bit differently and fills the area which went off the screen in white but does not seem to actually redraw the contents of the window :shrug:


My workaround for this before is to just redraw the entire object but I don't think that's the correct solution.

Redraw routines don't seem to do anything specifically.


This just "whites out" the area to redraw, so assume this is correct, even though it doesn't behave in TOS104.
I will have to look at what INTERSECTION is actually doing. I think it is just calculating the areas to redraw. But where does this information to redraw actually come from ?!

It seems virtually impossible to win with this stuff :pullhair:

I got the background to change colour to red green or blue depending on which redraw event it is doing.

So if I move upwards to a menu and click somewhere below on desktop then it looks like redraw works fine.

However, if moving from right to left in the menus it first placed a square to redraw later ( I don't think it can redraw immediately because it is stuck in the menu stuff ?!)


Then moving to the next menu to the left, the redraw happens and actually redraws over the top of the current menu :roll: :cussing: :cussing:


You would think it is redrawing the whole window as opposed to just a square which would cause that problem. Though the AES is actually setting the squares to redraw in the first place :pullhair: