Jump to content
IGNORED

BASIC / XB Translator (TidBit)


matthew180

Recommended Posts

Code In:

CALL CLEAR
I=3
B:  PRINT "TI-99"
   CALL SCREEN(I)
   I=I+1
   CALL SOUND(100,440,30)
     IF I>15 THEN END
   GOTO B

Code Out:

100 CALL CLEAR
110 I=3
120 PRINT "TI-99"
130 CALL SCREEN(I)
140 I=I+1
150 CALL SOUND(100,440,30)
160 IF I>15 THEN END
170 GOTO 120

 

=) Kinda nice.... I don't know why I indented the way I did... but it worked anyway. Nice

Link to comment
Share on other sites

A nice write-up... courtesy of Wiki

 

 

 

In computer programming, an indent style is a convention governing the indentation of blocks of code to convey the program's structure. This article largely addresses the C programming language and its descendants, but can be (and frequently is) applied to most other programming languages (especially those in the curly bracket family). Indent style is just one aspect of programming style.

 

Indentation is not a requirement of most programming languages. Rather, programmers indent to better convey the structure of their programs to human readers. In particular, indentation is used to show the relationship between control flow constructs such as conditions or loops and code contained within and outside them. However, some programming languages (such as Python and Occam) use the indentation to determine the structure instead of using braces or keywords.

 

The size of the indent is usually independent of the style. Many early programs used tab characters for indentation, for simplicity and to save on source file size. Unix editors generally view tabs as equivalent to eight characters, while Macintosh and Microsoft Windows environments would set them to four, creating confusion when code was transferred back and forth. Modern programming editors are now often able to set arbitrary indentation sizes, and will insert the appropriate combination of spaces and tabs.

 

The topic issue of using hard tabs or spaces is an ongoing debate in the programming community. Some programmers such as Jamie Zawinski[1] feel that spaces instead of tabs increase cross-platform functionality. Others[who?] believe the opposite, that hard tabs increase cross-platform functionality.

 

There are a number of computer programs that automatically correct indent styles as well as the length of tabs. A famous one among them is indent, a program included with many Unix-like operating systems. These programs work best for those who use an indent style close to that considered "proper" by their programmers; those who use other styles will more likely become frustrated. Furthermore, indent has only been updated once in the past 6 years and does not work well either with C++ or GNU extensions to C.

 

 

 

Edited by Opry99er
Link to comment
Share on other sites

Here was a quick and dirty success for me. =) Just a mockup to see what a menu might look like

 

Code In:


REM PROGRAM START
A: CALL CLEAR
  DISPLAY AT(1,4):"THIS IS A MENU TEST";"FOR BERYL REICHARDT";
  DISPLAY AT(8,1):"PRESS 1 FOR WEAPONS";"PRESS 2 FOR STATS";"PRESS 3 TO EXIT";
K: CALL KEY(0,K,S):: IF S=0 THEN GOTO K
  ON K-48 GOTO W,S,E
W: CALL CLEAR :: PRINT "WEAPONS" :: PRINT "PRESS ENTER TO EXIT"
W1:  CALL KEY(0,K,S):: IF S=0 THEN GOTO W1
  IF K=13 THEN GOTO A ELSE W
  
S: CALL CLEAR :: PRINT "STATS" :: PRINT "PRESS ENTER TO EXIT"
S1: CALL KEY(0,K,S):: IF S=0 THEN GOTO S1
  IF K=13 THEN GOTO A ELSE S

E: CALL CLEAR :: PRINT "THANK YOU"
  CALL SOUND(1000,440,30)
  END




Code Out:

100 REM PROGRAM START
110 CALL CLEAR
120 DISPLAY AT(1,4):"THIS IS A MENU TEST";"FOR BERYL REICHARDT";
130 DISPLAY AT(8,1):"PRESS 1 FOR WEAPONS";"PRESS 2 FOR STATS";"PRESS 3 TO EXIT";
140 CALL KEY(0,K,S):: IF S=0 THEN GOTO 140
150 ON K-48 GOTO 160,190,220
160 CALL CLEAR :: PRINT "WEAPONS" :: PRINT "PRESS ENTER TO EXIT"
170 CALL KEY(0,K,S):: IF S=0 THEN GOTO 170
180 IF K=13 THEN GOTO 110 ELSE 160
190 CALL CLEAR :: PRINT "STATS" :: PRINT "PRESS ENTER TO EXIT"
200 CALL KEY(0,K,S):: IF S=0 THEN GOTO 200
210 IF K=13 THEN GOTO 110 ELSE 190
220 CALL CLEAR :: PRINT "THANK YOU"
230 CALL SOUND(1000,440,30)
240 END

Link to comment
Share on other sites

Hey Matthew... quick question. I tried to input the following:

 

  A=1
B  PRINT A:
  A=A+1
  GOTO B

 

and received the following code output:

 

100 A=1
110 B  PRINT A:
120 A=A+1
130 GOTO B

Labels have to be on their own lines as the first non-whitespace characters, and end with a colon, So, your code should have been

  A=1
  B: 
  PRINT A
  A=A+1
  GOTO B

To generate

100 A=1
110 PRINT A
120 A=A+1
130 GOTO 110

Then I tried using a number for a "label" instead of B and the following was the resulting code:

 

Code In:

  A=1
1  PRINT A:
  A=A+1
  GOTO 1

Code Out:

100 A=1
1 PRINT A:
11 A=A+1
21 GOTO 1

In the new revision, the explicit line number resets the line number counter in the converter, which allows you to define the code following as starting at a specific line number.

 

 

*** Edit: I stand corrected about the label needing to be on its own line. That is pretty nifty. Yes, this thing is cool, and I am working to convert some of my re-write listings to work with it.

Edited by OLD CS1
Link to comment
Share on other sites

I'm glad you guys are enjoying it. Sorry Owen, I was not online when you were having your problems. I'm glad you got it sorted out. I think your indentation style is heavily influenced from assembly language. :)

 

Leading and trailing white space is not considered, and before any processing happens on a line, all white space is trimmed from both ends. If you "define" a label, it has to be the first token on a line and end with a single colon. You can use A-Z, a-z, 0-9, - (hyphen), and _ (underscore). Labels *are* case sensitive and have no *practical* length, however I would not really go too crazy, after all, you have to type them. Currently labels are global.

 

I do need to get the latest changes documented though. There is support for line numbers now, as CS1 pointed out (and as you accidentally discovered, Owen) they force the internal line number counter to the specified line number. There is no checking that your line number is valid. Remember, this is ONLY a translator, there is NO syntax checking going on here. I could add all that, but then it would be too much like a real language, so I might as well spend my time *making* a real language instead. ;)

 

This may be my new development platform... how freakin cool is this thing?!

 

I'll be up all night on this damn translator... thanks alot, Matthew. My wife is already on my ass to get off the computer... but I'm having too much fun. =)

 

You're welcome.

 

1 PRINT A:

I put the colon AFTER the "PRINT A" instead of after "1"... I've since sorted it all out. =)

 

Actually, that is a valid BASIC statement, and that is the reason XB uses a double colon for its multi-line operator, instead of a single colon like every other BASIC of the day. It is also the reason if you use multiple colons after a PRINT statement, that you have to separate them out.

// This works in BASIC, but not XB
PRINT:::::

// You have to do this in XB
PRINT: : : : :

 

The trailing colon in a PRINT statement does something, but I can't remember. The semi-colon suppresses the newline I think. It was a stupid idea to double-up the colon token like that. Personally I would have changed the PRINT statement, but hey, I'm not writing an XB interpreter, so I don't have to worry about it. :)

Edited by matthew180
Link to comment
Share on other sites

Line numbers are supported... Does this mean I can paste in a pre-existing program (say, my current RPG demo) and use the translator to add in the menu system? For instance, I had planned to do the menu system with your translator and then sequence it to drop it into my pre-existing program... but if line numbers are supported, I could drop the whole shebang into TIdBiT and it'll integrate it for me?

 

The reason I want to do this is that all the variables I will be using exist in the main program, so for me to test the validity of my program, I would need those variables to be included... I couldn't do it without them. I was planning on doing it all step-by-step and manually transfer over code bit by bit (no pun intended), but if I could just write all my source as a hybrid of line numbers and TIdBiT translation and paste it in and convert, it would make my life so much easier. =) I could be very abstract and coding would be so much faster!!!

Link to comment
Share on other sites

This for instance....

 

This is a chunk of my code... Notice after line 3030, the code gets into the abstract menu system... is this allowed?

 

 

210 REM       Beginning of main game loop
220 CALL SETMAP(MX,MY)

230 REM       CHARACTER ON SCREEN
240 DISPLAY AT(PX,PY):CHR$(42);

250 REM       KEYBOARD SCAN
260 CALL KEY(0,K,S) :: IF S=0 THEN 260

270 REM   must add 2 to each X and Y to compensate for the DISPLAY/GCHAR offset
280 IF K=69 THEN CALL GCHAR(PX-1,PY+2,Q) :: IF Q>104 THEN 260 ELSE PX=PX-1 :: GOTO 330
290 IF K=83 THEN CALL GCHAR(PX,PY+1,Q) :: IF Q>104 THEN 260 ELSE PY=PY-1 :: GOTO 330
300 IF K=68 THEN CALL GCHAR(PX,PY+3,Q) :: IF Q>104 THEN 260 ELSE PY=PY+1 :: GOTO 330
310 IF K=88 THEN CALL GCHAR(PX+1,PY+2,Q) :: IF Q>104 THEN 260 ELSE PX=PX+1 :: GOTO 330

314 REM THIS IS THE "EXAMINE" SUB
315 IF K=32 THEN GOSUB 2000
320 GOTO 260


330 REM       this determines the boundaries onscreen and sets the map to be drawn by assembly routine
340 REM       PX, PY are the current player's position on the screen
350 REM       MX, MY are the designations for which map will be drawn
360 IF PX<11 THEN PX=22 :: MY=MY-1 :: GOTO 400
370 IF PX>22 THEN PX=11 :: MY=MY+1 :: GOTO 400
380 IF PY<1 THEN PY=28 :: MX=MX-1 :: GOTO 400
390 IF PY>28 THEN PY=1 :: MX=MX+1 :: GOTO 400
400 IF MX<1 THEN MX=1 ELSE IF MX>2 THEN MX=2
410 IF MY<1 THEN MY=1 ELSE IF MY>6 THEN MY=6
420 GOTO 220


2000 REM "EXAMINE"
2010 DISPLAY AT(1,1):"WHICH DIRECTION?";
2015 CALL KEY(0,K,S) :: IF S=0 THEN 2015
2020 IF K=69 THEN CALL GCHAR(PX-1,PY+2,Q):: IF Q=115 THEN GOTO 3000 ELSE DISPLAY AT(1,1):"                "; :: RETURN
2030 IF K=83 THEN CALL GCHAR(PX,PY+1,Q):: IF Q=115 THEN GOTO 3000 ELSE DISPLAY AT(1,1):"                "; :: RETURN
2040 IF K=68 THEN CALL GCHAR(PX,PY+3,Q):: IF Q=115 THEN GOTO 3000 ELSE DISPLAY AT(1,1):"                "; :: RETURN
2050 IF K=88 THEN CALL GCHAR(PX+1,PY+2,Q):: IF Q=115 THEN GOTO 3000 ELSE DISPLAY AT(1,1):"                "; :: RETURN
2055 GOTO 2015
3000 DISPLAY AT(1,1):"YOU FOUND A BROADSWORD";"ADD TO INVENTORY? (Y/N)";
3010 CALL KEY(0,K,S) :: IF S=0 THEN 3010
3015 IF K=89 THEN DISPLAY AT(1,1):"                      ";"                       ";:: RETURN
3020 IF K=78 THEN DISPLAY AT(1,1):"                      ";"                       ";:: RETURN
3030 GOTO 3010


REM MENU
  FOR I=2 TO 14 :: CALL COLOR(I,16,1):: NEXT I
A: CALL CLEAR :: CALL SCREEN(2)
  DISPLAY AT(1,4):"THIS IS A MENU TEST";"   FOR BERYL REICHARDT";
  DISPLAY AT(8,1):"PRESS 1 FOR WEAPONS";"PRESS 2 FOR STATS";"PRESS 3 TO EXIT";
K: CALL KEY(0,K,S):: IF S=0 THEN GOTO K
  IF K>51 THEN GOTO K ELSE IF K<49 THEN GOTO K
  ON K-48 GOTO W,S,E
W: CALL CLEAR :: PRINT "WEAPONS" :: PRINT "PRESS ENTER TO EXIT"
W1:  CALL KEY(0,K,S):: IF S=0 THEN GOTO W1
  IF K=13 THEN GOTO A ELSE W
  
S: CALL CLEAR :: PRINT "STATS" :: PRINT "PRESS ENTER TO EXIT"
S1: CALL KEY(0,K,S):: IF S=0 THEN GOTO S1
  IF K=13 THEN GOTO A ELSE S

E: CALL CLEAR :: PRINT "THANK YOU"
  CALL SOUND(1000,440,30)
  END

9000 REM       **END MAIN GAME LOOP**



9500 REM       **SUB TO CALL THE ASSEMBLY ROUTINE TO LOAD MAP INTO MEMORY**
10000 SUB LDAT
10010 CALL INIT
10020 CALL LOAD("DSK1.NEWFORO")
10030 SUBEND

 

 

Link to comment
Share on other sites

Why not try it and not wait for an answer...

 

But yeah, if I can come up with a good iteration scheme - this could save lots of time, for sure. I spend a lot of time manually renumbering stuff if my 10 line # increments get jammed full of crap I didn't anticipate. Happened a LOT with BloxoTIz - probably due more to single statement lines (and their convoluted language requirements) than a real reason... But still.

 

-H

 

Line numbers are supported... Does this mean I can paste in a pre-existing program (say, my current RPG demo) and use the translator to add in the menu system? For instance, I had planned to do the menu system with your translator and then sequence it to drop it into my pre-existing program... but if line numbers are supported, I could drop the whole shebang into TIdBiT and it'll integrate it for me?

 

The reason I want to do this is that all the variables I will be using exist in the main program, so for me to test the validity of my program, I would need those variables to be included... I couldn't do it without them. I was planning on doing it all step-by-step and manually transfer over code bit by bit (no pun intended), but if I could just write all my source as a hybrid of line numbers and TIdBiT translation and paste it in and convert, it would make my life so much easier. =) I could be very abstract and coding would be so much faster!!!

Edited by unhuman
Link to comment
Share on other sites

The trailing colon in a PRINT statement does something, but I can't remember. The semi-colon suppresses the newline I think. It was a stupid idea to double-up the colon token like that. Personally I would have changed the PRINT statement, but hey, I'm not writing an XB interpreter, so I don't have to worry about it. :)

 

It prints a blank line after the print contents. One blank line for each colon.

PRINT A::::

in TI BASIC would print the value of A, then scroll up four lines. To my recollection, TI BASIC (and XB when the colons are separated by a space) is the only BASIC language which does this.

Link to comment
Share on other sites

Owen: The quick answer: Yes. Check out post #49 (the last post before you started posting last night... ;) )

 

http://www.atariage.com/forums/topic/172765-basic-xb-translator/page__view__findpost__p__2208860

 

If a line starts with a line number, it will be retained and force the internal counter to become that line number. So you can mix and match sections of code with and without line numbers. OLD CS1 wanted that feature to be able to have subroutines at specific line numbers (although with a totally "label-based" program, I'm not sure why it matters... But hey, who am I to question the needs of the uses?? :) )

 

I realized this was actually a good change since it would allow you to start with an existing program and change it gradually as you removed line numbers.

 

Oh, buy the way, DO NOT make a label with an internal BASIC keyword. Well, I suppose you can, but it will be your headache. Like I said, this is just a translator, not a parser, and it will let you shoot yourself in the foot.

Edited by matthew180
Link to comment
Share on other sites

By the way Owen, I would recommend a "block" indentation style. I really helps you see the flow of a program. There is also a pseudo token "ENDIF" that you can use to help with visualization. So you can do something like this (with XB anyway):

// Do something useless...
X=1

FOR I=1 TO 10

   IF X=1 THEN ..
     PRINT "X IS 1" :: ..
     X=2 :: ..
     PRINT "X IS NOW 2"
   ENDIF

   PRINT "X IS NOT 1, X IS ";
   PRINT X

NEXT I

 

Give that a whirl.

 

Hmm, actually, that will work, but there seems to be a new bug in the translator when I added some recent features. The double-colons are missing from the translation. I'll get that fixed. I will work though.

 

EDIT:

Actually I don't have a bug. I just forgot that you will have to include the double-colon where necessary (which I added to the code above.) The double-period is simply a line join token for the parser.

Edited by matthew180
Link to comment
Share on other sites

OLD CS1 wanted that feature to be able to have subroutines at specific line numbers (although with a totally "label-based" program, I'm not sure why it matters... But hey, who am I to question the needs of the uses?? :) )

 

I realized this was actually a good change since it would allow you to start with an existing program and change it gradually as you removed line numbers.

 

Yuppers. Plus, in an all-structured BASIC, like AmigaBasic or GFA Basic, line numbers would be irrelevant. But since the ultimate TI BASIC program will have them, I find it handy sometimes to know exactly where specific blocks are located for recoding on-the-fly, troubleshooting, etc.

 

(Read as, the control freak wants to manipulate the output :))

Edited by OLD CS1
Link to comment
Share on other sites

I'm doing all my coding in Notepad++.... then just pasting right into TIdBiT. My source is very easy to read and the labels are just awesome. Some of the things I like about assembly are in this... no line numbers being #1. =) And I like being able to address or reference a label elsewhere in the code. So much cleaner than the spaghetti that always ends up occuring tying dozens of lines of XB code together... the output code that TIdBiT throws out is interesting as well... I would have never put all those GOTO statements in my code, but that's just because it's not very understandable... It works perfectly, and I'm confident that (because it is such a direct translation) the code is quite efficient.

Link to comment
Share on other sites

I don't have a bug, as I thought in post #64. You still have to include the double-colon where necessary. The double-period is simply a "line join" token for the translator.

 

Owen, you might want to take a look at post #8

 

http://www.atariage.com/forums/topic/172765-basic-xb-translator/page__view__findpost__p__2141606

 

I converted my Hunt-Kill Maze to a line-number-less version, with indentation and comments. The only difference is, now the triple-period is only a double-period. You might get some formatting ideas as to what you can do.

Edited by matthew180
Link to comment
Share on other sites

I'm afraid the trailing periods are escaping me right now... I'll keep re-reading. =)

 

I like the formatting of that HK maze source code. Very interesting. =) Learning more and more as I read and experiment. The TIdBiT page hasn't been out of my browser window since yesterday, BTW.

 

Hmmm... TIdBiT

 

(T)exas (I)nstruments .d. (B)ASIC .i. (T)ranslator

 

I didn't make that connection on the name til just now. =)

Link to comment
Share on other sites

I would have never put all those GOTO statements in my code, but that's just because it's not very understandable... It works perfectly, and I'm confident that (because it is such a direct translation) the code is quite efficient.

 

Well, in reality you *are* putting all those GOTO statements on your code. They are just "readable" labels now instead of "number" labels. However, GOTO, i.e. an unconditional jump, is in every language and an essential part of a computer. You just have to take the responsibility to use them in a logical and structured way.

 

Any logical looping construct can be broken down into a conditional jump, followed by an unconditional jump, and you always need two labels (a loop point and a break point.) However, most languages wrap those details up into statements like WHILE (WEND), FOR (NEXT), DO (UNTIL), SWITCH-CASE, etc. and give you alternative names for GOTO like BREAK and CONTINUE. Don't get me wrong, I'm a proponent of those constructs, but I think people bash BASIC too hard because it lacks some of those (old BASIC dialects anyway.) You can write crap spaghetti code in any language.

 

The main ideas with TidBit was to allow indentation, heavy commenting, labels instead of line numbers, and some semblance of block structure. It is still BASIC or XB though, but it is funny how viewing it in a new way makes you understand the code better and be more efficient.

 

You know, C++ started as just a preprocessor to a C compiler. :)

Link to comment
Share on other sites

I'm afraid the trailing periods are escaping me right now... I'll keep re-reading. =)

 

They just let you brake a line. In BASIC, and XB with the double-colon, every statement has to be a single line. That in a pain in the ass for readability. The double-period simply lets you put those statements on lines of their own in your source, and they will be joined back up into a single line.

// This
X=1 ::
Y=2

// Becomes
X=1::Y=2

// I think this is easier to read
FOR I=0 TO SX+1 ::
MAZE(I,0)=-1 ::
MAZE(I,SY+1)=-1 ::
NEXT I

// Than this
FOR I=0 TO SX+1 :: MAZE(I,0)=-1 :: MAZE(I,SY+1)=-1 :: NEXT I

 

And, I made a mistake again. If your line "ends with" a double-colon, you don't need the double-period. The translator will join them automatically. You only need the double-period when you need to join a line that does not end with a double-colon, like after a THEN.

// In
IF RESET=0 THEN ..
   HX=I ::
   HY=J ..
ELSE ..
   HX=1 ::
   HY=1
ENDIF

// Out
IF RESET=0 THEN HX=I :: HY=J ELSE HX=1 :: HY=1


// In
IF (MAZE(X,Y) AND 4)=4 THEN ..
   IF C=98 THEN ..
       C=96 ..
   ELSE ..
       C=97
   ENDIF
ENDIF

// Out
IF (MAZE(X,Y) AND 4)=4 THEN IF C=98 THEN C=96 ELSE C=97

Link to comment
Share on other sites

Normally I use SUBs and GOSUBs which make for a more logical and "human-readable" program listing, but speed is sacrificed.... The labels make me re-think GOTO and not be so afraid of it. :) While the output code might not be as compartmentalized as something I would write, it certainly will be faster!!! Very direct, using labels.... :)

 

I'm thrilled that this program exists--- if for no other reason--- because it has forced me to rething BASIC a bit. :)

 

Thanks for the explanation of the trailing ".." - It makes sense and makes me like this even more. :)

Link to comment
Share on other sites

Okay... tried implementing the whole thing in with line numbers, labels, the whole shebang.

 

Here is the code I inputted

 

 

 

100 REM    LINK UP TO LOAD DATA INTO MEMORY
110 CALL LDAT
111 REM       DESIGNATE MAP AND CHARACTER START POINT
112 MX=1 :: MY=1
113 PX=18 :: PY=8
200 CALL CHAR(42,"193DD9FFD91924C3") :: CALL COLOR(2,15,1)

120 REM       SET UP SCREEN AND BORDER FOR EXPLORATION
130 CALL CLEAR
140 CALL SCREEN(2)
150 CALL HCHAR(9,1,101,32) :: CALL HCHAR(24,1,101,32) :: CALL VCHAR(9,1,97,16) :: CALL VCHAR(9,32,97,16)
160 CALL HCHAR(9,1,98) :: CALL HCHAR(9,32,100) :: CALL HCHAR(24,1,99) :: CALL HCHAR(24,32,96)

210 REM       Beginning of main game loop
220 CALL SETMAP(MX,MY)

230 REM       CHARACTER ON SCREEN
240 DISPLAY AT(PX,PY):CHR$(42);

250 REM       KEYBOARD SCAN
260 CALL KEY(0,K,S) :: IF S=0 THEN 260

270 REM   must add 2 to each X and Y to compensate for the DISPLAY/GCHAR offset
280 IF K=69 THEN CALL GCHAR(PX-1,PY+2,Q) :: IF Q>104 THEN 260 ELSE PX=PX-1 :: GOTO 330
290 IF K=83 THEN CALL GCHAR(PX,PY+1,Q) :: IF Q>104 THEN 260 ELSE PY=PY-1 :: GOTO 330
300 IF K=68 THEN CALL GCHAR(PX,PY+3,Q) :: IF Q>104 THEN 260 ELSE PY=PY+1 :: GOTO 330
310 IF K=88 THEN CALL GCHAR(PX+1,PY+2,Q) :: IF Q>104 THEN 260 ELSE PX=PX+1 :: GOTO 330

314 REM THIS IS THE "EXAMINE" SUB
315 IF K=32 THEN GOSUB 2000
316 IF K=77 THEN GOTO 3040
320 GOTO 260


330 REM       this determines the boundaries onscreen and sets the map to be drawn by assembly routine
340 REM       PX, PY are the current player's position on the screen
350 REM       MX, MY are the designations for which map will be drawn
360 IF PX<11 THEN PX=22 :: MY=MY-1 :: GOTO 400
370 IF PX>22 THEN PX=11 :: MY=MY+1 :: GOTO 400
380 IF PY<1 THEN PY=28 :: MX=MX-1 :: GOTO 400
390 IF PY>28 THEN PY=1 :: MX=MX+1 :: GOTO 400
400 IF MX<1 THEN MX=1 ELSE IF MX>2 THEN MX=2
410 IF MY<1 THEN MY=1 ELSE IF MY>6 THEN MY=6
420 GOTO 220


2000 REM "EXAMINE"
2010 DISPLAY AT(1,1):"WHICH DIRECTION?";
2015 CALL KEY(0,K,S) :: IF S=0 THEN 2015
2020 IF K=69 THEN CALL GCHAR(PX-1,PY+2,Q):: IF Q=115 THEN GOTO 3000 ELSE DISPLAY AT(1,1):"                "; :: RETURN
2030 IF K=83 THEN CALL GCHAR(PX,PY+1,Q):: IF Q=115 THEN GOTO 3000 ELSE DISPLAY AT(1,1):"                "; :: RETURN
2040 IF K=68 THEN CALL GCHAR(PX,PY+3,Q):: IF Q=115 THEN GOTO 3000 ELSE DISPLAY AT(1,1):"                "; :: RETURN
2050 IF K=88 THEN CALL GCHAR(PX+1,PY+2,Q):: IF Q=115 THEN GOTO 3000 ELSE DISPLAY AT(1,1):"                "; :: RETURN
2055 GOTO 2015
3000 DISPLAY AT(1,1):"YOU FOUND A BROADSWORD";"ADD TO INVENTORY? (Y/N)";
3010 CALL KEY(0,K,S) :: IF S=0 THEN 3010
3015 IF K=89 THEN DISPLAY AT(1,1):"                      ";"                       ";:: RETURN
3020 IF K=78 THEN DISPLAY AT(1,1):"                      ";"                       ";:: RETURN
3030 GOTO 3010


REM MENU
  
A: CALL CLEAR :: CALL SCREEN(2)
  DISPLAY AT(1,4):"THIS IS A MENU TEST";"   FOR BERYL REICHARDT";
  DISPLAY AT(8,1):"PRESS 1 FOR WEAPONS";"PRESS 2 FOR STATS";"PRESS 3 TO EXIT";
K: CALL KEY(0,K,S):: IF S=0 THEN GOTO K
  IF K>51 THEN GOTO K ELSE IF K<49 THEN GOTO K
  ON K-48 GOTO W,S,E
W: CALL CLEAR :: PRINT "WEAPONS" :: PRINT "PRESS ENTER TO EXIT"
W1:  CALL KEY(0,K,S):: IF S=0 THEN GOTO W1
  IF K=13 THEN GOTO A ELSE W
  
S: CALL CLEAR :: PRINT "STATS" :: PRINT "PRESS ENTER TO EXIT"
S1: CALL KEY(0,K,S):: IF S=0 THEN GOTO S1
  IF K=13 THEN GOTO A ELSE S

E: CALL CLEAR :: GOTO 150

9000 REM       **END MAIN GAME LOOP**



9500 REM       **SUB TO CALL THE ASSEMBLY ROUTINE TO LOAD MAP INTO MEMORY**
10000 SUB LDAT
10010 CALL INIT
10020 CALL LOAD("DSK1.NEWFORO")
10030 SUBEND


10040 REM       **SUB TO DRAW THE MAP ONSCREEN**
10050 SUB SETMAP(MX,MY)
10060 X=MX :: Y=MY
10070 IF ADR<>0 THEN 10100
10080 CALL PEEK(16382,P,Q)
10090 ADR=P*256+Q+2
10100 Y=Y-1 :: MAP=Y*2+X
10110 IF MAP<1 OR MAP>12 THEN SUBEXIT
10120 CALL LOAD(ADR,0,MAP)
10130 CALL LINK("DRAW")
10140 SUBEND

 

 

 

And here's what I got

 

 

 


100 REM    LINK UP TO LOAD DATA INTO MEMORY
110 CALL LDAT
111 REM       DESIGNATE MAP AND CHARACTER START POINT
112 MX=1 :: MY=1
113 PX=18 :: PY=8
120 REM       SET UP SCREEN AND BORDER FOR EXPLORATION
130 CALL CLEAR
140 CALL SCREEN(2)
150 CALL HCHAR(9,1,101,32):: CALL HCHAR(24,1,101,32):: CALL VCHAR(9,1,97,16):: CALL VCHAR(9,32,97,16)
160 CALL HCHAR(9,1,98):: CALL HCHAR(9,32,100):: CALL HCHAR(24,1,99):: CALL HCHAR(24,32,96)
200 CALL CHAR(42,"193DD9FFD91924C3"):: CALL COLOR(2,15,1)


210 REM       Beginning of main game loop
220 CALL SETMAP(MX,MY)


230 REM       CHARACTER ON SCREEN
240 DISPLAY AT(PX,PY):CHR$(42);



250 REM       KEYBOARD SCAN
260 CALL KEY(0,K,S):: IF S=0 THEN 260
270 REM   must add 2 to each X and Y to compensate for the DISPLAY/GCHAR offset
280 IF K=69 THEN CALL GCHAR(PX-1,PY+2,Q):: IF Q>104 THEN 260 ELSE PX=PX-1 :: GOTO 330
290 IF K=83 THEN CALL GCHAR(PX,PY+1,Q):: IF Q>104 THEN 260 ELSE PY=PY-1 :: GOTO 330
300 IF K=68 THEN CALL GCHAR(PX,PY+3,Q):: IF Q>104 THEN 260 ELSE PY=PY+1 :: GOTO 330
310 IF K=88 THEN CALL GCHAR(PX+1,PY+2,Q):: IF Q>104 THEN 260 ELSE PX=PX+1 :: GOTO 330
314 REM THIS IS THE "EXAMINE" SUB
315 IF K=32 THEN GOSUB 2000
316 IF K=77 THEN GOTO 3040
320 GOTO 260

**END KSCAN HERE, GO BACK TO TOP**



330 REM       this determines the boundaries onscreen and sets the map to be drawn by assembly routine
340 REM       PX, PY are the current player's position on the screen
350 REM       MX, MY are the designations for which map will be drawn
360 IF PX<11 THEN PX=22 :: MY=MY-1 :: GOTO 400
370 IF PX>22 THEN PX=11 :: MY=MY+1 :: GOTO 400
380 IF PY<1 THEN PY=28 :: MX=MX-1 :: GOTO 400
390 IF PY>28 THEN PY=1 :: MX=MX+1 :: GOTO 400
400 IF MX<1 THEN MX=1 ELSE IF MX>2 THEN MX=2
410 IF MY<1 THEN MY=1 ELSE IF MY>6 THEN MY=6
420 GOTO 220



2000 REM "EXAMINE"
2010 DISPLAY AT(1,1):"WHICH DIRECTION?";
2015 CALL KEY(0,K,S):: IF S=0 THEN 2015
2020 IF K=69 THEN CALL GCHAR(PX-1,PY+2,Q):: IF Q=115 THEN GOTO 3000 ELSE DISPLAY AT(1,1):"                ";:: RETURN
2030 IF K=83 THEN CALL GCHAR(PX,PY+1,Q):: IF Q=115 THEN GOTO 3000 ELSE DISPLAY AT(1,1):"                ";:: RETURN
2040 IF K=68 THEN CALL GCHAR(PX,PY+3,Q):: IF Q=115 THEN GOTO 3000 ELSE DISPLAY AT(1,1):"                ";:: RETURN
2050 IF K=88 THEN CALL GCHAR(PX+1,PY+2,Q):: IF Q=115 THEN GOTO 3000 ELSE DISPLAY AT(1,1):"                ";:: RETURN
2055 GOTO 2015
3000 DISPLAY AT(1,1):"YOU FOUND A BROADSWORD";"ADD TO INVENTORY? (Y/N)";
3010 CALL KEY(0,K,S):: IF S=0 THEN 3010
3015 IF K=89 THEN DISPLAY AT(1,1):"                      ";"                       ";:: RETURN
3020 IF K=78 THEN DISPLAY AT(1,1):"                      ";"                       ";:: RETURN
3030 GOTO 3010



3040 REM MENU
3050 CALL CLEAR :: CALL SCREEN(2)
3060 DISPLAY AT(1,4):"THIS IS A MENU TEST";"   FOR BERYL REICHARDT";
3070 DISPLAY AT(8,1):"PRESS 1 FOR WEAPONS";"PRESS 2 FOR STATS";"PRESS 3 TO EXIT";
3080 CALL KEY(0,K,S):: IF S=0 THEN GOTO 3080
3090 IF K>51 THEN GOTO 3080 ELSE IF K<49 THEN GOTO 3080
3100 ON K-48 GOTO 3110,3140,3170
3110 CALL CLEAR :: PRINT "WEAPONS" :: PRINT "PRESS ENTER TO EXIT"
3120 CALL KEY(0,K,S):: IF S=0 THEN GOTO 3120
3130 IF K=13 THEN GOTO 3050 ELSE 3110
3140 CALL CLEAR :: PRINT "STATS" :: PRINT "PRESS ENTER TO EXIT"
3150 CALL KEY(0,K,S):: IF S=0 THEN GOTO 3150
3160 IF K=13 THEN GOTO 3050 ELSE 3140
3170 CALL CLEAR :: GOTO 150



9000 REM       **END GAME LOOP**
9100 REM SUBS BELOW


9500 REM       **SUB TO CALL THE ASSEMBLY ROUTINE TO LOAD MAP INTO MEMORY**
10000 SUB LDAT
10010 CALL INIT
10020 CALL LOAD("DSK1.NEWFORO")
10030 SUBEND

10040 REM       **SUB TO DRAW THE MAP ONSCREEN**
10050 SUB SETMAP(MX,MY)
10060 X=MX :: Y=MY
10070 IF ADR<>0 THEN 10100
10080 CALL PEEK(16382,P,Q)
10090 ADR=P*256+Q+2
10100 Y=Y-1 :: MAP=Y*2+X
10110 IF MAP<1 OR MAP>12 THEN SUBEXIT
10120 CALL LOAD(ADR,0,MAP)
10130 CALL LINK("DRAW")
10140 SUBEND

 

 

 

 

BRAVO!!!!!!

Edited by Opry99er
Link to comment
Share on other sites

Made a little TIdBiT demo video. =) Hope you all enjoy...

 

***Warning***

This video looks much better full screen, so open it up in a browser window so you can see the text. My screen capture program is set to save at a low resolution, so it won't be very legible without watching it full-screen.

 

Also, the audio is REALLY quiet for some reason. It wasn't this quiet in my video editor, but somehow it's really quiet on YouTube.

 

http://www.youtube.com/watch?v=NBq_yL9M3M0

Edited by Opry99er
Link to comment
Share on other sites

That was actually a delightfully laid back insight video. You got a wonderful deeper voice. And I do understand you wanting Mark to put some voice to your game. He's got a wonderful dialect.

 

It seems like things are moving along on many fronts. The graphics are getting better and more detailed, and there's more interaction. I know you've done a lot of designing and planning behind the scenes, but I like how you communicate the next few steps, some obtainable goals, and tries to implement.

 

The big tree seems a little out of place, both in style and size. I think you should loose it, your own style is coming together nicely.

 

Concerning the examine functionality. I would rather just "walk over" an object, and then be asked if I'd like to pick up. Maybe even just a sound if my backpack is not full. Maybe the opponents can be attacked by "walk over", and in some instances, they (the opponents) won't allow you to pass within a certain distance (without battle).

 

:cool:

Edited by sometimes99er
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...