Jump to content

Photo

Need Guidance for First Project

noob atari 2600 programming issues

9 replies to this topic

#1 ExhaustinAustin OFFLINE  

ExhaustinAustin

    Combat Commando

  • 5 posts

Posted Fri Mar 31, 2017 7:26 AM

So hey there^^ I've decided to pick up and start learning bB and using the visual tool recently. To be honest,I've got more of a background in art, I've never programmed a day in my life before recently. Unfortunately, all of the information I've found so far seems really disorganized and I haven't found any sort of hub or directory that shows examples of code and explaining how the information actually works. I've had a few problems so far, but I know how to do part of what I want. If anyone could point me in the right directions when it comes to specific tutorials/ part of guides and such, that would be great.

 

The project itself is called "Magnificent Heist" it's a top-down, Zelda-style, stealth based dungeon crawler where you play as a thief and have to evade lasers, spotlights, and security guards as you go deeper through a building to burgle treasure.

 

Things I can do/ know  I can do:

- Create and place sprites (multiple copies of one as well) on a playfield

- sprite animation

multicolor sprite/pfcolor kernels (also the no_blank_line)

- missile creation (I won't it for this project, however)

- programming lives/ how to lose them

- sound effects

- items (temporarily invisibility cloaking device)

 

Things I've struggled with:

- creating working controls for the player

- proper playfield dimensions/structure (how to form a "good" screen that's big and isn't cut off when emulated, how to design a level for the 2600)

- Keeping Code Organized ( as the project gets bigger, I'm wondering how I'm going to keep everything straight/in their own sections)

 

Things I'll need to figure out/learn eventually for this project

- Title Screen

- moving from one screen to another

- applying a transition animation to that screen change (similar to the Zelda transition when you move screens)

- Enemy logic (A spotlight/ guard chasing you if you get to close to a guard or touch a spotlight it and lose health/ a life to it once)

- multiple "floors" with a few rooms on each floor, possibly the need to search the rooms for a key to get to the next floor

- progressive difficulty with each floor

- end goal that sends back to title screen

 

So yeah, if anyone could give me some advice or point me in the right direction that would be great. As of posting this, my current issue is the inability to get the player character to move.

 

I'm at work on my phone, so I'll have to wait until later to share the file/code, but If anyone has more advice, thoughts, scathing criticism, etc. I'd love to hear that as well ^^



#2 Gip-Gip OFFLINE  

Gip-Gip

    Chopper Commander

  • 210 posts
  • Location:Georgia, US

Posted Fri Mar 31, 2017 9:50 PM

Things I've struggled with:

- creating working controls for the player

- proper playfield dimensions/structure (how to form a "good" screen that's big and isn't cut off when emulated, how to design a level for the 2600)

- Keeping Code Organized ( as the project gets bigger, I'm wondering how I'm going to keep everything straight/in their own sections)

 

I'll try to give you some of the info I know, even though I haven't programmed in bB in a good 3 years:

 

Random terrain seems to have a good tutorial, and I remember using it when I programmed in the language (even though I actually just skimmed through it till I found the parts I liked, usually completely missing important points). You can look through it here.

 

Controls are individual variables in bB, and you need an if-then statement.

 

Constant playfields were never my thing, and the best advice I can give is find what's right for you and the VCS (don't go outside the limits)

 

My method of code organization is probably hated by others, but I find it works best for me and it probably will help you in some form:

  • Split your code into files based on what the code does; I put subroutines and the such in their own files as it's easier for me to read and debug.
  • Try to keep the files from exceeding 100-200 lines unless it's a MAIN.BAS or something like that (it becomes really hard to read really quickly).
  • Use version control like git or SVN
  • Use directories liberally
  • Name things so that they are self-explanatory

Plus the general programming rule that you should always solve a bug once it appears, or you may end up programming around it and ruining your work

 

If you need specific help, I'll do what I can, but it's been 3 years since I started as well, so I'll have a hard time explaining while you may have a hard time understanding



#3 ExhaustinAustin OFFLINE  

ExhaustinAustin

    Combat Commando

  • Topic Starter
  • 5 posts

Posted Sat Apr 1, 2017 11:24 AM

 

I'll try to give you some of the info I know, even though I haven't programmed in bB in a good 3 years:

 

Random terrain seems to have a good tutorial, and I remember using it when I programmed in the language (even though I actually just skimmed through it till I found the parts I liked, usually completely missing important points). You can look through it here.

 

Controls are individual variables in bB, and you need an if-then statement.

 

Constant playfields were never my thing, and the best advice I can give is find what's right for you and the VCS (don't go outside the limits)

 

My method of code organization is probably hated by others, but I find it works best for me and it probably will help you in some form:

  • Split your code into files based on what the code does; I put subroutines and the such in their own files as it's easier for me to read and debug.
  • Try to keep the files from exceeding 100-200 lines unless it's a MAIN.BAS or something like that (it becomes really hard to read really quickly).
  • Use version control like git or SVN
  • Use directories liberally
  • Name things so that they are self-explanatory

 if I split the code into multiple files, will it automatically run every code file at the same time, or is there an extra step? ( like having to combine them into one in the end and updating that one, big file every time you have to make a change to a single code file)



#4 Gip-Gip OFFLINE  

Gip-Gip

    Chopper Commander

  • 210 posts
  • Location:Georgia, US

Posted Sat Apr 1, 2017 5:28 PM

 if I split the code into multiple files, will it automatically run every code file at the same time, or is there an extra step? ( like having to combine them into one in the end and updating that one, big file every time you have to make a change to a single code file)

 

In assembler you would either build files one at a time or include their code using an "include command". bB also has an include command, but it looks to have different behavior than I'm used to. Try using the include command and if it doesn't work, I'll help you find a way to work it out. Keep in mind bB is more of a starter language, and probably lacks some basic functionality most programmers expect.

 

Then again, trial and error may be on your side. Visual bB may be much more sophisticated than it seems, and you might just have to slap the files in the same project and hope for the best

 

I cannot run Visual bB, so I may be crippled in helping you.



#5 ExhaustinAustin OFFLINE  

ExhaustinAustin

    Combat Commando

  • Topic Starter
  • 5 posts

Posted Sat Apr 1, 2017 11:17 PM

thanks for your help ^^ I really appreciate it. I guess for my first question: I've the animation for my character, so I'm wondering: how do I add in an "idle" animation when there's no directional input on the joystick. If I stop moving, he just sort of runs in place

 set kernel_options playercolors player1colors pfcolors
 set tv ntsc
 x=75 : y =75
main
 COLUP0 = $06
 COLUP1 = $06
 COLUBK = $00
 f=f+1

 player1x=x
 player1y=y

 if f=10 then player1:
 %0100010
 %0010010
 %0011100
 %1011100
 %1011100
 %0111111
 %0011101
 %0011110
 %0110101
 %0111111
 %0111111
 %0011111
end
 if f=10 then player1color:
 $02
 $06
 $06
 $0C
 $02
 $02
 $0C
 $3E
 $02
 $FA
 $FC
 $FE
end

 if f=40 then player1:
 %0001000
 %0001000
 %0001000
 %0011100
 %0011100
 %0011100
 %0011100
 %0011110
 %0110101
 %0111111
 %0111111
 %0011111
end
 if f=40 then player1color:
 $02
 $06
 $06
 $0C
 $02
 $02
 $0C
 $3E
 $02
 $FA
 $FC
 $FE
end

 if f=70 then player1:
 %0100010
 %0010010
 %0011100
 %1011100
 %1011100
 %0111111
 %0011101
 %0011110
 %0110101
 %0111111
 %0111111
 %0011111
end
 if f=70 then player1color:
 $02
 $06
 $06
 $0C
 $02
 $02
 $0C
 $3E
 $02
 $FA
 $FC
 $FE
end

 if f=100 then player1:
 %0001000
 %0001000
 %0001000
 %0011100
 %0011100
 %0011100
 %0011100
 %0011110
 %0110101
 %0111111
 %0111111
 %0011111
end
 if f=100 then player1color:
 $02
 $06
 $06
 $0C
 $02
 $02
 $0C
 $3E
 $02
 $FA
 $FC
 $FE
end

 if f=40 then f=0
 drawscreen
 player1x=x :  player1y=y
 if joy0right then REFP1 = 0
 if joy0right then x=x+1
 if joy0left then REFP1 = 8
 if joy0left then x=x-1
 if joy0up then y=y-1
 if joy0down then y=y+1
 goto main



#6 Gip-Gip OFFLINE  

Gip-Gip

    Chopper Commander

  • 210 posts
  • Location:Georgia, US

Posted Sat Apr 1, 2017 11:31 PM

 

thanks for your help ^^ I really appreciate it. I guess for my first question: I've the animation for my character, so I'm wondering: how do I add in an "idle" animation when there's no directional input on the joystick. If I stop moving, he just sort of runs in place

 

Now here's where bB gets ugly

 

normally in assembler, we'd just have a number pointing to an address and we'd increment that every frame or so to animate it. And that would be the way to go if the language allowed it, but as you could guess from a mile away, it doesn't support it (at least, without a lot more explanation and modification)

 

The second best is to separate the individual states into their own files and call them conditionally through a subroutine or goto, which wouldn't be that hard to implement.

 

The third and most shunned way to do so, aka the way you shouldn't do it, is to do AND comparisons on each frame to check the player state, and since I don't want you to kill your programming experience that early, I won't tell you how to do that

 

P.S. please attach the file next time


Edited by Gip-Gip, Sat Apr 1, 2017 11:33 PM.


#7 ExhaustinAustin OFFLINE  

ExhaustinAustin

    Combat Commando

  • Topic Starter
  • 5 posts

Posted Sun Apr 2, 2017 2:45 AM

Alright, so besides using the "! and &&" method (which you advised against, so I deleted it after I just tested it for S&G), I'm stumped I've got two different files now, one that controls the sprite on a playfield with animation and one that does the same, except only in his idle sprite . I've tried the include/include files but that hasn't worked for me, as I'll just get a black screen It seems like I would just need to know which pieces of code to combine, add, or leave out in my file(s), but nothing that would work is popping out. I'm wondering if I could do something with else, but in the end, that just might be as inefficient as the && method. 

 

https://drive.google...ZjJVU2hVX3RZTWc
 



#8 Gip-Gip OFFLINE  

Gip-Gip

    Chopper Commander

  • 210 posts
  • Location:Georgia, US

Posted Sun Apr 2, 2017 11:36 AM

Alright, so besides using the "! and &&" method (which you advised against, so I deleted it after I just tested it for S&G), I'm stumped I've got two different files now, one that controls the sprite on a playfield with animation and one that does the same, except only in his idle sprite . I've tried the include/include files but that hasn't worked for me, as I'll just get a black screen It seems like I would just need to know which pieces of code to combine, add, or leave out in my file(s), but nothing that would work is popping out. I'm wondering if I could do something with else, but in the end, that just might be as inefficient as the && method. 

 

https://drive.google...ZjJVU2hVX3RZTWc
 

 

If you have to keep it in a single file (which after I did some research, you might have to do), my advice is to develop your code like you would (in multiple files) and just merge them at build time. I recommend using this batch script to do the merging for you

@echo off
 
rem The files foo, bar, and baz are just placeholders. To add your own files,
rem remove them from this list
set mergeList=foo.txt, bar.txt, baz.txt
 
rem The file all the other files merge to...
set outFile=qux.txt
 
del %outFile%
 
for %%a in (%mergeList%) do (
    echo Merging "%%a"...
    type %%a >> %outFile%
)

Edited by Gip-Gip, Sun Apr 2, 2017 11:41 AM.


#9 ExhaustinAustin OFFLINE  

ExhaustinAustin

    Combat Commando

  • Topic Starter
  • 5 posts

Posted Sun Apr 2, 2017 1:58 PM

 

 

If you have to keep it in a single file (which after I did some research, you might have to do), my advice is to develop your code like you would (in multiple files) and just merge them at build time. I recommend using this batch script to do the merging for you

@echo off
 
rem The files foo, bar, and baz are just placeholders. To add your own files,
rem remove them from this list
set mergeList=foo.txt, bar.txt, baz.txt
 
rem The file all the other files merge to...
set outFile=qux.txt
 
del %outFile%
 
for %%a in (%mergeList%) do (
    echo Merging "%%a"...
    type %%a >> %outFile%
)

Alright, I the merging method and got it working, hooray, now I'll just have to take the important parts of that document and transfer them over into the main game file when I'm done. (I also put in variable "e" that flips to 1 when joy0left and 2 when joy0right which will determine which side the idle sprite is facing depending on last button press)

 

It's not a necessity if there's no way around it, but is there a command that can set the speed of the character lower. The player is a sneaky burglar, so it doesn't make sense for him to make a mad dash across the playfield to get to his destination. 



#10 Gip-Gip OFFLINE  

Gip-Gip

    Chopper Commander

  • 210 posts
  • Location:Georgia, US

Posted Sun Apr 2, 2017 2:40 PM

It's not a necessity if there's no way around it, but is there a command that can set the speed of the character lower. The player is a sneaky burglar, so it doesn't make sense for him to make a mad dash across the playfield to get to his destination. 

 

No, but you can just wait to move the character







Also tagged with one or more of these keywords: noob, atari 2600, programming, issues

0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users