Whole bunch of questions...

Monkey Forums/Monkey Programming/Whole bunch of questions...

hobo(Posted 2012) [#1]
Hello,

I am reaching a reasonably complete state of my first Monkey Game. I have been targeting HTML5 for convenience and experimented briefly with Flash and iOS targets just to check it loads.

However as a complete noob, I have a number of questions which hopefully the monkey community can help me with.

So here goes:

- When I build a flash version the graphics look rough, as in they are not anti-aliased. Is this just how the flash version will look? while the HTML5 target the graphics look crisp?

- Might be related but all my assets are .png - when I save them I set the compression level to the highest - 9. Is this the setting people are generally using?

- I want to target iPad and iPhone. Should I keep a seperate set of assets for each target? I currently receive the assets in iPad 3 resolution and convert to 640*480.

When I tested the game on iPhone it did display but is that Monkey upscaling the assets to the correct resolution?

I am also using Diddy so perhaps that is scaling?

I am slightly confused as you can tell about the best way to approach graphics for multiple targets. If anyone can explain their method I would be grateful.

- Gameplay on the different screen sizes. I noticed when I tested on the iPhone the touch screen controls were out of sync (for example touching a button on the browser version was perfect, but on the iphone I had to touch down and to the right to press the same button)

I presume this is because I have coded the gameplay to a 640*480 resolution and need separate version targeting the specific resolutions? Again any explanation or a method to manage the variations in targets would be gratefully received.

Thanks for any help in advance.


Gerry Quinn(Posted 2012) [#2]
I've always found the Flash version looks fine, so I don't know what's wrong. Certainly it does use anti-aliasing, although it's possible the details of how it does it are different.

Diddy does have a scaling option, but I don't use it, so I don't know if it's on by default. You could always make a simple test project that does the minimum, and try it on everything.

If you are targeting devices of different sizes, you probably need different assets too if you are not happy with scaling. Adjusting layout depending on device width and height may be useful too.

Your touch issue definitely seems to indicate that some scaling is happening to the graphics and not the mouse, i.e. the graphics are shrunk so your button at 400,300 is displayed at pixel 300,225 but you still are requiring a touch at 400,300. If you scale the graphics, you must scale the mouse/touch too, in reverse. Here's a little module I wrote recently, when I realised I needed scaling for Androids with small screens:




Why0Why(Posted 2012) [#3]
You need to be sure to code screen size as a variable and not a fixed 640x480. A button in the middle should be x=screenwidth/2 instead of 320. I do this with almost everything except the most basic tests because with Monkey odds are you will be using many different resolutions.


Samah(Posted 2012) [#4]
If you're using Diddy virtual resolution, you need to be using the game.mouseX and game.mouseY fields, as they take VR into account.


hobo(Posted 2012) [#5]
Thanks for the advice everyone.

Looks like I will create a iPad 3 HD resolution version and implement xy locations relative to screen dimensions rather than manually. Hopefully this version can also use diddy virtual resolution also and scale to the iPhone/iPad 1/2

Will be a bit of reworking but kind of what I was expected. Just couldnt resist whacking in direct x y locations of things and knew it was going to bite me later.


silentshark(Posted 2012) [#6]
re: hard coding x and y values - sure it might be ugly, but I think you'll be ok if you are using VR? Certainly, I've not had an issue with this (ugly tho it is) when using the AutoFit module - I think I remember seeing that it's the same code in Diddy.

Do check Samah's point about about using game.mouseX and game.mouseY

HTH


silentshark(Posted 2012) [#7]
re: png level 9 compression - I think this is fine, as png is not lossy even on the highest compression. I'm sure someone will shout if I'm wrong here :-)


Gerry Quinn(Posted 2012) [#8]
I believe that is the case. If you have a lot of horizontal lines of the same colour, PNG will use run-length encoding and be very compact - it's often a great choice for button graphics etc. On the other hand, if you have a photographic-type image, you will be able to get in a lot of extra compression with JPG. So the optimal choice will probably be a mixture of both.