Jump to content
IGNORED

Arkanoid 2600?


retrogoober

Recommended Posts

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.

.

 

I was thinking about this some more today and I came up with this for CAA:

    lda    #$80                  ;2  @2
    cmp    INPT0                 ;3  @5
    adc    padZero               ;3  @8
    sta    padZero               ;3  @11
    lda    #$80                  ;2  @13
    cmp    INPT1                 ;3  @16
    adc    padOne                ;3  @19
    sta    padOne                ;3  @22

I now have a few different kernels that I branch to mid screen in CAA, and I found it too hard to compensate for TIM64T with a look-up table because I don't read the paddle inputs on the same cycle, and the cycles can vary even for the same scanline once I'm in a different kernel. I still like your idea of a look-up table, but it won't work in my case. :(

 

 

But this allows me to read both paddles rather cleanly. I can get away with this since I need to sample 119 lines so I never overflow bit 7 with my count... I just have to AND #$7F for both registers after I'm done reading them. This also leaves me X and Y free. :)

Link to comment
Share on other sites

I cannot see why the lookup table would not work. It makes not difference if you read INPT0 and INPT1 on different cycles.

 

BTW: CAA? :?

Circus AtariAge = CAA

 

You're right about INPT0 and INPT1, I meant to imply that I would be reading INTIM at different times too. It turned out to be much easier to do what I did, and it also saved alot of bytes over using a look-up table.

Link to comment
Share on other sites

I meant to imply that I would be reading INTIM at different times too.

Which still would be no problem. :)

 

Also you do not even have to read it twice:

    lda    INTIM     4
    bit    INPT0     3 
    bmi    .save0+1  2
.save0
    sta    padZero   3         
    bit    INPT1     3 
    bmi    .save1+1  2
.save1
    sta    padOne    3 = 20
Anyway, if it works for your kernel, then there is no reason to change it. Edited by Thomas Jentzsch
Link to comment
Share on other sites

Which still would be no problem. :)

No, that is the problem. The timer is running out sooner then the scanline, so the cycle it runs out will be different on every scanline until they reach a common denominator. For a given scanline I could be reading it before or after it rolls over (the second time). I can't predict what cycle I'm reading INTIM on since there are a bunch of different kernels with different timing constraints. I also can't predict what kernel I will be in and adjust for it, without a lot more overhead.

 

Anyway I think we are derailing this thread now...

Link to comment
Share on other sites

Sorry, I don't get you.

 

What I mean is, that it is not relevant that a certain paddle position results into a certain value which is the same for both players.

It is only relevant, that a certain paddle movement results into certain value change for players.

Link to comment
Share on other sites

Sorry, I don't get you.

I know. :)

 

 

I am talking about reading INTIM (once) per scanline, and correcting that value with a look up table. This value is the scanline count, of course. If I read INTIM on the same cycle for every scanline this works. But I run into situations where for the same given scanline (say scanline 120) I have to read INTIM at a different cycle because I'm in different kernels, and the timer value is different. If you have a paddle that is stationary but it also happens that the capacitor finishes charging on that very line then this will cause a 1 pixel wobble for your player.

 

For my game it is also not predictable which kernel I will be in for a given scanline.

Link to comment
Share on other sites

But if the code you posted above is executed at different cycles, you will have the same wobble problem too, no?

Yes and no. It comes down to mitigating the occurrences, and preventing them from compounding together.

 

I used a 1 pixel movement debouncer in my previous builds. I tried using a 2 (and more) pixel debouncer and found the movement started to look too jerky. I also found that the INPTx reads drift on their own as the thermal characteristics kick in (on the 2600). I really didn't want to throw in reading INTIM at different times to that too. I'm also trying to keep the cycles that INPTx is read on the same as much the same as I can, but it's not always possible when the kernel gets busy...

Link to comment
Share on other sites

  • 1 month later...

Here's a sneak peak of something I've been working on - it's just a kernel test at the moment really - I ran into a couple of bugs in stella, so theres two binaries attached, one for stella and one for the real machine.....I'm due to work on the proper ball movement and bat collisions next, the ones in this version are not how I plan on implementing it, they are a bit buggy but I need to rework all the code for different speeds of the ball etc...

 

If anyone does have a chance to test it on real hardware - I need to make sure the paddle read is working ok, seems fine on my hardware, but my paddles are bit jittery anyway so it's hard to be sure - Omegamatrix mentioned issues with paddle reads and early hmove here: http://atariage.com/forums/topic/223653-maintaining-p0-horizontal-position-after-previous-resp0/

 

I'm not planning to do an exact clone of arkanoid as I prefer to do things in a way that suits the 2600 - the enemies won't go into the brick area or cross the same scanlines as I'm flicker averse, also multi-ball will only have two balls and a few other changes I'm sure....

 

The bricks are just a random mix of colours at the moment to test the kernel - it supports three different colour bricks per line with some limitations

 

Excuse the programmer graphics :)

 

The screenshot below is with Stella's NTSC ratio set all the way down at 81 - this is about the ratio I see on my screen.

 

post-19935-0-87102300-1399465807_thumb.png

 

paranoid_0.01_stella.bin

paranoid_0.01_real.bin

  • Like 3
Link to comment
Share on other sites

theloon - any updates?

 

Well, this was really an excuse to see if I could code further into paddle game territory. I dabbled with the concept when a similar game called BriX appeared for the 2600. It "felt" like a batari BASIC game so I attempted to code a clone in bB to see if it was true. Sure enough, I was able to reproduce all the features and subsequently the author stated he did make it in bB. I was never quite satisfied with my brick/ball collisions in my implementation.

 

This topic came up and it got me to dabble further. I re-wrote the engine and got better collision going. It was/is a kludge but it works much, much better. RevEng graciously contributed a new mini-kernel that allowed me an additional multi-color paddle.

 

Alas, I got bogged down in figuring out what to do about the flicker issue. This topic had awesome feedback from many people. It's just that *I* personally couldn't make up my mind and went on to do work on other games. It sounds like eshu might be interested in creating a new paddle game, though.

Link to comment
Share on other sites

Hey theloon, please don't feel like I'm hijacking your project, theres no reason two versions couldn't be done (see the current donkey kong projects). I couldn't resist having a crack at a kernel which handled multi-colour bricks which I think would be tricky with the standard Bb kernels without giving up a lot of objects. I had a feeling you had stopped working on it as you've been active on other projects. I really would like to complete this one but there's a long way to go yet, and the kernel tends to be the most fun part for me...

Link to comment
Share on other sites

Hey theloon, please don't feel like I'm hijacking your project, theres no reason two versions couldn't be done (see the current donkey kong projects). I couldn't resist having a crack at a kernel which handled multi-colour bricks which I think would be tricky with the standard Bb kernels without giving up a lot of objects. I had a feeling you had stopped working on it as you've been active on other projects. I really would like to complete this one but there's a long way to go yet, and the kernel tends to be the most fun part for me...

 

I appreciate the thoughts but, naw. It really is me :) I'm already committed to two games and this was just something I was experimenting with. I've reached an impasse with the flicker issue and have learned it's best to set some roadblocks aside and work on something else lest you not make progress in anything :P

Link to comment
Share on other sites

I'd like to play both of these Arkanoid clones; Pong games are my favourite :)

 

Eshu's port is looking awesome!

 

Loon also had an awesome build where I could percieve no flicker, but I play on a real TV and not LCD; I also don't fancy the Stella debugger (comes in handy when it's broken) so I'm never stepping through, searching hard for the flicker (kind of silly); I go by what I can actually see playing the game :)

 

The no flicker build was awesome, I hope Loon completes it when he is done with his current isometric game (also looking awesome) :)

Link to comment
Share on other sites

eshu - that is really nice work, thank you! Looks like you have the nice animated power ups down

 

Thanks - I sort of have the powerups down, the one issue is that I can't use the ball which is doing the background colour in the bricks (They're drawn using the playfield as well as playfield and background colour changes), I'm not sure yet whether to have the powerups come from the enemies (ala off the wall), or to have threm drawn differently until they leave the brick area. I'm leaning towards the second - maybe sort of dashed lines falling quickly until it leaves the brick area, or a question mark until it leaves the brick area - anyway that's a way away for now, I'll do some tests once/if I get that far....

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...