Ninja Fight

[Sik]

Oh, well, here I go:
http://srb2town.sepwich.com/junk/nfight.bin

Very early prototype for a fighting game. Through for now you can only walk and "jump" (the jumping code doesn't do what it should, try to jump and you'll see ). Also there's only one character, through both players already work (use the second joystick for the second player, d'oh).

It only works in Fusion and Regen. Also, somebody tell me if it works in the real hardware please.

[King Of Chaos]

Here's some screenshots for you guys.

Kega:


Regen:

[Fonzie]

Wow Sweet!
Haha, i like the perfectionism of the line scrolling background, fake dithered shadow and more !

The jump is kinda nice too Even if its a bug, i wish you could keep it (as a protect/hipercut combo?)

You coded that in C ? or asm?

Genskmod just report this problem (but it should not be dramatic..)....

Spy : 00202 Reg. 15 : an auto increment data of 0 is a bad idea!

[Sik]

Wow Sweet!
Haha, i like the perfectionism of the line scrolling background, fake dithered shadow and more !

Er, tile scrolling background Through the dithered shadow is a good one. Also check how it blinks. I actually figured it out by myself, but later I found out Gunstar Heroes uses this trick too. Good to go then

The jump is kinda nice too Even if its a bug, i wish you could keep it (as a protect/hipercut combo?)

The classic teleport special move, I may do it later.

You coded that in C ? or asm?

Assembler.

Genskmod just report this problem (but it should not be dramatic..)....

Spy : 00202 Reg. 15 : an auto increment data of 0 is a bad idea!

KMod reports that in all games because first it initializes all VDP registers to 0 (as the real hardware) and then it detects that and gives a warning. A bug in KMod really.

[notaz]

it initializes all VDP registers to 0 (as the real hardware)

Are you sure about that? I've seen that Fusion uses some non-zero initial values. Never checked the real hardware though.

[Sik]

BIOS hack? (remember the BIOS initializes the VDP by its own, also it writes a bit of stuff to RAM (exactly at $FFC000) to be able to do the bank switching properly). Actually I don't care, I write to all the registers

Anyways, that may be the cause of the warning in KMod. I just know absolutely all ROMs give that warning.

EDIT: er, shouldn't I have posted this topic in the "demos" subforum? (argh, stupid name, it should be more like "demos and games" :/)

EDIT 2: updated background. The Japanese characters say, literally, "Geisha" (according to Google XD)

[TmEE co.(TM)]

That game demo looks nice. I think the jumping bug is some stupid Bxx error.... my particle stuff did all kinds of weirdnesses until I found that one Bxx was wrong But then again, I have no idea how your stuff is written so..... anyway good luck. I'll test it on my MDs ASAP.

[Sik]

That game demo looks nice. I think the jumping bug is some stupid Bxx error.... my particle stuff did all kinds of weirdnesses until I found that one Bxx was wrong But then again, I have no idea how your stuff is written so..... anyway good luck.

This is the only piece of code that has to do with jumping:

Code: Select all

;-------;
; Jump! ;
;-------;

    cmpi.w  #199, d6
    bne.s   RunPlayerCantJump
    btst.l  #ILBitButtonUp, d0
    beq.s   RunPlayerCantJump
    moveq   #-28, d2
RunPlayerCantJump:

;---------;
; Gravity ;
;---------;

    move.w  d2, d3
    addq.w  #1, d2
    asr.w   #4, d3
    add.w   d3, d6
    cmpi.w  #199, d6
    blt.s   RunPlayerOnAir
    move.w  #199, d6
RunPlayerOnAir:

D0 = joystick input (bit set = pressed)
D2 = gravity (positive = downwards)
D3 = unused at this point (so free for anything)
D6 = Y coordinate (floor at 199)

Seriously, what's wrong with it? In C it would look as follows (converting right now, mind you ):

Code: Select all

if (y == 199 && (input & BUTTON_UP))
   gravity = -28;

y += gravity++ >> 4;
if (y >= 199)
   y = 199;

Yes, I know that dividing by 16 is way too much, normally I divide by 4. I'm using that value for testing Also don't ask me why am I using >= rather than >, later this will help me setting a player state properly.

I'll test it on my MDs ASAP.

Thanks!

[TmEE co.(TM)]

your game works perfectly on MD and I can't understand your ASM code... and I don't know C....

[Sik]

your game works perfectly on MD

YAY!

and I can't understand your ASM code... and I don't know C....

• Jump code: if the player is on the floor (player's Y = floor's Y) and the up button is pressed, jump (set a negative gravity).
• Gravity code: first increase player's Y according to the current gravity. Increase gravity a bit. If player's Y is below the floor, make it to be on the floor.

What's wrong with it?

[TmEE co.(TM)]

ok.... I hope you understand QB (that code is not too functional.... but it gives the idea):

Code: Select all

 IF (PlayerY% = Ground%) AND JumpPressed% = 1 THEN   ; if player is on ground and jump pressed, JUMP :)
 Jump% = 1                                ; set the jump flag
 PlayerForce% = (anything)                ; set the lifting power
 END IF

 IF Jump% = 1 THEN                        ; if JUMP is happening
 PlayerY% = PlayerY% + PlayerForce%       ; Player is off the ground with the power of lifting ;)
 PlayerForce% = PlayerForce% - Gravity%   ; but you can't deny the gravity, lifting power gradually decreases and player plumments back to ground
 IF PlayerY% <= Ground% THEN Jump% = 0    ; and if ground is reached, no jumping action anymore
 END IF

[notaz]

Wen you load your variables, you load them as words, including gravity:

Code: Select all

ROM:00000380 loc_380:
ROM:00000380                 move.w  0(a0),d7
ROM:00000384                 move.w  2(a0),d6
ROM:00000388                 move.w  4(a0),d5
ROM:0000038C                 move.w  $C(a0),d2

But you save your gravity as byte:

Code: Select all

...
ROM:00000448                 move.w  d5,4(a0)
ROM:0000044C                 move.b  d4,$A(a0)
ROM:00000450                 move.b  d2,$C(a0)

[Sik]

• It won't work unless both PlayerForce% and Gravity% are negative.
• You're checking against a ceiling, not a floor (PlayerY% <= Ground%, should be >= instead).

EDIT: it was respect to TmEE's post

EDIT 2: notaz was right... ARGH. OK, ROM updated, through I think I'm going to change some speeds...

[TmEE co.(TM)]

ok...

I use exact same method here (only in ASM) :

http://www.hot.ee/tmeeco2/TMFPLAY.RAR

[Sik]

To be honest another impression I got from that code is that you were considering Y to be positive upwards, rather than downwards as I do.

EDIT: updated, fixed another issue. Silly me ^_^'