BBC BASIC for Windows: Debug window size

BBC BASIC for Windows
General >> General Board >> Debug window size
http://bb4w.conforums.com/index.cgi?board=general&action=display&num=1410372985

Debug window size
Post by malham on Sep 10^th, 2014, 6:16pm

Hello
I am putting together a program that has a 1024x768 BMP file as a background, when I RUN the program the image is off the top of the window, I need to be able to see the whole image to get the MOUSE co-ordinates, I have dragged the window larger but the image can't be moved, I have used MODE 22 to show the whole image but the MOUSE co-ordinates are not accurate having a 30 pixel offset, is it possible to have the window open at a larger size?, once the program is compiled the full image is visible but of course it can't be used to get the MOUSE co-ordinates there doesn't appear to be any way of scrolling the window to see the top of the image, any ideas?

Re: Debug window size
Post by rtr2 on Sep 10^th, 2014, 9:35pm

on Sep 10^th, 2014, 6:16pm, malham wrote:

any ideas?

This extract from the BB4W manual may be helpful:

"Don't be tempted to use a MODE whose nominal dimensions are the same as your display resolution; by the time you've made allowances for the window's title bar and borders, and the task bar, it won't fit! So if your display is set to a resolution of 1024 x 768 don't use a MODE bigger than about 800 x 600 pixels (e.g. MODE 20). If you (exceptionally) want to use the entire screen you can either maximise the window or operate in full screen mode. You should not attempt to achieve the same effect by choosing a MODE larger than will fit."

For a demonstration of scrolling over a canvas larger than the client area of the window see the supplied example program SCROLL.BBC (in the EXAMPLES\GENERAL folder).

Re: Debug window size
Post by DDRM on Sep 11^th, 2014, 08:50am

Hi Malham,

How are you displaying the image? The following appears to work correctly for me with a 1024x768 bitmap:

Code:

      MODE 22
      ON MOUSE PROCwhereamI(@wparam%,@lparam%):RETURN
      *DISPLAY Norwich.bmp
      REPEAT
        MOUSE x,y,z
        IF z>0 THEN PRINT TAB(10,11);x DIV 2,y DIV 2;"  ";
      UNTIL FALSE

      END
      :
      DEFPROCwhereamI(w%,l%)
      PRINT TAB(10,10);l% AND &FFFF,l%>>>16;"  ";
      ENDPROC

I can see the whole image, which exactly fills the working area, and both methods of mouse reporting give the expected answers (MOUSE x,y,z reports from the bottom left, ON MOUSE reports from the top left), but there doesn't appear to be an offset.

Assuming you can see the whole window at once onscreen (so you don't need scrollbars), that should be OK - otherwise you'll need to use g4bau's tip.

I wonder if you are using Windows API commands to position the image, and you are putting it at the top left of the whole window, i.e. behind the title bar etc? That might explain the offset.

Hope that's helpful!

D

Re: Debug window size
Post by rtr2 on Sep 11^th, 2014, 12:47pm

on Sep 11^th, 2014, 08:50am, DDRM wrote:

The following appears to work correctly for me with a 1024x768 bitmap

Well, I don't think a program which uses 100% CPU time and therefore risks causing overheating, and rapid depletion of the battery if present, can be described as "working correctly"!

But putting that to one side, it takes only a small modification to your code to make it fail in the way the OP described:

Code:

      MODE 22
      VDU 26

The addition of the VDU 26 results in a vertical offset of 22 pixels (as measured here) between the two methods of reporting the mouse coordinates. That's one reason why you shouldn't select MODE 22 on a 1024 x 768 display, as the extract from the manual states.

Quote:

I wonder if you are using Windows API commands to position the image, and you are putting it at the top left of the whole window, i.e. behind the title bar etc? That might explain the offset.

What API command are you referring to? The only common coordinate systems used by the Windows API are 'screen coordinates' and 'client coordinates'; I don't know of any API that allows you directly to position an image according to (non-client) 'window coordinates'.

Re: Debug window size
Post by Malvern on Sep 11^th, 2014, 3:20pm

Quote:

a program which uses 100% CPU time and therefore risks causing overheating, and rapid depletion of the battery if present

I have seen this kind of warning many times and it is a bit overblown. Certainly it is not a good idea to tie up the CPU unnecessarily and it does cause extra battery drain but cooking the CPU, really?

On muti-core processors BB4W will not use 100% CPU on all cores unless you have a special program written in assembler to make it do just that.

Commercial machines will always be able to handle 100% CPU usage on all cores so that they can run software such as Microsoft MovieMaker.

Laptops are the most likely problem because people use them on their furnishings and on cat fur so the heatsinks get blocked with crud. But although it is not a good idea to use 100% CPU time on any core unnecessarily the risk of overheating whilst using BB4W is very small indeed.
But before you start video rendering or searching for prime numbers or mining bitcoins on your laptop make sure the air ducts and heatsinks are free of fluff.
And when they do overheat they might shut down abruptly which can cause data corruption on the hard drive but the CPU is usually fine.

Re: Debug window size
Post by malham on Sep 11^th, 2014, 3:43pm

Hello again

All I am doing is using a little loop thus:-

*DISPLAY mypic
REPEAT
MOUSE x,y,z
UNTIL FALSE

Then using the show variables utility to get the co-ordinates.

This puts the bottom left corner of the image at 0,0 but the top 50ish pixels are outside of the debug window when RUN.

I created a grid at 50 pixel spacing as a BMP file and did as above it showed the window height to be 720 pixels.

I have managed a work around by a REPEAT loop to find the MOUSE co-ordinates and printing them to the screen, then a quick compile and I can find the co-ordinates, this is not as quick as doing it from the debug window but it does work
The program its self doesn't use a MODE command it runs in a fixed size window that can only be minimised not maximised, it is basically an interface to a music quiz, it consists of a series of menus that are used to select questions, the questions are all WAV files which are played by the program, everything works as it should.
All of the menus are BMP files and clicking in the right place on them calls the appropriate routine this is where I need the MOUSE co-ordinates. My other option is to resize the BMP files to be 720 not 768 pixels high which would then fit the debug window, this not a problem as the original 1024x768 was used as it fitted the full screen on an old laptop that I was using and was a standard screen ratio.
Many thanks for your replies.

Re: Debug window size
Post by Malvern on Sep 11^th, 2014, 4:01pm

Quote:

REPEAT
MOUSE x,y,z
UNTIL FALSE

You need a WAIT 0 in that loop to stop it hogging the CPU time unnecessarily. Add the WAIT and you will use probably 2% of the CPU time on your program and so make the machine much more responsive to any input or other programs running concurrently.

Re: Debug window size
Post by rtr2 on Sep 11^th, 2014, 5:14pm

on Sep 11^th, 2014, 3:20pm, Malvern wrote:

cooking the CPU, really?

Yes, really! The reason I was alerted to the issue in David's program is that I noticed the CPU fan running noisily, which indicated a high CPU load requiring increased forced cooling. Although the fan should be able to cool the chip efficiently enough to avoid damage in the short term, any dust build-up or increased friction in the bearings can reduce that efficiency. Also, any temperature increase accelerates the ion migration processes which eventually cause modern chips to fail.

Quote:

On multi-core processors BB4W will not use 100% CPU on all cores

My CPU is a single-core (hyperthreaded) processor so BB4W can indeed use 100%. I also commonly run multiple copies of a BB4W program (sometimes up to five simultaneously) so that could fully load a multi-core CPU.

The potential for overheating the CPU is just one of a number of reasons to avoid unnecessarily using 100% CPU, which taken together mean it's a problem which should not be trivialised.

Re: Debug window size
Post by rtr2 on Sep 11^th, 2014, 5:31pm

on Sep 11^th, 2014, 3:43pm, malham wrote:

the top 50ish pixels are outside of the debug window when RUN.

What do you mean by "debug window"? If you are referring to the 'output window' or 'main window' the size of the client area is determined by the MODE (or VDU 23,22...) statement.

From your description I wonder if you are omitting the MODE/VDU and instead using the 'initial window width and height' settings in the Compile dialogue to determine the window size. You should not do that, because it will result in a program which cannot be tested in the IDE.

You can in addition use the settings in the Compile dialogue, in order to prevent a momentary 'flash' of a window of the wrong size, but not as the sole means of determining the size.

So, get your program fully working in the IDE first, which will mean including a MODE/VDU23,22. Only when the program is working to your satisfaction should you compile it, and at that stage you can optionally use the 'initial size' settings.

Quote:

My other option is to resize the BMP files to be 720 not 768 pixels high which would then fit the debug window

No, don't do that. The default size of the 'output window' is not constant, it will vary with your screen size, version of Windows, theme settings etc. So any attempt to match the size of a bitmap (or anything else) to that window is non-portable. You should set the size of the window to match the bitmap.

Re: Debug window size
Post by DDRM on Sep 12^th, 2014, 08:28am

Hi g4bau,

OK, as Malvern says, it should have a WAIT 0 to give the CPU a rest. I was trying to keep the program as simple as possible for maximum clarity, since it was a minimal test of a specific problem, not a "working program" intended to run for more than a minute or two.

VDU26: Ooh, I almost never use that, so I didn't know about that! That's exactly the kind of thing I was thinking about with the non-specific comment about using Windows API commands - that the window as a whole has bits which are outside the "work area" defined by the mode. Since *Display positions the bottom left of the image at the bottom left of the window, I wondered if some other command was being used that positioned the image at the top left, perhaps resulting in the top part being hidden behind the title bar or some other component.

Mode 22 on a 1024x768 display: I wasn't - I have a 1280 x 1024 display, and a mode 22 window works just fine! ;-) I was assuming the OP was in the same boat, since he HAD found solutions whereby he could see the whole image at once in a BB4W window - though I covered the possibility that that wasn't true and that he would need to use the tip you provided about SCROLL.BBC.

I missed the possibility that the problem related to the default output window because the OP specifically said he had tried it with MODE 22,and that is when he saw the problem...

best wishes,

D

Re: Debug window size
Post by rtr2 on Sep 12^th, 2014, 11:11am

on Sep 12^th, 2014, 08:28am, DDRM wrote:

I was trying to keep the program as simple as possible for maximum clarity, since it was a minimal test of a specific problem, not a "working program" intended to run for more than a minute or two.

What you intended might not be what happens! I quite inadvertently left your program running over lunchtime, and when I got back to the office I realised immediately that things weren't right - the fan was screaming and there was a noticeable 'hot' smell (my old Pentium 4 - Netburst architecture - has a horrendous maximum dissipation of about 85 Watts!).

Hopefully no damage was done, and it wouldn't have been your fault if it had, but the addition of a WAIT 1 would have eliminated the risk. Do you really think its inclusion would have significantly compromised the 'simplicity' of your program? Wasn't there a possibility that an inexperienced user would build on your code without appreciating the issue?

Quote:

VDU26: Ooh, I almost never use that, so I didn't know about that!

VDU 26 resets the text and graphics viewports to correspond to the current window (client) dimensions - typically you might use it after maximising or resizing the window to allow you to make use of the increased area. You need to be aware that VDU 26 can, and typically will, alter the relative positioning of graphics (origin at the bottom-left) and ordinary 'VDU 4' text (origin at top-left).

Quote:

Mode 22 on a 1024x768 display: I wasn't - I have a 1280 x 1024 display

I must admit I automatically assumed the OP's display was 1024x768, both because all our desktop PCs (four of them) work at that resolution, and because it would have explained the symptom he described. It was also for a long time the most popular size, but it may no longer be.

But given his later clarification of the symptoms I may well have been wrong in that assumption.

Re: Debug window size
Post by Malvern on Sep 12^th, 2014, 2:56pm

on Sep 12^th, 2014, 11:11am, g4bau wrote:

the fan was screaming and there was a noticeable 'hot' smell (my old Pentium 4 - Netburst architecture - has a horrendous maximum dissipation of about 85 Watts!).

Hopefully no damage was done,

Unlikely, but you could buy another one for �10 now.
Pentium 4's are designed to throttle back performance as the temperature rises above certain thresholds and safely shut down when the silicon gets too hot.
But best clean off your heatsink just the all the same.

If anyone wants more information about what really happens if you run at 100% CPU load then look up the Bitcoin mining sites.
People there run very high loads continuously trying to get rich so there is a lot of advice. Keep your fans running, your heatsink clean and monitor the on-board temperature sensors.

Re: Debug window size
Post by Edja on Sep 12^th, 2014, 3:10pm

Quote:

Keep your fans running, your heatsink clean and monitor the on-board temperature sensors

... or you could add a WAIT 1 to your code, as suggested.

Re: Debug window size
Post by rtr2 on Sep 12^th, 2014, 4:22pm

on Sep 12^th, 2014, 2:56pm, Malvern wrote:

People there run very high loads continuously trying to get rich so there is a lot of advice. Keep your fans running, your heatsink clean and monitor the on-board temperature sensors.

Certainly, if that's what you use your PC for, but nobody should need to do it simply to run a trivial 'BBC BASIC for Windows' program!

Another good place to find information is the 'overclocking' sites, where the consequences of running the CPU faster and hotter than intended are discussed. In particular you will find confirmation that the accelerated electromigration resulting from an elevated core temperature is a genuine phenomenon, which really can shorten the life of the chip.

Re: Debug window size
Post by Malvern on Sep 12^th, 2014, 5:58pm

Quote:

where the consequences of running the CPU faster and hotter than intended are discussed.

So overclocking gets mentioned now. The Microsoft analysis of fault histories that get sent to them suggests that Under-clocking is the best way to increase the life of the PC, and that laptops are more reliable than desktops and brand name PCs are more reliable than "white box." Now that is most likely because of heat related issues and how the manufacturers deal with it. Home brews and "White Box" are more likely to get it wrong.

Why do you keep on implying that running at 100% CPU load implies overheating? Heating, yes, but overheating is going to occur if the heat load is not being removed adequately. There are two parts to this equation and you focus on one.
As a physicist you know the heat flow equations. If the heat sinking capacity is large and the conduction interfaces are good then the chip temperature can easily be kept well below the design maximum silicon temperatures and should be to stop all the things you fear.
If the heat sinking is poor or non-existent or there is bad chip to heat sink conduction then you can overheat on very low loads, but you know that. But even that does not necessarily mean that your CPU will be destroyed. In the majority of cases it will generate and exception and shut down safely. You might get data loss but the CPU will survive. (Otherwise how would Microsoft get the data?)
The heat sink vendors will tell you just how bad the stock heat sinks are and how you are about to fry your PC. It's not true.

Back to BB4W trivial programs. Of course they should not use all the CPU capacity doing nothing useful. I never ever implied that was a good thing.

But your argument is akin to saying you shouldn't go on the Autobahn because your radiator might not be working properly.
And an overheating engine will shorten its life. And now we have added that if you over-rev it it can reduce the life of the engine. So only keep the car (or P4) for going to the shops?

Maybe it is because I majored in thermodynamics and designed heat exchangers for the first couple of years of my professional life that I hold such odd views.

If anyone has actual information about how long a CPU should last under any set of conditions that would be wonderful to see. It is information that does not seem to escape the foundries.

Re: Debug window size
Post by rtr2 on Sep 12^th, 2014, 9:31pm

Quote:

Why do you keep on implying that running at 100% CPU load implies overheating?

You continue to miss the point. We are talking about unnecessarily running at 100% CPU, through the omission of a WAIT statement. That has a number of undesirable consequences:

It slows down other processes/threads running on the same core.
It depletes the battery when that is the source of power.
It uses extra energy and therefore adds to CO2 emissions.
It causes heating, which will shorten the life of the CPU chip.

I have never said that 100% CPU load necessarily causes overheating, but simply that it may cause overheating. Neither you nor I know what proportion of PCs have insufficient or impaired cooling arrangements, such that running at 100% CPU for extended periods may cause damage (which I reiterate may not necessarily be catastrophic failure, but parametric changes caused by ion migration). But what is certain is that some do.

The remainder of your comments and insults are largely irrelevant and do not merit any response from me. I have no idea why you feel the need to be so obnoxious and provocative.