Warhawk DS (HK & Flash's DS Diary)

BaDToaD · **Reply #90 on:** January 15, 2009, 10:45:23 pm

The scroll is ok but would be better if it was constant. i.e. it didn't stop scrolling in the middle third of the screen. I found it disconcerting. Not sure if that's doable or not?

Other than that things are looking sweet. I have got to at least do a different main warhawk sprite. I always did hate that! Give me a sprite size and gun positions and I'll do one. Do I get to use 16 colours? I won't need more than that.

Time to fire up the Amiga and Personal Paint methinks!

flash · **Reply #91 on:** January 15, 2009, 11:44:09 pm

I will send you the sprite and a clut file. This can be used in photoshop to maintain a palette across the board for sprites - though it can use all 256 colours (or true colour) I want to use 16 to keep things tidy (and allow multiple palettes at a later date.
It has made me BLOODY happy that you are prepared to spend some of you (very small) free time to help.. You have to admit that it would not be the same without your input and to be honest, I was starting to lose a 'bit' of momentum..

Regarding the scroll. This is a tricky one. I tried to make the scroll move with the ship, but due to the difference between the viewable area and the level width, when at either edge, 4 pixels of the background fail to scroll on. Trying to compensate for that causes 4 slight steps in the horizontal scroll - not a desired effect.
I will have a rethink and perhaps come up with another solution?? Hmmmm.

Thanks as always Ian for your support.. You have put a little smile on my face and a glint back in me eye!! (or that could be a bit of ash).

BaDToaD · **Reply #92 on:** January 16, 2009, 07:08:57 am

Believe it or not I'm not conversant with photoshop. I haven't tinkered with that for years. I'm too retro for such modern tools... LOL. If however you send me a 16 colour gif from the game with correct pallette I can load that into personal paint and be sure I'm using the right pallette.

As for the scroll, can you scroll 2 pixels instead of one across the background so you reach the edge sooner? Just a thought ... may look crap but as the screen is small it may not.

You do realise I'll end up buying a DS and cart because of this! LOL

flash · **Reply #93 on:** January 16, 2009, 07:17:28 am

I wish it was as easy as 2 pixels. The screen is 256 (minus 32 for the sprite) and the level width is 320. So, we really need to divide by 3.5 to get it to match up. Ie scroll the level horizontal 1 pixel every 3.5 pixels that you move... Half pixels are a little tricky...

If you do get a DS, I have got at spare backup card kicking about!

I will send you the graphics later today. (will start a graphics topic)

Cheers mate!

headkaze · **Reply #94 on:** January 16, 2009, 07:36:53 am

Really we should be using bit shifting instead of divide (which I'm sure were doing anyway). Cant we then just deal with any overflow by either ANDing it with a value or using something like movgt to keep it at the maximum if it goes over a limit. This rambling may not make any sense at all as I'm very tired right now!

flash · **Reply #95 on:** January 16, 2009, 07:42:39 am

sorry, my fault for keeping you busy

We are shifting. Though I did add code to enable divide by any number, may come in handy later.
we split the screen into 4 vertical ares. the centre 2 are no scrolls and the outer 2 take your x coord (-192 (then divide) +32 for right) and divide (lsr) and use the calculated result for an offset on BG1 (level). It works, but as BD said, constant movement will be nicer. I will have another look at it as perhaps a fresh head can tidy it up a bit.
The only problem is that we now have a constant speed to background speed. this may be tricky using another way - but I feel I can suss it out...

flash · **Reply #96 on:** January 16, 2009, 03:51:07 pm

Quote from: BaDToaD on January 16, 2009, 07:08:57 am

As for the scroll, can you scroll 2 pixels instead of one across the background so you reach the edge sooner? Just a thought ... may look crap but as the screen is small it may not.

I have spent over an hour trying to get the effect that you want... I have failed..
The problem is that to achieve that we need to use floating point maths, this is tricky in asm and worse in ARM. For it to work PERFECTLY, you need to take the ships X coord and divide that by 3.5 to return a number from 0-63 to set the amount of scroll that the level does horizontally... It is a pain...

Just to give you an example of how it would work (with floating math)
your X = 0-223 (255-32 = your ship width)
So, divide 223 by 3.5 gives us 63. (range 0-63)
Our screen is 256 pixels and the map is 320 - this difference is what we need to calculate, it is 64 pixels.
I can se no way round it sadly...

I will have another play later tonight hopefully and come up with another way of doing it... Perhaps a drift scroll from the centre out and then stop scrolling when it has reached it max and then allow the ship to drift to the edge, then add an auto-centre bit of code for when the ship is not moving horizontally?? Hmmm... Worth a try - what ever I can do to get it to how you see it... It is the only way we can get the FEEL into this version!

headkaze · **Reply #97 on:** January 16, 2009, 05:57:43 pm

With the arm we should be using fixed point numbers. Also I found a divide BIOS function for the DS.

flash · **Reply #98 on:** January 16, 2009, 06:18:44 pm

That link gave me a headache....

It looks interesting, but I do not really have any understanding of THUMB code as yet, but I do think the result would be the same:-

I cannot work out a way to perform and maintain the 3.5 division as illustrated earlier. As you can see, it is the only way to get continuous scrolling on the horiz based on the ships movement. If i use the carry and accumulate it, you get the occasional jerk when the accumulated fraction creates a whole that wraps the single pixel move on another straight move, ie.. a sudden 2 pixel move, or none...
Sadly there is no way to move half a pixel and any carry that you hold on to (for the halves) must be used to make a whole (or >1) at some point... You cannot do it on the dimensions we are using. Unless we made the sprite 1 pixel wide

I have had a play at Toads suggestion and come up with another more direct way of doing it (attached)

BaDToaD · **Reply #99 on:** January 17, 2009, 06:01:34 pm

Quote from: Flash on January 16, 2009, 06:18:44 pm

I have had a play at Toads suggestion and come up with another more direct way of doing it (attached)

That is how I envisaged it working

Great stuff!

flash · **Reply #100 on:** January 17, 2009, 06:08:56 pm

Phew!!!

Glad that worked out ok then! I spent several hours playing about with it and that was the best alternative I could come up with.
I have also taken the power up into account so that a single byte can increase the ships speed and the horiz scroll in conjunction..

Thanks Toad!

flash · **Reply #101 on:** January 18, 2009, 09:29:26 pm

Just shoved a score in,

Need to have a massive rethink about palettes because we have no yellow for the energy bars!! Hmmm....

The score graphics are the size I think works, but have not been properly edited.

PS. Warhawk used a 7 digit score also, mainly because the last sprite was used for the energy bar!!

PS. BaDToad, sorry I have used the original sprite, this is because that is the one set up in the main code.. Also, kinda like the idea of the ship selection idea... Will look into that nearer the end of the project.

flash · **Reply #102 on:** January 18, 2009, 09:53:12 pm

A little play with the title (thanks for .pool HK)

Now showing 1024 stars.. Tried 2048 and the DS could handle them easy - the emu couldnt

I think this is perhaps too many..

What would be a nice idea is to add a 'swarm' routine to the stars, so that when the screen is touched, the stars are atracted to the point of contact?

flash · **Reply #103 on:** January 20, 2009, 08:21:03 pm

Just had a play with level 3 to see how long it would take to "hi-resify" the backgrounds - not too long. Have not done the platau surrounds though.

flash · **Reply #104 on:** January 21, 2009, 10:29:03 pm

Latest source code!

headkaze · **Reply #105 on:** January 22, 2009, 02:34:49 am

Okay I've had some success today and got a few of the todo's done

- Fixed sprite movement code (No need to wait for vblank)
- Fixed end-of-level Wobble effect in No$GBA and hardware
- Made level taller so the end is just stars
- Added score digit display
- Set sprite priority to zero so bg0 is above

I was always wondering where you heard that you have to move sprites during vblank because it's not true. The or'ing I was trying to do in the earlier demo is correct, I was just or'ing in the wrong values. So I've fixed that and the ship sprite moves okay on hardware and No$. The problem I believe is that you can't write an 8-bit value to a 16-bit register. So when you were writing the sprite positions you have to call strh not strb and that means you must or in the attributes again and use a mask with the x and y positions.

The end-of-level wobble effect was an infinite loop. It was a simple matter of changing

Code: [Select]

holdonmate:
    ldr r2, [r0]
    cmp r2,r1
    bne holdonmate

to

Code: [Select]

holdonmate:
    ldrb r2, [r0]
    cmp r2,r1
    bne holdonmate

to prevent the value overflowing the 8-bits. As for adding more to the top of the level that was some trial and error as I don't think I fully understand the beginning offset. But I just added some space and a higher offset until the start of the level lined up.

I added some basic digit display code for the score but I have no idea how to extract each digit from a number to display in assembly. Any ideas?

flash · **Reply #106 on:** January 22, 2009, 07:29:24 am

Well done HK... See, a new pair of eyes can be a wonderful thing, a beautiful wonderful thing

I cannot remember where I read about the sprites, I will find it and put the link here!

With the score, we set two data areas

score:
.byte 0,0,0,0,0,0,0,0
adder:
.byte 0,0,0,0,0,0,0,0

We use the score to ref the digits the sprite uses and when we want to add to the score we call and add routine with the bytes set in adder. This goes from last byte back to the first adding the value of adder. if the answer is >9, subtract the dif and add one to the next, etc. When finshed, clear the adder. That is how I have done it in all my games.
There may be a better way, but it is quicker than trying to convert a word value.

Thanks HK, cant wait to have a play!

See what I mean though? How the hell did I mess up the wobble? How did I miss it? Madness! - Thanks!!!

EDIT: There is one problem now, the top 8 rasters of either screen is not being modified in the wobble.

flash · **Reply #107 on:** January 22, 2009, 07:59:05 am

I left it running and this is an example of just how far the maps for the backgrounds can drift...

Shall we just call it a special effect?

headkaze · **Reply #108 on:** January 22, 2009, 08:30:35 am

Quote from: Flash on January 22, 2009, 07:29:24 am

There is one problem now, the top 8 rasters of either screen is not being modified in the wobble.

That would probably be because it's not starting the horzontal shift early enough. Using a proper HBLANK interrupt would probably fix that, but I wouldn't worry about it too much for now.

BTW I didn't bother using sprites for the score, I thought we may as well keep it a background and then we can have the score, energy bars and text all using BG0. To have the sprites behind it it's a simple matter of setting ATTR2_PRIORITY(1). My convertion of the score digits is pretty lame I know. It would look better if the digits filled out the 16x16 space a bit more.

flash · **Reply #109 on:** January 22, 2009, 08:32:58 am

I will have a play with them when I get to work, make em sweet!

headkaze · **Reply #110 on:** January 22, 2009, 08:46:02 am

Quote from: Flash on January 22, 2009, 08:32:58 am

I will have a play with them when I get to work, make em sweet!

As for the levels getting out of sync I didn't even notice it until you posted that screenshot. I believe the delay is causing the REG_BG1xOFS and REG_BGxVOFS values (well actually vofsSFMain/vofsSFSub/vofsSBMain/vofsSBSub since the regs are write only) to get out of sync. One way to solve that would be to have one value for the offsets and calculate the subscreen offset based on that value. Then we know they will always be in sync.

Another way would probably be to re-write the delay code so it can't cause the two screens to go out of sync. Another possibility would be to subtract vofsSFMain and vofSFSub values and if the difference is not a constant value then to fix it. I believe there should always be 192 between them.

flash · **Reply #111 on:** January 22, 2009, 10:47:21 am

An update to the last post with the addition of a working score routine.

flash · **Reply #112 on:** January 22, 2009, 09:26:59 pm

A little picture of firepower

and score and other stuff!!!

BaDToaD · **Reply #113 on:** January 22, 2009, 09:28:17 pm

It's well interesting watching you two getting this all together. Reminds me of the old days

Keep up the good work guys!

flash · **Reply #114 on:** January 23, 2009, 06:44:09 pm

Quote from: BaDToaD on January 22, 2009, 09:28:17 pm

It's well interesting watching you two getting this all together. Reminds me of the old days

Keep up the good work guys!

Don't forget - you are part of that team now

headkaze · **Reply #115 on:** January 24, 2009, 08:30:14 am

Update: We now have sound

The blaster sample sounds great when you do the auto fire. Also added a text renderer so we can output text on BG0.

flash · **Reply #116 on:** January 24, 2009, 10:14:54 am

Looking (sounding) great HK

Had a play on real hardware and it is such fun!! Having sound makes such a difference!

The sound quality does need to be improved though. I will have a play later today with any luck and see what we can do. Our problem also lie in having the title and game in a single .nds file with all sound data. I am not concerned with rom size. Games like elite beat agents are 256mb... We will certainly be less than that

It is just adressing larger music files that may be the problem.

NOTE: To all who try these demos, we are at a point were you really do need hardware to play it. The emus like iDeaS really struggle with doing the sound, and No$gba seems to be the best compromise.

HK: I did shorten the ingame music as It will never get to play until the end (ingame).

flash · **Reply #117 on:** January 30, 2009, 10:08:36 pm

Well, I thought it was time we posted something.

This is just the executable, as I will release source when I am happy with the attack wave system.

This version has now got attack waves in place. At the moment it just does a little demo of a simple attack and you cannot shoot them either (you have to pretend). I still have a long way to go with the attack code, but it is now (after many headaches) falling into place. I have gone for a curved system with acceleration, though I will also implement the "much simpler" linear waves that the original used, along with the "mines" and "hunters"
The music has been turned off also on this version, mainly because I forgot to turn it on before compile..

Sorry about my debug numbers on the screen - I really could not be bothered to comment them all out.

PS. the game is set to support 64 aliens at once - though we will have to see how this pans out when all the other code it added.

Have fun!!

oh, and you can also accumulate a score by shooting the bases! (they will blow up one day

)

headkaze · **Reply #118 on:** January 31, 2009, 04:53:14 am

Coming along really nice there Flash

Now I'm just going to get myself a coffee and go through your source update and wrap my head around it.

Up next for me is

- Adding rotating sprite support
- Fix the scrolling code and background detection
- Start thinking about the app for creating attack waves

BaDToaD · **Reply #119 on:** January 31, 2009, 08:32:30 am

Looking good mate. I was dying to blast the little aliens scumbags...