wind_get area issue

News,announcements,programming,fixes,game patches & discussions.
Post Reply
User avatar
exxos
Site Admin
Site Admin
Posts: 28616
Joined: Wed Aug 16, 2017 11:19 pm
Location: UK
Contact:

wind_get area issue

Post by exxos »

I thought I would try this function to return the working area of the window for aligning objects better.

Code: Select all

junk=wind_get(our_aeshandle,WF_WORKXYWH,xw,yw,ww,hw)
Now this function does actually sort of work. Only does not seem to take into account the actual borders of the Windows. This is more problematic with 3D sylte windows as the window itself has to be a few pixels larger to accommodate the contents.

So the question is how are you supposed to get around these problems other than what I did before in just adding a few pixels padding around objects. The problem with that is it is difficult to get all the objects to align seamlessly :roll:

There also seems to be some "bug" in MiNT as the object area doesn't calculate correctly.

EG:

mint.PNG
mint.PNG (77.58 KiB) Viewed 3733 times

In TOS:

tos.PNG
tos.PNG (102.86 KiB) Viewed 3733 times

But even TOS manages to miss the bottom/right edges off somehow as well :shrug:
User avatar
stephen_usher
Site sponsor
Site sponsor
Posts: 7454
Joined: Mon Nov 13, 2017 7:19 pm
Location: Oxford, UK.
Contact:

Re: wind_get area issue

Post by stephen_usher »

That's not MiNT itself, that's Xaaes or whatever GEM reimplementation you're running on top.

MiNT doesn't have any GEM functionality in it and only deals with GEMDOS calls.
Intro retro computers since before they were retro...
ZX81->Spectrum->Memotech MTX->Sinclair QL->520STM->BBC Micro->TT030->PCs & Sun Workstations.
Added code to the MiNT kernel (still there the last time I checked) + put together MiNTOS.
Collection now with added Macs, Amigas, Suns and Acorns.
User avatar
exxos
Site Admin
Site Admin
Posts: 28616
Joined: Wed Aug 16, 2017 11:19 pm
Location: UK
Contact:

Re: wind_get area issue

Post by exxos »

stephen_usher wrote: Tue Dec 20, 2022 2:28 pm That's not MiNT itself, that's Xaaes or whatever GEM reimplementation you're running on top.

MiNT doesn't have any GEM functionality in it and only deals with GEMDOS calls.
Yeah meant Xaaes.
User avatar
exxos
Site Admin
Site Admin
Posts: 28616
Joined: Wed Aug 16, 2017 11:19 pm
Location: UK
Contact:

Re: wind_get area issue

Post by exxos »

Decided to just draw a red bar things simple.

So in TOS:

1.PNG
1.PNG (89.32 KiB) Viewed 3726 times

Xaaes

2.PNG
2.PNG (67.73 KiB) Viewed 3726 times

So must be some calculation problem relating to the actual form objects :roll:
User avatar
exxos
Site Admin
Site Admin
Posts: 28616
Joined: Wed Aug 16, 2017 11:19 pm
Location: UK
Contact:

Re: wind_get area issue

Post by exxos »

ahhh same problem as this post (again) viewtopic.php?p=95674#p95674

Have to set the XY in a different function, keep forgetting FFS. Ill write my own wrapper for it all when I got it all sorted cos be way easier in the long run.

Made it worse, but oh well. Progress.

Capture.PNG
Capture.PNG (123.27 KiB) Viewed 3714 times
User avatar
exxos
Site Admin
Site Admin
Posts: 28616
Joined: Wed Aug 16, 2017 11:19 pm
Location: UK
Contact:

Re: wind_get area issue

Post by exxos »

Still does not add up :roll: Even though the red Square clearly defines the internal of the window. When I set the XY location of the main window, it draws in the wrong place. :roll:

"menuy" is just a offset from the height of the menu bar, it is about 12px basically ( totally relevant ) but it also has 8px added on. So the Y offset ends up being 20px.. This would be the equivalent of drawing the red box 20px further down from under the title bar... It does not make sense..

Code: Select all

junk=rsrc_gaddr(0,INFO%,tree&) ' get new tree address

w=getob_width(HARD_BOX2%)  ' get W
h=getob_height(HARD_BOX2%) ' get H

x= (maxw/2) - (w/2) 
y= ((maxh/2) - (h/2))

WINDOW OPEN MAINID,"GEMBENCH 7."+build$+tmp$ ,x,y,w+4,h+menuy+4,&h9

junk=wind_get(our_aeshandle,WF_WORKXYWH,xw,yw,ww,hw) ' get work area of the main window (internal)

setob_y HARD_BOX2%,yw+menuy+8 'set the object location on the screen
setob_x HARD_BOX2%,xw+10

junk=objc_draw(tree&,HARD_BOX2%,7,0,0,0,0) ' draw info box at the internal window dimentions
This is the result of the above code. Granted the X axis is a little out.. but not important right now.

1.PNG
1.PNG (105.81 KiB) Viewed 3704 times

Now what *should* work is using the "red square" dimensions with no offsets at all. But this gives this instead.

2.PNG
2.PNG (132.32 KiB) Viewed 3704 times

The only possible thing is that the function to set the window location does not work correctly for some reason :roll:


:dizzy:


EDIT:

I guess it's possible the window (red block) takes into account the menubar size. But the object positioning is absolute on the screen and does not take into account the menubar.But that would not explain the X-axis being out as well :roll:


EDIT2:

But even with offsets it won't work with higher resolutions :roll:

Capture.PNG
Capture.PNG (99.34 KiB) Viewed 3690 times
User avatar
exxos
Site Admin
Site Admin
Posts: 28616
Joined: Wed Aug 16, 2017 11:19 pm
Location: UK
Contact:

Re: wind_get area issue

Post by exxos »

ahhhhhh

I opened the main window then did not work out the AES_handle :headbang:

Code: Select all

static wi_gw1, wi_gw2, wi_gw3, wi_gw4
junk = wind_get ( MAINID, WF_TOP, our_aeshandle, wi_gw2, wi_gw3, wi_gw4 )
This explains why it always seemed to be locating to the actual desktop rather than the GB7 window :lol:

The red box worked because that above code was run before drawing the red box. So I just moved that code up a few lines and voilà :D

Capture.PNG
Capture.PNG (85.94 KiB) Viewed 3688 times

Now just need to sort out the window sizes properly now.

It's taken so long to figure this out I cannot remember why I was doing it now :lol: :roll:
Rustynutt
Posts: 230
Joined: Fri Sep 29, 2017 8:24 am
Location: USA

Re: wind_get area issue

Post by Rustynutt »

That's purdy.
Post Reply

Return to “SOFTWARE PROGRAMMING & DISCUSSION”