Choosing the display mode for a mobile app

[RichardRussell]

I am well aware that this post is exactly the kind which makes some members very angry. I invite the moderators to delete it if they receive complaints.

I received, by email, this deceptively simple question: "Which Mode would you recommend so that I can get the best resolution and also the largest area of screen?". Because my reply may be of more general interest I reproduce it here:

That is one of those questions to which there is no 'right' answer, other than "it depends"!

If your main concern is to use the largest possible area of the screen, irrespective of its shape (which can imply orientation as well as aspect
ratio) then your best bet is not to use one of the preset MODEs at all, but to make your program adapt to any shape. Of course, depending on
the nature of your program, this may be anything from relatively straightforward to very difficult!

So all I can really do is to list the options along with some pros and cons:

1. Full Screen, Native Resolution
   
   This will give you the largest amount of 'real estate' and the best quality (because scaling is not involved) but because some devices have
   very high-resolution screens performance may be adversely affected if you are doing anything like real-time animations. You must write your program to adapt to any width and height, which can sometimes be difficult. The initial code should be something like:
   

   Code: Select all

      VDU 26 : REM Reset viewports to entire screen
      IF POS REM SDL thread sync
      dX% = @size.x% : REM width
      dY% = @size.y% : REM height
      REM You may need a VDU 23,22... here e.g. to set UTF-8 mode.
   

2. Full Screen, Reduced Resolution
   
   This is something of a compromise: your program fills the entire screen, but by means of scaling it can run in a reduced resolution (for example you can fix the width at a constant value and only vary the height, or vice versa). This can make coding the program easier, and improve performance. The initial code should be something like:
   

   Code: Select all

      VDU 26 : REM Reset viewports to entire screen
      IF POS REM SDL thread sync
      dX% = 800 : REM fixed width
      dY% = dX% * @size.y% / @size.x% + 0.5 : REM scale height
      VDU 23,22,dX%;dY%;8,16,16,128 : REM Change parameters to suit
   

3. Fixed size
   
   This is the easiest solution in terms of coding your program, but it won't (necessarily) fill the screen. Typically in landscape mode there will be black borders left and right, and in portrait mode there will be a black space below your program's output. You can choose either to use a relatively high resolution mode (e.g. 1920 x 1080) or a relatively low resolution one (e.g. 640 x 360) according to whether you are more concerned about quality or speed.
   

   Code: Select all

      dX% = 1920 : REM Fixed width
      dY% = 1080 : REM Fixed height
      VDU 23,22,dX%;dY%;8,16,16,128 : REM Change parameters to suit
   

As if this degree of choice wasn't enough, there are other considerations. For example how do you want your program to behave if the user changes the device's orientation (landscape <-> portrait) whilst it is running? If you take no speciai measures, the display will automatically rotate but won't scale or otherwise adapt to the new shape. You can include an ON MOVE handler to deal with this.

Also, do you want to allow, or not allow, the user to pan and zoom the window 'manually' by means of touch gestures. By default he can, but
that can be disabled, or you can take control yourself of what happens with those gestures, using *SYS 4 and an ON SYS handler.

There are example programs supplied with 'BBC BASIC for SDL 2.0' which use all of these techniques, so you can test out for yourself how they
behave. Ultimately you have full control, using the @zoom%, @panx% and @pany% variables, if the various 'automatic' modes don't do what you want.

[atom058]

Richard - Not sure why anyone would be angry about that information - I think it is great and will probably incorporate some of it into my program... Thanks!

[RichardRussell]

Not sure why anyone would be angry about that information

Because it was unsolicited. I have been asked to restrict my contributions to announcements (e.g. of new versions) and replies to questions explicitly directed at me. As it is, I am not properly abiding by that request because I am answering questions even if they don't mention me by name. But volunteering information that hasn't even been asked for is an unforgivable sin!

Admittedly I used to do it a lot, especially when the forum was quiet, in an attempt to provoke discussion and broaden interest in aspects of BBC BASIC perhaps a little outside some users' comfort zones. But I hadn't realised the degree of anger it was causing (to some people, not everybody) until somebody let rip.