Arkanoid 2600?

[Thomas Jentzsch]

I wouldn't publish an Arkanoid game if it was rendered sideways.

Hmmm...

 

[+save2600]

It's been 3 or 4 days since this thread was created. Has the game been finished and put on a cart yet?

Yep, just waiting on the boxes from Germany now.

[+Gemintronic]

I wouldn't publish an Arkanoid game if it was rendered sideways.

 

Edit: Nor would I play it.

 

..Al

 

Ouch Top down it is!

[+wongojack]

I'd be interested in a 5200 version - just sayin

[+Gemintronic]

This is as good as I can get it using batari BASIC. RevEng made a custom kernel so I can use the first paddle as well as other needed features.

 

[Greg2600]

Driving controllers are somewhat a rarity, probably 75% or more of owners would have paddles but less than 20% owners would have driving controllers.

 

Processing requirements should be much less for driving controllers. Probably 2-4 samples per frame equally spaced then process them during VBlank might be the ideal.

 

Realistically this game should have a joystick option although IMO stick suck for such games. Actually, supporting all 3 control types shouldn't add greatly to the size. Processing requirement for joysticks is minimal, it can all be done in VBlank.

 

True but I'm sure most VCS collectors like us have driving controllers. I would love to see it with either controller.

[Crimefighter]

I wouldn't publish an Arkanoid game if it was rendered sideways.

 

Edit: Nor would I play it.

 

..Al

 

Oh like this C64 clone?

 

[Omegamatrix]

hehe, and that is already quite smart

In that example you can also see that you have to reserve Y

There are always options... but with tradeoffs. The following code(s) assume the same trick Thomas mention with jumping between operator and operand.

 

 

This trashes A,X, and the stack, but Y is free, and no temp register is needed either:

;Stack holds scanline
;This routine counts UP
    
    pla                          ;4  @4   saves 1 byte and 2 cycles over TSX --> DEX --> TXS
    tsx                          ;2  @6
    bit    INPT0                 ;3  @9
    bmi    .skipPadZero+1        ;2³ @11/12
.skipPadZero:
    stx    paddle0               ;3  @14

.

 

This preserves X and Y, but takes 2 more cycles and more bytes:

;T1024T holds scanline    
;This routine counts DOWN

    lda    INTIM                 ;4  @4   timer decrements by 1, when it is written to...
    sta    T1024T                ;4  @8
    bit    INPT0                 ;3  @11
    bmi    .skipPadZero+1        ;2³ @13/14
.skipPadZero:
    sta    paddle0               ;3  @16

[Rybags]

Could paddle processing be optimised by running alternate kernals each frame. 1st frame, check state on even scanlines, 2nd frame check state on odd scanlines then interpolate the value.

 

Probably cause for unwanted jitter but it could free up some cycles.

[Thomas Jentzsch]

That should work. And you don't even need 2 kernels. Just end dumping the paddle in different lines.

 

Also you could sample only every 2nd line and move player a bit more coarsely. It depends how fine movements you want to support.

[Thomas Jentzsch]

This preserves X and Y, but takes 2 more cycles and more bytes:

;T1024T holds scanline    
;This routine counts DOWN

    lda    INTIM                 ;4  @4   timer decrements by 1, when it is written to...
    sta    T1024T                ;4  @8
    bit    INPT0                 ;3  @11
    bmi    .skipPadZero+1        ;2³ @13/14
.skipPadZero:
    sta    paddle0               ;3  @16

 

Maybe we could directly also directly read TIM64T here and save 4 cycles. Though sampling a value changing very 64 cycles only every 76 cycles will loose some values. So probably we would need a correction function/table to convert the sampled value to position. Edited March 20, 2014 by Thomas Jentzsch

[Thomas Jentzsch]

That should work. And you don't even need 2 kernels. Just end dumping the paddle in different lines.

 

Also you could sample only every 2nd line and move player a bit more coarsely. It depends how fine movements you want to support.

Effectively you are either compromising positioning granularity or position frequency. In both cases, the controls may feel sluggish.

[enthusi]

For Arkanoid I am not even sure if you'd have to get paddle data every frame

[Rybags]

As a minimum you'd need to do the check every 2nd scanline, every frame - I imagine doing by 3 scanlines over 3 frames would be too sluggish and inaccurate.

 

The purpose being that some cycles are freed up but how helpful that is, unknown. I get the feeling that to do the game properly would require 100% Assembler.

Edited March 20, 2014 by Rybags

[Thomas Jentzsch]

For Arkanoid I am not even sure if you'd have to get paddle data every frame

Agreed here. After all, Arkanoid on the C64 was played with a joystick. Which is much less responsive than a paddle.

For games like Kaboom! this would not work. But maybe coarser positioning would do instead.

[Rybags]

Having more cycles available per scanline in the kernal one frame and less the next - only really useful if there's some sort of display interleave going on, ie flicker.

 

Joystick tends to be fine with response but loses out due to constant speed. For a plain Breakout game the button could be used for fast/slow movement but Arkanoid has the laser feature which uses the button.

[enthusi]

Well, C64 was played with a Joystick when you had no paddles

The game supported paddles of course. And even mouse.

But in the C64 the VIC with its ADC does most of the job. Still tedious to read out paddles/mouse but less so than for the 2600.

[+Gemintronic]

Any feedback on the screenshot here:

http://atariage.com/forums/topic/223257-arkanoid-2600/page-2?do=findComment&comment=2951950

 

With that setup you get one flicker free enemy. One power up (flicker for the tones at the edges). One flicker free ball. The half-tone lines between bricks DO flicker.

[Rybags]

How are the vertical lines done? Missiles + ball or something? Gaps between the bricks would look good, as would vertical walls to enclose what's going on (in different colour to the bricks).

 

There's a fair bit that can go on. Not that I'm a 2600 expert but my take on the object use is along the lines of:

Bricks - playfield.

Enemies - players.

Up to 3 player balls + laser shot - missiles + ball.

Bonus objects - players.

Vaus - player/s.

 

Flicker obviously inevitable.

 

Re (offtopic) C64 paddle reading - there's little work. Obviously there, you have necessary translation between 256 possible values and screen coordinates which might potentially be up to 340 or so (catering for offscreen/partially visible).

[+Gemintronic]

player1 is used for the vertical lines. Every other frame I change the x coordinate to cover all the bricks. With RevEngs modified bB kernel I lose missile1 so it's no loss that player1 is as black as the background. The bonus object is the ball. The playfield is colored green where the ball (as a bonus item) drops. I shifted the x coordinate every other frame to get the half-tone at the balls edges. Missile0 is used as the ball because the hardware ball would take on the playfield colors and look weird when up and in the bricks. The paddle is composed of playfield pixels. player0 is the wandering enemy.

[Thomas Jentzsch]

Joystick tends to be fine with response but loses out due to constant speed. F

Speed doesn't have to be all constant. The movement can accelerate e.g. over time. Many joystick game have used this.

 

But it will never be as precise and attached to the player's hand as a paddle.

[Thomas Jentzsch]

 

Oh like this C64 clone?

 

If you read some reviews, then Krakout is much better playable with a joystick than Arkanoid. Probably the code is just better there, but maybe the sideway arrangement helps there too. One would have to test to find out.

 

I remember having more fun with Krakout than Arkanoid on my C64 too. But I only had a joystick.

[Omegamatrix]

Maybe we could directly also directly read TIM64T here and save 4 cycles. Though sampling a value changing very 64 cycles only every 76 cycles will loose some values. So probably we would need a correction function/table to convert the sampled value to position.

That is the problem. However you could maybe do a (six ?) line kernel followed by a quick load to re-align the timer.

 

76 - 64 = 12, and 76 / 12 = 6.333 lines.

 

 

I also wrote that PLA TSX saved 2 cycles over TSX DEX TXS. I was doing that right before I went to bed.

[Thomas Jentzsch]

IMO a six line kernel, requires quite a lot of space. And makes things complicated.

 

The table would require ~230 bytes and makes things easy.

[+Gemintronic]

This is just to show things animated. No brick breaking yet . Paddle control is not quite bounds checked yet.

 

pfcolpad3.bin