SpritesMind.Net

Posted: **Sat Apr 12, 2008 7:25 pm**

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.

Posted: **Sat Apr 12, 2008 8:03 pm**

Here's some screenshots for you guys.

Kega:

Regen:

Posted: **Sat Apr 12, 2008 8:47 pm**

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!

Posted: **Sat Apr 12, 2008 8:53 pm**

Fonzie wrote: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

Fonzie wrote: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.

Fonzie wrote:You coded that in C ? or asm?

Assembler.

Fonzie wrote: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.

Posted: **Sat Apr 12, 2008 9:17 pm**

Sik wrote: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.

Posted: **Sat Apr 12, 2008 9:26 pm**

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)

Posted: **Sun Apr 13, 2008 9:25 am**

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.

Posted: **Sun Apr 13, 2008 2:02 pm**

TmEE co.(TM) wrote: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.

TmEE co.(TM) wrote:I'll test it on my MDs ASAP.

Thanks!

Posted: **Sun Apr 13, 2008 3:18 pm**

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

Posted: **Sun Apr 13, 2008 3:24 pm**

TmEE co.(TM) wrote:your game works perfectly on MD

YAY!

TmEE co.(TM) wrote: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?

Posted: **Sun Apr 13, 2008 4:30 pm**

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

Posted: **Sun Apr 13, 2008 4:39 pm**

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)

Posted: **Sun Apr 13, 2008 4:44 pm**

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...

Posted: **Sun Apr 13, 2008 4:54 pm**

ok...

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

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

Posted: **Sun Apr 13, 2008 5:12 pm**

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 ^_^'

SpritesMind.Net

Ninja Fight

Ninja Fight