Jump to content

Photo

Arkanoid 2600?


78 replies to this topic

#51 maiki OFFLINE  

maiki

    Dragonstomper

  • 694 posts

Posted Thu Mar 20, 2014 12:32 PM

Looking good. I hope you don't extend the amount of flicker in the playfield. I remember I simply could not spend much time playing that game Brik because of the flicker of the borders.



#52 Gemintronic OFFLINE  

Gemintronic

    Jason S. - Lead Developer & CEO

  • 9,314 posts

Posted Thu Mar 20, 2014 12:36 PM

Looking good. I hope you don't extend the amount of flicker in the playfield. I remember I simply could not spend much time playing that game Brik because of the flicker of the borders.

 

I'd give up the vertical delineation between blocks but I'm afraid Arkanoid fans might balk at it.



#53 Gemintronic OFFLINE  

Gemintronic

    Jason S. - Lead Developer & CEO

  • 9,314 posts

Posted Fri Mar 21, 2014 9:50 AM

New developments.  See below.



#54 Gemintronic OFFLINE  

Gemintronic

    Jason S. - Lead Developer & CEO

  • 9,314 posts

Posted Fri Mar 21, 2014 11:18 AM

This looks more like a game.  Any feedback?

 

pfcolpad6.png

Attached File  pfcolpad6.bin   4KB   119 downloads



#55 Random Terrain OFFLINE  

Random Terrain

    Visual batari Basic User

  • 28,949 posts
  • Controlled Randomness
    Replay Value
    Nonlinear
  • Location:North Carolina (USA)

Posted Fri Mar 21, 2014 11:23 AM

This looks more like a game.  Any feedback?

 

The fuzzy look kind of makes me want to vomit. Better leave it up to assembly language programmers.



#56 Gemintronic OFFLINE  

Gemintronic

    Jason S. - Lead Developer & CEO

  • 9,314 posts

Posted Fri Mar 21, 2014 11:59 AM

 

The fuzzy look kind of makes me want to vomit. Better leave it up to assembly language programmers.

 

Here is a version without flicker.  Just give me the word guys.  Is it still Arkanoid without the vertical lines?

 

pfcolpad7.png

Attached File  pfcolpad7.bin   4KB   76 downloads



#57 Omegamatrix OFFLINE  

Omegamatrix

    Quadrunner

  • 6,233 posts
  • Location:Canada

Posted Sat Mar 22, 2014 3:18 PM

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



#58 Thomas Jentzsch OFFLINE  

Thomas Jentzsch

    Thrust, Jammed, SWOOPS!, Boulder Dash, THREE·S, Star Castle

  • 23,972 posts
  • Always left from right here!
  • Location:Düsseldorf, Germany, Europe, Earth

Posted Sat Mar 22, 2014 3:26 PM

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

Edited by Thomas Jentzsch, Sat Mar 22, 2014 3:48 PM.


#59 Omegamatrix OFFLINE  

Omegamatrix

    Quadrunner

  • 6,233 posts
  • Location:Canada

Posted Sat Mar 22, 2014 3:49 PM

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.



#60 Thomas Jentzsch OFFLINE  

Thomas Jentzsch

    Thrust, Jammed, SWOOPS!, Boulder Dash, THREE·S, Star Castle

  • 23,972 posts
  • Always left from right here!
  • Location:Düsseldorf, Germany, Europe, Earth

Posted Sat Mar 22, 2014 3:55 PM

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, Sat Mar 22, 2014 3:59 PM.


#61 Omegamatrix OFFLINE  

Omegamatrix

    Quadrunner

  • 6,233 posts
  • Location:Canada

Posted Sat Mar 22, 2014 4:06 PM

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



#62 Thomas Jentzsch OFFLINE  

Thomas Jentzsch

    Thrust, Jammed, SWOOPS!, Boulder Dash, THREE·S, Star Castle

  • 23,972 posts
  • Always left from right here!
  • Location:Düsseldorf, Germany, Europe, Earth

Posted Sat Mar 22, 2014 4:12 PM

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.



#63 Omegamatrix OFFLINE  

Omegamatrix

    Quadrunner

  • 6,233 posts
  • Location:Canada

Posted Sat Mar 22, 2014 4:35 PM

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.



#64 Thomas Jentzsch OFFLINE  

Thomas Jentzsch

    Thrust, Jammed, SWOOPS!, Boulder Dash, THREE·S, Star Castle

  • 23,972 posts
  • Always left from right here!
  • Location:Düsseldorf, Germany, Europe, Earth

Posted Sat Mar 22, 2014 4:40 PM

Ok, I got you now. :)

 

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



#65 Omegamatrix OFFLINE  

Omegamatrix

    Quadrunner

  • 6,233 posts
  • Location:Canada

Posted Sat Mar 22, 2014 5:23 PM

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



#66 retrogoober OFFLINE  

retrogoober

    Moonsweeper

  • Topic Starter
  • 282 posts

Posted Tue May 6, 2014 5:06 PM

theloon - any updates?



#67 eshu OFFLINE  

eshu

    Moonsweeper

  • 283 posts

Posted Wed May 7, 2014 6:32 AM

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

 

paranoid_0.01_stella.bin_1.png

 

Attached Files



#68 Gemintronic OFFLINE  

Gemintronic

    Jason S. - Lead Developer & CEO

  • 9,314 posts

Posted Wed May 7, 2014 7:16 AM

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.



#69 eshu OFFLINE  

eshu

    Moonsweeper

  • 283 posts

Posted Wed May 7, 2014 7:30 AM

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



#70 Gemintronic OFFLINE  

Gemintronic

    Jason S. - Lead Developer & CEO

  • 9,314 posts

Posted Wed May 7, 2014 7:40 AM

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



#71 Albert ONLINE  

Albert

    Quadrunner

  • 35,241 posts

Posted Wed May 7, 2014 7:42 AM

Eshu, that looks really great! :D

..Al

#72 Greg2600 OFFLINE  

Greg2600

    River Patroller

  • 3,119 posts
  • Location:NJ

Posted Wed May 7, 2014 7:57 AM

Woah, really looks good!  Good luck on this.



#73 Mr SQL OFFLINE  

Mr SQL

    River Patroller

  • 2,089 posts

Posted Wed May 7, 2014 8:00 AM

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) :) 



#74 retrogoober OFFLINE  

retrogoober

    Moonsweeper

  • Topic Starter
  • 282 posts

Posted Wed May 7, 2014 8:09 AM

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



#75 eshu OFFLINE  

eshu

    Moonsweeper

  • 283 posts

Posted Wed May 7, 2014 8:18 AM

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






0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users