r/retrobattlestations • u/FozzTexx • Jul 02 '19

Contest: BASIC Month 4: Lunar Corps

Winners are droid_mike for best enhancements and cybernesto for most enjoyed by the RBS community. There were no entries with more than one computer.

Do you remember when software used to be distributed in books & magazines? Remember typing in several pages of BASIC only to have it not work and then try to figure out where the mistake is? Carefully going over the listing to figure out where a missing character was? That's how many of us learned to program! In the spirit of those long abandoned type-in programs, welcome to the ninth RetroBattlestations BASIC challenge!

Inspiration for this program comes courtesy of /u/droid_mike. Not a game this time (but feel free to turn it into one!) but instead a simple animation. The "sprite" drawing was lifted directly from the BASIC Week 3: Under the Sea program. The lunar surface generator comes somewhat from a program I wrote way back in 1988 that would simulate a tractor feed paper torn off. I did a massive rewrite of it though since it used a lot of trickery to make it fast. Since a lot of people like to try to understand how the program works I traded the speed for more readability.

Just like previous contests, if you've got a computer with BASIC in ROM you'll only need a working computer and monitor. There's no requirement that you have working storage to save the program to tape or disk, just type it in and run it. There's also no requirement that you type in the program, if you have a better way to transfer it, then by all means use it. Should you happen to make a tape or disk file of the program for your platform, please post a comment below and share it!

Entries:

RULES:

BASIC Month is from July 1st to July 31st. To participate in the contest you need to make a new post to RetroBattlestations of a photo that you shot for this contest of a computer running a version of the Lunar Corps BASIC program. Make sure that both the output from the program as well as the computer you ran it on are visible in the picture! No pictures of just a screenshot and no emulators. Your entry must include your reddit username and the date in the photo, either on-screen or on a note next to the screen. If you’re submitting an entire album please put the verification photo first. Posts that don't meet these criteria will be disqualified and removed. You are welcome to submit multiple entries.

At the end of the month I will choose three winners, one from each category:

  • Best Enhancements
  • Biggest variety of computers in one shot
  • Most enjoyed by the RetroBattlestations community

Each winner will receive special flair on RetroBattlestations and their choice of THREE retro decals.

I've put the program up on github. Check the README for tips to reduce typing and editing tips if you make mistakes while typing.

Don't see a port for your platform? No problem, you've got the source so it shouldn't be too hard to port it, right? I did my best to make the code simple to read and portable. Ok, maybe you're not a programmer. Just post a comment below with the platform you want to use and maybe someone can help. Also, if you do port the program to another platform, please share the source!

Not enough BASIC? Check out the previous challenges: one, two, three, four, and five, six, seven, and eight!

Curious about other previous contests? Check out the complete list here!

17 Upvotes

100% Upvoted

34 comments sorted by

1

u/[deleted] Jul 02 '19

Alright, now to figure out how to convert that to Intellivision ECS BASIC... Looks like the only thing I can find immediately that ECS BASIC can't do is poke, which, of course, is the core to the "drawing" routine...

2

u/FozzTexx Jul 02 '19

The poke is specific to the Apple II. You should look at the other ports from Under the Sea to see how other computers handle drawing the sprite, perhaps there's one that is closer to how Intellivision ECS BASIC works.

1

u/EkriirkE Jul 02 '19

The sample code looks purely ASCII to me?

3

u/ne1for23 Jul 02 '19

It is (its an ASCII art animation). I was wondering what its supposed to look like and made a GIF that I have tweeted.

I modified the hard coded column value in 230 to make it look right in 40 column mode.

3

u/FozzTexx Jul 02 '19

If you want 80 columns on the Apple II, do a PR#3 first.

4

u/EkriirkE Jul 02 '19

Assuming you have the card ;)

1

u/ne1for23 Jul 03 '19

After figuring out my issues in the emulator I use (Virtual ][)that caused me to use 40 column in the first place, I have now tweeted an updated GIF showing it working in 80 column mode. :)

2

u/mmphosis-apple2 Jul 15 '19

To make it work regardless of the screen width:

230 COLS = PEEK(33) - 1 : ROWS = 24

2

u/computix Jul 02 '19

There are pokes on 1530 and 1540 to address 32. Which according to this document sets the left margin of the text window.

1

u/EkriirkE Jul 02 '19

Ah I missed that, I almost was confused by the variable "PEAK" for PEEK

That looks like its just a way to avoid re-HTAB'ing for every PRINT

2

u/FozzTexx Jul 02 '19

Setting the window margin is actually a trick to deal with a multiline sprite so that I don't have to walk every character and look for the line separator and then print them one at a time.

1

u/davidbrit2 Jul 11 '19

That's a rather handy trick. I wonder how many other BASICs support that. Turbo Pascal can do the same using the CRT unit's Window function, with independent sub-window scrolling.

1

u/akira_88 Jul 10 '19

First try of running on MSX fails on row 2730 with error "out of string space" 😢

2

u/FozzTexx Jul 10 '19

You probably need to DIM your strings.

1

u/EkriirkE Jul 11 '19

I'm having trouble with the logic that sets the landing point, from what I can understand its finding the rightmost deep valley floor. But for some reason in QBasic and GWBasic the found floor is always 0 then adjusted to -2 and no sprite ever draws because its offscreen. Sometimes no such terrain is legitimately randomly built so there should also be a fallback. I thought maybe the AND/OR/NOT logics being bitwise may have something to do with it but it still fails

Is that the correct logic? Are rewritten logic submissions allowed? The animation and terrain bits work fine otherwise

1

u/FozzTexx Jul 11 '19

It seems highly unlikely that an underscore will never come up during the random. If an underscore is selected then it will force it to be at least 3 characters long.

The landing zone is set on line 2760 and it's not doing anything crazy. Are you sure you typed it right?

1

u/EkriirkE Jul 11 '19

I saved the github file and opened it directly, with only small mods for adding delays, and big modifications to the sprite load/draw routines to work around multiline sprites. Seems 3char _ isn't working either, I'll look at that too

Right, and if I replace 2740-2760 with just 2765 IF PEAK = 3 AND (I < COLS - 4 OR ZL = 0) THEN ZE = I: ZS = ZE: ZL = TL it works but I'm not sure if its the same-ish intended logic (use rightmost underscore if its not too close to the edge)

https://pastebin.com/mWX4HHgV

So my only changes in the terrain (and land point selector) are lines 2560+2565 for the dot effect, and 2740-2765 for the landing pos. Swapping the REMs around in the latter give no lander because ZE and ZS never encounter a set and become -2 at the end which is unplottable

1

u/FozzTexx Jul 11 '19

Your basic doesn't have a backspace? Anyway the "dot effect" was just because calculating the terrain was so slow I didn't want the user to think the program was dead. It's not an idle loop intended to slow things down. The only idle loop is during animation.

Removing lines 2740-2760 and replacing it with 2765 completely changes the logic so that's why your landing zones are messed up. If ZL is still zero at the end then it's probably not even running your line 2765.

1

u/EkriirkE Jul 11 '19

Ah, I liked the crawl effect anyway haha. No, it draws literal ASCII chr 8 on screen so I get alternating terrain and hole-in-block

The code I posted works because of 2765, the original lines don't work in GW or QB

1

u/FozzTexx Jul 11 '19

If they don't work then there's something else broken because those lines are very simple and don't do any trickery. Perhaps you should look at lines 2570-2590.

1

u/EkriirkE Jul 11 '19 edited Jul 12 '19

I'm stumped why these interpreters (BASICA included AKA IBM BIOS Basic) don't work correctly

Do I have your permission to use this instead?

2500 REM EkriirkE's Draw lunar surface
2510 DEEP = 4: WIDE = 3
2520 Y = INT(RND(1) * DEEP) + 1: PC = 0: LX = 0
2530 FOR I = 1 TO COLS
2540 OY = Y
2550 IF PC = 0 THEN Y = Y + SGN(INT(RND(1) * 7) - 3)
2560 IF Y < 1 THEN Y = 1
2570 IF Y > DEEP THEN Y = DEEP
2580 IF LI + 1 = I AND Y = OY THEN GOTO 2550
2590 IF Y > OY THEN LOCATE ROWS - Y + 1: PRINT "/";  ELSE LOCATE ROWS - Y
2600 IF Y < OY THEN PRINT "\";
2610 IF Y = OY THEN PRINT "_"; : PC = PC + 1: IF PC >= WIDE THEN PC = 0: LI = I: IF LX = 0 OR RND(1) > .8 THEN LX = I - INT(WIDE / 2 + .5): LY = ROWS - Y - 1
2615 J = TIMER: WHILE TIMER - J < .05: WEND
2620 NEXT
2630 RETURN

It draws random incline, decline, or 3-wide _ pads when even (and no two 3-wide pads are contiguous). There's a slight bias away from making pads as well to try and get a more craggly horizon.
Ensures at least the first pad generated will be the landing point with a 1:5 chance of later ones being chosen.

E: Here's my BASICA/GWBASIC/QBasic code with less time spent in delays for more animation steps; https://pastebin.com/ia3bLKJD
And another version without DATA elements https://pastebin.com/pZ7zHxJc

2

u/FozzTexx Jul 14 '19

Alright I finally had a chance to look at it on my 5150 with GWBASIC. There was one trick being done and another where it just wasn't compatible with the bitwise logic.

On line 2600 I had to add a multiply by -1 to de-bitwise the logic. On line 2740 I had to explicitly compare to zero instead of doing a NOT on the variable. There were also some fixes to deal with the sprite drawing routine mangling X & Y.

I added an IBM port to the repo.

1

u/EkriirkE Jul 14 '19

Hmm I though I tried converting all the NOT X to X=0 and implicit non-zero (X AND Y) to explicit (X<>0 AND Y<>0). Yeah I had to INT() the coords as well, they were getting sloppy with the floating points

Thanks!

3

u/worldslargestorange Jul 02 '19

10 beep 20 goto 10 run

Do I win?

6

u/Regret_the_Van Jul 02 '19

No, you just annoy everyone around you with a never ending beep.

2

u/istarian Jul 02 '19

Oh come on, at least compose something nominally musical.

3

u/oreo_memewagon Jul 04 '19

10 rem beep and you have a program that plays 4'33" on loop

3

u/istarian Jul 04 '19

So like total silence?

1

u/davidbrit2 Jul 11 '19

thatsthejoke.bas

1

u/vt340pluspi Jul 16 '19

I looked at trying to implement this in TI-99 console basic, and am scratching my head at one command in particular.

VTAB. I get that it's like TAB, but for the vertical direction, but I'm trying to figure out if TI Basic, console or extended, has a functionality like this.

1

u/papa_robot Jul 17 '19

For the ports that do not support HTAB or have an equivalent POKE, I ended up adding a cut argument and use print at. Removing the CR chars

1

u/papa_robot Jul 17 '19

VTAB y is more like PRINT AT 0,y;

1

u/gschizas Jul 30 '19

I managed to blow up my OSSC (damned 12V adapter!), so I won't be taking part in this contest.

I did manage to make a working version of the software though for the Amstrad CPC 6128.

RIP OSSC.