Open towerofnix opened 6 months ago
My inclinations are for options 2 (fullscreen button)
I support this alternative
Feels to me like it would make sense to have provide the following options:
canvas { width: 100%; }
except to render smoothly. Under the hood, that means we probably need to measure the width of the parent container and then set the width/height of the canvas accordingly.Project
instance, it should be possible to call project.fullscreen()
to invoke the fullscreen API. I don't have strong opinions about whether or not the generated output should include a button that does this.For the sake of clarity, here's a rough proposed API:
// Change "steps" size of stage (what the Leopard code sees)
// We already have this option
const stage = new Stage({ width: 1920, height: 1080, costumeNumber: 1 });
// Change visual size of canvas – how large the project actually appears as pixels on your screen
const project = new Project(stage, sprites, {
frameRate: 30,
// A) Default canvas (dimensions match stage steps)
canvas: "default",
// B) Double size canvas
canvas: { width: 960, height: 720 },
// C) Viewport-filling canvas
canvas: "full"
});
// Regardless of canvas size, you can always call the following to invoke legit fullscreen (including using a button or menu item in-game!)
project.fullscreen();
Oh, and I would not put a button in the generated HTML to toggle into fill-viewport mode. That seems like something you would configure in code (for example, if you were building a webpage with your project embedded in it).
I broadly agree @PullJosh, and appreciate the example API a lot! I'm a big fan of how that plays with embedding Leopard as part of a broader in-page context.
I'm mostly thinking about students who may not necessarily care about adding a fullscreen mode to their project, nor to set up specialized presentation for the viewport in their generated template page. My understanding is that these students aren't touching the HTML or CSS of the project at all; they care about making a game or program in Leopard, not making it look pretty online. Most of the time they view their project through a small CodeSandbox iframe or through a popout window (which may or may not itself be in fullscreen, manually zoomed in-and-blurry, etc).
A fullscreen button (note: not a fill-viewport button) feels appropriate for these students as they'd like a very specific, easy, and reliable way to just make the project fill up the whole screen, dang it! For the sake of presenting to a colleague, teacher, friend, etc. They have no interest in learning CSS on the fly, and they might not want to bother to add a button which runs project.fullscreen()
in their actual project code. (Keep in mind that due to browser restrictions, it's never possible to use project.fullscreen()
without a user interaction, e.g. having the game start out in fullscreen mode. So folk who want fullscreen would actually have to add a button to their game that sets it appropriately!)
I've come around though, and don't think we need any "magic" for the controlling the viewport — I totally agree with your suggestions there! It should be configured in code and have nice, easy to use settings, just like you've suggested. It's fundamentally the same decision-making as the frame rate for the project - collecting those settings together is intuitive and good.
Edit: I may have missed that you reacted 👍 to @sfederici's comment above, LOL.
@towerofnix Love it. I'm sold on the fullscreen button.
My understanding is that these students aren't touching the HTML or CSS of the project at all; they care about making a game or program in Leopard, not making it look pretty online.
I agree. This is the most important thing for my students too
As @adroitwhiz comments we already have support for rendering smoothly to any canvas dimensions, so we only need to implement however stage ends up filling either or both the viewport (i.e. browser window) and screen (ala YouTube). Some thoughts:
Particularly if we have an "enter fullscreen" button and not a "fill viewport" button, here are some options for getting the fill-viewport behavior as well as proper screen filling (via button):
My inclinations are for options 2 (fullscreen button) and either 2 (configure in code, maybe default to always filling viewport) or 1 (fill viewport if significantly above 480x360).
I figure I'd share this before actually touching any of the code since there are a variety of options to choose from and there definitely might be other options I haven't even considered here. Please let me know what you think!
/cc everyone from #190: @sfederici, @PullJosh, @adroitwhiz