BASIC on CART Contest (BoCC)

[InfernalKeith]

Adam, the mockup of your game looks friggin' incredible. You've got graphical skills I'd give a stack of ZeroZap carts for. Maybe even a Yahtzee or two! Seriously, can't wait to see the game in action, that looks fantastic.

[Opry99er]

I'm writing a BASIC game to go into the pool of the great ones that are already started. I thought about how to draw my screen fast and easily without using HCHAR, and I decided to use strings... but I wasn't sure how long my strings could be in BASIC, so I tried the following program to test it. It just draws a checkerboard pattern...

 

10 CALL SCREEN(2)
100 CALL CLEAR
110 CALL CHAR(65,"FFFFFFFFFFFFFFFF")
120 A$="A A A A A A A A A A A A A A"
130 B$=" A A A A A A A A A A A A A "
140 FOR X=1 TO 12
150 PRINT A$
160 PRINT B$
170 NEXT X
175 CALL SCREEN(7)
180 GOTO 180

 

 

 

I decided to use uppercase letters so my strings don't look like this:

 

A$=CHR$(96)&CHR$(104)&CHR$96&CHR$(96)&CHR$(104)&CHR$96&CHR$(104)

 

 

This is not my gamescreen, just an example of how strings can be used to quickly draw the game screen. =) I'll post ACTUAL screenshots later on of my ACTUAL gamescreen. Just thought I'd post this in case someone wanted to use this method.

 

Edited November 16, 2010 by Opry99er

[jchase1970]

You might think strings could be the length of the entry line, or maybe a byte 256 characters, but oddly enough the max length is 272 characters. I don't know where the odd number comes from. But that means your string can store 9 lines. which means 3 strings can write a screen.

[unhuman]

Yep, that's how I made inaccurate invaders (although using display at) and it was pretty fast....

 

I'm writing a BASIC game to go into the pool of the great ones that are already started. I thought about how to draw my screen fast and easily without using HCHAR, and I decided to use strings... but I wasn't sure how long my strings could be in BASIC, so I tried the following program to test it. It just draws a checkerboard pattern...

 

10 CALL SCREEN(2)
100 CALL CLEAR
110 CALL CHAR(65,"FFFFFFFFFFFFFFFF")
120 A$="A A A A A A A A A A A A A A"
130 B$=" A A A A A A A A A A A A A "
140 FOR X=1 TO 12
150 PRINT A$
160 PRINT B$
170 NEXT X
175 CALL SCREEN(7)
180 GOTO 180

 

 

 

I decided to use uppercase letters so my strings don't look like this:

 

A$=CHR$(96)&CHR$(104)&CHR$96&CHR$(96)&CHR$(104)&CHR$96&CHR$(104)

 

 

This is not my gamescreen, just an example of how strings can be used to quickly draw the game screen. =) I'll post ACTUAL screenshots later on of my ACTUAL gamescreen. Just thought I'd post this in case someone wanted to use this method.

 

[sometimes99er]

You might think strings could be the length of the entry line, or maybe a byte 256 characters, but oddly enough the max length is 272 characters. I don't know where the odd number comes from. But that means your string can store 9 lines. which means 3 strings can write a screen.

Eh, try this then ...

 

100 A$=A$&"A"
110 PRINT LEN(A$);
120 GOTO 100

[Opry99er]

Here's an idea... I tried this just now and it seemed to work fine... you just have to be deadly accurate or you get junk...

 

Use Notepad++ to create your design like this...

 

 

Then take each line and backspace until you get long strings of A's and space characters... essentially taking 3 lines of "map" and compressing them down to 1.

 

 

In this way, you can design your map in notepad and then just add the line numbers. =) Probably not revolutionary, but something cool, nonetheless

[Opry99er]

Here's a screenshot of that parsing method.... code below.

 

 

 

10 CALL CLEAR
20 CALL SCREEN(2)
30 CALL CHAR(65,"44FF111111FF4444")

110 A$="AAAAAAAAAA  AAAAAAAAAAAAAAAAAAAAAAAAAA  AAAAAAAAAAAAAAAAAAAAAAAAAA            	AA"
120 B$="AAAAAAAAAA            	AAAAAAAAAAAAAAAAAAAAA  AA  AAAAAAAAAAAAAAAAAAAAAA  AA  AAA"
130 C$="AAAAAAAAAAAAAAAAAAA  AA  AAAAAAAAAAAAAAAAA   	AA  AAAAAAAAAAAAAAAAA   	AA  AAA"
140 D$="AAAAAAAAAAAAAA   	AA  AAAAAA              	AA  AAAAAA              	AA  AAA"
150 E$="AAAAAAAAAAAAAAAAAAAAAAA  AAAAAAAAAAAAAAAAAAAAAAAAAA  AAAA                    	AAA"
155 F$="A                    	AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"   
160 PRINT A$
170 PRINT B$
180 PRINT C$
190 PRINT D$
200 PRINT E$
210 PRINT F$
220 CALL SCREEN(7)
230 GOTO 230	

 

 

 

 

REMEMBER!!! your PRINT statement will only print 28 characters per line, so make sure when you are designing your maps in notepad, 28 per line. =)

Edited November 17, 2010 by Opry99er

[Opry99er]

100 A$=A$&"A"

110 PRINT LEN(A$);

120 GOTO 100

 

 

All the way to 255 and then it repeats.

[sometimes99er]

100 A$=A$&"A"

110 PRINT LEN(A$);

120 GOTO 100

All the way to 255 and then it repeats.

 

Yeah! Makes me think that strings can only hold 255 characters.

 

TIB continues silently whereas XB issues

 

* WARNING
 STRING TRUNCATED IN 100

[Bones-69]

Here is something interesting I found while experimenting in BASIC & XB. Given that I only write in XB, I have always been aware that there are speed advantages in producing random numbers in advance for programs. I usually do this as part of the initialisation in order to keep as much of the time consuming stuff outside of the actual program and then just call random numbers from arrays when required.

 

So I did the following test with the intention of measuring the actual advantage in BASIC and I was incredibly surprised there was ZERO advantage in doing the hard work first! In XB I can pick up a speed increase of 50% between the two routines below, but in BASIC it makes no difference whatsoever.

 

If anybody has any theories here as to what is going I would love to know! The real question is not why there are differences between the two routines in XB (I think this is obvious, producing random numbers is slower than calling a known value), but what is going on in BASIC to produce identical results in the two routines?

 

Bugger... All my little tricks that work in XB don't work in BASIC!

 

100 RANDOMIZE

110 INPUT "PRESS ENTER":A$

120 A=A+1

130 PRINT RND

140 IF A=100 THEN 160

150 GOTO 120

160 PRINT "TAKES 20 SECONDS IN BASIC AND 16 SECONDS IN XB"

170 DIM B(100)

180 A=0

190 A=A+1

200 B(A)=RND

210 IF A=100 THEN 230

220 GOTO 190

230 A=0

240 INPUT "PRESS ENTER TO RE-TEST":A$

250 A=A+1

260 PRINT B(A)

270 IF A=100 THEN 290

280 GOTO 250

290 PRINT "TAKES 20 SECONDS IN BASIC AND 10 SECONDS IN XB"

Edited November 17, 2010 by Bones-69

[sometimes99er]

Holy Moly. I was just about to believe there wasn't much difference in speed between the two.

 

I guess you had the 32K Memory Expansion connected ? XB will make use of it instead of VRAM, somewhere, so I guess that's the reason.

Edited November 17, 2010 by sometimes99er

[unhuman]

RESTORE command question... I'm sure I'm dreaming, but in the event of a failure, I want to re-draw / reset the level. Easiest way to do that is RESTORE the data for the level, but I want to do math to do that... Doesn't look possible... Ideas?

[jchase1970]

You might think strings could be the length of the entry line, or maybe a byte 256 characters, but oddly enough the max length is 272 characters. I don't know where the odd number comes from. But that means your string can store 9 lines. which means 3 strings can write a screen.

Eh, try this then ...

 

100 A$=A$&"A"
110 PRINT LEN(A$);
120 GOTO 100

 

 

DOH, addition error on my part, 9 lines and 3 characters doesn't =272. I was thinking 30 characters per line with made it 272 but it's 28*9+3 which is 255, that makes more sense.

REM LINE OF 28
10 A$="ABABABABABABABABABABABABABAB" 
REM NOW 3 LINES
20 A$=A$&A$&A$
REM NOW 9 LINES
30 A$=A$&A$&A$
REM PRINT 9 LINES
40 PRINT A$
45 PRINT
REM ADD 9 LINES TO IT
50 A$=A$&A$
REM BUT IT ONLY ADDS 3 CHARCTERS TO FILL STRING
60 PRINT A$

[jchase1970]

 

100 RANDOMIZE

110 INPUT "PRESS ENTER":A$

120 A=A+1

130 PRINT RND

140 IF A=100 THEN 160

150 GOTO 120

160 PRINT "TAKES 20 SECONDS IN BASIC AND 16 SECONDS IN XB"

170 DIM B(100)

180 A=0

190 A=A+1

200 B(A)=RND

210 IF A=100 THEN 230

220 GOTO 190

230 A=0

240 INPUT "PRESS ENTER TO RE-TEST":A$

250 A=A+1

260 PRINT B(A)

270 IF A=100 THEN 290

280 GOTO 250

290 PRINT "TAKES 20 SECONDS IN BASIC AND 10 SECONDS IN XB"

 

It's not the rnd that's slower it's the print

change 130 to PRINT A and it still takes 20 seconds.

[+adamantyr]

Some BASIC programming tips:

 

- One or two letter variables

- Subscripted variables are noticeably slower to work with. Better to move subscripted values into placeholders in a loop

- ALWAYS declare your subscripts in a DIM statement, otherwise BASIC will default-reserve 10 entries for each one

- Type up your code in a text editor first. This works way better than BASIC, which has lousy line number management tools

- Numeric variables consume 4 bytes each, try to reuse them as much as possible

- You can use this technique to set a lot of variables to the same value in one line: "A=B=C=0" But it's not stable... I had times when the first variable was initialized to -1

- DATA statements with RESTORE and loops is the most efficient way to initialize graphics, color, sound, and other data

- You can do some clever math tricks in IF/THEN statements, but the bigger they are the slower they will be. Keep the logic simple if you can

 

Cmon, let's see some BoCC projects announced, even if it's just a game idea without a screenshot! My intention with my game post was to inspire, not demoralize!

 

Adamantyr

Edited December 13, 2010 by adamantyr

[unhuman]

Cmon, let's see some BoCC projects announced, even if it's just a game idea without a screenshot! My intention with my game post was to inspire, not demoralize!

 

A=b=c=0 is crap don't recommend that

 

My game is good and will be released when done - first level works and 2nd is almost done - hopefully 30+ fit

Adamantyr

[+adamantyr]

Cmon, let's see some BoCC projects announced, even if it's just a game idea without a screenshot! My intention with my game post was to inspire, not demoralize!

 

A=b=c=0 is crap don't recommend that

 

My game is good and will be released when done - first level works and 2nd is almost done - hopefully 30+ fit

Adamantyr

 

Wow, I had no idea I planned 30 levels. (Need to clean up the quotes there, dude!)

 

Adamantyr

[+adamantyr]

RESTORE command question... I'm sure I'm dreaming, but in the event of a failure, I want to re-draw / reset the level. Easiest way to do that is RESTORE the data for the level, but I want to do math to do that... Doesn't look possible... Ideas?

 

I looked into this myself, RESTORE works with line numbers only, and they have to be statics, it won't accept variables or logical statements.

 

The technique I used was the following:

 

1000 ON L GOSUB 20000,20100
1010 REM LEVEL BUILDING CODE HERE
.
.
.
20000 RESTORE 30000
20010 RETURN
20100 RESTORE 30100
20110 RETURN
.
.
.
30000 REM DATA FOR LEVEL 1
30100 REM DATA FOR LEVEL 2

 

Adamantyr

[Opry99er]

Okay guys, I thought I'd go ahead and post my idea... It's sort of a borrowed idea from Karsten's daughter. =) I introduce you to "Chugger99", my train simulation. Nothing to this game, really... you're a train engineer who must collect several passengers from different stations. The "lights" next to the train pads where the people sit can either be "all on" or "all off", and if the lights aren't "on" you cannot collect the passengers. Your fuel supply goes down as you go through the game screen, and the only way to refill your fuel is to deposit passengers at the depot. If you run out of fuel, you lose. Still working on the game loop, but here's a screenshot.

 

I am planning on 5 levels with increasing difficulty. =)

 

Edited November 18, 2010 by Opry99er

[+adamantyr]

Okay guys, I thought I'd go ahead and post my idea... It's sort of a borrowed idea from Karsten's daughter. =) I introduce you to "Chugger99", my train simulation. Nothing to this game, really... you're a train engineer who must collect several passengers from different stations. The "lights" next to the train pads where the people sit can either be "all on" or "all off", and if the lights aren't "on" you cannot collect the passengers. Your fuel supply goes down as you go through the game screen, and the only way to refill your fuel is to deposit passengers at the depot. If you run out of fuel, you lose. Still working on the game loop, but here's a screenshot.

 

I am planning on 5 levels with increasing difficulty. =)

 

 

Looks cool!

 

Adamantyr

[unhuman]

Cmon, let's see some BoCC projects announced, even if it's just a game idea without a screenshot! My intention with my game post was to inspire, not demoralize!

 

A=b=c=0 is crap don't recommend that

 

My game is good and will be released when done - first level works and 2nd is almost done - hopefully 30+ fit

Adamantyr

 

Wow, I had no idea I planned 30 levels. (Need to clean up the quotes there, dude!)

 

Adamantyr

 

Stupid iPhone can't edit a decent amount properly.

[unhuman]

yeah, good idea. uses up a bit of room, however... I'll probably just store part of the levels that isn't static in memory and redraw that.... Probably cheaper than a multi-line solution like that, but that would work.

 

 

RESTORE command question... I'm sure I'm dreaming, but in the event of a failure, I want to re-draw / reset the level. Easiest way to do that is RESTORE the data for the level, but I want to do math to do that... Doesn't look possible... Ideas?

 

I looked into this myself, RESTORE works with line numbers only, and they have to be statics, it won't accept variables or logical statements.

 

The technique I used was the following:

 

1000 ON L GOSUB 20000,20100
1010 REM LEVEL BUILDING CODE HERE
.
.
.
20000 RESTORE 30000
20010 RETURN
20100 RESTORE 30100
20110 RETURN
.
.
.
30000 REM DATA FOR LEVEL 1
30100 REM DATA FOR LEVEL 2

 

Adamantyr

[InfernalKeith]

I like it! This looks like it could be a cool game. I remember seeing a few similar "route the trains" type games on the C64 back in the day... one may have been a kids' game starring Donald Duck, or I could be getting it mixed up with something else in my faulty memory.

 

Adam, you only "demoralize" us in the sense that you make this crap look so easy! I'm more frustrated by my lack of time than anything -- I wanna spend tonight just working on games, but I'm doing a big work thing and it's gotta be done tonight. There's never enough 'me time' to really spend a few hours working through code, taking the time to tweak graphics and sound effects, etc. This whole "adult" thing is for the birds sometimes...

 

I'm inspired by the work all you guys do, that's one of the biggest things I get out of this forum. I don't feel like my programs measure up to the general level of quality around here - I'm proud of my ideas, but I get bogged down in the execution. I know it'll get there, but it's a long process when you can't devote regular time to it.

 

Enough of that. More coding tonight, hopefully, after the work is done. If I can get a little more finished and actually decide on a name for my color-tile game, I'll start a thread for it tonight.

 

 

 

 

 

 

Okay guys, I thought I'd go ahead and post my idea... It's sort of a borrowed idea from Karsten's daughter. =) I introduce you to "Chugger99", my train simulation. Nothing to this game, really... you're a train engineer who must collect several passengers from different stations. The "lights" next to the train pads where the people sit can either be "all on" or "all off", and if the lights aren't "on" you cannot collect the passengers. Your fuel supply goes down as you go through the game screen, and the only way to refill your fuel is to deposit passengers at the depot. If you run out of fuel, you lose. Still working on the game loop, but here's a screenshot.

 

I am planning on 5 levels with increasing difficulty. =)

 

 

Looks cool!

 

Adamantyr

[unhuman]

HELP!!!! Running into a problem

 

10 I=1
11 V[i]=5
12 PRINT V[i]
13 PRINT V[1]
14 J=1
15 PRINT V[J]

 

results in

5
0
0

 

Why the hell do my indexes not work properly?

 

Err - maybe I need () instead of []

Edited November 19, 2010 by unhuman

[unhuman]

5 Levels complete! Need to get die / restart level working properly, but the levels all play properly. Now it's just encoding the level data for each level (and fixing that restart bug)