BASIC on CART Contest (BoCC)

[Opry99er]

Hey, you guys have over a month left!! The coding time just started!!! January 14, guys... so take your time, perfect your code, get it right, and when you submit in a month, there will be some awesome entries to compare to. Adam's game getting done so quickly is the odd-bird out.... he's a MANIAC, MANIAC, ON THE FLOOR!!!!!

 

=)

[unhuman]

Adam have you tracked hours you've put in? I know I'm probably in for somewhere around 20-40... Probably more. And level 16 has uncovered 2 bugs - one I fixed and one probably not a fun one.

Edited December 4, 2010 by unhuman

[+adamantyr]

Adam have you tracked hours you've put in? I know I'm probably in for somewhere around 20-40... Probably more. And level 16 has uncovered 2 bugs - one I fixed and one probably not a fun one.

 

At least 20 hours of work... probably closer to 30.

 

Let's not just have three entries, three winners!

 

Don't get discouraged, guys. TI BASIC is pretty rough... frankly, I'm surprised the game came out so well. I got VERY lucky that the only thing I ended up having to cut was the opening title sequence.

 

Adamantyr

[Opry99er]

I gotta say I am quite excited about the prospects of this contest. Aperture, BASIC Rogue, Crystal Garden, BloxoTIz and the one that kl99 is working on. (still want to see what's under the hood there, buddy) =) I'm encouraged... the contest started not yet a month ago and there's more than a month left. If Adam can write Aperture in 20 hours, I am really looking forward to seeing what everyone else can do with a month! =)

 

In all, I can't believe what is possible in BASIC. It's truly amazing that these games are not only possible, but actually being written right now. The fact that the winning game will be on cartridge is a testament to the excitement and energy generated here. Thanks go to Filip Van Vooren and Tursi for their efforts on making that a reality. I'm pretty pumped up to see what comes out of this contest. I've decided to play each of the entries a couple times to help debug during this coding time, but I'm not going to play any of these too much before the contest is over. I don't want to develop any biases one way or another towards any of the games... thus far I've played each of the demos put out for BASIC Rogue and BloxoTIz and I've played the disk version of Aperture. All pretty amazing. I wish you all luck on your games, and I look forward to my hardware projects building the winner's cartridges. =)

[unhuman]

Oh crap! Memory full on line 41. I only have 20 levels...

[Opry99er]

Can TIBASIC be tokensized? In XB, you can "shrink" your code by a few bytes per line and then add more. Continue this process until youre ACTUALLY full... sometimes you can add a K or even more to your code.

[+adamantyr]

Oh crap! Memory full on line 41. I only have 20 levels...

 

How many were you shooting for? Like I said, I was ready to drop a level or two if need be... As is, 16 levels in Aperture is basically the limit. And if I'd been too creative on some and added too many elements, it may not have fit.

 

Also, if you haven't already, use DATA statements and a loop for character and color initialization. Do NOT use a bunch of separate CHAR statements.

 

Adamantyr

[unhuman]

Was shooting for 33. And I don't really have a "won game" sequence - prints congrats and ends. I use a lot of data statements.... I probably could come up with a compression algorithm for the level data, but - don't really know if there's value there....

 

I'm sure I could trim out the code, but I've hacked it up so bad adding things, I honestly don't really understand it all anymore. I'll post latest to see if you see anything blatent, but, I'm honestly at the point of abandoning...

 

-H

 

Oh crap! Memory full on line 41. I only have 20 levels...

 

How many were you shooting for? Like I said, I was ready to drop a level or two if need be... As is, 16 levels in Aperture is basically the limit. And if I'd been too creative on some and added too many elements, it may not have fit.

 

Also, if you haven't already, use DATA statements and a loop for character and color initialization. Do NOT use a bunch of separate CHAR statements.

 

Adamantyr

[InfernalKeith]

I haven't posted my code yet BECAUSE it's a snarled mess of individual CALL CHAR and COLOR statements. It needs a LOT of neatening up before it's presentable. Luckily memory hasn't been a problem for me yet, but it may become one by the time I get the AI finished.

[+adamantyr]

How's everyone's BASIC contest entries going?

 

Adamantyr

[InfernalKeith]

How's everyone's BASIC contest entries going?

 

Adamantyr

 

 

See above. I really like my newer idea and I'm having a hard time getting enthused enough to tackle the AI in my game. I may see if I can do a weekend blitz and bash out a rough version of my newer idea in a couple days, to see if working on something new helps me clear my head about the first game. All a moot point for the next couple days, as I'm buried in work again, but hopefully I'll have some downtime during holiday travels to be away from work and just work on code.

[unhuman]

Coming along. Have 31 levels done (minus a couple deemed impossible to implement in my flawed architecture)... On level 32. 33 total. Then I need to re-test 'em translated... Then I need to use up all available RAM with other things....

 

Edit - all levels done. Had to introduce a new hack to account for a case that I didn't plan for. but all done. Now just to test and polish.

 

How's everyone's BASIC contest entries going?

 

Adamantyr

Edited December 14, 2010 by unhuman

[kl99]

How's everyone's BASIC contest entries going?

 

Adamantyr

 

Well well. Many hours went into coding since it's the first Basic/XB project since coming back to the TI World.

My brother and I used to code back in the 90s though.

 

The game will be called Dr.99 (title is almost fixed) and will be, guess it, a Dr. Mario clone for the TI.

Wikipedia Link

 

I can't believe what difference in speed it is running my game in TI Basic and TI Extended Basic (utilizing the 32K).

For now it's compatible with both 'worlds' and has around 6.2KByte.

 

In XB is actually arcade-like playable. I have not finalized the code for input yet but it is really enjoyable, and I often fall into playing when I actually wanna test something.

 

In TI Basic, well you can play but the computer doesn't react as fast to your inputs as in XB. That's bad! As speed is part of the game, that is my pain point! I am still hoping to optimize the code in order to bring it into an enjoyable game even in TI Basic.

 

To get into detail, maybe someone can help or give a good advice:

 

I have built up a 2 dimensional string matrix.

M$(15) for rows 0 - 15 (16 rows), with 8 characters each because there are 8 columns.

The matrix gets filled with the stones and viruses in the 'lower area'.

The matrix is shown up on the screen afterwards.

 

When the first pill (2 chars) drops into the game, I have the choice of checking the neighbours either with the GCHAR command or check the value in the matrix.

If the player presses 'right', the right neighbour has to be checked.

If the player presses 'left', the left neighbour has to be checked.

If the pill drops one row, the neighbour below has to be checked.

[As the player can turn the '2-char' pill, checking differs whether the pill is lying (y/x y/x+1) or standing (y/y y+1/x).]

 

Right now I am checking against the matrix, when the pill is moving and when I want to check if there are 4 of the same colour that shall be erased.

When a pill gets erased or drops onto something the matrix gets updated.

 

I hope that it will run faster in TI Basic when I check with GCHAR instead, at least while the pill is moving.

And the other hope is to optimize the main loop with the keyboard input.

 

Other question:

 

Is there a better (faster) way than to simply set all the chars one by one like:

110 CALL CHAR(33,"2639879084738974")

120 CALL CHAR(40,"5634785634785634")

..

300 CALL CHAR(96,"2984273442389742")

 

br, Klaus

[unhuman]

I hope that it will run faster in TI Basic when I check with GCHAR instead, at least while the pill is moving.

 

Awesome! If you have data in a matrix/multi-dimensional array (and it's not a string to parse), it's gonna be way faster than GCHAR.... Of course, if you're displaying that matrix, a string is way faster (inaccurate invaders)... In a game loop, you can really only get away with 1 GCHAR (or 2 if you're lucky)... It eats up lots of power.

 

But glad to see some secret projects coming out of the woodworks. Said it before, but I'm pretty amazed with what we're doing here and think we coulda ruled the world (or at least gotten published in 99'er - what'd they pay? $100? like $2 an hour for me).

 

-H

Edited December 14, 2010 by unhuman

[kl99]

I hope that it will run faster in TI Basic when I check with GCHAR instead, at least while the pill is moving.

 

Awesome! If you have data in a matrix/multi-dimensional array (and it's not a string to parse), it's gonna be way faster than GCHAR.... Of course, if you're displaying that matrix, a string is way faster (inaccurate invaders)... In a game loop, you can really only get away with 1 GCHAR (or 2 if you're lucky)... It eats up lots of power.

 

But glad to see some secret projects coming out of the woodworks. Said it before, but I'm pretty amazed with what we're doing here and think we coulda ruled the world (or at least gotten published in 99'er - what'd they pay? $100? like $2 an hour for me).

 

-H

 

I have changed the matrix from a string matrix to numeric values matrix and it's indeed faster now. Switching from keyboard to joystick and optimizing the main loop gave me another gain in speed/smoothness. It's no pain to play the game in TI Basic anymore, although it uses sounds in gameplay! In XB it's extra cool but that's another story!

 

I have read that numeric variables do cost a lot of memory, 10 Bytes each, is that true? Is that the case as well, if I define a numeric 2-dimensional matrix like DIM M(7,15) ?

 

Am I right that a program runs the same speed, independend how much free RAM is avaiable? If it runs it runs, right? Asked the other way around: An Instruction like Call HChar needs the same amount of time to execute whether it's performed in a 2K program or an 10K program, right?

 

What has still to be done in my game:

 

) numeric-matrix adaption of the code, that checks for 4+ stones of the same color and removes them.

) create the code, that checks after removement of any stones if there are any remaining stones above that have to fall down (a taff one!)

) intelligent generator for the initial stones and viruses on the screen (a taff one!)

) add score

) add virus counter

) add game over check

) add preview on the next pill

) add level and speed select screen (speed is already implemented)

) add cool title screen (depending on the remaining memory)

) optimize sounds

 

When I get the main program features to run, I will release a test version.

 

It's really fun to program, it's a creative process, and it's a mind challenge. I don't know why we have this 'nerd' reputation.

[unhuman]

To see the size of an array, you would do as follows

 

10 DIM ARRAY(7,15)

SIZE

RUN

SIZE

 

The difference in numbers should be the size of memory you used... XB keeps data in memory until you alter the program or get an error... So you can hit break and see things like this, values of variables, etc.

 

From my BloxoTIz thread, apparently (at least in a data statement) each numeric is 4 bytes. It might be 2 + 2, however - 2 for the separator and 2 for the value. Don't have a TI (or emulator) here to play with.

Edited December 17, 2010 by unhuman

[kl99]

 

What has still to be done in my game:

 

) numeric-matrix adaption of the code, that checks for 4+ stones of the same color and removes them.

) create the code, that checks after removement of any stones if there are any remaining stones above that have to fall down (a taff one!)

) intelligent generator for the initial stones and viruses on the screen (a taff one!)

) add score

) add virus counter

) add game over check

) add preview on the next pill

) add level and speed select screen (speed is already implemented)

) add cool title screen (depending on the remaining memory)

) optimize sounds

 

 

I have done the followings things:

 

) code, that checks for 4+ stones of the same color and removes them (so far the code is only for a standing pill, not a lying one)

) virus counter

) game over check and game over screen with opportunity to play again

) stage clear check

) preview on the next pill

) level select

) code optimization to reduce memory usage [data & for next - loops, reduce variables used,...]

) code resorting & resorted the used ascii-chars to optimize color charset usage

) designed the viruses differently for each color

) have created a game screen - mockup, based on an actual screenshot from my program, in an image editor on my pc

 

It's 7.5 KB for now.

 

The upcoming taff challenge is the generation of the initial screen which gets filled 'randomly' with viruses.

Depending on the level we talk about 4 to 84 viruses on the screen.

During generation you got to make sure that not 4+ of the same color are in a row or a column.

 

The original Nintendo version seems to use presaved initial screens. I am thinking this because resetting the emu often leads to the same viruses at the same locations. Depending on the level, more of the presaved data is used or not. This would be the fastest option for the game start but would lack variety. Memory usage could be safed with compression but decrypting the compression algorithym would lead to less speed.

 

As soon as I find time to integrate the visual changes I have planned for the game screen, a snapshot will be shown!

[Tursi]

I have read that numeric variables do cost a lot of memory, 10 Bytes each, is that true? Is that the case as well, if I define a numeric 2-dimensional matrix like DIM M(7,15) ?

 

Numbers in RAM should be 8 bytes, though DATA statements may be storing as strings. At any rate you have the tools to check that now.

 

Am I right that a program runs the same speed, independend how much free RAM is avaiable? If it runs it runs, right? Asked the other way around: An Instruction like Call HChar needs the same amount of time to execute whether it's performed in a 2K program or an 10K program, right?

 

Yes, but when memory gets tight, certain operations will run more slowly, such as modifying string variables. The reason is that new strings are created each time, which takes more memory. When memory is tight, the garbage collector runs more often, which slows you down. Basically, when a string is modified, a new string is created, and the old one is just marked as no-longer-used. But it's still there in memory taking up space -- this is done for performance reasons. The garbage collector runs when needed to delete the no-longer-used strings and relocate the used ones so that all the free space is in one block again, sort of a memory defragmentation.

 

I /think/ only strings will do this in TI BASIC, meaning if you only use numeric variables there's no concern of unpredictable slowdown. Likewise few string variables will take less time to relocate.

 

The above is theory and my understanding of things, and not necessarily proven.

[kl99]

Thanks for the explanation, Tursi!

[+OLD CS1]

If I can finish it on time, I will throw my old game re-write into the ring. It will not win, but I think it would be cool to debut it in the contest.

 

Also, in terms of AI, it depends upon what you need your AI to do. I wrote an AI for "Laser Strike," another of my COMPUTE! Magazine conversions which is essentially "Battle Ship." It had two modes: Merely Aggressive and Downright Nasty (yeah, big biter!)

 

In MA mode, the AI would poke about the 10x10 grid dropping bombs in a semi-random fashion, making randomized random selections based upon the type of ship it was looking for during that turn. Then, based upon the ship it found it would do what pretty much any of us would do: drop the next bomb in a strategic circle trying to guess the positioning of the ship.

 

In DN mode, the AI started pretty much the same way, with the exception that as soon as it found a part of a ship it immediately knows where the rest of it is. Pretty nasty, huh?

 

This is one of my games that I cannot find on my cassettes, yet. I am hoping to find it as I have no development notes from which to recreate the program.

[+OLD CS1]

Yes, but when memory gets tight, certain operations will run more slowly, such as modifying string variables. The reason is that new strings are created each time, which takes more memory. When memory is tight, the garbage collector runs more often, which slows you down. Basically, when a string is modified, a new string is created, and the old one is just marked as no-longer-used. But it's still there in memory taking up space -- this is done for performance reasons. The garbage collector runs when needed to delete the no-longer-used strings and relocate the used ones so that all the free space is in one block again, sort of a memory defragmentation.

 

I /think/ only strings will do this in TI BASIC, meaning if you only use numeric variables there's no concern of unpredictable slowdown. Likewise few string variables will take less time to relocate.

 

The above is theory and my understanding of things, and not necessarily proven.

 

Based upon the disassemblies of Microsoft's BASIC on other platforms, and the assumption that MS did the same tricks with TI BASIC, I would concur with your assessment. When I wrote my BBS/OS for the Commodore 64, I used a lot of my own string manipulation routines for this very reason; the idea was to avoid the "waste" created by BASIC's string handling and avoid unnecessary garbage collections.

 

For instance, my string concatenation routine attempts to move the two strings to concatenate together if close enough, and I also wrote a string rotation routine which rotates the contents of a string to avoid wasted memory, and one routine which combines the two processes. Was actually quite fun to write.

 

I am looking forward to learning 9900 assembler as well as I know 6502.

[+OLD CS1]

Was shooting for 33. And I don't really have a "won game" sequence - prints congrats and ends.

 

A "Still Alive" musical performance??

[Tursi]

Based upon the disassemblies of Microsoft's BASIC on other platforms, and the assumption that MS did the same tricks with TI BASIC, I would concur with your assessment.

 

Thanks! Although, the fact that TI BASIC creates new strings all the time and there is a garbage collector, that is not theory, I have observed this (use Classic99's debugger and watch near the top of VRAM ). The theory is more whether numeric variables or any other temporary data also use this temporary space.

 

For instance, my string concatenation routine attempts to move the two strings to concatenate together if close enough, and I also wrote a string rotation routine which rotates the contents of a string to avoid wasted memory, and one routine which combines the two processes. Was actually quite fun to write.

 

Hehe.. nice! Sounds pretty cool.

 

I am looking forward to learning 9900 assembler as well as I know 6502.

 

The register count is very nice compared to the 6502.

[sometimes99er]

Based upon the disassemblies of Microsoft's

I am looking forward to learning 9900 assembler as well as I know 6502.

 

The register count is very nice compared to the 6502.

Yeah, I know and rate those classic processors by design and use like this

 

1. 68000

2. 9900

3. Z80A

4. 6502

 

[unhuman]

Was shooting for 33. And I don't really have a "won game" sequence - prints congrats and ends.

 

A "Still Alive" musical performance??

 

It has it - go play!