Jump to content

  • Log In with Google      Sign In   
  • Create Account

C0lumbo

Member Since 02 Nov 2012
Offline Last Active Yesterday, 03:36 PM

#5263375 Article on Lockstep Multiplayer

Posted by C0lumbo on 24 November 2015 - 01:10 AM

I wrote an article on lockstep multiplayer, with a particular focus on the steps you can take to prevent or catch the vast majority of desync bugs long before you write a single line of multiplayer code:

 

http://www.tundragames.com/minimizing-the-pain-of-lockstep-multiplayer/

 

 




#5262977 IDE for Android NDK

Posted by C0lumbo on 21 November 2015 - 02:50 AM

I use NSight Tegra (which plugs into Visual Studio): https://developer.nvidia.com/nvidia-nsight-tegra

 

When it works, it's great. When it's not working or you're struggling to plug in some new library, it can be very frustrating because all the online tips and tutorials are geared around eclipse and Android Studio.




#5259605 Mobile games with big file size

Posted by C0lumbo on 29 October 2015 - 11:58 AM

Loads of successful games are bigger.

 

If you were close to the 100MB mark *, I'd recommend trying to get under it, so that your game can be downloaded over a cellular connection.

 

You're nowhere near small enough to get under that (unless you're being very wasteful and there's loads of stuff you can cut), but you're nowhere near large enough that typical users would worry about downloading over WiFi or worry about the storage you're taking up on the device.

 

Some games cheat the system a bit by making their initial download small, then downloading loads of extra stuff immediately. This is partially justified by the fact that different devices support different types of compressed texture, so the correct texture format can be selected.

 

* Limit used to be 50MB until very recently. It's now 100MB for apps targeting Android 4 and above.




#5259446 ETC and PVRTC dead to an unified compression ?

Posted by C0lumbo on 28 October 2015 - 12:32 PM

"since Vulkan and Metal support BC compression and is used for mobile too, is it the end of multiple compression for one unified compression ?"

I'm not sure if the OP meant BC or ASTC, but metal support for both is device-dependent: https://developer.apple.com/library/ios/documentation/Miscellaneous/Conceptual/MetalProgrammingGuide/MetalFeatureSetTables/MetalFeatureSetTables.html#//apple_ref/doc/uid/TP40014221-CH13-SW1

 

If there is going to be a unified compression (across phones and desktop) it will be ASTC, not BC, but you'll have to wait a good few years before you can assume support.




#5257623 What are my options for loading my game files for an android app?

Posted by C0lumbo on 16 October 2015 - 11:52 PM

im using fopen (C++) to load files directly from sdcard/internal memory <- i would like not to change that but loading things through assets and then saving them to sd card seem pretty lame since game will take 2x more space than it should.

 

I dont want to change the loading code.

 

The ideal thing would be that apk (game only could be downloaded with all game files - without any additional download from my app.)

 

So during apk installation it could extract files to desired path, then delete the zipped content.

 

I'm pretty sure you can't delete the apk contents, I'm afraid.

 

One option would be for you to disable compression of your files within the apk. Certain extensions like .mp3 .zip, etc don't get compressed, so if you rename your game files to one of those then you can disable compression, alternatively you can get your hands dirty and figure out whereabouts in the build process the compression decision is made and turn it off completely or just for your particular file extensions.

 

With an uncompressed asset in your apk, you can use AAsset_openFileDescriptor to get a file descriptor for a package file, then you can use fdopen followed by fread/fclose. So you'd only have to rewrite your file opening code and not your file manipulation code which might be a less daunting prospect.

 

Obviously if the build process isn't compressing for you, then you probably ought to be compressing your game files yourself, plus it's worth noting that the docs don't really make promises that AAsset_openFileDescriptor will work. I'm pretty certain that AAsset_openFileDescriptor does always work for non-compressed main apk assets and that it's unlikely to ever change on future revisions, but that's very different from it actually being a guarantee in the documentation.

 

All that said, you're probably best introducing a layer of abstraction in your file loading code and just using AssetManager functions on Android.




#5257503 What are my options for loading my game files for an android app?

Posted by C0lumbo on 16 October 2015 - 10:05 AM

The max size for your main apk used to be 50MB, but it was very recently (few weeks ago) raised to 100MB but only for apps that only target Android 4.0 and above.

 

However, you can also have two 'expansion apk' files which will be hosted by Google Play which can be 2GB each.

 

If you use expansion apk(s) then there's some extra code you'll have to write to handle the case where they're missing from the original download and you need to download them dynamically.

 

If you can avoid using expansion apk files then I believe your app can be downloaded over a cellular connection which might improve downloads a little, so if you're near that 100MB threshold it might be worth putting in the effort to get under it.




#5256676 c++ direct9 fullscreen problem

Posted by C0lumbo on 11 October 2015 - 08:04 AM


Lost device handling is a bit of a pain with D3D9.

 

The worst bit is getting useful debugging information for DX9 on a modern version of windows. Enabling debug runtime just doesn't work anymore (on Windows 7 and above I beleive). So if you've forgotten to release one of your non-managed resources, it can be a challenge to track down the problem!




#5256486 Do you use friend to avoid security problems ?

Posted by C0lumbo on 10 October 2015 - 12:13 AM


If you're truly concerned with security, that is, you want to prevent malicious users of your API from doing things that could be harmful to other users or to you, then making functions private will do very little to help you achieve your goals of protection. If a malicious person wants to call a private function, they only need to discover its existence, find its location in the executable, determine the proper calling convention and parameters, and then they can freely call it with whatever parameter values they want. While the above steps aren't trivial, especially for your average script kiddie, for a well practiced malicious agent it's not that hard.

 

If you're using protected/private to try to 'secure' an API, it'd be even more trivial for a user just to add the following lines before including your headers:

 

#define protected public

#define private public

 

And they will have access to all the innards of your classes as if they had the friend designation.

 

It's probably best to think of protected and private as mechanisms to encourage and simplify correct use of your API rather than to prevent misuse.




#5256437 Do you use friend to avoid security problems ?

Posted by C0lumbo on 09 October 2015 - 03:53 PM

Hi,

Do you use friend to avoid security problems of public functions ?

 

Yes, I always get a friend to keep a lookout when I urinate in public.




#5255204 How exactly does localizations of apps translate to more downloads?

Posted by C0lumbo on 02 October 2015 - 12:42 PM

As well as the other points made, on mobile, Apple and Android are important gatekeepers with their featuring systems, and the features are different per territory.

 

You are unlikely to be featured in France without French localization for example.




#5254549 How do I know what Android version to target?

Posted by C0lumbo on 29 September 2015 - 01:04 AM

This contains a lot of useful information about Android fragmentation: http://opensignal.com/reports/2015/08/android-fragmentation/

 

We're about to release on Android and are support 4.0+. Version 3.* was never widely distributed, so you can pretty much pretend it doesn't exist. Version 2.* is still used by about 5% of devices but we decided to ditch it because it doesn't support setPreserveEGLContextOnPause which we're using to keep our OpenGL context alive after multitasking.

 

Picking an API level has little to do with dealing with low-end performance devices. That's a whole other kettle of fish. I'd use the above link and try to identify a few popular low end devices, and try to hit a variety of GPU manufacturers. Also, borrow as many devices off friends as possible. It took testing on about 20 devices before the flow of weird device specific issues dried up for me, but then I'm writing an engine from scratch. If you're using Unity or something, then you won't have to worry about all the quirky workarounds for various device specific issues.




#5254255 binary alpha

Posted by C0lumbo on 27 September 2015 - 12:13 PM

For bonus points, use this technique to avoid jaggies on your foliage (not invented by Wolfire, but they have a relatively short clear explanation): http://blog.wolfire.com/2009/02/rendering-plants-with-smooth-edges/

 

TLDR version: Render all foliage twice. First pass use clip/discard/alpha test on your foliage (as Hodgman describes). Second pass, render with alpha blending.

 

A more correct solution might be to look into alpha-to-coverage with multi-sample antialiasing.




#5249285 Alpha blend mystery

Posted by C0lumbo on 28 August 2015 - 12:03 AM

I think Jihodg is on the right track. Your code that's hardcoding a test value for texture two's alpha is only modifying the top mip.

 

If the lower mips are already generated, then they will still be opaque. Try regenerating the lower mips after hardcoding that transparency, or modify your code so that you iterate through all the mips and hardcode an alpha value.




#5248363 OpenGL-ES Light-Shader: distance-issue

Posted by C0lumbo on 23 August 2015 - 09:34 AM

Sounds like a precision issue to me. Your math is being done at mediump which could have a maximum range of -16384 to 16384, which is quite a lot more than your 250-300 but do bear in mind that the distance function is almost certainly having to square. In fact, maybe the compiler is smart enough to remove the square root from the 'distance' function and compare with your radius squared (which can be calculated per draw call) instead of using radius.

 

First up, if you have a device that supports highp in the pixel shader try just changing 'precision mediump float;' to 'precision highp float;'. If that fixes it then we're on the right track.

 

But I wouldn't stop there because lots of Android devices don't support that. Try doing your lighting math in normalized screen coordinates instead of pixel coordinates maybe? (i.e. divide both the pixel pos and the light pos by the screen height or the screen width)




#5247748 Controls for Mobile Platformer

Posted by C0lumbo on 19 August 2015 - 03:12 PM

I would check out the Mikey games (Mikey Shorts, Mikey Boots) for example of how to do it right. Basically, you want a left and right button for your left thumb, and a jump plus a maximum of one other button for your right thumb. I wouldn't recommend any more than that.

 

Extra points if you make the button size/positioning customizable.






PARTNERS