cncds_project

On Hold..

2006-11-14T09:49:22Z

Not dead, just on hold for a bit! Not much longer though... sorry guys and girls

cncds_project @ 2016-07-18T10:31:00

2006-07-18T09:36:33Z

Moved!
You can now find the new and improved development blog here:
http://www.cncds.worldoffokkers.nl/

Loading Tiles

2006-07-17T23:39:43Z

I put the code in to load a palette file and tile graphics.. though the formats are open to change. But I'm pleased to say it seems to work fine :) The screenshot on the right shows the 'TEMPERAT.PAL' palette loaded, with each block on the tile showing one of the 256 colours, and then repeated to fill the screen. The shot on the left replaced some of those tile graphics with ones loaded from disk, and then I changed the map by hand in code to line up a few of the tiles properly on the top left corner. It's not corrupted memory or anything you're looking at don't worry ;)

The next step will be to start writing a map format that will load in the correct layout of tiles, then we'll start to see something resembling better a C&C level, woohoo!

Project Sighting

2006-07-16T22:43:43Z

Just quickly googled 'C&C DS' to see what came up, and found this thread (http://www.penny-arcade.com/forums/viewtopic.php?t=1073827823&postdays=0&postorder=asc&start=0) which brings this project up a few times using the mockup concept art I made below - lol. They were quite quick to point out that the minimap and actual battlefield don't line up, and on the particular level shown you don't get to build anything and you can clearly see that in the game NOD forces are being controlled but it's GDI everything in the bottom... whoops ;p

It really was just concept art though. I doubt the game would be too playable as seen in that screen shot because the buttons would be too small for the stylus, especially when your frantically clicking on everything. The interface will get worked out when the game actually becomes playable ;)

FAT File System and C&C Formats

2006-07-16T22:09:58Z

Today I've managed to spend some time on the file system of the game, and looking at C&C file formats. I've downloaded the FAT file system for the DS by Chishm (http://chishm.drunkencoders.com/gba_nds_fat/) and so far it seems to work a treat :) I've been able to do a PC/DS port that works pretty much identically very quickly. Dualis seems to like it, but haven't looked at target hardware. I'm a little worried because I have a SuperCard SD which I think only supports reading, not writing through the file system ;(

Thanks to Vladan's Homepage and his brilliant resource on C&C file formats (http://www.geocities.com/SiliconValley/8682/) I've been able to create a quick .TMP file viewer, and it works a treat. This is the start of a suite of hopefully automated export tools that people can run to prepare data for the DS game. I believe this will get around the legal problem, as you must own a copy of the game to generate the required data. I will only distribute the DS ROM with no assets. Right now with the viewer you can just see the TMP files, but when done it will export them to the right format for me (such as slicing it up into the desired 8x8 tiles for the DS).

Another good resource for C&C file data and general extraction tools is the XCC Home Page by Olaf van der Spek - http://xccu.sourceforge.net/

I've also done some minor tweaks to the source code, including a fix for the DS input handling. The next few steps will be in the asset system, which will manage the loading of the palettes and tiles etc. This will tie together the file system and the graphics system.. then hopefully very shortly we'll see something resembling a C&C map on the DS screen itself :D But don't be fooled by thinking that by seeing C&C tiles on the DS it's almost done... it's still a long way to go...

More Tiles

2006-07-13T23:15:56Z

Apparently it is an endian issue.. I think the DS is big endian, although it could be middle endian who knows. I believe that ARM chips can operate in both endian modes, but it doesn't matter. I should look out for it though with the PC port, which would be little endian.

Anyway I've been able to throw together this very unexciting demonstration of a screen filled with three different tiles, which in turn are filled with three colours from the palette... but it's a start :) The PC port has fallen behind though until I've figured out exactly the behaviour of the DS in this mode and can simulate it. Oh well.

Very soon I'll need to look at treating the top tile layer like a framebuffer so that the debug menu etc. will work again. If this proves problematic I may have to redo the bitmap font system to use tiles and so on.. which would be a pain in the ass ;p

Oh I should point out this does NOT mean I have maps now, or it's scrollable or anything like that. This is very early days! Hopefully that should follow soon though :D

Tile Mode

2006-07-12T23:17:05Z

I've been busy with work last couple of days, and saw the RHCP at a concert in Manchester last night so didn't get much work done \m/

Tonight I spent some time adding in a Tile Mode for the graphics system. Right now there's two modes - tile mode and frame buffer mode. I think frame buffer mode will be useful for playing FMV's etc. but it's likely the rest of the game will require Tile Mode. I'm still undecided whether I'll use tiles for both screens, but if I write a decent routine that will let me draw on a tile back ground layer as if it was a framebuffer (just map the pixel co-ordinates differentley) then I don't see why not. I got some tiles visible but I'm having a minor headscratch over the format of the tile graphics.

Following the tutorial here (http://www.dspassme.com/programmers_guide/tutorial/using_tiles.html) I'm storing the location of the tile graphics as a u16* called m_tile. At first I set the palette of the first by calling:

  m_tile[0] = 1;  //1 is a pink colour in the palette.

Of course this didn't work because each pixel in the tile graphic is 8 bit. The code above made the first pixel of the two pink though, and not the second as I was expecting. Then when I changed the pointer to u8* I couldn't get it to work at all :( So then I'm wondering if the DS is little or big endian, I'm not sure.

  m_tile[0] = 0x0002 + 0x0100; //2 is a yellow colour.

This seemed to work okay, I could set the palette entries of both pixels fine, except it displayed them the other way round to what I expected! (Yellow (2) then Pink (1) :( So the first two bytes are for the second pixel, and the second two bytes are for the first pixel.. I'm sure I'm missing something here. If it was an endian thing I shouldn't see anything because the pallete entries would be very high. I dunno, I'm just a little confused right now but I'm sure it's something obvious.

I've also started to layout some of the structures needed to store the different units and buildings in the game.

Concept Art

2006-07-09T23:02:22Z

Here's a little preview of the sort of direction I'm planning on taking the interface in. I want it all to look very familiar, but at the same time take advantage of the DS. You can now see more of the units/buildings available to build and a bigger minimap. You can tap on select/sell/repair modes too, though this is not final. Under neath the units is a build queue of up to 10, although this would only be used in 'enhanced' mode. The arrow on the top left of the screen is used to swap the screen over, so you can use the stylus on both views.

And finally here's a fun little picture showing what it might look on the DS itself :) To be honest I cannot wait to get the game to this stage. C&C on a DS!! ROCK!

Screen Shot

2006-07-09T10:59:13Z

Here's an screen shot of the project showing where it stands - remember things are prone to change! The left side is the Dualis emulator running the game, and on the right is the PC SDL port. Currently they share roughly 85-90% of the code. The game is running in framebuffer mode and everything is being drawn straight to the framebuffer during a VBlank.

You can see the debug menu in the top left. That is turned on by default, but when finished a key combination will show/hide it. You use up/down to navigate the menu and A/B to select or deselect a group or item. Once you select an item you can use up/down to change its value. On the PC port you can see the 'SLIDESPEED' item is being modified (the M to the left shows this). This variable effects the speed that the red block of diagonal lines moves across the screen at. You can see the trail it leaves behind has varying size steps, caused by changing SLIDESPEED as the game runs. Any variable in the game can be exposed to the debug menu this way, and global functions as callbacks (once implemented).

The red, grey, blue and green blocks are all bitmaps added through the graphics buffer. The green area behind the debug menu is actually two animated bitmaps side by side. These pulse in brightness right now. The smaller red blocks behind the text in the middle appear when certain keys are pressed to test the input system. Currently the DS port has some issues with the directional keys.

All the text is drawn using the bitmap text system, using the command buffer. There is no tiles used, everything is framebuffer on the top screen. That's pretty much everything you can see in the shots below. Things will get a lot better, but here's a humble beginning. I'm aiming to get all my core systems in place and working before I start filling in the game which is why it doesn't look very C&C like at the mo :P

Research

2006-07-09T10:15:35Z

I'm still busy reading in depth the ins and outs of the DS hardware. I'm not sure whether I like the tile background mode and the OAM sprite stuff. I feel like I'd just prefer doing everything myself in framebuffer mode, though I don't think I'll be able to. There seems to be lots of limitations imposed using tile mode and OAM, although there are work arounds.

An annoying thing about this research is that most of the good well documented stuff is for the GBA.. while this is relevant the DS has differences. The DS stuff I find is always incomplete, and different sources seem to contradict each other. Such a pain in the ass! I'm tempted to try and compile everything I find in one place, but then it seems plenty of people have done that before and failed. Ho hum.

Meanwhile I've been streamlining the graphics system and debug menu. I think I'm tempted to strip the graphics buffer stuff to an extent.. just keep a buffer for all the stuff that may require Z-Sorting, otherwise I'll draw it straight to the back buffer.. but I'm holding off any big changes until I finish my research.

System Requirements

2006-07-06T21:16:54Z

C&C : Tiberian Dawn system requirements:

Processor: 486 DX2/66 or Higher
RAM: 8 MB
Disk Space: 30 MB
CD-ROM Drive: Double Speed or Higher
Graphics Card: VGA Video Card (320x200x25)
Sound Card: 100% Sound Blaster Compatible Sound Card
Operating System: MS-DOS 5.0 or Higher

All fairly reasonable, except the DS has 4mb :( Except the NDS Tech Wiki memory layout page has "4mb (8mb)" next to the Main RAM listing... I can pray this means each ARM processor has 4mb totalling in 8mb but I doubt it.

I knew memory would be a squeeze but this is my first time looking at it, and it's scary. It's going to be fun figuring out every trick under the sun to pack C&C into 4mb of RAM, woot!

I've also been reading into much further detail about the DS memory layout, framebuffers and tilemap backgrounds. I'll present my findings soon in the form of a semi tutorial (though there's a few of these already around it helps me understand it all myself). Found another good link on this here : http://www.dspassme.com/programmers_guide/tutorial/using_tiles.html

Posted On GBADev.Org

2006-07-05T12:50:39Z

I posted about the project (http://forum.gbadev.org/viewforum.php?f=20) and started talking to some other people developing for the DS. First of all it would seem quite obvious I need to read more about the hardware features available on the DS, specifically the background modes. I know the rough details but I need to look closely, see what is suited best to the project and then worry about making the SDL port work the same :)

Also I think I need to start looking closely at memory. The memory in the DS seems pretty divided up into specific regions, and I need to make sure I'm using them to their full potential. Right now everything is being held in system ram and then copied straight to the frame buffer.

Dark Knight ez from the forum is working on an RTS engine too, specifically Dune 2. We've agreed to help each other out where we can as both engines would have similar goals, and he has even sent some code showing use of tiling backgrounds on the DS. I've not had a chance to look at this yet though due to working late, but hopefully I will later tonight. My work may cut in to the project somewhat over the next few weeks as we're nearing the end of our dev cycle, but there's nothing like taking a break from code by coding in my free time.... hey hang on a sec....

Debug Menu

2006-07-04T08:17:50Z

I continued work on the debug menu a bit. You can now enter and leave groups, and see which groups you've traversed above you a bit like the folder tree in explorer. The next step is to display the variables exposed to the menu and let you modify them. I added numbers to the bitmap font but I think I need to add some more characters yet.

Also it would be cool to draw the font in different colours but from the original bitmaps, so I don't need to create a red, blue, green (etc) font. I'm thinking about a tint draw method, or possibly just specify a colour that gets replaced by another (e.g. white = red). It would be pretty easy to do, but it would need a bit of logic per pixel which makes me think there's probably an easier way.

DS Links

2006-07-03T11:09:49Z

Thought I'd just post some useful DS links, because I keep losing track of my bookmarks between home and work and it'd be handy for others too ;)

This looks like an excellent DS/GBA development forum:
http://forum.gbadev.org/

News and general stuff. I think it's a small community however.
http://www.ndshb.com/

Some Excellent NDS Tutorials
http://www.double.co.nz/nintendo_ds/

A Scumm port for the DS, with source code etc.
http://scummvm.drunkencoders.com/

DS Technical Wiki
http://bottledlight.com/ds/

... More...
Excellent news site.
http://www.drunkencoders.com/

The home of DevkitARM, libnds and more.
http://www.devkitpro.org/

Homebrew Programmers Guide to the DS
http://www.dspassme.com/programmers_guide/tutorial/index.html

Dovoto’s NDS(lib) documentation (Though maybe out of date)
http://www.drunkencoders.com/documents/DS/ndslib.htm

DS Wiki - Looks pretty good so far
http://tobw.net/dswiki/index.php?title=Main_Page

Animated Bitmaps and Bitmap Fonts

2006-07-03T09:09:25Z

As the subject suggests I've got some animated bitmaps and bitmap fonts working - though it's still early days for both. It is pretty cool however to write the DrawText function and then almost instantly see the start of the Debugmenu working.. replacing what used to be a big red block with some nice pixelly text :D The Debugmenu needs some navigation to be coded in now, which I've started. So far so good, it highlighted a couple of tweaks that need making to the Input System but pretty much everything has been falling into place.

The Animated bitmap class just contains a pointer to several bitmaps. This has more overhead than using a single very wide bitmap but is much easier to use. I may replace it at a later date though to squeeze out some more efficiency. The bitmap font uses one of these animated bitmaps to hold each letter on a seperate frame. Because there's no file system code yet the graphics for the font have been typed into the code ;p

Again I've got some screenshots, this time slightly more interesting, but I forgot to upload them - maybe later :) Oh the DS emultator likes the DS build just fine, but I've not even tried it on target hardware yet 0.0

Rendering Bitmaps

2006-06-29T09:01:32Z

I managed to spend a little time working on the graphics system last night, and have implemented a method of drawing bitmaps. I'm not sure if it's a method I'm going to stick with however, as it doesn't take advantage of any fancy DS features.

I do it by basically writing directly to the frame buffer memory, storing the bitmap data in a uint16 array. It's then just a case of copying the data directly to the frame buffer. This should be pretty bloody quick, but I can see some ways to speed it up already (I copy data one uint16 at a time instead of in chunks). I'd feel better doing some comparisons anyway.

One thing I like about it though is that I'm bypassing a lot of the ndslib stuff. Although the lib is great I'm finding it hard to use due to documentation, and doing it myself is a good learning process and gives me full control.

I've managed to duplicate the behaviour almost exactly on the PC build using SDL, even using the same bitmap structure. When it comes to copying the memory I just used a SDL_FillRect instead to draw the pixel, after a quick conversion from a RGB15 to a full RGB value. I am using a SDL_FillRect of width 1, height 1 to get a pixel however, which is hardly fast! It doesn't really matter so much on the PC build though - I just want it to work as closely to the DS as possible which I'm happy its doing right now ;)

I have some screenshots of this working to post, but I don't have the net at home right now, so maybe some time after the weekend. Right now it was just some code generated blocks of grey, red, blue and green that show each shade of that colour, not exactly exciting to look at but its a start!

Oh on a final note I'm having second thoughts about my graphics buffer stuff... maybe just using a double buffer technique would be both simpler and faster... right now if the graphics system takes longer than a VBlank to draw the command buffer you'd see weird glitches. Damn. I could fix it by rendering the command buffer to a offscreen buffer and flipping it, but then I'd have to come up with some really cool tricks using the command buffer otherwise what's the point??

More Delays

2006-06-28T12:21:45Z

I've finished moving house now, but I won't have much time to work on the project until after the weekend. What work I do get done however will focus on the graphics system and drawing bitmaps.

Little Graphics System work

2006-06-23T08:19:04Z

I took a little time thinking about how to implement the graphics system bitmap support. So far I've had a hard time tracking down good documentation on the correct/best way to draw graphics on the DS. I can write directly to the frame buffer memory, and so in theory that is all the power I need - but I think there could be hardware blitting and other features that I should be taking advantage of.

I've found my approach to this being somewhat guided by the SDL implementation and I need to be careful to not just implement the PC side and then make the DS side a copy of it. I'm going to try and get the DS side working first, and then see how I can make the SDL implementation copy that instead.

Basically I could write everything I needed by writing directly to the frame buffer... I could store graphics in my own memory formats, do clipping in software and so on and I wouldn't mind the work involved in this but I'm sure I'd be missing on faster or more memory efficient methods. I fear that trawling through other peoples source code could be the best way right now to find what I want. I'm yet to find a very active DS forum yet to ask about this sort of thing on. I'm tempted to try gamedev.net

Moving House

2006-06-20T09:25:02Z

Won't be able to work on this for a couple of days as I'm moving house.. and the world cup is on! I may spend a little time thinking about the architecture and perhaps some new game features though. If I have any revelations I'll post them here ;)

New Features Preview

2006-06-19T17:09:41Z

Thought I'd just post a few random ideas I'd had about the gameplay side of things. I'm planning on creating a C&C 'classic' mode where everything is as close to the original as possible. I also want to add an enhanced mode too, where you can choose some new features. Each feature will be an option as you set up the game. I may add some enhanced single player missions that take advantage of the new features too, but it's likely to start with they'll just stay for skirmishes and multiplayer.

Here's a few of them copied and pasted from my ideas text file... I'll leave them with minimal explanation to enhance their mystery ;)

###########################
C&C Enhanced Features:
###########################
-Build Queues

-Fog of war (optional) (various on battlefield conditions)

-Way points / patrol routes

-New C&C themed units
--Making use of little used original art

-Can shoot down NOD supply plane?
--NOD can set supply plane waypoints?

-AI Tactics
--The AI has several strategies coded that act like simple scripts
--If the conditions are right an AI might attempt a 'tactic'
--This could be as simple as a tank rush, or as complex as a commando strike on a critical building.
--Each tactic should have a difficulty rating.
--The aim is to make interesting player like play.
--A General could be given a specific set of tactics that define a playing style.

-Unit behaviour
--Aggressive
--Defensive
--etc.
--Default behaviour after construction

-Unit Customisation
--Can name units

-Unit promotion
--Better skills in general

-Troops
--Hand to hand combat
--Swimming - coming ashore from hovercraft
--Climbing cliffs
--Using real building entrances/exits
--Hiding
--New and improved commandos?

-Tanks
--Damage effects (smoke etc.)
-Amphibious tanks?

-Tiberium
--Changes terrain beneath it over time?
--Introduce blue tiberium to C&C? And veins?

Input System

2006-06-19T08:59:15Z

I've got a working Input system architecture in place now... however I feel it could be improved further still. It doesn't use any of the DS key IRQ's, instead using the nds lib scanKeys function. The key polling is only done in one place however, as whatever part of the game that requires code to be ran from a key hit can register a callback with the Input System. I may add a priority system to the callbacks but if everything is coded correctly I think this shouldn't be required.

The SDL and Emulated DS versions seem to work almost identically which is good, but I've not tried further to get the ROM running on target hardware.

Little Engine Updates

2006-06-16T09:42:04Z

I spent some time working on the engine last night even though I couldn't get a hardware build working still. I looked at getting the Input system working better. I want to avoid a key-polling architecture, favouring an event based one. I think I'll end up with something similiar to the key events in SDL, which is convenient because I'll be using SDL for the PC port :) The Input System will require some changes still before it's almost finished but I have some proof of concept code in and working on the DS emulators.

I also spotted a flaw in the graphics buffer. Basically when the logic update is faster than the VBlank the buffer was marked as complete, but then immediately filled with more data, whether the buffer was drawn or not. This had the effect of overflowing the buffer each frame even when only a single draw operation existed! The problem is the render commands didn't check if the buffer was completed before drawing. All this should require for a fix is to only call the Render functions if the buffer is marked as empty.

Still no luck!

2006-06-15T19:27:08Z

I've installed the Supercard software and tried to convert my NDS file without much luck. The generated .dsq file was 0 bytes. I stumbled across a link on a forum however (http://www.dcemu.co.uk/vbulletin/showthread.php?t=20280) that is supposed to fix exactly the kind of error I was getting - but that has had no effect.

I'm also not sure about the firmware version of my supercard. I tried to upgrade to 1.62 (which it might already be, not sure how to check) but it always gets a data validation error and gives up. Perhaps this has something to do with it?

Then again what my program is trying to do so far is very simple, and I've already had homebrew running fine on the DS with this level of sophistication... so I think it's probably just a bug - a memory access violation or something similar that the emulators didn't pick up on. Maybe an IRQ misuse or I'm not initialising the DS properly. Grrr, hope I fix it soon.

DS Crash Clue

2006-06-13T09:37:53Z

I've been on holiday for the last couple of weeks and haven't had time to work on the project, but now I plan to resume work again. Speaking to a friend at work it seems he was having similar problems until he converted his .nds file into a .nds.dsq or a nds.dsi - I'm not sure what these formats do exactly but I believe it's something to do with the DS file system. I will read up on exactly what the differences are and see if I can get my rom to work. I've now tried the rom on both Dualis and Ensata ( the emulator that is included in the official DS SDK) and the rom works fine.

Fixed Dualis Crash

2006-06-01T13:02:10Z

I've fixed the crash - it was down to a couple of function calls being made in the wrong order on load and accessing a null pointer ;p Now it seems to run fine on Dualis and PC, outputting pretty much the same graphics, although it is an unexciting red box, which is going to be part of the debug menu.

Now I've moved on to the next step, getting it to run on the target hardware - but without success! I'm just greeted with two white screens and a whole lot of nothing. I'll have to investigate why it works in Dualis but not on the DS when at this point it's a very simple program.

I've implemented a graphics buffering system for the engine. Basically the vBlank interrupt asks the graphics system to render, but it will only render if the buffer has been marked as filled. So the buffer can be filled over several vBlank interrupts, but drawing will only progress once the game is ready and exactly on a vBlank. Hopefully this should make frame-rate issues not interfere with drawing nicely.