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.
@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
@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.
@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?
@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.
@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
@UberGoober It may or may not involve reimplementing supportedOrientations with this concept at the center. Should mean no projects will need modifying.
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.
@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.
@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.
@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
@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.
