Don't go! (WIP)

[vitoco]

Hi!

 

There were many times that I tried to program something for the 2600, but after I downloaded docs and related sw, I always drop the idea for any external (real life) reason, and I had to start from zero every new time.

 

In the latest couple of months I've seen some very nice WIP and releases that made me try once again, and this time I have a very simple and reachable goal: to port one of my 8bit BASIC tenliners to the 2600, and I chose Don't go! because it is really simple, and it would use both players, both missiles and the ball in a way I could learn a lot. This is how it looks in the 8bit:

 

 

I started reading docs and examples of bB, but I finally decided to go directly to the roots in order to understand the basics and to not add overhead that I don't understand yet.

 

I built a kernel with pieces from tutorials and different AA threads, but I had to fine tune one of the many routines to position sprites I tried because neither of them worked OK with all the object types at the same time, specially because I want to use them in double or quadruple width.

 

These are some screenshots of the process...

 

- Trying to adjust the sprite positions:

 

- Applying the shapes and colors to the pads:

 

- Resizing the ball:

 

- Removing the PF stripes (used to measure sprite's horizontal positioning):

 

It looks very nice, but I had to test the border contitions, in order to be sure that no objects were missing some pixels and, of coure, I found some issues at the first try:

 

 

Here, the ball is missing its first scanline, and the last one which it is being partially displayed should not be there.

 

As I want to use all the scanlines (a single line kernel for fine vertical scrolling) and no interlaced display, I guess that I need to start drawing the left pad at the end of the previous scanline and start WSYNC with the ball, and something else should be done for the last scanline of the top pad.

 

Solving that, the next step will be either the routine to move the ball between the boundaries (it is completely static by now), or the routine to read the paddle in order to move the pads (currently they are moving from side to side using a counter). Then, sound and FX. The last step will be the addition of the score... and I'm still thinking about doing something with the playfield to increase difficulty by adding some obstacles.

 

If I'm OK, I need to include some code in the kernel routine to read the POT (paddle), which it could be critical for the timing in the display, so I guess I should try this first.

 

Could someone point me to some simple explanation and/or example for paddle reading? I've searched and read some real code, but I think I need a more detailed explanation than what the Stella Programmer's Guide says.

 

Thanks!

 

[vitoco]

I solved the border condition issues by moving the portion of code that manages the left pad to the end of the previous line (just after increasing the scanline counter and before checking for the loop).

 

After some research, I found Darrel's Paddle Demo, which gave me a clean view of how to read POTs in a practical way.

 

I replaced my old paddle simulation code with a real one and I made it work, but I had to de-optimize my previous kernel. Fortunately, it could fit inside the scanline without introducing glitches.

 

Anyway, I'll have to move some of the assembly constants into variables (RAM or indexes to ROM tables), because I want to check for difficuly switches and change the pads sizes according to them.

 

If someone has some other ideas to improve the game, please post them here!!! I'm still re-coding the game while learning about this machine.

 

[bluswimmer]

This looks neat so far! I think a co-op mode would work wonders for this game, with each person controlling a different set of paddles.

[+SpiceWare]

On 9/7/2020 at 3:53 PM, vitoco said:

I had to fine tune one of the many routines to position sprites I tried because neither of them worked OK with all the object types at the same time, specially because I want to use them in double or quadruple width.

 

I don't know if you've seen my tutorial, the second note in the comments for the PosObject subroutine point this out.

;===============================================================================
; PosObject
;----------
; subroutine for setting the X position of any TIA object
; when called, set the following registers:
;   A - holds the X position of the object
;   X - holds which object to position
;       0 = player0
;       1 = player1
;       2 = missile0
;       3 = missile1
;       4 = ball
; the routine will set the coarse X position of the object, as well as the
; fine-tune register that will be used when HMOVE is used.
;
; Note: The X position differs based on the object, for player0 and player1
;       0 is the leftmost pixel while for missile0, missile1 and ball 1 is
;       the leftmost pixel:
;           players     - X range is 0-159
;           missiles    - X range is 1-160
;           ball        - X range is 1-160
; Note: Setting players to double or quad size will affect the position of
;       the players.
;===============================================================================
PosObject:
        sec
        sta WSYNC
DivideLoop
        sbc #15        ; 2  2 - each time thru this loop takes 5 cycles, which is 
        bcs DivideLoop ; 2  4 - the same amount of time it takes to draw 15 pixels
        eor #7         ; 2  6 - The EOR & ASL statements convert the remainder
        asl            ; 2  8 - of position/15 to the value needed to fine tune
        asl            ; 2 10 - the X position
        asl            ; 2 12
        asl            ; 2 14
        sta.wx HMP0,X  ; 5 19 - store fine tuning of X
        sta RESP0,X    ; 4 23 - set coarse X position of object
        rts            ; 6 29

 

 

On 9/7/2020 at 3:53 PM, vitoco said:

Here, the ball is missing its first scanline, and the last one which it is being partially displayed should not be there.

 

As I want to use all the scanlines (a single line kernel for fine vertical scrolling) and no interlaced display, I guess that I need to start drawing the left pad at the end of the previous scanline and start WSYNC with the ball, and something else should be done for the last scanline of the top pad.

 

If you turn on VDELP0 and VDELBL then updates to GRP0 and ENABL are delayed until GRP1 is written to. This is the normal kernel for Draconian:

NormalKernel:               ;   20
        lda #DS_SIZE        ; 2 22 <- just to keep stream in sync
nk1:    lda #DS_COLOR       ; 2 24 2 33 from Resm0Strobe28 <- just to keep stream in sync
        lda #DS_HMP0        ; 2 26
nk2:    sta HMP0            ; 3 29 3 39 from Resm0Strobe33
        lda #DS_HMP1        ; 2 31
nk3:    sta HMP1            ; 3 34 3 44 from Resm0Strobe38       
        lda #DS_MISSILE0    ; 2 36
nk4:    tax                 ; 2 38 2 48 from Resm0Strobe43 
        stx HMM0            ; 3 41
nk5:    lda #DS_MISSILE1    ; 2 43 2 53 from Resm0Strobe48
        tay                 ; 2 45
        sty HMM1            ; 3 48
        lda #DS_BALL        ; 2 50
nk6:    sta HMBL            ; 3 53 3 62 from Resm0Strobe53             
        sta ENABL           ; 3 56 <- for next scanline, VDELBL on 
nk8:    lda #DS_GRP0        ; 2 58 2 68 from Resm0Strobe63
nk7:    sta GRP0            ; 3 61 3 71 from Resm0Strobe58 <- for next scanline, VDELP0 on
nk9:    lda #DS_GRP1        ; 2 63 2 73 from Resm0Strobe68
        sta WSYNC           ; 3 66/0
nk10:   sta HMOVE           ; 3  3
        sta GRP1            ; 3  6 <- also updates GRP0 and BL
        DIGITAL_AUDIO       ; 5 11
        stx ENAM0           ; 3 14
        sty ENAM1           ; 3 17
        jmp FASTJMP         ; 3 20

 

This is using the CDFJ coprocessor, but take note of the STA ENABL at cycle 56 and STA GRP0 at cycle 61. The updates to GRP0 and ENABL are not visible until the STA GRP1 is done at cycle 6, so you won't get any shearing.

 

I was going to point you to my paddle demo, but see you already found it.

[vitoco]

16 hours ago, SpiceWare said:

I don't know if you've seen my tutorial, the second note in the comments for the PosObject subroutine point this out.

Thank you for pointing this. By that time, I had not seen the tutorial (although I had read some of it a couple of years ago in a previous attempt), but the routine I finally did it is clearly based on yours from that turorial. This is what I built to manage my wider objects:

 

MoveSprites
  ldx #4
MoveSpritesLoop
  lda #2
  cpx #2
  bcc MoveSpritesAdjust
  lda #3                      ; carry has another 1
MoveSpritesAdjust
  adc Position,x
  sec
  sta WSYNC
MoveSpritesWait
  sbc #15                     ; 2
  bcs MoveSpritesWait         ; 3-
  eor #7                      ; 2
  asl                         ; 2
  asl                         ; 2
  asl                         ; 2
  asl                         ; 2
  sta HMP0,X                  ; 4
  sta RESP0,X                 ; 4
  dex
  bpl MoveSpritesLoop
  sta WSYNC
  sta HMOVE
  rts

I'm repositioning all 5 objects once on every frame, which it takes 5+1 scanlines, even when missiles are horizontally static, but I prefer this way because I'd probably include some other reposition for score (if I don't build it with PF) or an Activision-like signature.

 

Anyway, it seems that I must halt for a while and think all again, because I'm facing some other issues I hadn't thought before because in the 800XL the things goes in another way. For instance, I must provide a kernel for a static screen that allows a player to select difficulty before the game starts and another for the game over. As I won't write such duplicates, I guess that I must change my view of how to design this game and turn into a better approach, with a modular kernel or such, probably managing events and timers instead of counting WSYNCs.

 

16 hours ago, SpiceWare said:

If you turn on VDELP0 and VDELBL then updates to GRP0 and ENABL are delayed until GRP1 is written to.

That was my second option, but fortunately all went OK.

 

16 hours ago, SpiceWare said:

This is the normal kernel for Draconian:

NormalKernel:               ;   20
        lda #DS_SIZE        ; 2 22 <- just to keep stream in sync
nk1:    lda #DS_COLOR       ; 2 24 2 33 from Resm0Strobe28 <- just to keep stream in sync
        lda #DS_HMP0        ; 2 26
nk2:    sta HMP0            ; 3 29 3 39 from Resm0Strobe33
...

This is using the CDFJ coprocessor,

What is going on here with those 3 immediate LDAs in a row? I don't know about the coprocessor, but it doesn't make sense to me anyway...

 

I had read Andrew's tutorial at RandomTerrain and some other pages (including bB) in that site before I started coding this project. Now, I'll read yours deeply because I feel it suits better on what I'm thinking for my game/project.

 

Any hint about best practices is welcome!

 

Thanks again.

 

[+SpiceWare]

43 minutes ago, vitoco said:

I prefer this way because I'd probably include some other reposition for score

 

Scores don't move, so the repositioning can be hard coded.  In Frantic just 1 scanline is used to set the players to triplicate, turn on VDELPx, set the colors, AND reposition the players for the score:

_SCORE_KERNEL:                   ;   20 // was _EXIT_KERNEL
        stx GRP0                ; 3 23 - should be off, but just in case
        stx GRP1                ; 3 23 - should be off, but just in case
        stx PF2                 ; 3 26 - before 38
        ldx #3                  ; 2 28
        stx NUSIZ0              ; 3 31
        stx NUSIZ1              ; 3 34
        stx RESP0               ; 3 40 - set to postion 57, target is 56
        stx RESP1               ; 3 43 - set to position 66, target is 64
        stx VDELP0              ; 3 37
        stx VDELP1              ; 3 46
        ldx #8                  ; 2 48
        stx LoopCounter         ; 3 51        
        ldx #$1F                ; 2 53
        stx HMP0                ; 3 56 - move left 1       
        inx                     ; 2 58
        stx HMP1                ; 3 61 - move left 2
        lda #_DS_COLORS         ; 2 63 score color
        sta COLUP0              ; 3 66
        sta COLUP1              ; 3 69
        stx WSYNC
        ;----------
        stx HMOVE               ; 3  3

 

 

43 minutes ago, vitoco said:

What is going on here with those 3 immediate LDAs in a row? I don't know about the coprocessor, but it doesn't make sense to me anyway...

 

They're reading data streams which contain a value for every scanline. DS_SIZE contains values that end up in NUSIZx (for players and missiles) or CTRLPF (for the ball) and DS_COLOR contains values which ends up in COLUPx. They are only used when an object is repositioned, but if you don't read them on every scanline then the streams will get out of sync (ie: you could end up using values for scanline 2 during a reposition on scanline 10). Using data streams is advanced stuff and goes hand-in-hand with using a coprocessor. You can learn about it in the Harmony/Melody club, though I recommend learning to write a 6507 assembly game first.

 

43 minutes ago, vitoco said:

Any hint about best practices is welcome!

 

Be sure to include cycle counts in any time critical routine.  The two numbers after the ; in my code snippets are the cycle count for that instruction followed by the cumulative cycle count for that scanline. You'll have updates that must occur at specific times, so document them as well - such as all the updates to PF0, PF1, and PF2 in this snippet from Frantic:

_NORMAL_KERNEL:                 ;   20
        SLEEP 4                 ; 4 24
_HMCLR_KERNEL:                  ;   24
        lda #_DS_PF2L           ; 2 26
        sta PF2                 ; 3 29 - PF2L, before 38
        sty PF0                 ; 3 32 - PF0R, 28-49
        lda #_DS_PF0R_M1        ; 2 34
        tay                     ; 2 36 - save M1 data for NEXT scanline
        lda #_DS_HMXX_BL        ; 2 38
        sta ENABL               ; 3 41 - for next scanline, VDELBL
        lda #_DS_GRP0           ; 2 43 
        sta GRP0                ; 3 46 - for next scanline, VDELP0
        lda #_DS_PF1R           ; 2 48
        sta PF1                 ; 3 51 - PF1R, 39-53
        lda #_DS_PF2R           ; 2 53
        sta PF2                 ; 3 56 - PF2R, 50-65
        lda #_DS_PF0L_M0        ; 2 58
        sta PF0                 ; 3 61 PF0L, after 55 - for NEXT scanline
        tax                     ; 2 63 - save M0 data for NEXT scanline
        lda #_DS_PF1L           ; 2 65
        sta PF1                 ; 3 68 PF1L, 66-28
        lda #_DS_GRP1           ; 2 70
        sta HMCLR               ; 3 73
        sta GRP1                ; 3  76/0
        lda #_DS_COLUP0         ; 2  2
        sta COLUP0              ; 3  5
        lda #_DS_COLUP1         ; 2  7
        sta COLUP1              ; 3 10
        stx ENAM0               ; 3 13
        sty.w ENAM1             ; 4 17        
        jmp FASTJMP1            ; 3 20

 

The first store to PF2 is for the left side copy of PF2, and it must be updated before cycle 38. The first store to PF0 is for the right side copy of PF0, and must occur on or between cycles 28 and 49. And so on.

[vitoco]

On 9/9/2020 at 1:51 PM, SpiceWare said:

Using data streams is advanced stuff and goes hand-in-hand with using a coprocessor. You can learn about it in the Harmony/Melody club, though I recommend learning to write a 6507 assembly game first.

I had to go there to know the idea behind data streams, but I got lost... So I'll stick to 6507 assembly until I finish and release this game. Thank you for all your help (and useful posts somewhere else in this forum).

 

Just one more question: which is the higher cycle where is it safe to reach the "sta WSYNC" without losing a scanline?

 

Back to my project, this is the changlog:

 

• I rebuild the code to use timers in VB and OS, but I have not tried to fit the 262 scanlines yet, because the playfield/arena's height is not a single one, so I guess I'll add another timer waiting for kernel's the 192 scanlines.
• The rebuilt code now uses the ".byte $2C" trick to always get the same amount of cycles in the arena scanlines. This change made some scanlines need some extra cycles and warp around to the next scanline, so I had to change some things to make all work OK again.
• The code was structured in a way that the kernel could be used in different states of the game.
• I used many assembler constants and formulas to compute and define the playfield limits and objects' coordinates, but as I wanted to include a game variation that would kill some those constants, I turned most of them into data tables. This had the consequence that many RAM bytes where required to store the variable "constants" for the given difficulty.
• The color of the objects now matches the ones from the 800XL version. I guess that the motion of the pad are consistent between versions, at least both Stella and Altirra reacts in the same way for the same mouse movement.
• I included a simple routine to move the ball inside the arena and bouncing around without checking if there was a pad in place.

This is how it looks now:

 

 Normal

 

 Pro

 

I've attached a demo in the normal difficulty... If some can test it in a real 2600 (*), please let me know how it goes. I want to know if the pads are too close to the screen edges, specially in the case of CRTs.

 

(*) I still have mine from the old days, but it is not working and needs to be repaired.

 

Next steps:

 

- Score board: At top or bottom? Using playfield or players?

 

- About gameplay: I'm thinking if I'd keep it single-life & endless running (like in my 800XL version) or to increase the difficulty during the play. How? Random bounces? Increasing speed? Unable to controls bounce direction?

 

- To include the routines for different game states and manage SWCHB (difficulty swithches, B/W, game reset, game start).

 

Any other idea to improve the game? Please comment!!!

 

Thanks...

 

dontgo-20200911-demo.bin

[+SpiceWare]

8 minutes ago, vitoco said:

Just one more question: which is the higher cycle where is it safe to reach the "sta WSYNC" without losing a scanline?

 

This occurs multiple times in Medieval Mayhem:

sta WSYNC         ; 3 76

 

[vitoco]

Updates:

 

• Reorganized the code again. I started programming in a sequential way to fit the VB, kernel and OS display, but I think that its better to make blocks of code like in routines for legibility, even when I lose 12 cycles for each JSR/RTS pair.

• Managed the console buttons:

- TV type selects color and B/W mode

- left difficulty switch changes the pad size

- right difficulty does nothing (yet)

- game select does nothing (yet)

- game reset restarts the game

(all but reset returns to the game selection screen)

• Added a bounces counter (score).

 

Now it looks like this:

 

 - Normal

 

 - Pro in B/W

 

Now, I'm starting with the sounds.

  

On 9/8/2020 at 6:50 PM, bluswimmer said:

I think a co-op mode would work wonders for this game, with each person controlling a different set of paddles.

My current kernel is a single line one, so I have no machine cycles free to add a check for the second POT (paddle).

 

Anyway, I'll left the gamplay as the last item, because I'm still thinking about different difficulties for the game. Some ideas are:

- increase the ball speed every X bounces

- control bounce direction (depending on which side of the pad the ball hits)

- bounce with random angles/speeds

- lives & bonus (currently there is only one life)

- introduce gravity to change the ball direction

- introduce invisible walls to block and return the ball

- all the previous in stages/levels and combinations of them!

 

More ideas? Everything is welcome!!!

 

Stay tuned!

[Mr SQL]

On 9/7/2020 at 4:53 PM, vitoco said:

In the latest couple of months I've seen some very nice WIP and releases that made me try once again, and this time I have a very simple and reachable goal: to port one of my 8bit BASIC tenliners to the 2600, and I chose Don't go! because it is really simple, and it would use both players, both missiles and the ball in a way I could learn a lot. This is how it looks in the 8bit:

 

 

Awesome to see Don't Go! on the Atari 2600 and you writing games for the 2600 vitoco!

 

If you would like to enter a 10-line BASIC game for the 2600 in the Programming contest, SuperCharger BASIC has an old-school mode for classic BASIC programming with line numbers like the A8.

 

[vitoco]

6 hours ago, Mr SQL said:

Awesome to see Don't Go! on the Atari 2600 and you writing games for the 2600 vitoco!

Thanks! 

 

The new changes are:

• It has sounds with a simple FX tracker I'm writing. I have to experiment a lot more with the available AUDCn modes and the 5 bit only AUDFn to get good quality sound effects, not just peep and toot.

• The game is playable, because the ball bounces only on pads, not on every border... Now I'm scared!!! Even when I'm using simple diagonal bounces, it is a bit faster that the original game, and it seems to be very difficult. A difficult game immediately turns into a frustrating game when there is no extra motivation to try again other than a hi-score challenge. I need to add many more elements to keep it as an intereting game to try, and try, and try again.

 

6 hours ago, Mr SQL said:

If you would like to enter a 10-line BASIC game for the 2600 in the Programming contest, SuperCharger BASIC has an old-school mode for classic BASIC programming with line numbers like the A8.

When I first saw your 9lineBlitz some years ago, I tried to update myself about current VCS' state-of-the-art. I think that it was the first time I considered to write something for the 2600, but as I said in my first post of this thread, I needed to learn more about the hardware and then I forgot that for some time. Then I tried again with bB, but quit it some days later.

 

What it made me to discard trying a tenliner for the 2600 was all those very long names to control features like "SUSTAINFORFRAMES" or "playfieldpos". Also, the lack of structured programming that it cannot be distributed in the middle of different lines of code makes hard to get the most of every line. Just like 8bit's AtariBASIC, having only 10 destination lines for GOTOs is a real challenge, but with the lack of line space, that makes almost impossible to write a playable and enjoyable game.

 

Of course, I'm aware of some BASIC's builtin features that could be used to make a great game, but that requires some previous experience, and I'm on it!!!

 

Also, I've found that the resulting binaries require upgraded hardware like Supercharger, Harmony and Melody cart provides, and that's another new world for me. Be patient... In this first stage I'm trying to create my first VCS game using the original programing techniques, and I'll try to burn my own 2K ROM/EPROM with it ?

 

[Mr SQL]

3 hours ago, vitoco said:

The new changes are:

• It has sounds with a simple FX tracker I'm writing. I have to experiment a lot more with the available AUDCn modes and the 5 bit only AUDFn to get good quality sound effects, not just peep and toot.

• The game is playable, because the ball bounces only on pads, not on every border... Now I'm scared!!! Even when I'm using simple diagonal bounces, it is a bit faster that the original game, and it seems to be very difficult. A difficult game immediately turns into a frustrating game when there is no extra motivation to try again other than a hi-score challenge. I need to add many more elements to keep it as an intereting game to try, and try, and try again.

RT has a great online resource for all of the AUDC and AUDF values for Fx here

 

Very cool, Looking forward to seeing the new elements added!    

  

3 hours ago, vitoco said:

When I first saw your 9lineBlitz some years ago, I tried to update myself about current VCS' state-of-the-art. I think that it was the first time I considered to write something for the 2600, but as I said in my first post of this thread, I needed to learn more about the hardware and then I forgot that for some time. Then I tried again with bB, but quit it some days later.

 

What it made me to discard trying a tenliner for the 2600 was all those very long names to control features like "SUSTAINFORFRAMES" or "playfieldpos". Also, the lack of structured programming that it cannot be distributed in the middle of different lines of code makes hard to get the most of every line. Just like 8bit's AtariBASIC, having only 10 destination lines for GOTOs is a real challenge, but with the lack of line space, that makes almost impossible to write a playable and enjoyable game.

Thanks! Check out 10lineBlitzII for my latest version of this game with some new enhancements.

 

I agree about how challenging it is to fit the code particularly with only being able to have if at the start of a line, but I managed to add ramping difficulty, adjustable difficulty levels, and colorful waves and mission levels!  

 

There is also a trick to increase the line space using tokens like AtariBASIC that I think you would like - I didn't do it because I wanted the BASIC listing to be as readable as possible, but all control features like "SUSTAINFORFRAMES" can be replaced with whatever their token is in the zero page and the same for the big register names, freeing extra line space for competition code.

 

3 hours ago, vitoco said:

In this first stage I'm trying to create my first VCS game using the original programing techniques, and I'll try to burn my own 2K ROM/EPROM with it ?

 

Fantastic start! You write lots of awesome games for the A8 and I am looking forward to seeing what you will create on the 2600 in both assembly and BASIC!  

 

[vitoco]

On 9/16/2020 at 4:54 PM, Mr SQL said:

RT has a great online resource for all of the AUDC and AUDF values for Fx here

Excelent page! That is a very good start point to select some values and to mix them for an FX.

 

On 9/16/2020 at 4:54 PM, Mr SQL said:

You write lots of awesome games for the A8 and I am looking forward to seeing what you will create on the 2600 in both assembly and BASIC! 

My mini games are just that: mini-games.  They might be awesome because you know there was a tenliner restriction when I wrote each of them. But I have fun programming them, trying to get the best of the available resources and, the most important, playables!!! I already have 2 (unpublished) games ready for NOMAM 2021 contest and 2 more developements stand-by. Games for the 2600 became my source for ideas in the latest years, but I wanted to give me a break on BASIC tenliners and tried going in the other direction: from A8 tenliners to 2600 games. It seems that I like to suffer with extreme programming, and I had knocked my head against the keyboard trying to get the things on sync just like when I had to fit statements in lines for a tenliner.

 

Updates on "Don't go!":

• It supports many lives now. The A8 game is a single life one.

• Right difficulty switch selects between 1 or 3 lives (0 or 2 extra lives).

• Paddle's trigger restarts the game on certain conditions

 

 

I've attached a new playable demo. It has just one type of bounces, totally predictable, but hard enougth, like a practice level. Both difficulty switches are working, and TV type switch changes between color and B/W. Using any of those switches abort current game. Use game reset to (re)start the game. There are some FX sounds included for testing purposes.

 

Please try it and comment... If someone tries it on a real console, please let me know how it feels with real paddles. If a CRT is used, please post a photo.

 

As usual, any idea is welcome!

 

dontgo-20200917-demo.bin

[Prizrak]

@vitoco could you post or DM what you would like for instructions for this game for me? Looking to add it to your PlusCart folder please.

Sent from my SM-N960U using Tapatalk

[overgrouth]

59 minutes ago, vitoco said:

Excelent page! That is a very good start point to select some values and to mix them for an FX.

 

My mini games are just that: mini-games.  They might be awesome because you know there was a tenliner restriction when I wrote each of them. But I have fun programming them, trying to get the best of the available resources and, the most important, playables!!! I already have 2 (unpublished) games ready for NOMAM 2021 contest and 2 more developements stand-by. Games for the 2600 became my source for ideas in the latest years, but I wanted to give me a break on BASIC tenliners and tried going in the other direction: from A8 tenliners to 2600 games. It seems that I like to suffer with extreme programming, and I had knocked my head against the keyboard trying to get the things on sync just like when I had to fit statements in lines for a tenliner.

 

Updates on "Don't go!":

• It supports many lives now. The A8 game is a single life one.

• Right difficulty switch selects between 1 or 3 lives (0 or 2 extra lives).

• Paddle's trigger restarts the game on certain conditions

 

 

I've attached a new playable demo. It has just one type of bounces, totally predictable, but hard enougth, like a practice level. Both difficulty switches are working, and TV type switch changes between color and B/W. Using any of those switches abort current game. Use game reset to (re)start the game. There are some FX sounds included for testing purposes.

 

Please try it and comment... If someone tries it on a real console, please let me know how it feels with real paddles. If a CRT is used, please post a photo.

 

As usual, any idea is welcome!

 

dontgo-20200917-demo.bin 2 kB · 4 downloads

I will do a comparison for you.

[overgrouth]

Tried this on PC will be running on a real console soon. I was thinking this was a 4 player game only to find out it is a single player and so far it is very cool. I can use paddles with my PC but so far I only tried the mouse which gets confusing but I bet the paddles will make this whole thing feel natural in every way as it should beings I grew up playing with paddle controllers.

Just curious what else is planned for this title? like I say so far so good but I'm thinking of all these cool ideas but it is your project so I will find out what you have in mind in the future.

[+atari2600land]

I played it on my CRT TV and it rolled horribly. Then I thought "perhaps it's a PAL game." Could you make an NTSC version?

EDIT: So then I try it on Stella and it's a constant 258 scanlines. Perhaps you should bump it up to 262 so it doesn't roll horribly any more.

[Rogerpoco]

Wow!!!!!

I'm nowhere near a programmer, you Guys are insane, but I swear, I have scribbled notes, and have given "detailed" explanations to people, some members here, of a game fantastically similar to this!!!

I'll check it out, am looking forward to seeing this go farther!

I was thinking to start with an almost full border, that got smaller and smaller over time, as the levels progressed?

Very interesting.

 

*Edit*

I actually have my paddles out, paddle weeks are coming up in the HSC, so I'll try to give some feedback soon!

(Hehe, I "found" a bug last week in Ms. Galactopus, we actually had to scratch a bunch of scores and replay with an updated version, so I am a, *cough, cough* "professional bugtester".)

Edited September 18, 2020 by Rogerpoco

[Mr SQL]

12 hours ago, vitoco said:

I've attached a new playable demo. It has just one type of bounces, totally predictable, but hard enougth, like a practice level. Both difficulty switches are working, and TV type switch changes between color and B/W. Using any of those switches abort current game. Use game reset to (re)start the game. There are some FX sounds included for testing purposes.

 

Please try it and comment... If someone tries it on a real console, please let me know how it feels with real paddles. If a CRT is used, please post a photo.

 

As usual, any idea is welcome!

Just played this on the real hardware with my PlusCart  - very intriguing game vitoco! Once it hits the corner there is a double hit that is quite difficult to orchestrate. Some tuning will make this a lot of fun!  

 

Paddles work great with no jitter. I suggest using the right joystick port for the paddles though, the left port should be for the joystick or players have to swap.

 

Had no problems viewing this on my CRT and it is right on the spec and will roll if the scanline count varies by 1.

 @atari2600land maybe you need to adjust the vertical synch?

 

 

[vitoco]

12 hours ago, overgrouth said:

Tried this on PC will be running on a real console soon. I was thinking this was a 4 player game only to find out it is a single player and so far it is very cool. I can use paddles with my PC but so far I only tried the mouse which gets confusing but I bet the paddles will make this whole thing feel natural in every way as it should beings I grew up playing with paddle controllers.

"Don't go" is a single player game. The full story is in its description page as a BASIC tenliner (about 70 statements in 10 lines of BASIC code).

 

To play it in Stella without paddles+Stelladaptor, you can use the mouse, moving it horizontally. All 4 pads will move at the same time: opposite pads move on different direction, but both clockwise or counterclockwise.

 

2 hours ago, Mr SQL said:

Just played this on the real hardware with my PlusCart  - very intriguing game vitoco! Once it hits the corner there is a double hit that is quite difficult to orchestrate. Some tuning will make this a lot of fun!  

Vertical and horizontal pads move to the same corner at the same time, so a hit in the corner might be saved by the same move.

 

2 hours ago, Mr SQL said:

Paddles work great with no jitter. I suggest using the right joystick port for the paddles though, the left port should be for the joystick or players have to swap.

Is this a common practice today for the VCS? I didn't see that in the 80's. I think that doing this port change would counfuse Stella players, because the mouse won't work.

 

12 hours ago, overgrouth said:

Just curious what else is planned for this title? like I say so far so good but I'm thinking of all these cool ideas but it is your project so I will find out what you have in mind in the future.

This is what I've thought:

On 9/14/2020 at 6:44 PM, vitoco said:

- increase the ball speed every X bounces

- control bounce direction (depending on which side of the pad the ball hits)

- bounce with random angles/speeds

- lives & bonus (currently there is only one life)

- introduce gravity to change the ball direction

- introduce invisible walls to block and return the ball

- all the previous in stages/levels and combinations of them!

- parabolic bounce

- zig-zag bounce

 

3 hours ago, Rogerpoco said:

I was thinking to start with an almost full border, that got smaller and smaller over time, as the levels progressed?

I found this a very interesting idea to test, because even when some of the rules are hardcoded, most of them could be changed at compile time. Before taking some action, (while in the shower) at first it seemed to me that the difficulty would be greater in a smaller area because the player would need faster reflexes, but it turns that a smaller area has less space to let the ball escape, because the pads would always have the same size. In the extreme, the ball would be surounded by pads and no free space to escape.

 

11 hours ago, atari2600land said:

I played it on my CRT TV and it rolled horribly. Then I thought "perhaps it's a PAL game." Could you make an NTSC version?

EDIT: So then I try it on Stella and it's a constant 258 scanlines. Perhaps you should bump it up to 262 so it doesn't roll horribly any more.

I changed the way I code all the same time while I'm learning about this machine, and instead of counting the scanlines as I initially did, I moved to the use of timers. Unfortunatelly, formulas using integer arithmetics need some tunning and also timeouts don't fit scanlines, so I left them just as they worked for me in the Stella emulator. But at @atari2600land's notice, I went into Stella's debugger, and I found that the scanline counter starts from zero when exiting the VSYNC lines, so I had to count all the scanlines that timers provide. In total, the kernel was using 194 scanlines instead of 192, and the overscan had a lot less than the required to get 262 in total for NTSC. I adjusted the timers and sent him a new binary to test.

2 hours ago, Mr SQL said:

Had no problems viewing this on my CRT and it is right on the spec and will roll if the scanline count varies by 1.

 @atari2600land maybe you need to adjust the vertical synch?

I'm glad that it is working anyway on real hardware and CRTs, but I want to write a game that it could be playable everywhere, both NTSC and PAL, real and emulated. If I could make a cartridge with it, I'd be happy. Of course, if it becames an interesting game, it could be great if it is published, but that's another story where I don't know a single word on how that works.

 

15 hours ago, Prizrak said:

@vitoco could you post or DM what you would like for instructions for this game for me? Looking to add it to your PlusCart folder please.

Could you be more specific on what do you need?

 

BTW, it looks like this PlusCart is something to seriously consider. But first, I need to repair my old VCS.

 

++V

 

[+Al_Nafuur]

19 minutes ago, vitoco said:

 

BTW, it looks like this PlusCart is something to seriously consider. But first, I need to repair my old VCS.

 

I can send you a PlusCart DIY-Kit.
If repairing your old VCS includes soldering, then you can just can go on with it

 

[+Al_Nafuur]

17 hours ago, vitoco said:

Pease try it and comment... If someone tries it on a real console, please let me know how it feels with real paddles. If a CRT is used, please post a photo.

 

 

I am not used to paddle games, bought them just 2 weeks ago.

 

The ball movement is too predictable, maybe you should add some obstacles in the middle of the Playfield 

[vitoco]

1 hour ago, Al_Nafuur said:

I can send you a PlusCart DIY-Kit.
If repairing your old VCS includes soldering, then you can just can go on with it

I'd appreciate it very much, but I don't know exactly what's wrong with my console. There was a flood in my neighborhood in 1984, and I managed to recover the console among many things from the mud, but I never took the time to do a restoration, which I only did to the controllers so I could use them in my brand new 800XL ('til today). A few years ago, I took my 2600 to a local retro meetup event and turned it on for the first time in about 30 years. It worked fine for a few minutes and then some garbage appeared in the TV screen. I have to do a real cleaning of it and see which components need to be replaced, and I'll do that as soon as I finish this project.

 

1 hour ago, Al_Nafuur said:

Whoops... a naked PlusCart!!! ?

 

When I'm trying to adjust the scanlines but I fail to tune the timers, Stella automatically changes from NTSC to PAL and displays those colors (the score should be purple instead of red). Now I see another "problem": the height of the vertical pads becames larger in PAL than in NTSC. I tried to adjust them to fit the width of the horizontal ones. I'm not sure if I need to either dynamically adjust their size (and the whole arena height) to make them look similar. Even the ball doesn't look square and a scanline should be removed from it. I have to think about this...

 

Thanks for the picture!!!

 

1 hour ago, Al_Nafuur said:

The ball movement is too predictable, maybe you should add some obstacles in the middle of the Playfield

Yes, it is predictable, and that's why I called it a "practice level".

 

As I'm using a single line kernel, I have no room to add visible obstacles using the playfield, and if I could, it would be of the same color of the ball, unless flickering is used, and I don't want to do that in my first project. That's why "invisible walls" are in my list... but I'll try different types of bounces first.

 

[+atari2600land]

I have a few ideas:

• make the ball's starting point random. Right now it is on the center of the screen.
• when you start a new game, the ball always goes to the upper left, perhaps you can make the ball's starting movement direction random as well.
• and also increase the ball's speed every, say, 50 points. A new sound effect could be used to indicate the ball is moving faster.

Do you plan on keeping this 2k? How much space do you have left? To switch to a 4k game, you could change the ORG $f800 at the beginning to ORG $f000.

[vitoco]

15 minutes ago, atari2600land said:

I have a few ideas:

• make the ball's starting point random. Right now it is on the center of the screen.
• when you start a new game, the ball always goes to the upper left, perhaps you can make the ball's starting movement direction random as well.
• and also increase the ball's speed every, say, 50 points. A new sound effect could be used to indicate the ball is moving faster.

Ball will start to a random direction, but always from the center. For now, it starts always to the upper left just because I was testing the addition of negative numbers

I haven't tried random numbers yet, and I guess I should start with any algorithm really soon.

 

Currently, there is a sound that it can be heard every 10 points... the idea is to signal that something different is happening (speed up, zig-zag, gravity, parabolic, ...) Of course, current sound FXs are experimental. They should be better!

 

25 minutes ago, atari2600land said:

Do you plan on keeping this 2k? How much space do you have left? To switch to a 4k game, you could change the ORG $f800 at the beginning to ORG $f000.

There is about two pages free, that's a quarter of the 2K limit. I'll try to fit in that space, but I think that some features would require more data tables, and that probably make me go for the full 4K ROM. I hope not. 

 

Thanks for testing!

 

++V