wind_get area issue

News,announcements,programming,fixes,game patches & discussions.
User avatar
exxos
Site Admin
Site Admin
Posts: 28344
Joined: 16 Aug 2017 23:19
Location: UK

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

In TOS:

tos.PNG

But even TOS manages to miss the bottom/right edges off somehow as well :shrug:
You do not have the required permissions to view the files attached to this post.
User avatar
stephen_usher
Site sponsor
Site sponsor
Posts: 7376
Joined: 13 Nov 2017 19:19
Location: Oxford, UK.

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: 28344
Joined: 16 Aug 2017 23:19
Location: UK

Re: wind_get area issue

Post by exxos »

stephen_usher wrote: 20 Dec 2022 14:28 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: 28344
Joined: 16 Aug 2017 23:19
Location: UK

Re: wind_get area issue

Post by exxos »

Decided to just draw a red bar things simple.

So in TOS:

1.PNG

Xaaes

2.PNG

So must be some calculation problem relating to the actual form objects :roll:
You do not have the required permissions to view the files attached to this post.
User avatar
exxos
Site Admin
Site Admin
Posts: 28344
Joined: 16 Aug 2017 23:19
Location: UK

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
You do not have the required permissions to view the files attached to this post.
User avatar
exxos
Site Admin
Site Admin
Posts: 28344
Joined: 16 Aug 2017 23:19
Location: UK

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

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

2.PNG

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
You do not have the required permissions to view the files attached to this post.
User avatar
exxos
Site Admin
Site Admin
Posts: 28344
Joined: 16 Aug 2017 23:19
Location: UK

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

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:
You do not have the required permissions to view the files attached to this post.
Rustynutt
Posts: 230
Joined: 29 Sep 2017 08:24
Location: USA

Re: wind_get area issue

Post by Rustynutt »

That's purdy.

Return to “SOFTWARE PROGRAMMING & DISCUSSION”

Who is online

Users browsing this forum: Baidu [Spider], ClaudeBot, DuckAssistBot and 4 guests