Howdy, Stranger!
It looks like you're new here. If you want to get involved, click one of these buttons!
Quick Links
Categories
- 7.8K All Categories
- 11 Help with translations
- 4.2K General questions
- 106 Roadmap
- 358 Game & application design
- 315 Plugins
- 70 User experience
- 74 Marketplace
- 290 Code snippets
- 34 Building a team?
- 269 Suggestions & requests
- 352 Announce your apps made with Gideros.
- 90 Step by step tutorials
- 659 Bugs and issues
- 195 Introduce yourself
- 236 Announcements
- 105 Forum talk
- 403 Relax cafe
Comments
Hi I've been testing Verb Smash and our new game and the HTML5 export seems to be progressing nicely. Great stuff!
One thing I notice is the letterbox scaling mode, which works really well for native mobile apps (where you can set the orientation), doesn't always work so well straight out of the box in a browser - with portrait games when you scale the window or when the window is in landscape, or when you rotate the screen, for example. You can’t force the screen orientation from a browser on mobile devices.
Our first few games were made with Construct 2 . The "letterbox mode" with C2 provides a canvas area which fills the window and has black borders when the aspect ratios of the game and the window don't match, and the game keeps its aspect ratio if you resize or rotate the window. This is not ideal for native mobile apps, where you want to design for slight variations in aspect ratios and fill the screen (C2 provides a scale to height/width option for that - akin to the letterbox mode in Gideros), but is useful for a portrait game, played in a landscape window.
I've tried setting the window size in project settings and it doesn't seem to work as you can still see outside the gameplay area and any previous calculations for getting the dimensions of the viewport are remembered if you scale the window.
I have experimented a lot with our C2 games and one workaround, which almost works, is to place the game in a responsive iframe (using bootstrap) but it doesn't work very well for a portrait game in landscape view as the content goes off the bottom of the window unless you reduce the width of the iframe so the height fits the height of the window. The problem you then get is that when the user rotates or scales the window, you need to change the width of the iframe again. If you change the width of the iframe (on an event listener), you can make it maintain its aspect ratio and everything works well on Android and Windows, but you end up getting bugs on the iPhone where areas of the game become untouchable. I drove myself crazy and looked all over the web trying to solve it because generally everything works well on Windows, OSX and Android until you then test on an iPhone! It’s a shame because we wanted to use an iframe and include our website’s navigation bar.
For our C2 games I decided that the best solution overall was to use the C2 letterbox mode (bordered), which works well even though you can’t fit any other content on the screen.
Could we have another scale mode which works like that, please?
Sorry I am not really sure I understood what you think is best. HTML5 use a specific 'fixed' orientation, since as you said browser don't know about orientation (well, maybe there is some API I am unaware of), but thats not the point.
Scaling modes works the same as with mobile phones, i.e. you can draw outside the 0,0->logicalWidth,logicalHeight area. If this is not what you want, then you could use stage:setClip(0,0,width,height) to prevent gideros from drawing outside.
Did I understood correctly ?
Sorry it's a bit difficult to explain and after thinking about it, it can be coded around as you say, but in case you're interested this is what I mean:
We design our games to fit multiple aspect ratios for native mobile apps (where you can fix the orientation and so there are less extreme variations). In Gideros we use the following logic for anchoring in corners and setting the widths of GUI element etc:
left=-application:getLogicalTranslateX()/application:getLogicalScaleX()
right=-application:getLogicalTranslateY()/application:getLogicalScaleY()
relativeWidth=logicalWidth-2*left
The same kind of logic is used for our Construct 2 game too but the logical area is automatically clipped for the web version (exported as C2's "letterbox") and also works well when wrapped up as an app using a HTML to native wrapper (exported as C2 "scale to fit" - similar, I think, to the Gideros "letterbox") so that it fills the screen.
Here is an example of one of our games made with C2 and exported with C2's "letterbox":
Learn and Spell English Words
I'm not sure exactly how much of the scaling is done under the hood with the C2 engine and how much is done by jquery. I think the basic effect is that logical translate ends up being 0 and the game is centered and clipped.
The (fixable) problem we currently have is that in its current state our Gideros app uses various calculations done on initialization (such as the ones above) to set the size of objects we want to fill the screen, which then cause problems when the window is changed.
I can code around this issue by overriding the above calculations etc so that left and top are always 0,the relativeWidth=logicalWidth, and incorporating the clip as you suggest, but perhaps you'll find the above comparison useful.
I've implemented those changes. It was fairly simple to code around in the end and everything is looking as we want.
I've also replaced setting a background colour, which was filling the whole screen ( stage:setClearColorBuffer(false)), with a background rectangle in order to get a nice framed area.
It's all working surprisingly well, already. Everything is saving too.
It performs well on the desktop, Galaxy tab and iPad (except for sound) . It's a bit slow on the iPhone 5 and Chrome snaps on my quite old Sony Xperia S phone, which I assume is a memory issue.
The .GAPP is about 10mb and so is the gideros.js. I assume minifying the javascript file would reduce it in size a bit.
There is a bit of a delay and a blank screen between the Gideros loading page and our Wobble Monkey splash on the first frame (used to mask setup) where nothing much is happening in the code yet (we setup the app on a frame by frame basis from the 2nd frame onwards). So perhaps it would be nice to be able to display something here to reassure the user that everything is OK. Likewise, the download is quite big so perhaps a loading bar or percentage ticker would reassure the user while the game is loading.
In regards to the sound issue on the iPad, those are 22khz WAVs. I didn't try the 44khz WAVs we use for our iOS exports, but 44khz WAVs would be very large for the web. Something I've been meaning to suggest for a while is using .oggs for Android and desktop and MP4/M4As for iOS as there are no potential copyright issues (as with MP3s) and they are all a lot smaller.
We are currently revamping our website and we need to tweak a few bits of the game because it was designed for Android and iOS, but we'll post a link ASAP.
Overall, I'm very happy. It will be great to reach people on desktops easily and for sharing on Facebook etc. Great stuff!
Likes: hgy29, simwhi, SinisterSoft
Files size is kind of a problem, but there is not much we can do to reduce them. JS file is already minified (for most part). GApp could eventually be compressed, but you won't see much gain since browsers usually gzip files during transfer no matter what.
Luckily, files are cached by the browser, so huge loading time only on first run.
I still agree that a loading progress bar would be good, as well as some splash screen during init.
Not sure about MP4, but I think ogg support would be good too.
Likes: NatWobble
Likes: pie, simwhi, SinisterSoft, NatWobble
I decided a few weeks ago that the HTML5 port was mature and stable enough for a general public release. There may still be a few details to enhance, but all in all it seems to work quite well already.
So I am glad to announce that HTML5 export will be integrated into main gideros releases starting from the next version, expected to be 2016.2.
The last version (already available to 50+ backers as always) fix/add a few things:
- Black screen while loading has been supressed: canvas will be shown only when the first frame from gideros is actually drawn.
- Keyboard support has been enhanced with a new event (Event.KEY_CHAR) allowing to get typed text without having to deal with modifiers (shift,caps lock, ...) nor composition. This event as also been added to WinRT/UWP and QT ports.
- URLLoader has been fixed to allow binary content to be sent
- Memory arena size will be selectable through gideros studio export tab
- Gideros studio will be able to generate loading icon and favicon automatically from an asset inside your project (this feature will be added to all exports at some point)
- Some issues regarding app orientation and scaling mode were fixed (hopefully)
And some more minor things...
Thanks to everyone who helped me out on this.
Likes: SinisterSoft, pie
Could this also be added for Android and iOS (they can have usb keyboards too) ?
https://deluxepixel.com
I've been playing around withe the latest HTML5 update and things seem to work quite nicely on desktop browsers.
However when I try to test the same sample on iOS safari, I seem to get a lot of problems.
I'm only using two texture sheets, but I can't seem to load the second scene (screen just stays black).
The texture sheets are property's of the scenes, so they should be getting unloaded on scene change.
Thanks you in advance for your help!
Can you check iOS Safari's console log for anything unexpected ? Or can you send me a link to your app so that I can see it by myself ?
Hi @hgy29
I have resized exported gideros project but click events doesnt work correctly. Event fires when I click the old position (full sized position) of button.
How can I resize project correctly? I need to place app on a specific position of the webpage.
Thanks.
I have found a way to achieve this. Included gideros.html file to another html file and resized it.
I sent you a dropbox link with my test project, basically it will load a splash screen animation and then ( after about 2 seconds) it should load a level with a turtle.
On Desktop this works fine, but on mobile I just get a black screen.
I also can't find anything that looks related in the console (there are some other warning and errors - which always seem to be there, even with an empty project).
I've downloaded the latest HTML5 template and I'm still having problems with clicks registering twice (on iOS and Android browsers). Any idea, what could be causing this?
Also, just wondering if you've received the dropbox link I sent you, as I'm also still having trouble with loading a new scene?
Thank you
Sorry I hadn't much time to check the project you sent me recently, I'll try to do it today.
However I found a potential issue with events handling: events weren't marked as consumed so that touch events would have been translated to mouse events by Android and iOS in addition to what gideros already does.
I've just fixed it and updated the HTML5 template accordingly. Let me know if it works now!
No problem, I understand you must be busy
Awesome, that solved the 'double click' issue! I think it's just the scene change problem now + I'm not getting any sounds on iOS (is there any guidelines for sounds that I might be missing?)
Thanks again!
I tried the project you sent me, and had to increase memory arena to 512MB instead of template default of 128MB to make it work on iOS. No problem on desktop, maybe because my iPhone6 resolution is higher than a PC ?
You can change manually memory arena size in gideros.html file (GIDEROS_MEMORY_MB variable)
Thank you for that, it works
1. Is there any detrimental effect by setting the memory higher?
2. Also, just trying one of my levels - and it seems very slow and jerky/unresponsive on the first run through. It seems like once the level has already been played, everything starts running smoothly, almost as if things were still trying to load as you're playing the game.
Thanks again!
collectgarbage()
https://deluxepixel.com
Thank you for the suggestion. I now seem to get a back screen no matter what I try - changing the memory setting or removing collectgarbage().
I've tried wiping the browser cache multiple times, but nothing.
I'd love to use the html5 template, as it would make Gideros an awesome one stop shop.
Do you think perhaps I'm jumping in too early? Maybe it's not quite ready for production yet. I've compared the speed of the level I'm working on in Construct 2, vs the Gideros Html5 template, and the differences are very noticeable (on iOS and Android).
The C2 version runs absolutely smooth, but the Gideros Html 5 version is quite jerky and laggy. I'm not too sure whether this is me doing something wrong, as the code is very similar (mainly a few tweens and touch listeners), or whether the Gideros Html5 template is slower because of the translation from Lua?
Any advice would be awesome
Thank you guys!
Sorry to tell this again, but you can't expect gideros to run smoothly in HTML5 on a phone, at least on current hardware, because phones have far less processing power than desktop. Probably next gen phone will be more capable, and if webassembly is widely adopted things may be better too.
Gideros in written in C/C++, which is not something a browser can run natively, so to make gideros run in a browser, C code have to be compiled into JS. This done thanks to emscripten. But we can't expect some C translated to JS then translated back to C by the browser to run as fast as original C code, and I doubt automatically generated JS will be as efficient as some app nartively written in JS. Think iof gideros in HTML5 as an emulated gideros.
Desktop often have a lot of memory and a lot of power, so that the overhead is not much of a problem, but for phones a native app will be much more efficient!
Thank you for the explanation and I hope my post didn't sound negative. You are doing an absolutely incredible job
I really love Gideros and I'm using it for a game series, that I have planned out for this year. For me however, html5 speed is very important. I really need my future games to be accessible/playable on phones - as I sell licenses to sponsors and have people accessing my website from mobile devices.
I think that until devices are a little bit faster, the best option for me will be to work with both tools - Gideros and Construct 2, as they both do their intended job VERY well. Gideros is an incredible engine for native games, while Construct 2 is one of the best html5 engines around.
Thank you heaps for all your hard work!
I still hope that webassembly will incitate browser makers to support that kind of apps more and more.
I've been playing with the HTML5 template a little bit more (in the hope of still using it for my project), and I've noticed something.
When I first play the game, things seem to be very jerky / choppy, but after a while everything seems smooth - especially on a second play through.
Any idea what could be causing this, or how I could avoid the first run choppiness?
Thank you in advance!
It's almost as if the level logic etc. was already cached
It's frustrating, because on a second run, the game runs perfectly smooth ... on the first run it's almost unplayable.
Damn, I was hoping I could get around it somehow lol.
https://deluxepixel.com
I've tried 128mb - and my levels don't even load.
At 256mb - a little jerky on the first run (not on the second) - levels don't always load
At 512mb - very jerky on the first run (not on the second) - levels always load
Testing on iPhone 5s, over wifi - second run through the game is absolutely smooth.
I tried lowering the frame-rate and using lower quality assets as well.
https://deluxepixel.com