Is it possible to make a custom MODE where virtual resolution = real resolution?

[p_m21987]

Hello,
Is it possible to make a custom mode in which the number of graphics units equals the number of pixels?

So for example, if the actual window size were 640x480, this would draw an 'X' that fills the whole window:

Code: Select all

MOVE 0,0
DRAW 648,480
MOVE 0,480
DRAW 640,0

Also while I'm at it, is it possible to disable the text wrapping behaviour when printing strings as graphics (that is, after you've done a 'VDU 5' statement), so that text instead just gets clipped off at the edge of the screen and doesn't try to wrap around onto the next line?

Please let me know.
Regards,
- PM

[Hated Moron]

Is it possible to make a custom mode in which the number of graphics units equals the number of pixels?
So for example, if the actual window size were 640x480, this would draw an 'X' that fills the whole window:

Not exactly a 'custom mode', but this is as close as you can get (requires BBC BASIC for SDL 2.0 of course, it can't be done in BB4W):

Code: Select all

      MODE 18
      ORIGIN 0,480
      VDU 24,0;0;639;479;
      @zoom% = &10000

      MOVE 0,0
      DRAW 648,480
      MOVE 0,480
      DRAW 640,0

Since it's done by scaling, everything (including text, and aliasing!) is twice as big as it would normally be. It meets your specification "this would draw an 'X' that fills the whole window" but that limitation may or may not be acceptable to you.

Also while I'm at it, is it possible to disable the text wrapping behaviour when printing strings as graphics (that is, after you've done a 'VDU 5' statement), so that text instead just gets clipped off at the edge of the screen and doesn't try to wrap around onto the next line?

Of course, this is a very common requirement:

Code: Select all

      VDU 23,16,64|

[Hated Moron]

Is it possible to make a custom mode in which the number of graphics units equals the number of pixels?

Incidentally, while we're on the subject, my very strong opinion is not that BBC BASIC should have used a 1:1 scaling between graphics units and pixels but that the 2:1 factor (1,280 units across the width of the BBC Micro screen) is not large enough!

If I could turn the clock back I would choose at least a 16:1 factor (10,240 graphics units across the BBC Micro screen). There are a couple of reasons why this would have been a nice factor; firstly, 10,240 graphics units is well within the range of 16-bit coordinates supported by VDU (-32,768 to +32,767).

Secondly, the same integer coordinate system could reasonably have been used for antialiased graphics (in which coordinates are not constrained to be integer multiples of pixels). As things stand I have to support antialiased graphics by means of libraries which take floating-point coordinates.

Still, we are where we are. There aren't many features of BBC BASIC (+ Acorn MOS) that I wish had been designed differently back in 1981, but this is near the top of the list.

[p_m21987]

That's my man Richard. Can't rustle the Russell, you always know what to do. Cheers mate.

It meets your specification "this would draw an 'X' that fills the whole window" but that limitation may or may not be acceptable to you.

Nice! Actually this is really nice and will work just perfectly for what I'm aiming to do.

Of course, this is a very common requirement

Ahh, thank you. Sorry, I should have looked through the manual a bit more.
I wonder, maybe it'd be a cool community project for the forum members to put together some sort of "BBC BASIC FAQs" list. It might catch a lot of stuff like this.

Thank you a lot for the help,
PM

[Hated Moron]

I wonder, maybe it'd be a cool community project for the forum members to put together some sort of "BBC BASIC FAQs" list. It might catch a lot of stuff like this.

As a 'general purpose' programming language, there are so many different kinds of applications that BBC BASIC can be used for that one programmer's 'frequently asked' question is another's 'never asked' question - and vice versa.

Therefore it's arguable that there are already too many, rather than too few, places where useful information about BBC BASIC can be found - the Help manual, the Wiki, Rosetta Code, this and other forums, example programs etc.

Similarly, the number of places where BBC BASIC users congregate (this forum, other forums, the discussion group, Facebook etc.) means that when a question is asked the one person who knows the answer may never see it!

This problem seems to be insoluble.