Warhawk DS (HK & Flash's DS Diary)

[headkaze]

Great work there Flash, and did you try and get it running on hardware to show off to your kids?

I think getting text to output would be a fun challenge I think I'll give that a shot and maybe try and get a random function working.

The main problem with getting the Mod player to work is the IPC code used to communicate with the ARM7 from the ARM9. There is a special part of shared RAM that is used for this. I'll look into it but my guess is it will probably be difficult to do in pure asm.

[flash]

Even a simple sample loop would be a start

I did put it on the DS and it works a treat!

Text output (even just numbers) would be really easy even in framebuffer. Just an image from 0-9 in 8x8 grid (10x8 units) would make it easy to pick the data and just dump it. I would cheat and convert the number to individual bytes and display one after the other Not much use for text though.

Perhaps looking in to doing these as includes would be great.

Random numbers and some help on tole based scrolling are two things I need your help with..

[headkaze]

I had a look at your demo running on the DS and it looks great

I just uploaded a demo to output text which also demonstrates using a tile mode.

Still haven't looked into random numbers yet, but I did get the Mod Player compiling under the new DevKitPro (only the C version thus far). I had to modify the DevKitPro ipc.h header to use the old method of sending audio data through the IPC struct. More on that later though.

[Grapple]

Well this project seems to be coming out nicely... Damn now i wish i had gotten that DS as a christmas present to the kid...

[flash]

or one for the big kid called "Grapple"

[Tempest]

I feel foolish giving you guys programming advice, but I remember that on the c64, the random number generator wasn't truly random. It produced the same list everytime. I think they used to use the clock somehow to generate random numbers. Hmmm maybe they only used a value from the clock as a seed for the random number generator....
See, I told you I shouldn't talk programming! That's my post for the day. 

[flash]

On the c64 the main way to do an RNG was just to hook the white noise generator in the sid chip. Something sadly we do not have the pleasure of on the DS.
Some people also used the Raster as a generator, I cant as am awaiting the VBlank to keep the updates smooth.. The numbers would all be nearly the same evey time...

So, down to some "newman" (is that his name?) code in asm as a way to generate - arrghh

[Grapple]

Mmm yep I am the Biggest kid at home... however i just bought me some christmas presents (A trackball kit) and a few nice bottles of Whiskey... so no DS for me officially.. hehe

[flash]

Been playing with Mappywin32 and it looks great at generating maps.

Have done a dummy warhawk map as a base for a level. Not quite sure of the correct way to output it though?

HK: Put a map file here for you to look at (it is Mappy format) - if you want

[headkaze]

Grapple: It would be great if you could join in the fun You can always start by using the emulators and then get the hardware later.

Flash: The random number generator only needs a unique value for the seed. We could use a timer and a button click, VCOUNT anything that will give us a seed of some sort. But anyway for now we just need a random number generator that uses a seed. We can worry about making the seed different later.

Don't worry about MappyWin32 all you have to do to create a map is to add a png made up of 8x8 tiles and save it as Eg. level1.png and create a level1.grit to go with it like so:

Code: [Select]

#-------------------------------------------------------
# graphics in tile format
#-------------------------------------------------------
-gt

#-------------------------------------------------------
# tile reduction
#-------------------------------------------------------
-mR

#-------------------------------------------------------
# map output
#-------------------------------------------------------
-m

#-------------------------------------------------------
# graphics bit depth is 4 (16 color)
#-------------------------------------------------------
-gB4
It will use the "grit" tool (located in C:\devkitPro\devkitARM\bin). It will automatically find repeated, rotated and flipped tiles and create the map data for you (and you just write the map data to CHAR_BASE_BLOCK(x) or CHAR_BASE_BLOCK_SUB(x)). For later stages you will need to combine maps, tile data and palettes but we'll worry about that later. For now we just need to get a single map displaying and scrolling. Speaking of scrolling, all you have to do is write the offset to the REG_BGxHOFS / REG_BGxVOFS / REG_BGxHOFS_SUB / REG_BGxVOFS_SUB registers to scroll a background (NOTE: Those registers only work in text modes ie. Mode 0 as used in the text example). Just remember you probably want to use a 64x32 map size so you can scroll in new tiles as your scroll registers are moved 8 pixels along ie.

Code: [Select]

ldr r0, =REG_BG0CNT_SUB            @ Set sub screen format to be tiles
ldr r1, =(BG_COLOR_16 | BG_64x32 | BG_MAP_BASE(29) | BG_TILE_BASE(0))
str r1, [r0]
Also I think it's really important to get it so we can read the touchscreen and buttons. I believe only the ARM7 can do that so we have to use shared memory to get it over to the ARM9. I'll see what I can come up with in regards to that.

[flash]

Thanks for your continued help.

But I really wanted to use 32x32 tiles to construct the level?

Did you have a look at mappy? I understand what you are saying about grits function in the generation of maps, but using mappy allows for much more versitility for construction. You can output the entire map as a single graphic though - which would be the same. It is a nice bit of software that is worthy of a look.

[headkaze]

I'm not sure if I explained things well enough. You don't need a tile editor you can simply draw an entire level in a graphics program and grit will take that image and extract all the tiles from it. So you can use photoshop to draw a level and grit will do the conversion. To use photoshop I would turn on "snap to grid" and set the grid size to 32x32.

Again your getting confused with tile size vs map size. A map simply says what tile goes where on the screen. So a 64x32 mode just means you can fit 64 tiles horizontally (with 32 visible onscreen) and 32 vertically (with 24 visible onscreen) as the display is 256x192 pixels and each tile is 8x8 pixels. That is so you can scroll in tiles without being able to see them being drawn (you draw the new tiles in the non-visible map area offscreen as the map is scrolled).

Tiles are always 8x8 pixels but you can use 32x32 pixel sized tiles it doesn't matter they will just be 1 tile made up of 4 smaller tiles. When you draw a level in Photoshop it will scan the image in 8x8 and it will only store one tile for repeated, rotated or mirrored tiles to save memory. A map can use the same tile over and over just by using the same tile id. To flip or rotate a tile you simply set a bit for the map entry; but all that is taken care of by grit when it generates the map data.

Here is a level from Tales of Dugar which is an RPG written by a friend of mine in the NDS coding scene. As you can see the entire level is drawn up for each background. You don't need a tile editor just a graphics program like Photoshop is fine. All you really need to worry about is where your going to write the data into VRAM. The greatest challenge in coding the DS for me was figuring out VRAM so I think once you get the basics of tile mode you will be flying. I'm really impressed with what you've come up with in such the short time since we started and I think your previous experience with the C64 is certainly starting to show

[headkaze]

BTW I was looking at Warhawk today in WinVice and you can actually run an Action Replay cartridge (I got one from here) which allows you to reset the game and view sprites in memory and from that take a screenshot to rip graphics. I was taking screenshots of the start screen and so far I've ripped most of the Warhawk font. So far I have the copyright symbol, the full uppercase alphabet and all the numbers except for "7". There are probably other characters I'm missing too but unfortunately I cant get them to display even using the AR's edit screen function. If you have any ideas on how to grab the rest of the font let me know.

[flash]

You are a little sweetie really aren't ya!

It would perhaps be easier to just draw the missing characters. Pass me what you have and I can add them?

With regards Grip and doing it in photoshop.

I understand the size of the screen and the tilemap made of tiles. If I can ref with warhawk.
this used a tilemap of 12x(cant remember) tiles to construct the level, each tile was 32x32 pixels and referenced exactly the same as the ds does it in hardware. Each tile had a value (0 being blank) and the map was made by just referencing the tile at each location. Each tile was made from 4x4 8 pixel blocks, creating the 32x32 tiles.
In warhawk some tiles were denoted as destructable and checked against the data for a bullet collision. If I do not have control over what tile numbers are used how can you do this check easily. C64 used a range - ie tiles 250-255 were bases.

Going back to Mappy though (please look at it). This does have the benefit of easy level construction and the ability to output the entire level as a png for use with grip.
Also, I would personally liked to have my own tile set to use on all levels and then have individual levels that used that tileset but alternate palletes. Does that make sense to you, or am I just making work for myself? I mean use the same graphics but modify the pallet as done in the c64 version.
I personally wonder if more would be learnt by me if I coded the level display and scroll using my own routines rather that hardware?

Thanks for the compliments on the coding - I love that.

The way I can put your help into perspective is - I like to think of myself as an able artist, but do need the help of that wonderful Canvas builder called HK.. I do struggle to paint a picture with 4 bits of wood and a piece of cloth..

[flash]

I have had to make a concession on the maps that the ds version uses. (as mentioned earlier) the C64 had a 320x192 res screen and used blocks of 32x32 pixels (4x4 DS blocks). The Ds is 256x192 and as such cannot display the data the same as the C64. 24x24 blocks are the closest and would still not fit the width of the screen. The only option is display 8 32x32 blocks horizontally and use a map of 10 32x32 blocks (yes, I know the ds works in 8x8's - but trying to match the c64 levels).
With this in mind the DS would have to scroll the screen horizonatally 32 pixels - which would be quite nice to be honest.

Have uploaded a messy demo of what I have been playing with before I got too tired to work out any more. All I have done is an "Initial" level display code to draw the level as it would be upon the levels start ready to scroll it.
I then had a play with the data offsets to see how the tile mode works. So, the level will scroll the whole of the map for you, not smoothly nor correctly!!! This is redrawing the entire map each time a move is needed, but this still helps to see the way the ds works.

I could not do a screenshot as it is far too "FLICKERY" for that But, it is all progress...

Now all that I need to work out is SCROLLING (correctly)... Then move the display to the bottom and draw the rest of the map on the top screen - using both screens (oh god!) to display the level...

Here are some pics of the original C64 level 1 and A half-arsed mess-about at the DS version of the same level (Improving the graphics comes last on my list - unless there are any OFFERS )

PS. Am using mappywin to do the levels with a nice set of blocks to construct them. This does make it nice and easy to do, the outputted png of the level could then be edited in photoshop for added detail.

[flash]

It is getting late, but had a play with the scroll registers and got myself confused..

I have it scrolling down a few pixel and looping back to start. Ie. scroll down 8 and then return to possition 1... cycle..

What I need to do is work out how to move the entire screen down 8 pixels.. I hope I do not have to do the loop to move the entire screen data down one line - that is a lot of cycles...

Start at bottom line (rightmost)
copy line above down one line,
move left one block and repeat back all the way to the top left positon...

Oh well... Will have another think tomorrow!

Actually it can scroll the entire screen using the register (256 positions) but will repeat add nauseum... but there only appears to be one line of blank (8 pixel vert) at the top by which to use for the next map line...

[headkaze]

In warhawk some tiles were denoted as destructable and checked against the data for a bullet collision. If I do not have control over what tile numbers are used how can you do this check easily. C64 used a range - ie tiles 250-255 were bases.

As you can see there is a collision map used in Tales of Dugar so maybe you could make another map that denotes the destructable tiles?

Going back to Mappy though (please look at it). This does have the benefit of easy level construction and the ability to output the entire level as a png for use with grip.

I did have a look at Mappy and that level you posted. It does look handy to build the levels although I would have thought taking screenshots of the levels directly from an emulator and pasting them into Photoshop would be easier than remaking them in a tile editor. But if that's easier for you then I'm happy to go that way. The DevKitPro example actually uses Pern Edit so that might be another Tile Editor to look into.

Also, I would personally liked to have my own tile set to use on all levels and then have individual levels that used that tileset but alternate palletes. Does that make sense to you, or am I just making work for myself? I mean use the same graphics but modify the pallet as done in the c64 version.
I personally wonder if more would be learnt by me if I coded the level display and scroll using my own routines rather that hardware?

Yes we can definately do that, palette changes. I did a similar thing for my keyboards where the key would hilight when you pressed it by changing palette. So yes we can do that, we just have to figure out how to tell grip to use a different palette. If worse comes to worse we can simply add a palette manually by entering the color values and switching them.

I would stick with using the scroll registeres - that's what they're there for and they are much faster than anything we could code ourselves.

With this in mind the DS would have to scroll the screen horizonatally 32 pixels - which would be quite nice to be honest.

I agree a little horizontal scrolling will be a nice touch

I then had a play with the data offsets to see how the tile mode works. So, the level will scroll the whole of the map for you, not smoothly nor correctly!!! This is redrawing the entire map each time a move is needed, but this still helps to see the way the ds works.

Wow! That's really impressive mate! I can't believe you've already got a level displaying and scrolling.

It is getting late, but had a play with the scroll registers and got myself confused..

I have it scrolling down a few pixel and looping back to start. Ie. scroll down 8 and then return to possition 1... cycle..

You shouldn't need to return the scroll register back to anything. You can just keep adding to it. According to GBATek the scroll value is a number between 0-511 using 9 bits to store it or a maximum value of 0x1FF (or 111111111 in binary). So what we can do is just AND the value with 0x1FF and that will ensure it will be between 0-511.

Eg.

Code: [Select]

    ldr r0, =REG_BG0VOFS_SUB        @ Load our vertical scroll register for BG0 on the sub screen
    mov r1, #0                        @ Set our scroll counter to 0
    ldrh r2, =0x1FF                    @ This is our mask to ensure the scroll value stays between 0-511

loop:
    strh r1, [r0]                    @ Write our scroll counter to REG_BG0VOFS_SUB
   
    add r1, r1, #1                    @ Increment our scroll counter
    and r1, r2                        @ AND our scroll counter with our mask
   
    b loop                            @ Our main loop

What I need to do is work out how to move the entire screen down 8 pixels.. I hope I do not have to do the loop to move the entire screen data down one line - that is a lot of cycles...

Scroll one pixel at a time using the scroll registers and write a new map every 8 pixels.

Start at bottom line (rightmost)
copy line above down one line,
move left one block and repeat back all the way to the top left positon...

Oh well... Will have another think tomorrow!

Actually it can scroll the entire screen using the register (256 positions) but will repeat add nauseum... but there only appears to be one line of blank (8 pixel vert) at the top by which to use for the next map line...

It's a 64x32 tile map so if there are 24 visible vertically that should mean there are 8 tiles or 64 pixels available to scroll in tiles vertically.

[headkaze]

I've knocked up a picture to hopefully explain things better than I can in words. This picture shows a 64x32 map mode, and how we will have to deal with all the offsets. Since the actual level is 40 tiles across that leaves a 24 tile gap to the right of the map.

What I've done is take the level and make it 64 tiles wide (512 pixels wide). That means we can draw the map without having to worry about that 24 tile gap. It doesn't take up much more VRAM because they are just blank tiles. Some more map data is required but for the convenience I think it's worth it.

For some reason I had to add the "-mLs" option to grip which means Map layout is "reg sbb". I have no idea what that means right now but without it it was forcing a 32 tile width map.

Attached is the demo that needs to be changed to add in more tiles when it's scrolled 8 pixels up which I haven't done yet.

Also attached is the font I've ripped so far.

[flash]

I will look into collision maps after getting this scrolling working, you know me - always thinking ahead..

Mappy: Glad you had a look at it.. I think it is a nice package. Yes, I could have dumped the entire c64 level as a png (overlaying the multiple scores), but from a "Game from scratch" perspective, I thought it would (again) be best to follow the process on a comparative C64 level. Anyway, I am just playing with the level and will hopefully find someone to do some graphic work on the levels. I have tried on several occassions to get in contact with one of the original Warhawk team (who did most of the graphics) BadToad. I had been talking to him online, but he has not been online since the 14th Dec, which is prior to this coding exersise in madness..

Scrolling: I will have another play with the scrolling again tonight. It was getting late and parts of my brain were shutting off. All that was left was the descision area that kept telling me to drink more coke..
Drawing the entire map on each 8 pixel scroll takes quite a lot of cycles btw. I also want to extend the map to the top screen at some point (when I have a smooth vertical scroll going on the base screen that is), I am a bit concerned about the overheads..

I will have to look into input (surelly this can be integrated into Arm9?) as It would be nice to push the screen horizontal as it scrolls - for testing purposes.

About Maps:
On the demo level, the blank areas and areas around the edges of levels I need to make transparent so that I can have another layer (or 2) beneath that doing a vertical star routine. What do I have to do in grit if i make all BLANK areas a set colour (ie ff00ff as mentioned in the docs) transparent..?

Thanks as always for your help and I am sure the next demo will have a full scroll going on... (then on to the top screen for stage 2)... (ulp!)

[Tempest]

You guys are way over my head.... Had another thought (My last one) about the random number thing. If you used too use whitenoise from the sid, would it be possible to use the microphone on the DS (I Googled, and it does have one???) to get random values?

[flash]

That may be possible.. A sound idea from an unsound guy

[flash]

Ok, we have a fullscreen vertical scroller working on a per pixel level.

A couple of strang things have been introduced...

HK: VBLANK - we are only scrolling one pixel per interupt, but by god it looks bloody fast on the emu, and worse on the DS, and this is with a delay?? The scroller should scroll 60 pixels down the screen (up the map) per second. It seems more like 600 on the ds (with delay?). If aliens move 1 pix per second - this is gonna be a bloody hard game with very short levels

Also, the map is messed up and this seems to be in blocks of 512 bytes? The map is fine as a png and the tilemaps look ok, but something has gone wrong with grip I suspect. Also, some of the graphics are messed up on a 8x8 basic, almost like the tiles are confused? Hmmmmmm

back to the little demo - sadly, the graphics are not displayed as intended, but the main thing is that it works..
I may add a sine based l/r move into it just so the horizontal movement can be seen later tonight...

All code is highly commented as always.

I am keeping a running commentary of this in the hope that anyone who is reading this will see that it is perhaps not as hard as it may appear. So, not only will the good be displayed, I will also post the problems and complete f*** ups - we all learn by mistakes so I may as well share them with you all.

PS. This still contains the strange error in the tilemaps? I have no idea why??

[flash]

Oh god!!! Another update

I got bored at looking at a single scrolling screen - quite dull really...

So, now we have it scrolling through 2 screens and I have also added a sine wave scroll (thanks for sinuslab hk) on the horizontal scroll to demonstrate the way in which i wish to use the screen during gameplay - a slight horizontal scroll.

It still runs FAR too fast (is that a bad thing?) and I have put a massive slowdown into the code! I am sure that HK will see why and I have not spent much time looking into why as I was more involve in getting the scroll working.. Hurrah!

PS. Cannot use ideas for screenshots as doing so makes the screenshot show the top and bottom screens look out of sync so had to use a simple screen capture.

HK, what is quite strange is that the left/right scroll works at rhe speed that it should, but the vertical scroll is way ahead of it even though they both update at the same time? I have spent just over 2 hours doing the code for the 2 screens and will have another look tomorrow.. Gonna have another little play with the title screen and that character set you sent from Warhawk!

[flash]

A little update to the title screen to move between 2 different screens (3 eventually perhaps with hiscore?)

The clearscreen code is messy and I will tidy that up later!!

Oh, and the credit screen will include a lot more people by tomorrow - I just made it quick to test!

PS - If there is anyone who wants to offer there services to improve the graphics - I would be very grateful!!!!

[headkaze]

Latest demos look sweet 

I too was confused why the scrolling is so fast. It should be waiting for vblank and it should be scrolling smoothly. I don't know whats going on I will have to take another look.

Also there are two ways we can speed up writing the new map each 8 pixels scrolled

- Only write the part of the map that is scrolling in instead of the whole map each time
- Use DmaCopy. This one I'm working on at the moment. I'm trying to convert the dma.h C code over to asm. It's the fastest way to copy memory around on the DS. You simply give a source and destination address and a size and it will do a fast copy.

[flash]

The level test now works perfect on the ideas without any delays - different kettle of fish on a real ds though - way too fast... Still cannot sort out the tilemap?

Updated the title with credits also..

The title now checks key presses and A will freeze the stars (It is a start)

PS. Tried all sorts of ands and ors to get the Vblank working correctly - Gonna smash up the pc and the bloody DS... 

[headkaze]

I'm enjoying watching the progress your making

I'm having even less luck than you are at the moment I'm afraid (I have comfort in the fact that I'm not the only one having problems here ). As I said before dealing with VRAM was one of the greatest challenges coding the DS for me and that hasn't seemed to change. In all my recent NDS projects I use dmacopy to move memory around because it's fast and you will notice that in this demo I'm going to post. The problem is the data has to be in the structure it needs to be in VRAM so when you copy the chunks of memory it's already there to display otherwise you have to use a loop to make sure everything is placed correctly.

The problem is how map data is stored in banks and it gets a bit tricky as soon as you use a map larger than 32 tiles wide because those tiles to the right need to be stored in the next bank. I had this problem when I started coding Cluedo which also uses a 64x32 map. To be able to dmacopy the map I had to draw the map as it would be stored in VRAM. Attached is a picture of the map and as you can see when you go over 32 tiles wide it stores those tiles into the next bank. I was looking at the grit options as I'm sure there must be a way to store the data like that. Although I have no idea why your original demo works okay but when I added dmacopy it introduced this large gap in the data. If I have to write a program that will split the map up into the banks then I will but anyway I'm posting what I've done so far in the hope you might be able to shed more light on the problem.

I also started playing with some interrupt code as I thought using a VBLANK interrupt might improve the scrolling. I realised there is more to interrupts than I first thought. Like there is a special place in memory where an interrupt rountine needs to go and also a table of memory addresses where the actual irq handling addresses go. The libnds library normally takes care of much of that but since were coding in pure asm we have to implement all of that manually. So for now I think I'll leave interrupts alone.

[flash]

I wonder if outputing from grit as done originally and drawing the screen using an x counter to wrap at the boundry would work? Does the map need to be 64x32? I will have a play today.

The vblank is of the most concern as the game relies on it. I just fail to understand why it works fine on the title screen?

Is there anyway you can backtrack the code in libds to get a basis in what it does. Ie. If you knocked up the exact same code using the same data in C, what would happen different?

Thanks for all your help!

[headkaze]

I got the level scrolling okay now I think

What I did was make the map 64x64 so when the vertical scroll register hits 255 I dmacopy a new bank of the map to the screens. This means we only need to write the map every 255 lines scrolled.

The level from Cleudo shows the problem I was having pretty clearly. Even if you have a 64xWhatever size map it still only stores the top left 32x32 tiles in a block so you must write the next 32x32 block after that to get the tiles to the right. Having 64 tiles vertically to play with means we can scroll out a whole screen of 32x32 and then dmacopy in the next block as needed. If we don't use the -mLs option in grit (which I have found out means to format the data in "screen blocks") then we couldn't use the fast dmacopy to write the maps. In fact it would mean every line would have to be written to the two banks in a loop (ie. Much slower).

It's probably buggy but it works okay in the emulators. Running it on real hardware is still way too fast. I even tried a different style of waitvblank but it didn't work on hardware either

Anyway some more code and things to ponder on. Sprites would be nice to get working but I think the header will be a little difficult to translate because they use structs for the OAM entries and I don't believe that is so straight forward in asm.

Here is the vblank code I translated. Perhaps I did something wrong?

Code: [Select]

// C Code

void waitForVBlank(void)
{
    while(!(REG_DISPSTAT & DISP_IN_VBLANK));
    while((REG_DISPSTAT & DISP_IN_VBLANK));
}

@ My (probably wrong) translation to asm

    ldr r0, =REG_DISPSTAT

waitVBlankA:
    ldr r1, [r0]
    tst r1, #DISP_IN_VBLANK
    bne waitVBlankA
waitVBlankB:
    ldr r1, [r0]
    tst r1, #DISP_IN_VBLANK
    beq waitVBlankB

[flash]

That should work based on the c code, why the hell doesn't it?