Super JumpKick Turbo 64 (C64 port)

[pmprog]

Not sure how many of you played Super JumpKick Turbo on your desktops/Pandoras (probably not many).

Anyway, as I was feeling a bit nostalgic, I thought I'd have a little play in converting it to run on the Commodore64. It's coming along quite quickly, which is good. If people are interested, I'll update with the PRG when it's finished, but for now, enjoy the cool broken gameplay

 

[ible]

it looks a little glitchy

 

[Magic Sam]

Hi all !

@pmprog : Super JumpKick Turbo is installed on my Pandora, my girlfriend played it the other day while in the train

Good luck with your C64 port ! I'm looking forward to playing it

Cheers, Magic Sam

 

[edgex004]

I am also a fan of the Pandora port. Glad to see you have further plans for it!

 

[pmprog]

Super JumpKick Turbo is installed on my Pandora, my girlfriend played it the other day while in the train

That's great to hear. Thanks

I am also a fan of the Pandora port. Glad to see you have further plans for it!

Not sure i'd consider this "further plans" but thank you.

 

[pmprog]

Quick update, having issues with sprite collisions

 

[rSl]

verry coool!

 

[FBnil]

issues with sprite collisions

How come? Look up sprite-to-sprite collision: http://sta.c64.org/cbm64mem.html

See: http://www.lemon64.com/forum/viewtopic.php?t=51752

$D01E puts a 1 in the bit of your sprite (0 to 7) has collided with another sprite and $D01F for background.

Be careful to not evaluate one sprite first, then the other, because in that case, one player always wins when tied (both hitting at the same time). AND you need to peek twice.

So maybe in a loop, read: 53273 Interrupt status register. Bit #2: 1 = Sprite-sprite collision occurred (with any given sprites).
Only then check $D01E for 1st and 2nd bit set to 1. Do test both, and if both hit eachother, use a randomizer to determine who won.
poke 53273,0 to unset the bits (see "Acknowledge sprite-sprite collision interrupt"). (during initializing, 53266 set the rasterline (to zero))

you know what... I'm rusty... and not sure what I am talking about... your demo looks nice though... looking forward playing it.

 

[pmprog]

How come? Look up sprite-to-sprite collision: http://sta.c64.org/cbm64mem.html

Thanks, but I know how it works. The problem with the sprite-sprite collision matrix is it only indicates when a sprite is overlapping any other sprite. Because I'm using multiple sprites next to each other to create the players, this is sometimes triggering a "collision", and $D01E doesn't differentiate between which sprites are colliding. I've overcome this by doing a bounds check against foot and head sprites, this has been far more reliable and it's looking good

Also, if both players hit each other (not sure if this will actually be possible given that I'm only checking head collisions, but I might change that), the round will result in a draw, and you replay it... No "randomiser" is needed.

 

[FBnil]

but I might change that

This code served me well in the past (it is very optimized):
http://www.visibone.com/inpoly/inpoly.c.txt

You define a polygon (or 4 points to make a rectangle), then you check the boundaries of the other rectangle/user/sprite, if <0 A is in B if >0 B is in A.

I modified it once, to also if it returns -2, then it is the second point of A that is colliding... (see begin_func(PolygonCollision, 2) )
http://sphere.cvs.sourceforge.net/v.../engine/script.cpp?revision=1.231&view=markup

 

[levi]

Surely, in this game, whoever is further off the ground when a collision happens wins. If using the bounding check you can identify when the two players collide, it doesn't matter who hit who according to the c64 sprite code.

 

[pmprog]

This code served me well in the past (it is very optimized):
http://www.visibone.com/inpoly/inpoly.c.txt

True, but it's overkill. I can work with rects, and it's you can compare rects a lot faster than this
https://github.com/pmprog/SuperJump...03479d949aefe6c6f51b8ade3865/tools.h#L81-L100
In case you're wondering why widths and heights are in variables, I was going to use the expandx/y flags to set them accordingly, but I might just remove that because in this game they'll only ever be expanded when checking. That'll save me a few bytes

Surely, in this game, whoever is further off the ground when a collision happens wins. If using the bounding check you can identify when the two players collide, it doesn't matter who hit who according to the c64 sprite code.

That's majority true... might even be exactly true in this version of the game, considering there's only one character. However, I still can't use the C64 sprite collision because as I've mentioned, I get fake collisions with players being built of multiple sprites. That means I need to do a bounds check, and thus the C64 sprite collision flag is unnecessary

 

[_jr_]

Couldn't checking the sprite collision flags save you from performing the bounds check on every iteration?

 

[pmprog]

I don't perform them every iteration, only when at least one player is in the "KICKING" state. This keeps the checks to a minimum and there doesn't appear to be any significant impact whilst it's checking.

I'm half wishing I'd tried to put a bit more effort into trying this in ASM rather than C, because I have no idea how or even if I can link in a SID tune.

 

[FBnil]

How about this (totally not sure if the CBM works this way):

• We think the kicking leg sprite is in-collision.
• move that body sprite to -64,-64 (offscreen) or disable it
• reset the collision flags
  
• bring back the kicking leg sprite to its original position

What I think would happen: As only that single sprite moved, only that single sprite is checked against the other sprites? Ignore the sprites that are from the same fighter, only check the sprite bits from the opponent.

 

[levi]

The SID format is a bit weird as I understand it - it's not really like MIDI or a tracker format. Instead the C64 games ran code (probably on a timer interrupt) that periodically triggered the SID chip to make a new noise, so actually to play a tune on a C64 you need the code to fire off events in 6502 machine code, and the data for it to play, while tracker and midi files are just the data and none of the code.

I dunno how you access interrupts from C code - most 'high level' languages on those machine didn't have any explicit support for it in the main. Are you cross compiling, or one of the languages released for the machine in the 1980s?

 

[pmprog]

How about this (totally not sure if the CBM works this way):

• We think the kicking leg sprite is in-collision.
• move that body sprite to -64,-64 (offscreen) or disable it
• reset the collision flags
  
• bring back the kicking leg sprite to its original position

What I think would happen: As only that single sprite moved, only that single sprite is checked against the other sprites? Ignore the sprites that are from the same fighter, only check the sprite bits from the opponent.

Aside from moving a single sprite offscreen - which will glitch onscreen - you can't only check between two specific sprites, it doesn't work that way, that's why bounds checking is easier. Trust me.

The SID format is a bit weird as I understand it - it's not really like MIDI or a tracker format. Instead the C64 games ran code (probably on a timer interrupt) that periodically triggered the SID chip to make a new noise, so actually to play a tune on a C64 you need the code to fire off events in 6502 machine code, and the data for it to play, while tracker and midi files are just the data and none of the code.

I dunno how you access interrupts from C code - most 'high level' languages on those machine didn't have any explicit support for it in the main. Are you cross compiling, or one of the languages released for the machine in the 1980s?

Yeah, you kinda program the SID chip, but there are tracker tools (I released GoatTracker for the Pandora), which generate you a player and song data that you can link in. I've done it in previous C64 work, but that was with some Assembler projects, not a C project. And yes, I'm cross compiling using cc65