Game porting question
Author
If you have a game that uses a screen size of 128 x 128.When you port it over to a phone with the screen size of 128 x 160.Do you all resize the graphics to fit the new screen or just maintain the screen size of 128 x 128?If so,won't the aspect ratio be change thus making the game graphics look skewed?
I intend to port a game created using Nokia extensions to the Sony Ericsson platform.I was wondering do you all convert the graphics and other method calls from Nokia to the proprietary method calls(Sony Ericsson in this case) or do you just use MIDP image methods to create images and try to keep everything as native as possible unless you really need to utilise some feature in the handphone like vibration alert,full canvas,backlight etc etc.
When it comes down to porting to a different screen size you end up with a lot of choices.
You can just stretch all the images, and other than things not looking right (aspect problem and artifacts) it does the least changes to the game.
Or... you could completely redo all images to be used for the size screen it's going to be on. This can be a lot of work but will often look better, depending just how much of size difference and what type of game it is.
Depending what type of game it is and how closely you want to keep it to original, you could modify the play field to fill the screen. i.e. for a pong game you'd just have a bit bigger table, or a tiled rpg would show an extra row or two of the environment.
Along the same lines as the last option, but without changing the actual game play, you could add/modify GUI/HUD type elements in the extra space, such as showing the number of lives or the score, or if you are already doing that, move it off the play area or make the text a slight bit larger...
It really comes down to exactly what you are doing and what you think will work best. There isn't one solution for all situations. Hopefully one of those sticks out as the right thing for your project though.
You can just stretch all the images, and other than things not looking right (aspect problem and artifacts) it does the least changes to the game.
Or... you could completely redo all images to be used for the size screen it's going to be on. This can be a lot of work but will often look better, depending just how much of size difference and what type of game it is.
Depending what type of game it is and how closely you want to keep it to original, you could modify the play field to fill the screen. i.e. for a pong game you'd just have a bit bigger table, or a tiled rpg would show an extra row or two of the environment.
Along the same lines as the last option, but without changing the actual game play, you could add/modify GUI/HUD type elements in the extra space, such as showing the number of lives or the score, or if you are already doing that, move it off the play area or make the text a slight bit larger...
It really comes down to exactly what you are doing and what you think will work best. There isn't one solution for all situations. Hopefully one of those sticks out as the right thing for your project though.
Author
Ok,i've got it.Do you try to use native code for such stuff as image objects creation as much as possible and, avoid using API extensions unless there is a need to?Examples would be using API extensions to play sound,use vibration etc etc.
Yeah spot on moose. Try and build a generic game first and then go through and add all the API specific pieces target device by target device.
What you'll find really useful is to use a preprocessor. I personally use the C preprocessor, but there are Java specific versions (antenna for one). Then, you can do stuff like:
I also have a file that contains useful functions and '#include' it into the class:
I can then have different versions of "graphics.h" depending on the model of phone the application is being built for - so I can take advantage of phone APIs or handle 'features'.
Skizz
#if SCREEN_HEIGHT == 128 // draw screen for 128 pixel high#elif SCREEN_HEIGHT == 160 // draw screen for 160 pixel high#endifI also have a file that contains useful functions and '#include' it into the class:
public class game_canvas extends Canvas{#include "graphics.h" public void paint (Graphics dc) { // this function is defined in "graphics.h" and // draws the graphic with ID GRAPHIC_SPRITE_1 at the // given x,y position // the source image contains multiple graphics (to // reduce file size) much like a texture page (a sprite // page) DrawGraphic (dc, x, y, GRAPHIC_SPRITE_1); }}I can then have different versions of "graphics.h" depending on the model of phone the application is being built for - so I can take advantage of phone APIs or handle 'features'.
Skizz
Most of the time when porting games between handsets with different sized screens we usually do a combination of two things:
1) Make the art to fit the phone with the smallest screen and letterbox the game on larger ones.
2) Make the art fit one of the mid sized phones and draw it in such a way that we can cut off the sides/top/bottom when we draw it on the smaller screens.
If the screen size is dramatically different (128x115 vs 176x203 for instance) there will be a separate set of art for that class of phones.
Skizz's idea is nice, but its a luxury you can't use too often (on BREW anyways) since when you send the games to get tested for release they charge you an extra chunk of money for each unique binary. Therefore the more phones that can use the same binary, the less money you spend. Therefore we only use it when we have to do different art anyway.
However, internally we have phone detection code that may call different routines, such as unpacking a bitmap into 444, 5551, 565, or 888 formats depending on the type of phone. This, however is not done with the preprocessor and all nessasary routines are in the binary.
if(mPhone.type == PHONE_1) {
Stuff();
}
else if(mPhone.type == PHONE_2) {
Phone2Stuff();
}
etc.
-Evan
1) Make the art to fit the phone with the smallest screen and letterbox the game on larger ones.
2) Make the art fit one of the mid sized phones and draw it in such a way that we can cut off the sides/top/bottom when we draw it on the smaller screens.
If the screen size is dramatically different (128x115 vs 176x203 for instance) there will be a separate set of art for that class of phones.
Skizz's idea is nice, but its a luxury you can't use too often (on BREW anyways) since when you send the games to get tested for release they charge you an extra chunk of money for each unique binary. Therefore the more phones that can use the same binary, the less money you spend. Therefore we only use it when we have to do different art anyway.
However, internally we have phone detection code that may call different routines, such as unpacking a bitmap into 444, 5551, 565, or 888 formats depending on the type of phone. This, however is not done with the preprocessor and all nessasary routines are in the binary.
if(mPhone.type == PHONE_1) {
Stuff();
}
else if(mPhone.type == PHONE_2) {
Phone2Stuff();
}
etc.
-Evan
Author
Quote:Original post by terminate
Most of the time when porting games between handsets with different sized screens we usually do a combination of two things:
1) Make the art to fit the phone with the smallest screen and letterbox the game on larger ones.
-Evan
Uh,what do you mean by letterbox the game?
Quote:Original post by Moose6912Quote:Original post by terminate
Most of the time when porting games between handsets with different sized screens we usually do a combination of two things:
1) Make the art to fit the phone with the smallest screen and letterbox the game on larger ones.
-Evan
Uh,what do you mean by letterbox the game?
Letterboxing is simply drawing the game in the middle of the screen, leaving a border around the outside on larger screens.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
