Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

UI tool: replace SupportedOrientation and perfectly scale between iPhones and iPads

edited May 16 in Code Sharing Posts: 1,284

note this post was originally about @West’s Well Racer game, and a modification I made of it to preserve portrait mode. It is now more about the code that was used to make that modification. Original post follows:

This code is sloppy and misbegotten but it demonstrates a way to force an orientation, in this case portrait mode.

I used West’s Well Racer as a guinea pig — hope you don’t mind, West!

I only worked to get the menu and information screens right, but they do their job (and as an unintended result they scale pretty well to the iPhone too), including translating touch positions to match the matrix rotation.

Update: now consistently sizes instructions optimally using fitText(). ;)

Update: I think the whole thing, including game play, now reacts properly to the forced orientation.

Update: the technique is now usable in anyone’s project by using the Orienter class, now attached. “Perfect” may be over-selling it, but it’s darn close.

The project itself demonstrates its use, and all you have to do to use it in your own projects is:

-- 1. initiate an Orienter, stating your desired orientation
-- 2. use it to call orient() in draw()
-- 3. use its HEIGHT and WIDTH values anywhere you'd normally use the system HEIGHT and WIDTH values

Update: works on iPhone now—silly me I didn’t use relative sizes when I made it on the iPad.

Tagged:

Comments

  • dave1707dave1707 Mod
    Posts: 9,429

    @UberGoober supportedOrientation is no longer supported, which means it will be gone in a future release. CurrentOrientation should be used. Here’s an example. Run the code and rotate the screen. The example is for Portrait or Portrait_Upside_Down.

    PS. Check the warnings printed in Well Racer.

    function setup()
        fill(255)
    end
    
    function draw()
        background(40, 40, 50)
    
        if not checkOrientation(PORTRAIT,PORTRAIT_UPSIDE_DOWN) then
            text("Rotate screen",WIDTH/2,HEIGHT/2)
            return
        end
    
        sprite(asset.builtin.Planet_Cute.Character_Horn_Girl,WIDTH/2,HEIGHT/2)
    end
    
    function checkOrientation(...)
        -- PORTRAIT, PORTRAIT_UPSIDE_DOWN, LANDSCAPE_LEFT, LANDSCAPE_RIGHT
        arg={...}
        for _,b in pairs(arg) do
            if b==CurrentOrientation then
                return true
            end
        end
        return false
    end
    
    
    
  • Posts: 1,284

    @dave1707 did you run the project?

    The whole point is simulating supportedOrientation using CurrentOrientation.

    I don’t reference supportedOrientation anywhere in the code or in my op.

  • dave1707dave1707 Mod
    Posts: 9,429

    @UberGoober I ran the code and supportedOrientation is the first line of code executed. I didn’t play the game or look thru the code, I just looked at the warnings that printed out.

  • edited May 14 Posts: 1,284

    @dave1707 I see the confusion. I meant I didn’t use supportedOrientation in my added code, and the first line there is @West’s original code.

    But of course there’s no way to tell that just from looking at it, so it looked like I was saying "I NEVER mentioned supportedOrientation” when it’s actually the first thing in the whole project—lol, that must have seemed like quite a numb-skulled proclamation, I apologize for that. It would have irritated me for sure, were I on the other end of it.

    I’ve updated the project and removed that line at the start.

    Also in the update: I think I’ve actually completely refit the entire app to respect the forced orientation—even gameplay. It worked when I tested it. @West, want to give it a spin?

  • dave1707dave1707 Mod
    Posts: 9,429

    @UberGoober At first I thought you were talking about a different project, but then I rechecked. I’ll have to actually try running the code to see what changes you made and how they work.

  • Posts: 887

    @UberGoober works well with me - good job!

  • edited May 14 Posts: 194

    @UberGoober This is a fantastic idea! I’m just going to run with the main idea here. Bear with me… Interesting things are coming in for WebRepo projects :wink:

  • Posts: 1,284
    @Steppers , @West I’m working on extracting what I did here to make it applicable to any project.

    If that’s what you’re up to, Steppers, I’ll let you go at it, you’re probably able to do it faster.
  • Posts: 194

    @UberGoober It may or may not involve reimplementing supportedOrientations with this concept at the center. Should mean no projects will need modifying.

  • edited May 15 Posts: 1,284

    Well for anyone interested here’s an easy-to-cut-and-paste orientation locker.

    I think there’s probably a better way to do some of it, but it works.

    Also demonstrates what happens to various coordinates when you don’t use it.

    Edit: an even more updated version is now in first post.

  • Posts: 1,089

    looks like just what i need, @UberGoober, i'll check it out :)

  • dave1707dave1707 Mod
    Posts: 9,429

    @UberGoober What happens if the project needs to run in Landscape orientation. Your code forces it to Portrait.

  • Posts: 172

    this is great but, i’d be more interested in a way that allows changing orientation but re-centers the scene

  • Posts: 1,284

    @dave1707 good point, I think to be complete it needs to initialize with a variable telling it which orientation it’s supporting.

    Doing the landscape version shouldn’t be very complicated, but it’d be a labor for sure, and it might take me a little bit to have the oomph for it.

  • edited May 15 Posts: 2,361
    All - I think that you should steer away from Orientations and just check the aspect ratio. You can then include a database for all Apple tablets/phones so you can identify the device. I don't see the difference between ORIENT_LEFT OR RIGHT etc - does that really matter?

    I check aspect ratio at each draw() function then modify the graphics accordingly. I think you should have ASPECT_RATIO as a defined system variable you can check instead of calculating each draw() cycle.
  • Posts: 1,284

    @Bri_G including a database for all Apple tablets/phones seems like a pretty monumental endeavor to me, but in any case this isn’t really about that.

    I want control over how my apps draw themselves, and if I’m making a game that’s supposed to be played in landscape mode, I want to be able to tell my app “never ever ever draw yourself in portrait mode,” and that’s what this code allows me to do.

    I think I overcomplicated it a little though, I am revising it to make it more straightforward to use.

  • edited May 15 Posts: 2,361

    @UberGoober - I built a small database that is out of date but I was hoping that @Simeon could introduce one into Codea. Also what’s the difference between orientation == PORTRAIT and ASPECT_RATIO == 1.25 ? Also, aspect ratios for two orientations won’t change whereas we know Codea’s definitions do and Codea could be made to determine the aspect ratio of the machine it is on on installation.

  • Posts: 1,284

    @Bri_G I think the updated version will explain all this better than anything else. It’s in the first post now.

    @West, @dave1707, @RonJeffries, @Steppers: please check out the new version, it’s MUCH better and MUCH simpler and much, much, much better explained.

    The project itself demonstrates its use, and all you have to do to use it in your own projects is:

    -- 1. initiate an Orienter, stating your desired orientation
    -- 2. use it to call orient() in draw()
    -- 3. use its HEIGHT and WIDTH values anywhere you'd normally use the system HEIGHT and WIDTH values

  • Posts: 194

    @UberGoober In the end I had to move away from a simple translate & rotate to adjust the rendering. It seems this has a few limitations when it comes to 3D rendering.

    ortho & perspective both use defaults that incorporate WIDTH & HEIGHT so they also needed wrapping.

    In the end I decided to go down a route using setContext to render to a separate framebuffer sized to the desired orientation. That framebuffer is then drawn to the screen at the end of the user’s draw() function at the correct rotation. Probably not ideal but for the moment it works pretty well.

  • edited May 16 Posts: 1,284

    @Steppers I hadn’t thought about 3D, that’s a good point.

    @Simeon, can you lend a hand here? It would be awesome to be able to apply this technique to 3D and to craft stuff too, but it’s beyond me.

Sign In or Register to comment.