gbadev.org forum archive

This is a read-only mirror of the content originally found on forum.gbadev.org (now offline), salvaged from Wayback machine copies. A new forum can be found here.

DS Misc > Operation Nutcracker 2006

#66019 - Phantomus - Sat Jan 07, 2006 5:19 pm

Hello,

I am working on a game for PocketPC (Operation Nutcracker 2006) and I am considering to port it to the DS to get a broader audience. If you have some spare minutes, check out the demo, available from http://www.bik5.com/nc2 . A PC-based demo is also available, as most of you probably don't have a PocketPC. :)

PocketPC's typically have 200Mhz StrongARM processors, the game is 2D, so performance-wise there should be little problems.

Does anyone know how hard it is for a total newbie to port a game to the DS? Is anyone interested in lending a hand with this? Or perhaps the game is so boring that it isn't worth the trouble? :)

Nutcracker 2006 is a stealth action adventure, loosely based on the 8-bit 2D metal gear games (I played them on the MSX once).

- Jacco.

#66021 - MaHe - Sat Jan 07, 2006 5:34 pm

I must admit it - it's a fairly neat game. Kinda addicting.
Keep it up.

However, porting it would be a hard nut to crack ;), since it demands twice the CPU power DS has.

You can recode it in pa_lib ( www.palib.com ) or libNDS ( www.drunkencoders.com ). I hope you suceed!

#66030 - tepples - Sat Jan 07, 2006 6:57 pm

MaHe wrote:
However, porting it would be a hard nut to crack ;), since it demands twice the CPU power DS has.

Unless the graphics are rewritten for the DS's 2D and 3D acceleration.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#66031 - Phantomus - Sat Jan 07, 2006 7:30 pm

Well it's not really a graphics-intensive game (it's content-intensive though). Let me summarize what the graphics engine does:

First of all, the levels are divided in areas of 18x16 tiles. Each tile is 32x32 pixels (16bit, could get away with palettized). An area is prerendered to a large bitmap when you enter an area (is this a problem on the DS?). Next, the game precalculates shadows using 'height tiles' and prerenders static sprites that will always be below the player.

In the main game loop, the game copies a part of this bitmap to the screen, renders the player, and the dynamic sprites. All sprites use an alpha channel for smooth edges, but this is not really neccessary (just pretty).

Water is rendered by reflecting a scrolling 256x256 sky texture, displaced per-pixel using a sine lookup.

In the background, a mod file is playing (is there a modplayer available for the DS?).

SO all in all I don't think this is extremely heavy, especially considering that the PocketPC has a 320x240 screen res, while the DS is a bit smaller.

My main concern is memory usage (I probably need to swap out unused sprites, as I use several MB's of image data right now) and the mod file player. I believe there is already direct screen access on the DS?

- Jacco.

#66035 - tepples - Sat Jan 07, 2006 7:43 pm

Phantomus wrote:
First of all, the levels are divided in areas of 18x16 tiles. Each tile is 32x32 pixels (16bit, could get away with palettized). An area is prerendered to a large bitmap when you enter an area (is this a problem on the DS?).

It's best to leave your tile maps as tile maps.

Quote:
Next, the game precalculates shadows using 'height tiles' and prerenders static sprites that will always be below the player.

That could possibly be a problem.

Quote:
In the main game loop, the game copies a part of this bitmap to the screen, renders the player, and the dynamic sprites. All sprites use an alpha channel for smooth edges, but this is not really neccessary (just pretty).

GBA and Nintendo DS games get away without using alpha edges, but if you aren't sharing a palette between two sprites, I know how to fake alpha edges.

Quote:
Water is rendered by reflecting a scrolling 256x256 sky texture, displaced per-pixel using a sine lookup.

On the GBA and DS you can easily displace each scanline.

Quote:
In the background, a mod file is playing (is there a modplayer available for the DS?).

There are a few such as Krawall and AAS.

Quote:
My main concern is memory usage (I probably need to swap out unused sprites, as I use several MB's of image data right now)

If you redraw your sprites in 16 colors, you'll be able to reduce your image data requirement by a factor of four. You have 16 different 15-color palettes available for sprites.

Quote:
I believe there is already direct screen access on the DS?

There's frame buffer access, but everything will work better if you structure things in terms of tile maps and sprites.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#66045 - MaHe - Sat Jan 07, 2006 9:39 pm

Yeah, I think PA_lib would do the job (it even has a MOD player), although shadow rendering could be a problem. Check out the Wiki, it's fairly simple to use.

www.palib.com

#66067 - Xtreme - Sun Jan 08, 2006 12:27 am

Phantomus wrote:
Or perhaps the game is so boring that it isn't worth the trouble? :)

Nutcracker 2006 is a stealth action adventure, loosely based on the 8-bit 2D metal gear games


I will wait and hope that you make the DS port of that game. Those screen shots looked nice indeed.
_________________
My Theme
DS Lite (FM_V8a) ** R4 Revolution (2GB Transcend) ** SuperCard Lite (2x 2GB Transcend)

#66082 - agentq - Sun Jan 08, 2006 3:08 am

It's a nice game, and would be a perfect fit for the DS.

The DS can support huge tilemaps and you don't need to build the bitmap each frame, as the hardware does it for you for no CPU cost.

The tiles are 8x8, but you can easily stick four of them together to make your 32x32 tiles.

I don't see you having problem with RAM either, as your tiles look like they would work easily at 256 colours. You might even be able to fit them all in VRAM at once.

You could even use the second screen for your map and pop up boxes.

You have about 4Mb of RAM to play with and about 700Kb of VRAM, which should be plenty since you won't ever have to build a framebuffer.