6 replies to this topic

[physcopanda]

Hi everyone - I've been working with GMS for a while now and as I keep starting little game projects - they nearly always have the same initial requirements regarding control input and window resizing. As a timesaver - I've created a little starter project to get things going.

 

This was initially aimed at OUYA/Windows developments but has since been expanded to generic Android and has been tested on Amazon Kindle, OUYA and Nexus 5 devices. It is by no means perfect but the repo is public and if anyone's in the mood to contribute then I would be very happy to see some collaboration.

 

The documentation is probably a little light - I will try and improve it when time allows. Anyway - hope someone finds it useful.

 

Here's the link :- https://github.com/p...er-OUYA-Starter

[shadeflea]

Looks nice! A really good start saving everyone some time with prepping! Good work!

[physcopanda]

Thanks shadeflea - it has some handy scaling features - pops to the nearest pixel size in windowed mode on window resize.

 

Also has an OVERSCANXY variable which defines a dead zone around the screen not essential to your game.

 

If the game is run fullscreen on a device with a display aspect that would clip the overscan for a larger screen but not anything else, then this is allowed. Otherwise - you get the next scale down that fits on screen.

 

There is the odd occasion (Some Nexus pads I believe) where this comes in handy as it gives a bigger display. Just ensure that your OVERSCANXY area really never contains anything you *must* be able to see.

 

I will add this to the docs when I figure out a better way to explain it ;-)

Edited by physcopanda, 30 December 2014 - 07:17 PM.

[physcopanda]

Just improved the docs a little bit and added some indicators to show the controllers in action. Also for those scared of GIT (dont be it's awesome once you get used to it!)

 

Grab the gmz here

 

Just click on view raw on github to get the gmz

Edited by physcopanda, 31 December 2014 - 10:26 AM.

[gnysek]

One quick question - does window_set_size() works for you on OUYA? Cause for me window size is still 1920x1080.

[physcopanda]

Hi gnysek - we don't actually do any of the resize code for android - look at the obj_application_surface - that does all the window management and it's only used for windows. The room size for our projects is set to 640 x 360 and in the case of OUYA - the draw_gui method in upscales this to the native screen resolution.

 

The whole game actually runs at 640 x 360 and the surface is upscaled in a pix perfect manner. (ie no horrible aliasing) This gives you exactly 3 real pixels per pixel which is perfect for nice pixel retro games.

 

The room size *should* be configurable but you'll need to update the init game globals script and it will center and give you black bars if you use something out of the 16:9 aspect ratio. I haven't actually tried a different size with this so let me know how you get on if you decide to try it!

 

I'd really recommend 640x360 as a good working size though.

[Heavy Stylus]

Just improved the docs a little bit and added some indicators to show the controllers in action. Also for those scared of GIT (dont be it's awesome once you get used to it!)

 

Grab the gmz here

 

Just click on view raw on github to get the gmz

 

Just wanted to say this framework is super easy to use and IIRC pre-set for games that run at 640*360 resolution (this scales up to both 1080 and 720p without pixel stretching, so it is best to use variants of this in your games for 16:9 screens - see below). Jamie and I knocked out the basic concept for this project in a few hours using it - https://www.youtube....h?v=ZfFmrSDYxHI

It's so nice to have all the controllers, fixed pixel alignment and screen scaling already ready to go when prototyping ideas

I'd really recommend 640x360 as a good working size though.

 

Or 320x180 for the super-retro vibe

Edited by Heavy Stylus, 05 January 2015 - 08:12 PM.