Hell's Halls - TI BASIC Cassette Game Dungeon Crawl Project

[senior_falcon]

It turns out you can enter more than 4 lines using just the BASIC editor.

10 DATA ENTERDATATILLYOUHITTHEFOURLINELIMIT...

Press ENTER

10 then down arrow to edit

Now you have one more line to type on.

Repeat for line 6 if necessary

I probably knew this back in the day.

 

[+adamantyr]

Great looking game! So Flooraway's only competition is Flooraway 2, hmm? (*cough* APERTURE *cough*)

[pixelpedant]

1 hour ago, adamantyr said:

Great looking game! So Flooraway's only competition is Flooraway 2, hmm? (*cough* APERTURE *cough*)

I guess I didn't think of Aperture as a conventional platformer.  But I suppose it surely is a platformer of one stripe or another. 

Just in its own somewhat distinct puzzle platformer category. 

And that's its strength, after all.  Its design works better under BASIC than more traditional platformer designs. 

[WhataKowinkydink]

Sorry it took a bit longer to actually finish the video than expected - good one!  ("Learn to love the taste of spaghetti code" ?).   Excited to see this one released into the wild.

[Retrospect]

This is great

[pixelpedant]

Thanks!  I've just finished an unrelated project for an upcoming video, so I'm back in the saddle with this one!  And glad to be.  There's an awful lot of room for improvement and expansion, here.  If I can ever convince myself to stop fiddling with minor optimisations of little broader consequence

 

 

[+dhe]

Have you ever seen any of the disk by Ken Gilliland - Like Disk of Horrors?

 

I know you don't want to 'cheat' and use a loader. 

 

One avenue you could take and still keep it pure, is to provide a short story of Hell's Hall - maybe a kewl font and pictures or moving graphics + instructions to 'set the mood' for the game play?

[suberbanator]

4 hours ago, dhe said:

Have you ever seen any of the disk by Ken Gilliland - Like Disk of Horrors?

 

I know you don't want to 'cheat' and use a loader. 

 

One avenue you could take and still keep it pure, is to provide a short story of Hell's Hall - maybe a kewl font and pictures or moving graphics + instructions to 'set the mood' for the game play?

i believe i have a couple but have to look

[pixelpedant]

I have poked away at Ken Gilliland's disks, indeed. 

 

And though those are XB programs with consequently very different capabilities from those available under TI BASIC, I suppose somewhat along those lines, one thing I'm considering at present is in fact after completing the cassette version, doing a disk version which exploits the potential to load comparatively gigantic amounts of pattern/palette/music/text data on demand.  Even in an SSSD context, if I were to stick with legacy TI spec, which I likely would, 90K is leagues ahead of the 3K or so of DATA statements I can reasonably make room for in my present cassette program. 

 

But time-wise, 90% of the work on this and 90% of the fun of the exercise, especially through its last month, has been figuring out ways to cram the program and its data into 11K in ways that are sufficiently performant under TI BASIC (and compatible with its limited toolset).  So I do not for a moment regret that aspect of the exercise and the way it is imposed by the medium.  Cramming a complex game (and its subroutines and data) into ever smaller spaces has very much been the joy (and most of the time investment) of this business, for me. 

 

But as for places to go subsequently, another possibility encouraged by a disk version would be integration of support for TEII speech and sound.  I just don't have the space for the data or supporting subroutines in the current program.  But being able to load any speech data from disk would make it viable. 

 

On the other hand (and because it will always be the most obvious upgrade), I don't think an XB version would make sense.  The program is (and its current army of subroutines are) at this point far too hugely focused on figuring out ways to make interesting things happen with CALL HCHAR, CALL VCHAR, and CALL COLOR while compressing the arguments for those commands to strings.  Once DISPLAY AT and real sprites enter the picture, one might as well just throw out the whole thing and start over.  Because giant strings of CALL HCHAR/VCHAR/COLOR/SOUND argument data aren't a good way to accomplish anything, in that context.  And it would not be easy to translate the current program data back into a saner format.  Just for example, these are the last lines of the program as currently written:

 

9500 DATA "A.,'%'''%'","HBBABB","A@$     $","B@!]#   !]#","C@%  $  %","E@\\\\\"
9510 DATA "AOBHGB","A..","H@AND SO IN DEATH","A))","L@IT IS YOUR FATE","A''"
9515 DATA "P@TO HAUNT MY HALLS","A%%","T@NOW AND FOREVER","A''","W@**<<<++"

Aside from the odd bit of text, most of the data isn't human-readable discrete values anymore, so it's just not very portable. 

 

[senior_falcon]

It is clear that this game must be saved to/loaded from cassette. Nobody is going to type it in every time they want to play it. So the cassette player is a must. Once you require a cassette player, I don't think it would be cheating if you were to load things such as character patterns, perhaps a new screen, etc. from the cassette player. That would free up some number of bytes that could then be used to enhance the game. Of course there is the slow access to data that comes from using tape, but that would (probably) be tolerable, especially at the beginning of the game.

Page II-118 of "User's Reference Guide" has the details.

[pixelpedant]

Updated intro sequence and startup for the latest version of Hell's Halls.  Much that is changed is obviously "behind the scenes" stuff to make things more extensible and reusable to develop more content within memory limitations, but there are also fairly obvious changes you'll notice.

 

Sound design especially (and the way it's stored) is completely revamped.  Principally in order to sound much more sinister. 

 

 

[pixelpedant]

In a perfect world, as I say, one would calculate the frequencies of notes on the chromatic scale (for the purpose of storing musical "note" values packed into strings then feeding them to CALL SOUND) via the actual formula for calculating these frequencies.  But that formula happens to involve a fractional exponent.  And TI BASIC is brutally slow at handling fractional exponents.  So I ended up improving on my original approach while not doing that (and satisfying performance requirements) by just coming up with a simple arithmetic expression (handled quickly enough by TI BASIC) which results in frequencies diverging (based on input character value) at a rate roughly satisfactory to the range of musical frequencies I'm dealing with.  Which happened to be

 

(where A is the ASCII value of a character)

A*A*A/14400+25

 

Such that ASC("I")=73 and 73*73*73/14400+25 = 52 (Hz) whereas G#1 = 51.91Hz such that "I" = (roughly) G#1.

 

Fun fact: A*A*A is much, much faster than A^3 in TI BASIC. 

 

So for printable character input values of 32, 33, 34, etc. this results in apparent frequencies from 27.28Hz to 163.915Hz.  That's five octaves, which is way more than enough. Possibly an even more compressed "scale" would be desirable. 

 

This frequency is itself really just a reference point though.  It isn't directly used by CALL SOUND.  It's used to derive the tone generator 3 frequency required to generate periodic noise at that frequency, and the overtones desirable in that context. No tone generator is actually set to that frequency. 

[pixelpedant]

On 6/26/2022 at 9:34 AM, senior_falcon said:

It is clear that this game must be saved to/loaded from cassette. Nobody is going to type it in every time they want to play it. So the cassette player is a must. Once you require a cassette player, I don't think it would be cheating if you were to load things such as character patterns, perhaps a new screen, etc. from the cassette player. That would free up some number of bytes that could then be used to enhance the game. Of course there is the slow access to data that comes from using tape, but that would (probably) be tolerable, especially at the beginning of the game.

Page II-118 of "User's Reference Guide" has the details.

Following up on this somewhat belatedly - I can certainly see the appeal of this from a practical standpoint.  But in the end, I think I went into this wanting to overcome (or at least hide) the slowness of TI BASIC by any means necessary (like loading the great majority of characters in small pauses in between animations and text during the title sequence).  So I feel like making startup more cumbersome would be unfortunate in that context.

 

Mind you, I'm already succumbing in various respects to a willingness to make things slower/cludgier in the name of memory economy (mainly, storing all sound and nearly all HCHAR/VCHAR data in strings, which is inherently slower, but not painfully so).  So who knows where I'll succumb next. 

 

Heck, in a recent desperation move, all instances of =0 or >0 or <0 in my program have been replaced with =W and >W and <W.  Where W is a variable that does not exist.  That, while some hideous nonsense, saved me 40 bytes in numeric constant tokens. 

[+FarmerPotato]

1 hour ago, pixelpedant said:

Heck, in a recent desperation move, all instances of =0 or >0 or <0 in my program have been replaced with =W and >W and <W.  Where W is a variable that does not exist.  That, while some hideous nonsense, saved me 40 bytes in numeric constant tokens. 

Wow. I would never have imagined that W.  Does it have a speed penalty for looking up W undefined vs W=0?

 

I did use _ as the constant 1 in XB. 
 

(Zed was not available?  )

[pixelpedant]

1 hour ago, FarmerPotato said:

Wow. I would never have imagined that W.  Does it have a speed penalty for looking up W undefined vs W=0?

 

 

I did use _ as the constant 1 in XB. 

 

There is a tiny performance cost to using a variable rather than a constant in an IF comparison.  But it is truly tiny.  Under a millisecond. 

 

However, the speed of a comparison involving a constant is proportional to its length.  So while X=0 is faster than X=W (where W is undefined), X=999.9999 is slower than X=W, where W=999.9999. 

 

And yeah, _ and \ and @ and [ (among other things) are legit variables (if you want them to be) in good old TI BASIC and Extended BASIC. 

 

As a consequence of which, this is a functioning Extended BASIC program I wrote a while back, just to be perverse:

 

5 ON WARNING NEXT
10 ]\]=[/[
15 [=[-]=]
20 DEF ]\(_)=(_)/[
21 CALL CLEAR::ON ERROR 81::CALL SOUND(]\(),[\],]\],]\])
22 CALL ERR([\,[\],[\],\])
23 CALL HCHAR(]\([\])/[--[\],]\([\])/[--[\],\]-[\)::ON ERROR 22::PRINT::RETURN NEXT
81 ON ERROR 22
82 CALL SOUND(]\(),[\],]\],]\])
119 CALL SOUND(]\(),[\],]\],]\])
128 CALL SOUND(]\(),[\],]\],]\])
130 CALL SOUND(]\(),[\],]\],]\])
135 CALL SOUND(]\(),[\],]\],]\])
139 CALL SOUND([-],[/[,[/[,])
141 CALL SOUND([-],[/[,[/[,])
147 CALL SOUND([-],[/[,[/[,])
180 CALL SOUND([-],[/[,[/[,])
188 CALL SOUND([-],[/[,[/[,])
190 CALL SOUND([-],[/[,[/[,])

Which prints the following text. 

 

 

While containing no numeric or string constants, and no alphanumeric variables. 

 

[Asmusr]

9 hours ago, pixelpedant said:

There is a tiny performance cost to using a variable rather than a constant in an IF comparison.  But it is truly tiny.  Under a millisecond.

In other words: Under 2830 clock cycles. ?

[GDMike]

I think there's also a drop in ram when placing commands on another line number rather than placing as much data on 1 line, if I remember correctly. I think the same applies in assembly when using labels.

[Tursi]

11 minutes ago, GDMike said:

I think there's also a drop in ram when placing commands on another line number rather than placing as much data on 1 line, if I remember correctly. I think the same applies in assembly when using labels.

Labels in assembly do not consume memory, they are only used by the assembler.

 

Technically a 'DEF' label is stored in memory if you use the loader, so that would consume 8 bytes of low RAM, but that doesn't usually concern software that needs to link with others.

[Asmusr]

7 minutes ago, Tursi said:

but that doesn't usually concern software that needs to link with others.

You mean it only concern software that needs to link with others?

Edited June 30, 2022 by Asmusr

[pixelpedant]

But yeah, minimising line count is a benefit in TI BASIC and XB, if you're doing everything you can to save every byte.

 

Not where performance is concerned though.  There is no performance advantage in putting multiple statements on a line in XB.  Only a program memory footprint advantage.

And honestly, the difference between

 

10 PRINT

20 PRINT

 

And

 

10 PRINT::PRINT

 

Is five bytes.  So while there is in principle a memory savings there, one is compelled to ask whether those five bytes are actually the difference between whatever given XB program executing or exceeding program memory limitations.  In a world where 99 out of 100 XB programs do not use all the memory available to them. 

And also, one is compelled to ask whether any strategy for reducing line count involves basically *any* additional code complexity at all.  Because if it does, you might actually end up consuming more memory in fewer lines.  Meaning nothing is achieved by the exercise. 

 

[GDMike]

36 minutes ago, Tursi said:

Labels in assembly do not consume memory, they are only used by the assembler.

 

Technically a 'DEF' label is stored in memory if you use the loader, so that would consume 8 bytes of low RAM, but that doesn't usually concern software that needs to link with others.

Great to get clear on this. I always was afraid I'm using 4 bytes up. Thx

[Tursi]

40 minutes ago, Asmusr said:

You mean it only concern software that needs to link with others?

No, I meant that consuming 8 bytes of low RAM isn't usually a design concern when writing software that links with other packages. IE: usually people don't care.

[GDMike]

I'm wondering where I heard that I use 4 or 8 bytes, can't remember how much, but I was distinctly told at some point that a label in assy uses ram and that I did not want too many labels in my code.  But if it's just the Assembler tracking the instruction, that's good news to me 

I'm gonna make a label for each line of code, actually I'll make two! Ok... just kidding.  But I sure wish I knew what someone meant by, keeping label count down 

Edited June 30, 2022 by GDMike

[Asmusr]

10 minutes ago, GDMike said:

I'm wondering where I heard that I use 4 or 8 bytes, can't remember how much, but I was distinctly told at some point that a label in assy uses ram and that I did not want too many labels in my code. 

No, the number of labels only affects the size of your source code - not the size of the assembled machine code program.

 

 

 

 

Edited June 30, 2022 by Asmusr

[+TheBF]

20 minutes ago, Asmusr said:

No, the number of labels only affects the size of your source code - not the size of the assembled machine code program.

Is there a practical maximum size to the symbol table in the old TI assembler that maybe someone confused with affecting program size?