Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 02 Nov 2012
Offline Last Active Today, 02:52 AM

#5272218 Will launch game on PC first ruin the console sale rate in future?

Posted by C0lumbo on 22 January 2016 - 12:41 AM

This reply is a bit speculative because I don't have any experience on the non-mobile publishing side of things.


I doubt a PC release will have any impact on console sales, as the two markets are pretty isolated from one another. Lots of game developers play games on PCs and consoles, normal users typically don't.


However, a PC release might limit your ability to negotiate a beneficial exclusive (or timed exclusive) console release with one of the big manufacturers. If you have limited reach and marketing budgets, then exclusivity might be a good way to get some level of featuring and visibility in the online stores. It might be worth talking with your Xbox/Sony/Nintendo account managers before releasing on PC to make sure you're not missing out on any golden opportunities.

#5271661 How long should I sleep the Cooperative Pathfinding Thread?

Posted by C0lumbo on 18 January 2016 - 01:42 AM

What exactly is the thread doing? Waking up every 16ms to see if there's some work that needs doing, and if not, going back to sleep?


If that's it, then I would probably sleep more like 1ms, because the cost of waking up to poll for some work is pretty cheap. But if you're still worried about performance, then you might be better using a better construct like having the thread wait on a semaphore, then when some work is scheduled for it, signal the semaphore and the thread will wake up and do it.


Or maybe you're worried that the thread is taking up too much CPU time and it's affecting the overall performance of the game? In which case, I'd be surprised because I'd have thought pretty much any piece of hardware you might be talking about should have plenty of CPU threads to spare and you probably needn't worry too much about it. I don't think we could tell you how much sleeping would be necessary to free up enough CPU resources for your title without knowing anything about the engine or even the target hardware.

#5269157 Article on Lockstep Multiplayer

Posted by C0lumbo on 04 January 2016 - 03:15 AM

Deterministic lock-step has an inherent flaw (openy admitted in the article) that it goes with a speed of the slowest player. What about (ab)using deterministm in a different way - to send all the inputs to the server, where the server will timestamp them, and to send them to all the clients where the input will be "replayed" based on determinism? In other words, the only thing which server will do, is timestamping+forwarding.


Actually, I omitted it from the article for brevity but this is what I do in Rapture World Conquest.


The reason I do it that way isn't really because I'm worried about slowing everyone down to the speed of the slowest connection. In fact that might not even be helped in my case, because I don't have a good solution to identify the individual with the best connection to make them act as server, so I'm as likely to pick the worst choice as the best choice.


The reason I do it is to simplify handling what happens when one player disconnects. If everyone was sending their input messages to everyone in the fully connected mesh, and someone disconnects, it's hard to manage things so that all players agree on exactly when the individual disconnected. With more of a server-client approach (I have a fully connected mesh, but someone is an arbitrarily designated server) it's a little simpler because clients inform the server what the last step they received was, and the server tells clients the step that it knows everyone has received, then when a server disconnects and a new server is chosen, the first act of the new server is to tell all the clients to rewind to the point that it knows everyone reached.


I remember now why I left this out of the article! I'm not sure the above paragraph is very clear. TLDR version: Disconnect handling in a peer-to-peer input sharing scenario is very complicated, using a server-client model and host migration is also very complicated, but slightly less so (IMO).

#5267681 How to share review copy of iOS game?

Posted by C0lumbo on 23 December 2015 - 01:14 PM

After release you use promo codes. Prior to release, I believe it's possible with testflight. I think the reviewer would have to send you their device ID, and you add it to some permitted list.

#5267455 My code will not work when it is watched

Posted by C0lumbo on 22 December 2015 - 02:21 AM

My guess would be that Character_Health_Timer is an integer and that the term:


Character_Health_Timer += 20 * ( deltaTicks / 1000.f );


Is implicitly rounding, and ends up adding zero each frame when you play normally.


When your app is off-screen, deltaTicks is large enough that a non-zero value can actually be added.

#5266899 Why don't modern GPUs support palettized textures

Posted by C0lumbo on 18 December 2015 - 08:11 AM

I suppose texture size could be a factor too in the death of texture palettes. As texture sizes get larger and larger, the quality of block compression remains unchanged, but the ability of a 256 colour palette to do a reasonable job diminishes. Especially in the fact of texture atlases where unconnected textures with very different colours are munged together.

#5266678 Particle lighting : cos + sin is a good solution ?

Posted by C0lumbo on 16 December 2015 - 11:35 AM

You could replace a sin and a normalize with a sqrt:


n.z = sqrtf(max(0.0f, 1.0f - n.x*n.x - n.y*n.y))


I'm sure there's many other solutions. A texture lookup would probably be faster on mobile (but probably slower on desktop GPUs).

#5265508 Visual studio Android Native Activity project VS NDK

Posted by C0lumbo on 08 December 2015 - 05:10 PM

I can't see why native would be slower either.

I'd go with the usual approach of having the bulk of your code as c++, but using JNI and Java. Primarily because that way it's easier to plug in stuff like Google Play Game Services and Ad Networks and Facebook, etc. Depending on the title you're developing, there can be a surprising number of annoying SDKs to integrate, and lots of them won't have pure native versions.

#5265497 Blending settings question

Posted by C0lumbo on 08 December 2015 - 04:11 PM

You can render the cylinders with depth write on and glColorMask off (or the DIrectX equivalent) so that you don't write any pixels, this 'primes' the depth buffer. Then, render the cylinders again with depth test set to equal, and whatever blending you like.

#5265299 Replay & recorded games

Posted by C0lumbo on 07 December 2015 - 12:15 PM

Going back to the OP, I'd recommend doing the following to get the replay system robust:


* Do a binary save after every single step of the simulation.

* After each step, load the previous step's save, and apply the input again.

* Compare the CRC of the two states

* If there's a difference, then compare a binary save of the original step against a binary save from the repeated step

* Find out which byte of the binary saves is the first one that's different.

* Load one of the binary saves, but this time assert when you get to the different byte

* You should have a callstack that indicates which member of which entity has diverged which should give you a pretty strong clue about where you went wrong.


Do this all the time in your debug builds so you catch any new bugs immediately, and not just when you're explicitly trying to test your replay system.


I recently wrote an article which covers some relevant stuff (in the context of lockstep multiplayer): http://www.tundragames.com/minimizing-the-pain-of-lockstep-multiplayer/

#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:





#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.