My First Smartphone (& PDA) game.

Send us News! | Rules

Please Log In or Register - it's FREE!

You Are Here » WinMo @ MoDaCo » Smartphone / Windows Mobile Standard (non Touchscreen) » Smartphone Software » Smartphone Software - Games

2 Pages

1 2 >

My First Smartphone (& PDA) game., Columns

Options

nIghtorius

Apr 29 2005, 16:44

Post #1

Newbie

Group: Posters
Posts: 28
Joined: 25th March 2005
Member No.: 119,535

Device(s): SPV C_500

Hi!

I have finished my first smartphone game.. (which also works on PDA's by resizing the 176x220 image to 320x240 or 640x480, depending on what PDA)

the controls of the game are selfexplainery. but still I'll explain them..

{enter} = select a item in the menu / pauses/unpauses the game.
{left} or {4} = move column to the left
{right} or {6} = move column to the right
{up} or {2} = move up in the menu / slides the available items in the column
{down} or {8} = move down in the menu / forces faster down movement of column

smartphone only {r-soft-button} = immediate shutdown of the game. (my panic button

)

some in-game screens:

download the .CAB version for smartphones.. (confirmed to be working on SP2003(SE)) and if the .CAB version refuses or you own a PDA/MDA use the .ZIP attached file.. just put the contents in a directory.

also.. I have a C500. so you don't have to worry about the "flickerbug".. It runs just fine.

I hope you enjoy this game. I think this is my first post.. even I have registered a while ago.

The graphics on this post aren't representative anymore..
go visit DaddyCool's post for a feel:

download here:

columns_ce.zip ( 426.65K ) Number of downloads: 196

columns.CAB ( 424.19K ) Number of downloads: 86

This post has been edited by nIghtorius: May 3 2005, 11:22

Mehka

Apr 29 2005, 16:46

Post #2

Regular

Group: Posters
Posts: 123
Joined: 24th March 2005
Member No.: 119,356

Device(s): none homie

isnt there alot of these games avaible already? thanx anyway

nIghtorius

Apr 29 2005, 16:48

Post #3

Newbie

Group: Posters
Posts: 28
Joined: 25th March 2005
Member No.: 119,535

Device(s): SPV C_500

QUOTE(Mehka @ Apr 29 2005, 17:46)

isnt there alot of these games avaible already? thanx anyway

Gimme some slack here.. this is my first SP game.. heck my first SP application whatsoever. It's all a learning process here..

Most of those games I downloaded suffered from the annoying flickerbug on my C500.. which is irritating like hell. So I thought why not do it myself? and learn some neat tricks along the way.

is also a good way to test my GAPI graphicslibrary which supports the following:

* Alpha rendering
* Sprites
* Stretching
* avoiding the flickerbug on the SPV C500

* screendisplaysize independecy.. (i.e.: 176x220 being fullscreen on 320x240 PDA devices, or a 320x240 image scaled down to fit in 176x220 without hassling the programmer)
* Heck it even supports a "working directory" (this is really a pain in the ass with the CE OS.. having to working directory)
* Font engine
* Loading of 24bpp bitmaps (8-bit bitmaps (RLE compressed) in the works)
* smooth-scrolling by using (scoll (SCROLL_UP)

and this featurelist still grows.. depending what my next project needs.

This post has been edited by nIghtorius: Apr 29 2005, 16:56

gpcarreon (MVP)

Apr 29 2005, 16:58

Post #4

RN, MS MVP-MD
Group Icon

Group: Moderator Team
Posts: 4,532
Joined: 7th August 2003
From: Legazpi, Philippines
Member No.: 12,251

Device(s): ASUS P525, ASUS N10J-A1

Hi NIghtorious.

Welcome to MoDaCo. Thanks for sharing this game.

--------------------

Jakult everyday, everyday OK!

agent.m

Apr 29 2005, 17:13

Post #5

Vario fanatic!
Group Icon

Group: Posters
Posts: 1,008
Joined: 11th January 2003
From: Leeds
Member No.: 1,806

Device(s): MDA Vario II

QUOTE(nIghtorius @ Apr 29 2005, 16:48)

and this featurelist still grows.. depending what my next project needs.

Hey homes chill! You dont have to justify yourself

welcome to Modaco

--------------------

Pre phones:3210-3310-sl45i-m50-mt50-spv-T-mobile Sda - C550 - Nokia N70 - MDA Vario

This is an official Invizible circle member!

http://www.myspace.com/mutantproductions

mupwangle

Apr 29 2005, 17:17

Post #6

Diehard

Group: Posters
Posts: 337
Joined: 22nd November 2004
From: Mirfield, W.Yorkshire, UK
Member No.: 66,050

Device(s): SPV c500 + Qtek S110

QUOTE(agent.m @ Apr 29 2005, 17:13)

Hey homes chill! You dont have to justify yourself

welcome to Modaco

Aye. Some folks are never happy! :roll:

Is it meant to flash as the columns rotate? It sort of looks deliberate, but I thought it was a bit visually distracting.

The 3d text on the title screen makes my eyes go funny. Kinda magic eye effect. :shock:

--------------------

I was walking past a building and I saw a man standing high up on a ledge. �Jump! Jump!� I started yelling. What happened next would haunt me for the rest of my days: the man came down from the building and beat the living daylights out of me.
-Jack Handy

nIghtorius

Apr 29 2005, 17:27

Post #7

Newbie

Group: Posters
Posts: 28
Joined: 25th March 2005
Member No.: 119,535

Device(s): SPV C_500

QUOTE(mupwangle @ Apr 29 2005, 18:17)

Well.. I also think I should have used more animation frames for the columns rotation animations. But I do not have 1337 drawing/animation skillz.

I will someday rework the animation frames of the columns to be more "smooth" and less distracting.

You can replace the ?cube.bmp files with your own versions.. be sure it's 3 frames of 16x16 images (making a whole 48x16 bmp image)

just to get a message out here:
If you want to make a animation for the game which exceeds 3 frames.. just submit it here and I will take a look and modify the game code if needed. they really could need some better animation..

neat feat: (stretching code)

CODE

unsigned short * buffer = (unsigned short *) GXBeginDraw();
    if (buffer == NULL) return;

    int dx = (Source.width << 16) / (gx_displayprop.cxWidth << 8);
    int dy = (Source.height << 16) / (gx_displayprop.cyHeight << 8);
    int rx = 0, ry = 0;

    for (unsigned int y = 0; y < gx_displayprop.cyHeight; y++) {
for (unsigned int x = 0; x < gx_displayprop.cxWidth; x++) {
     buffer [x] = Source.framebuffer [(rx >> 8) + ( (ry>>8) * Source.width)];
     rx+=dx;
}
ry+=dy;
rx = 0;
buffer+=gx_displayprop.cbyPitch >> 1;
    }

    GXEndDraw();

note:

It would be nice if you report the functionality of the game and on what hardware and what installation you used (CAB/ZIP)

for example: I have used the .CAB version to test-install on my SPV C500 phone. I also tested on a T-Mobile MDA (416Mhz ARM proc)

and also tell if the game is too difficult/easy.. (or hopefully just right)

This post has been edited by nIghtorius: Apr 29 2005, 17:44

muff

Apr 29 2005, 18:25

Post #8

Addict

Group: MoDaCo Plus
Posts: 938
Joined: 19th January 2003
Member No.: 2,098

hiya

well done on making your first game

I've not actually installed it yet (will do that later) but as a fellow coder there's a couple of technical points I'd suggest

- bmp's are HUGE compared to a compressed format like PNG
- look at the Hekkus sound library (http://www.shlzero.com/) instead of FMOD - smaller and cheaper should you go commercial with games in the future
- the loop above is begging for optimisation (if only to remove the multiplication you are doing every pixel)

all the best

muff

p.s. I pulled down the zip so I could look at the raw files quickly

mupwangle

Apr 29 2005, 20:02

Post #9

Diehard

Group: Posters
Posts: 337
Joined: 22nd November 2004
From: Mirfield, W.Yorkshire, UK
Member No.: 66,050

Device(s): SPV c500 + Qtek S110

The flashing isn't between frames - it's more like the 3rd frame is a flashing one (if that makes sense). It's like 1,2,flash,1,2,flash. That's why I thought it was by design.

I installed the CAB on an app-unlocked (not sim-inlocked) c500 running le neuveau rom francais. Seems to work OK so far. Haven't had a chance to play with it much though.

--------------------

nIghtorius

Apr 29 2005, 22:57

Post #10

Newbie

Group: Posters
Posts: 28
Joined: 25th March 2005
Member No.: 119,535

Device(s): SPV C_500

QUOTE(muff @ Apr 29 2005, 19:25)

hiya

well done on making your first game

That's what I mean. it's my first app.. So it's great food for optimalisations. Still. it runs quite fast.. read as: it ran smooth even on the slowest PDA i could find. (since this is the only thing what invokes this code (requires stretching on PDA's))

and due to the fact I can't emulate a PDA and not having availability of one nearby. I programmed as safe as I could. thus keeping readability a plus. highly optimised code is sensitive of little mishaps/mistakes.

Keep in mind that the code doesn't copy 1 on 1 but resizes the image in the process. (resizing a 176x220 image to 320x240 when putting on the screen)

I have refrained from the most performance killing technique. using floats/doubles for calculation.. those are sure make it really slow.

an obvious optimisation would be:

CODE

unsigned short * buffer = (unsigned short *) GXBeginDraw();
    if (buffer == NULL) return;

    int dx = (Source.width << 16) / (gx_displayprop.cxWidth << 8);
    int dy = (Source.height << 16) / (gx_displayprop.cyHeight << 8);
    int rx = 0, ry = 0;
    int yb;

    for (unsigned int y = 0; y < gx_displayprop.cyHeight; y++) {
yb = (ry >> 8) * Source.width;
for (unsigned int x = 0; x < gx_displayprop.cxWidth; x++) {
     buffer [x] = Source.framebuffer [(rx >> 8) + yb];
     rx+=dx;
}
ry+=dy;
rx = 0;
buffer+=gx_displayprop.cbyPitch >> 1;
    }

    GXEndDraw();

look @ the new var (yb) and how it's implemented. This optimisation did actually require not much thought and should have it right away. but my stretching code was a bit hush hush :oops:

also a good optimisation would be this:

CODE

unsigned short * buffer = (unsigned short *) GXBeginDraw();
    unsigned short * scanline;

    if (buffer == NULL) return;

    int dx = (Source.width << 16) / (gx_displayprop.cxWidth << 8);
    int dy = (Source.height << 16) / (gx_displayprop.cyHeight << 8);
    int rx = 0, ry = 0;

    for (unsigned int y = 0; y < gx_displayprop.cyHeight; y++) {
scanline = (unsigned short *) Source.framebuffer [ (ry >> 8) * Source.width ];
for (unsigned int x = 0; x < gx_displayprop.cxWidth; x++) {
     buffer [x] = scanline [(rx >> 8)];
     rx+=dx;
}
ry+=dy;
rx = 0;
buffer+=gx_displayprop.cbyPitch >> 1;
    }

    GXEndDraw();

I am going the "profile" those code snippets to figure out which one performs better.

about the flashing issue.. yes you're right.. it's the graphics what causes the problem.. just as I said before.. I should redo them (block graphics)

This post has been edited by nIghtorius: Apr 29 2005, 23:05

muff

Apr 29 2005, 23:36

Post #11

Addict

Group: MoDaCo Plus
Posts: 938
Joined: 19th January 2003
Member No.: 2,098

the first optimisation you did there was the obvious one I meant

only thing I'd then look at is reversing the x&y loops to do -- instead of ++ [ this means that the compiled code will be doing the equivalent of "branch if not zero" test, instead of actually doing a comparison ]

precalc the y line buffer bump as well? - instead of recalcing each time as well

oh, and on a device that has the original resolution, obviously dont do any scaling, have a tighter code specifically for that scenario - only add's an 'if' as overhead (actually on re-reading u might already have done this)

are you allowing for the different aspect ratio's at all?

there are loads more potential optimisations that are based on experience with the devices (like PPC's executing a blit loop like above slower than the Smartphones - so you end up writing specific blit's)

please dont take these as criticisms of your code though - think of it as enthusiatic fellow coder assistance

it's good to see a new coder on the block

muff

This post has been edited by muff: Apr 29 2005, 23:38

nIghtorius

Apr 30 2005, 09:29

Post #12

Newbie

Group: Posters
Posts: 28
Joined: 25th March 2005
Member No.: 119,535

Device(s): SPV C_500

QUOTE(muff @ Apr 30 2005, 00:36)

it's good to see a new coder on the block

muff

don't worry.. there is a if statement which checks if the resolution and output are equal and executes a much faster (just a bunch of memcpy's) method.. I haven't shown this piece of code as it is too obvious how to code such thing.

I am quite new to "C/C++" compilers.. But what you just said about "branch if not zero" sounds about right. at least I think it is.. since my "old" assembly days the "JNZ" instruction was far more efficient to use then "CMP AX, xxxx; JZ"

about the specific blits.. that alone defeats my purpose of having one piece of readable code for all PocketPC devices. I try to find the slowest piece of hardware I can find and if it still runs great then it is fine by me

about the y line buffer bump precalculation.. did you mean like this:

CODE

scanline += ylbump;

I would love to do such optimization.. but my "ylbump" is irregular. It may bump or it may not bump.. But there is a way.. but then I am wondering if it actually goes faster..

this is the optimisation I mean

CODE

unsigned short * buffer = (unsigned short *) GXBeginDraw();

    if (buffer == NULL) return;

    int dx = (Source.width << 16) / (gx_displayprop.cxWidth << 8);
    int dy = (Source.height << 16) / (gx_displayprop.cyHeight << 8);
    int rx = 0, ry = 0, by = 0;

    unsigned short * scanline;
    scanline = Source.framebuffer;

    for (unsigned int y = gx_displayprop.cyHeight; y > 0; y--) {
if ( (by >> 8) != ry) {
     ry = ( by >> 8 );
     scanline += Source.width;
}
for (unsigned int x = gx_displayprop.cxWidth; x > 0; x--) {
     buffer [x] = scanline [(rx >> 8)];
     rx+=dx;
}
ry+=dy;
rx = 0;
buffer+=gx_displayprop.cbyPitch >> 1;
    }

    GXEndDraw();

ps) this is a nice discussion.. it forces me to perform better. 8)

btw) as a fellow coder.. What programming-tools are you using for your games? I am using eMbedded VC++ 4.0 for my programming needs

ps2) aren't you the one who made SPVMan? since there is also a "SPVMan by Muff" in there

This post has been edited by nIghtorius: Apr 30 2005, 09:36

muff

Apr 30 2005, 09:46

Post #13

Addict

Group: MoDaCo Plus
Posts: 938
Joined: 19th January 2003
Member No.: 2,098

I actually meant the line

CODE

buffer+=gx_displayprop.cbyPitch >> 1;

and a slight change to the loops check (atm the compiler might still give you a CMP instead of the JNZ we are after)

so you'd get something like this

CODE

unsigned short * buffer = (unsigned short *) GXBeginDraw();

if (buffer == NULL) return;

int dx = (Source.width << 16) / (gx_displayprop.cxWidth << 8);
int dy = (Source.height << 16) / (gx_displayprop.cyHeight << 8);
int rx = 0, ry = 0, by = 0;
int ybump = gx_displayprop.cbyPitch >> 1;

unsigned short * scanline;
scanline = Source.framebuffer;

for (int y = gx_displayprop.cyHeight; y != 0; y--) {
scanline = (unsigned short *) Source.framebuffer [ (ry >> 8) * Source.width ];
for (int x = gx_displayprop.cxWidth; x != 0; x--) {
buffer [x] = scanline [(rx >> 8)];
rx+=dx;
}
ry+=dy;
rx = 0;
buffer += ybump;
}

GXEndDraw();

note ybump var and the changes to the for loop definitions to be != instead of >

also converted x+y to ordinary int's instead of unsigned ones - personally think that signed int's are easier on the CPU than signed ones

there is a slight overhead looking up the structure vars i.e. Source.width instead of looking this up from an ordinary var - but that's only slight

and of course your gfx blit routines can use the reverse loops if you're not already

This post has been edited by muff: Apr 30 2005, 09:48

nIghtorius

Apr 30 2005, 10:52

Post #14

Newbie

Group: Posters
Posts: 28
Joined: 25th March 2005
Member No.: 119,535

Device(s): SPV C_500

QUOTE(muff @ Apr 30 2005, 10:46)

also converted x+y to ordinary int's instead of unsigned ones - personally think that signed int's are easier on the CPU than signed ones

That one point I beg to differ.. good example: as we take 8-bit signed/unsigned integers. (shortint if I am correct)

computation:
32+64 = 96 (unsigned)

0010 0000
0100 0000+
------------
0110 0000 = 96 (unsigned)

now 128 + 32 = 160 (unsigned)

1000 0000
0010 0000+
------------
1010 0000 = 160

what if -32 + 32 = 0 (signed)

1110 0000 (!!! -32 signed var)
0010 0000+
------------
0000 0000 = 0 8) (signed)

meaning.. signed or unsigned integers is treated the same by the CPU.. actually there is no difference in arithmetic.

another example: heftier one..

-44 + 80 = 36 (signed)

1101 0100
0101 0000+
------------
0010 0100 = 32 + 4 = 36 (signed)

and again.. the right answer popped up. never ever had to change the method of computation here. that is the beauty of 2-complement numbers

muff

Apr 30 2005, 11:35

Post #15

Addict

Group: MoDaCo Plus
Posts: 938
Joined: 19th January 2003
Member No.: 2,098

in this case with loops you're right, and it's probably a moot point, but certainly in the past when using unsigned int's instead of straight int's in something more complex then I found them to be slower

you're right that the CPU should treat them the same speedwise - it's probably just a personal preference I've got into over the years

oh and 8 bit vars are CHAR

nIghtorius

May 1 2005, 00:57

Post #16

Newbie

Group: Posters
Posts: 28
Joined: 25th March 2005
Member No.: 119,535

Device(s): SPV C_500

QUOTE(muff @ Apr 30 2005, 12:35)

oh and 8 bit vars are CHAR

and shortints too

QUOTE

· shortint 1 Byte
8 bits

@ http://www.fsref.com/Fatal/FE090500.SHTML

This post has been edited by nIghtorius: May 1 2005, 00:58

argh

May 2 2005, 00:43

Post #17

Enthusiast
Group Icon

Group: Posters
Posts: 201
Joined: 7th November 2004
From: Milton Keynes
Member No.: 64,009

Device(s): SPV C500, SPV M3100

QUOTE(nIghtorius @ May 1 2005, 00:57)

and shortints too

@ http://www.fsref.com/Fatal/FE090500.SHTML

Implementation defined. Only char, signed char and unsigned char are guaranteed to be 1 byte in C++ (in fact, I heard somewhere that only char/signed char were guaranteed to be 1 byte - I haven't paid for the latest C++ spec document so mine may be out of date on this issue).

DaddyCool

May 2 2005, 20:50

Post #18

Newbie

Group: Posters
Posts: 8
Joined: 27th February 2005
From: Notts UK
Member No.: 113,776

Device(s): SPV C500

Made some replacement graphics for ya. There can be just copied over the orignal ones to work.

Attached File(s)

main.gif ( 15.48K ) Number of downloads: 3

gamescrn.gif ( 19.74K ) Number of downloads: 3

newgfx.zip ( 119.63K ) Number of downloads: 56

--------------------

hl2mapcentral.com : DC-deviantart