exxos blog - random goings on

[exxos]

Next problem is width=0 still shows a single black pixel line, even with no border

Capture.PNG (1.62 KiB) Viewed 10013 times

I guess if its moved to the end border it shouldn't be visible as such...

[exxos]

More investigation with widths.

WIDTH=0

0.PNG (1.65 KiB) Viewed 10009 times

WIDTH = 1

1.PNG (1.6 KiB) Viewed 10009 times

WIDTH = -1

-1.PNG (1.7 KiB) Viewed 10009 times

WIDTH = 2

2.PNG (1.86 KiB) Viewed 10009 times

So WIDTH = 0 is actually 2 pixels wide

So using WIDTH=1 and moving it to the right border..

yay.PNG (1.73 KiB) Viewed 10009 times

Now means the black bar is now hidden as I wanted!

I see this "trick" might not work with the red bar when I need to hide it though

I guess I only need 1 box, if I can make it red or black "on the fly" then I wouldn't need to mess about as much.

[exxos]

Ahhhh

IMG_0373.JPG (303.22 KiB) Viewed 9978 times

I just debugged the red and black boxes and got this.

Code: Select all

 4594
 4593

So as RED and BLACK are only 1 number different it tallies. So I can in fact do away with having separate red and black boxes!

[exxos]

Anyone work this one out, It worked in GB6, but converting to the new routines I have confused myself

There is basically two sets of calculations. Want to draw the red bar which will always be smaller than 100%.

Code: Select all

x=120 /100 * R

Where X is the width of the boxing pixels. And R is the result which would be 50% for example. I think that works fine...

I have the problem of when it is higher than 100%. IE 400%

So the calculation I had is:

Code: Select all

x=100 / 400 * 120 = 30

So 30 been the difference is probably about right I think. However the calculation should really be outputting the opposite like 70.

EDIT:

Think it's supposed to be more like this.

Code: Select all

	x=100 / r& * 120
	xx=120 - x

EDIT2:

Yep that looks more realistic now .

400.PNG (128.76 KiB) Viewed 9953 times

200.PNG (144.09 KiB) Viewed 9953 times

[exxos]

Now the red is behaving now as well.

Code: Select all

	x=120 /100 * r&
	xx=120 - x

25.PNG (151.14 KiB) Viewed 9950 times

50.PNG (157.66 KiB) Viewed 9950 times

[exxos]

So no more VDI box drawing calls

1.PNG (159.39 KiB) Viewed 9937 times

2.PNG (170.16 KiB) Viewed 9937 times

3.PNG (163.31 KiB) Viewed 9937 times

4.PNG (162.96 KiB) Viewed 9937 times

[exxos]

Next problem is that objects do not scale automatically

I'm sure I read something about drawing modes and scaling somewhere one of these books the other day. But saying that why can't other objects affected

Capture.PNG (90.08 KiB) Viewed 9928 times

[Roberto]

Next problem is that objects do not scale automatically

I'm sure I read something about drawing modes and scaling somewhere one of these books the other day. But saying that why can't other objects affected

Hi @exxos, so would you like to automatically resize and fit all your work to the set resolution? If so, I guess you have to do it by hand, calculating the right proportions (for the objects) for each resolution. For the most part, when I got into VDI calls and so on, I didn't see any handy feature that would allow me to rework objects other than resizing them one by one.

Then I advise you to use interface v2.30 for managing the drop-down menus and managing the graphical GUI. It seems to me the only one reliable enough with less bugs.

[exxos]

Hi @exxos, so would you like to automatically resize and fit all your work to the set resolution? If so, I guess you have to do it by hand, calculating the right proportions (for the objects) for each resolution. For the most part, when I got into VDI calls and so on, I didn't see any handy feature that would allow me to rework objects other than resizing them one by one.

I think you're supposed to have different RSC files for medium and high resolution for example. But as the main window seems to be basically okay then I am not too worried about it.

I may have to just bodge the box sizes based on the vertical resolution or something.

Then I advise you to use interface v2.30 for managing the drop-down menus and managing the graphical GUI. It seems to me the only one reliable enough with less bugs.

I do use interface 2.30. It is a bit more user-friendly than WERKS. However interface tends to crash a lot and seems to be some mutant version between German and English.

[Roberto]

I think you're supposed to have different RSC files for medium and high resolution for example. But as the main window seems to be basically okay then I am not too worried about it.

I may have to just bodge the box sizes based on the vertical resolution or something.

Yes, a .RSC should be done for each resolution, if you are expecting windows or object sizes that won't fit for each resolution.

I do use interface 2.30. It is a bit more user-friendly than WERKS. However interface tends to crash a lot and seems to be some mutant version between German and English.

I tried WERCS and RCP program but they don't work well at all, both on Hatari and on real machines. Let's say Interface is the least worst

I haven't found many C sources for Atari (which have a GUI part) around, other than Peter P.
If it's convenient for you, I'll leave you a source code written in Lattice C that I wrote at the beginning of last year. Maybe you find something interesting that you can adapt to your work (I see you are struggling with how to make an object child of a particular window). There is also the program already compiled.

Screenshot 2023-01-02 alle 19.24.10.png (297.9 KiB) Viewed 9951 times

GRPMOUSE.zip

(189.05 KiB) Downloaded 55 times