Jump to content

  • Log In with Google      Sign In   
  • Create Account

We need your help!

We need 1 more developer from Canada and 12 more from Australia to help us complete a research survey.

Support our site by taking a quick sponsored survey and win a chance at a $50 Amazon gift card. Click here to get started!


LoneDwarf

Member Since 27 Oct 2006
Offline Last Active Aug 31 2015 07:09 AM

Posts I've Made

In Topic: BitmapFactory.decodeFile() returning null

19 May 2015 - 12:07 PM

Can't say I have ever enjoyed BitmapFactory on Android.

 

I can't recall where but I have heard there can be issues with calling decodeFile. I changed mine to load the image into a buffer and then use BitmapFactory.decodeByteArray. This will allow you to log stuff like whether it was even found on the device and if it's the correct size. You could also do a MD5 and see if the image looks corrupt. Sounds like overkill but it might show something.

 

IIRC the Android build process will optimize your png files unless you tell it not to. Should be ok but maybe toggle it and see what happens.

 

It could be that the file itself is corrupt or not built exactly right. Some images made using a custom tool could be generating an image that most programs can load as they are less picky or can handle errors better. Try and load the file in something like Photoshop and resave it.

 

Finally I wouldn't format my if/else like that either. Playing with fire. When your code goes live, the Play Store will give you error reports with line numbers and you don't want to wonder what part of the line caused the error.


In Topic: Encoding Metadata in Bitmaps

19 May 2015 - 11:42 AM

I would suffer the texture swaps and drop the idea of atlases until you are willing to build a tool to handle it. You might find your game isn't having performance problems for it to even matter. Making an atlas by hand is crazy talk.

 

Myself I use lua with bindings to my own code in a dll to build source assets for the game. I then use the directory structure to define the atlases. I can add an atlas or sprite no problems at all.

 

Here are some directories:

 

atlases

atlases->hud

atlases->particles

 

The tool looks for all sub-directories in the root called atlases and makes one atlas for each directory. The name of the directory is then used for the atlas name. So we will have 2 atlases called hud and particles. Any images found in the directory get put into the atlas. There are articles online that talk about how to pack images into an atlas, just google it. The final atlas built will be a binary and an image using the atlas name with different extensions. I use hud.atlas and hud.png. The hud.atlas is a binary that gives the uv mappings for each image using the image filename as the id. I also have a bounding volume that looks for zero alpha in images starting from the edges.

 

Some other details are. I have a tmp directory that saves the source images used to make the atlas. This list is used to determine if the atlas needs to be rebuilt but you could always rebuild if you want. The lua script also tries to load a properties file for each image if I need to override something like a border. So player_hat.png might have player_hat.properties that is just a lua table of properties.

 

At runtime all the altases are loaded in a sprite manager and you can query a sprite using the image name. A sprite class will have it's texture name and other details like uv coords. Took a day to get going IIRC but has been tweaked over time.  This kind of tool is a stable in all my projects now.

 

 

 

 

 

 

 

 


In Topic: Android game resolutions

28 April 2015 - 11:59 AM

For me the problem is mostly just the UI as my games are 3D these days. For 3D it's a simple FOV and viewport. I use the stretching option and it looks fine. Used it in 2D games also. Now I am sure there are some really small or large devices that don't look 100% but it's a reasonable solution. While some people will rage over this, you need ask yourself how much time you have to spend on this and how much of the market you want to please. I used this method on my Tank Recon games and they have over 10 million downloads to date. So they have seen plenty of different devices.

 

For fonts I use freetype to rasterize the fonts when the game first runs based on the screen size and cache them using local storage. Check your license for the font to be sure it allows for this. Fonts just don't scale well.

 

First I define a reference resolution, last game was 1280x720. All art is created using this resolution and all screens are built in that resolution. This resolution was chosen based on the most common resolutions on the market at the time and then rounded up somewhat so that most scaling would be down. Then I make a scale factor that is the real screen size (at run-time) divided by the reference screen size. The smallest scale is taken.

 

Vector3f vScale = vScreenSize / vRefSize;
float fScale = (vScale.x < vScale.y) ? vScale.x : vScale.y;

 

Now this scale factor is applied uniformly to all sprites in my UI. I have an asset manager that will just apply this when I request a sprite. For a 2d game you will need to use this scale factor to adjust your world units.

 

At this point all the sprites and fonts are scaled based on the screen size. Next is the layout. I design the screens vertically and somewhat relative spacing. The layout units are normalized to the screen size (0-100%). I use helper functions like these:

 

s32 hDipToPixels( float fPercent )
{
    return s32(fPercent* ((float)vScreenSize.x / 100.0f));
}
s32 vDipToPixels( float fPercent)
{
    return s32(fPercent* ((float)vScreenSize.y / 100.0f));
}

 

Here is a small taste of how I use the layout. This somewhat sugar coats it as there are more complicated cases where I will have to use more procedural layout. Still I don't think you can get away without it and it's not worth solving IMHO. I have to say I like this method and will continue to use it.

 

s32       navBottomMargin        = ui.vDipToPixels( 1.0f );
s32       topMargin            = ui.vDipToPixels( 1.8f );
s32       pauseLeftMargin        = ui.hDipToPixels( 1.0f );
s32       healthLeftMargin    = ui.hDipToPixels( 1.0f );
s32       healthTopMargin        = topMargin;

s32       shieldsRightMargin    = ui.hDipToPixels( 1.0f );


In Topic: how to use GLCanvas with wxWidegets 3.0.2

28 April 2015 - 10:47 AM

You need to build a version of the wxWidget libraries that has OpenGL support.  I think there is a define like wxUSE_GLCANVAS. I have recently started to use wxWidgets for my tools and it has been good.


In Topic: Mobile Game Development - Java, C++, Lua? Whats best?

15 April 2015 - 08:45 AM

This topic pulls at me as I often wish I had someone talk sense into me when I was younger :) Frob gave you the answer and it's an answer that is hard to hear when you're starting out. Nevertheless it is very true.

 

The amount of effort to make a game is consistently under estimated. Now add learning mobile on top off it and just forget it. A common topic of bitching with colleagues is just how painful mobile development is. Console development IMHO is much easier. If someone wants to become a race car driver they need to start with a regular car first.  People don't just start off learning to be a race car driver. 

 

Now I am not interested in discouraging anyone at all and I know it sounds pretty preachy but I wish someone had preached it to me when I was younger.  Use your brilliance in a productive manner. I spent WAY too much time learning every aspect of a game engine or at least what I thought a game engine should do. In reality I wasn't equipped with the knowledge to even know a full game needed to do. In the end I never finished a game until I was in the industry. I had so many games that were almost done but in reality they were just graphics with a guy type of thing.  Perhaps 10% of a game at best.

 

If I was to start out today I would likely use Unity because there is so much support. The amount of work spent on just getting assets into the game and rendering something is huge. Don't fall for all this ego stuff that says you need to know 3D graphics and be a hard core C guy. Let other people go that way and see what they have in a year. People spend so much time on graphics and simple collision and still haven't even touched on game play.  Build a very very simple game in Unity and finish it.  Make it very small like pac man or space invaders but finish it. Seriously finish it.  Having finished projects will look very good on your resume and when hiring, people only want to hear about shipped games and there is a reason why.

 

After you have finished your little game you will now be more equipped to ask the right questions. Again this isn't meant to discourage as I say go out and conquer! Just be realistic and work smart. After reading this a second time I am reminded how I had a problem with some planes getting stuck on a couple of towers. The planes were somewhat of a secondary object in the world and it pained me that I had to try and fix the steering for this. I came up with a few ideas and then I moved the towers out of the way. I could have wasted god knows how much time making a better steering system or I could ship the game.  Work smart and get it done.

 

If you still just have to get at it, then use the suggested language for the platform. For Android you should use Java as it's way more supported and the debugging will work out of the box, well maybe. For iOS use ObjC. I hate ObjC myself and it pains me to suggest it, but all the samples are using it and you don't want to add the extra complexity of mixing ObjC with C++.

 

For the record I use C++/OpenGL/lua. I originally used Java to do BlackBerry development and later some Android and I loved it. The problem was I couldn't get enough platforms with it.  Using C++, OpenGL and lua for scripting got me 95% shared code for Android, iOS and BlackBerry 10.


PARTNERS