Subscribe to GameFromScratch on YouTube Support GameFromScratch on Patreon

24. July 2013

 

 

My somewhat recently published book, PlayStation Mobile Development Cookbook is currently the top ranked game programming book on Amazon…

 

…in Japan …on Amazon …in Kindle format.

 

But it’s still pretty cool. Smile

 

I check Amazon sales rank every once in a while to see how my book is doing ( it’s the only insight into book sales I have, amazingly enough ) and today when I check Japan, I see:

 

image

 

Number one baby!  Open-mouthed smile

 

Granted, Amazon track this value in pretty close to real time, so I am the number one selling game programming book in Japan for RIGHT NOW… in an hour I might be 50th…  but I’ll take it!

 

In another bittersweet milestone, I also just found the book on pirate sites for the first time.  That actually took longer than I expected to be honest.  I suppose an author or game developer should take it as a badge of honour that people will pirate what you created.

 

 

Oh, and Japan, you rock!

Totally Off Topic

24. July 2013

 

I have finally put together a single page for Project Anarchy tutorials.

 

image

 

Basically, it’s just a static page where you can access all current and future Project Anarchy tutorials on GameFromScratch.  There are a couple advantages to this though.  First, it makes it easier to find things than using tags.  Second, since the tutorial series is in order, I suppose it’s nice to actually put them in order, eh?

 

Finally and perhaps most importantly, it gives a great place to leave suggestions, feedback and comments on the series as a whole.  So, if you have a question that isn’t specific to an individual tutorial, or you want to request a specific thing be covered, this page is the perfect place to post them.

Programming ,

23. July 2013

 

In this second part of the input tutorials, we are going to look at handling input on a mobile device.  We are going to cover:

  • Configuring the RemoteInput plugin in vForge
  • Connecting with an Android device
  • Handling touch
  • Handling acceleration

 

This tutorial is fairly short, as once you’ve got RemoteInput up and running, most of the rest is pretty similar to stuff we have already covered, as you will soon see.

 

One major gotcha with working with a mobile device is emulating touch and motion control on your PC.  Fortunately Project Anarchy offer a good solution, RemoteInput.

 

RemoteInput

 

RemoteInput allows you to use an Android device to control your game in vForge.  This can result in a massive time savings, since you dont have to deploy your application to device to make use of the controls.

 

First though, you need to enable the plugin.  To enable the plugin, in vForge select Engine->Manifest Settings.

image

 

Then select the Engine Plugins tab

image

 

Then click Add Plugin

image

 

Then locate the vRemoteInput plugin, mine was located at C:\Havok\AnarchySDK\Bin\win32_vs2010_anarchy\dev_dll\DX9.

 

image

 

You will now be prompted to reload your project, do so.

 

Next you need to add a small bit of code to your project.

 

G.useRemoteInput = true

function OnAfterSceneLoaded(self)
  if G.useRemoteInput then
    RemoteInput:StartServer('RemoteGui')
    RemoteInput:InitEmulatedDevices()
  end
end

 

 

This code needs to be called before any of input is handled, I chose OnAfterSceneLoaded(), but there are plenty of other options earlier along that would have worked.  Of critical importance to notice is the global value, G.useRemoteInput, you need to set this to true if you are going to be using the RemoteInput plugin.  Next we start the server up with a call to StartServer() passing in an (arbitrary) string identifier.  We then initialize things with InitEmulatedDevices() which to be honest, I don’t know why you would ever defer this, so why not just do this in StartServer?  Anyways…  you need to call the init function.  You are ready to use RemoteInput.

 

Next time you run your app with the newly added code you will see:

image

 

Now on your Android device, open the web browser and enter the URL listed at the top of your app.  Once loaded, you can touch on screen and it will be sent to vForge as local input.  Motion data is also sent, allowing you to use the accelerometer and multi-touch without having to deploy to an actual device.  If you change the orientation of the device, it updates in vForge.  One thing to keep in mind, the coordinates returned by RemoteInput are relative to the window size on screen, not those of your actual device.

 

There are a few things to be aware of.  First, your computer and mobile device both need to be on the same sub-net… so both connected to the same wireless network for example.  Next, it doesn’t require a ton of speed, but as I type this connected to a cafe internet hotspot made of bits of string and a couple tin cans…  on a slow network it’s basically useless.  Also, you may need to reload your browser on occasion to re-establish the connection.  Finally, the browser may not support motion data, for example the stock browser on my HTC One works fully, but the Chrome browser does not.

 

Handling mobile input using Lua

 

Now we are going to look at how you handle touch and motion controls.  The code is virtually identical to the input code from the previous tutorial so we wont be going into any detail on how it works.

 

Handling Touch:

 

-- in the function you create your input map:
local w, h = Screen:GetViewportSize()

self.map:MapTrigger("X", {0, 0, w, h}, "CT_TOUCH_ABS_X")
self.map:MapTrigger("Y", {0, 0, w, h}, "CT_TOUCH_ABS_Y")

-- in the function where you handle input:
local x = self.map:GetTrigger("X")
local y = self.map:GetTrigger("Y")
-- Display touch location on screen
Debug:PrintLine(x .. "," .. y)

 

This code is taken from two sections, the initialization area ( probably where you init RemoteServer ) where you define your input map, and then in the function where you handle input, possibly OnThink().  It simply displays the touch coordinates on screen.  You can handle multiple touches using CT_TOUCH_POINT_[[N]]_X/Y/Z, where [[N]] is the 0 based index of the touch.  So for example, CT_TOUCH_POINT_3_X, would give the X coordinate of the 4th touching finger, if any.

 

Handling Acceleration:

-- in the function you create your input map:
self.map:MapTrigger("MotionX", "MOTION", "CT_MOTION_ACCELERATION_X")
self.map:MapTrigger("MotionY", "MOTION", "CT_MOTION_ACCELERATION_Y")
self.map:MapTrigger("MotionZ", "MOTION", "CT_MOTION_ACCELERATION_Z")

-- in the function where you handle input:
local motionX = self.map:GetTrigger("MotionX")
local motionY = self.map:GetTrigger("MotionY")
local motionZ = self.map:GetTrigger("MotionZ")

Debug:PrintLine(motionX .. "," .. motionY .. "," .. motionZ)

 

As you can see, motion and touch are handled virtually identical to other forms of input.  The value returned for MOTION values is the amount of motion along the given axis, with the sign representing the direction of the motion.

Programming ,

22. July 2013

 

For a point release, this one’s pretty good.Unity42

 

As mentioned in the title, probably the biggest change is the addition of 3 new platforms, Windows 8 ( as in the app store ), Windows Phone 8 and Blackberry 10.  Windows Phone 8 “Pro” is available free to Unity Pro subscribers.

 

Probably the biggest new feature isn’t new at all.  A number of previously “pro” level features are now available free.  Nav mesh baking ( used for AI pathfinding ), realtime shadows and text based serialization of assets for integration with version control have all become free features.  Those are perhaps the most cited missing features from the “basic” version, so if you are on a budget, that’s great news.

 

Other big features include:

  • OpenGL ES 3.0 support
  • Perforce source control integration
  • iOS crash reporter
  • Anti-aliased RenderTextures.
  • Numerous new image effects ( Blur, Bloom, Edge Detection, etc… )
  • Stencil buffer access (pro only)
  • Shuriken particle system callback scripting interface
  • Added the Quad primitive!

 

Of course, this is just a highlight of the features added, you can check them all out here.  Or of course you can just go ahead and download it, as all Unity basic versions are now free.

News ,

18. July 2013

Today the Blender Foundation released Blender 2.68.  It's not a large release, epecially compared to some of the more recent ones, but it has a few modelling features I am going to absolutely love. B268

 

 

 

 

First and foremost is the change to the Bridge tool.  You can now bridge between edge loops with a different number of vertices!  This is one of those features I miss when moving from other 3D packages to Blender.  Here is the new bridge tool in effect:

BlenderBridge

 

This feature is exceedingly handy for connecting multiple models together, even if it might require some cleanup later.

 

The next new modelling feature is Vertex Connect, which can basically be thought of as a knife tool that operates between vertices.

Vertexconnect

 

It's a small thing, but it will make doing face cuts much cleaner, resulting in at least two less vertices per cut.

 

 

Finally, you know have the option to split faces when you dissolve vertices.

BlenderFaceSplit

 

I'm not entirely sure if I will use this or not.

 

On the modelling side, there were a number of revisions for symmetric modelling, and a new Grid Fill tool for filling two connected edge loops.  In many ways this reminds me a ton of the early 3DS Max patch modelling plugin ( … which name I have forgotten… everyone had a copy… ).

 

These images are from Blender.com.

 

If you start with this:

GridFill1

 

And apply a grid fill, you end with this:

GridFill2

 

Very cool and potentially very useful, but I HATE Blenders curve tools with a passion.

 

On the non-modelling side of things, the Cycles renderer got a few improvements. CPU and GPU performance were improved, a mist render pass was added, hair rendering on GPU as well new nodes were added.  On the physics side, particles now respect the modifier stack and the smoke particle sample now is higher resolution.  There were improvements to motion tracking, general usability as well as 280 bug fixes!

 

 

Not an earth shattering release, but theres enough new stuff in there that certainly make your life easier.  They had me at bridge tool!

 

So head on over and download it now.  I offer a 100% money back guarantee!

Month List

Popular Comments

Unreal Engine development on laptops. Tips to maximize battery life
Subscribe to GameFromScratch on YouTube Support GameFromScratch on Patreon


Home > >

5. May 2015

 

Right when Unreal Engine 4 was released I promptly downloaded it on my Macbook Air.  Obviously I wasn’t expecting exceptional performance but where I was truly staggered was battery life.  When I started my battery was showing 9 hours remaining.  51 minutes later my machine died.  Wow.  Of course any machine running intensive CPU and GPU activity is going to drain fast, but for comparison, running Unity on the same machine lasted about 4 hours.  For developers like me, who are constantly on the go but not necessarily next to a plug, this is a bit of an issue.

 

The problem is that Unreal Engine editor is essentially an Unreal Engine game, running at nearly full clip.  The problem is, this is happening all of the time, even when you don’t need realtime rendering.  At the end of the day, Unreal Engine is designed to be run on a desktop machine, so power consumption is mostly an afterthought.  Fortunately there are some things you can do to maximize battery life.  Of course every single tip I am about to share comes at the cost of performance!  Generally though, this isn’t really all that big of a deal… you don’t need UE4 running at full speed if you are working on Blueprints or testing some new C++ code for example.

 

So, what follows is some tips to maximize your battery life as much as possible.

 

First let’s take a benchmark of battery usage.  This is Unreal Engine 4 running using the Twin Stick shooter example with the editor completely idle but focused.

Ss1

 

Obviously this value fluctuates based on being focused or not and various other factors, but it gives us a starting point.

 

Turn off Realtime Update

 

The easiest first step is to turn off realtime updating for your viewport.  In the top left corner of the viewport, drop down the menu and unselect Real Time Rendering.

Ss3

 

This setting prevents the viewport from constantly rendering, instead only updating when you change the view or update the scene.  You can use the hotkey combo CTRL+R or CMD+R to turn this off.  There is a similar setting when editing Blueprints as well.

 

 

Make sure Use Less CPU when in Background is selected

 

This one should be enabled by default, but lets make sure.  Go to Unreal Settings  (Unreal Editor->Preferences on Mac, File->Preferences on Windows), select Miscellaneous then under Performance verify that Use Less CPU when in Background is checked:

Ss4

 

This one does exactly what you would expect, when Unreal Editor isn’t in focus (isn’t the active application) it massively lowers the CPU consumption and thus battery usage.

 

 

Turn off Realtime Thumbnails

 

There is a nifty option in the content browser that it will generate realtime thumbnails of your assets.  This gives you quick previews of your models, textures, etc… but is also a pretty meaningless CPU sink.  You can turn if off by selecting View Options in the bottom corner of the Content Browser window and unselecting Real-Time Thumbnails.

Ss5

 

Set a Maximum Framerate

 

You can set a maximum rendering framerate for the viewport which can have a positive effect on CPU/GPU usage.  There are two ways to perform this action, one is temporary and the other will effect the editor every time you load it.

 

Temporary setting max framerate:

Hit the ~ key to bring up the Console

Enter “t.MaxFps 10"Ss6 

 

This will cap the framerate at 10FPS.  Play with this value to strike the best balance between performance and CPU usage.

 

Permanently setting max framerate

Open the config file ConsoleVariables.ini.  In my case on MacOS it is located at 

/Users/Shared/UnrealEngine/4.7/Engine/Config

Then locate [Startup] and add the line t.MaxFPS=10 below it.

Ss7

 

 

Throttle the CPU for the Unreal Editor PID

If all of these options don’t work enough, you can take the somewhat more draconian step of throttling the resources available to Unreal Engine.  If you are running a nVidia graphics card using Optimus, you can set Unreal to run using the Intel GPU instead of the nVidia, which should reduce GPU and thus battery usage.  You can also set the thread priority lower.  Here is an example with Mac OS.

 

First download and install cpulimit

Next locate the PID of the running Unreal Editor.  

You can get the PID from the terminal using the command 

ps -ef |grep "UE4Editor.app"

The PID is available in the results indicated below:

Ss9

 

Or you can simply locate it via Activity Monitor

Ss8

 

Now from a terminal enter the command sudo cpulimit —limit=30 —pid=numberfromabove —verbose

Ss10

This command will run in the terminal and hard limit the CPU available to Unreal Engine to 30%.  Obviously this is going to have a MAJOR impact on performance, but will also greatly limit battery drain too.  Obviously you can set the limit to whatever value you wish.  To stop throttling hit Ctrl+C in the terminal window.  As you can see from the results above, CPU throttling only has an effect if the CPU actually hits the specified threshold.

 

The Result

 

So, after all these tweaks… what is our current energy impact?

Ss11

 

Much much much better!  Less than 1/4 what it was!  That said, once you start doing things that require realtime feedback, you are going to want to undo everything you just did!  Thankfully it’s an extremely simple process.

blog comments powered by Disqus

Month List

Popular Comments