Advice for BASIC

b/Calculator Talk publicado por u/xMarminq_ November 17, 2016, 03:55:55 AM

Advice for BASIC

Should someone like me who is making his first BASIC program separate it into bits that run as one or just one big program?

Inicia sesión o crea una cuenta para dejar un comentario

u/SiphonicSugar November 17, 2016, 03:59:38 AM

Bits, it keeps it more organized ,and less likely to slow down.

u/xMarminq_ November 17, 2016, 04:00:01 AM

How would I do that exactly?

u/SiphonicSugar November 17, 2016, 04:02:01 AM

Oh gosh, lets see... It actually depends on how large the program is, if its a medium to large game, you should make different parts, but not for small things.

u/xMarminq_ November 17, 2016, 04:05:18 AM

Planning for a huge 25k game.

u/SiphonicSugar November 17, 2016, 04:07:51 AM

Oh, so say you have the movement engine, then the battle engine, all in 2 different programs.

PROGRAM:MOVEMENT
code
If battle is going to start
prgmBATTLE
code

PROGRAM:BATTLE
code

u/xMarminq_ November 17, 2016, 04:11:29 AM

Ill try a huge iceberg and the try to break it into icecubes

u/Unicorn November 18, 2016, 05:24:17 PM

Quote from: xMarminq_ on November 17, 2016, 04:05:18 AM
Planning for a huge 25k game.

Is this your first TI BASIC game? If so, I suggest not attempting to write some sort of huge RPG or something, but starting off with something a bit smaller, like a small shooter or something.

I'm not sure if DJ has already said this, but my advice

u/p2 November 18, 2016, 10:30:57 PM

theres actually no real problem to pure filesize in basic but when you program grows and grows you'll come to the point where you actually have to abandon the project as it grows way too slow which isreally sad after coming all that way...
thats actually the reason many of us stop programmign at all as its too frustrating.
you should see basic as training on how to create programs in general as real games (REALLY BIG ones I mean) will then be developed in other languages.
but that doesnt mean you should stop that project, it's great for learning

also the game might actually be fun ^^

u/xMarminq_ November 19, 2016, 04:11:22 AM

Thanks! Should be done with some part of he game soon!

u/Dream of Omnimaga November 19, 2016, 07:04:01 AM

Quote from: SiphonicSugar on November 17, 2016, 03:59:38 AM
Bits, it keeps it more organized ,and less likely to slow down.

Not necessarily. If your game has few sub-programs then it doesn't make a difference, but for large games with dozens of them, the slowdown can be significant. Metroid II 84+ ran at 4 FPS during early development, only to slow down at 2 FPS near the end, even without any change to the map engine.

However, sub-programs or sub-routines are inevitable if you want to avoid code repetition and I really recommend splitting your game into small sub-programs if you're developing it on-calc, as it will take less time to scroll through the code.

Also once you improve at TI-BASIC, read about Internal sub-programs http://tibasicdev.wikidot.com/subprograms

Internal sub-programs is a trick involving Goto where Goto is pretty much used as a Call command, but you have to keep the sub-routines code as high as possible in the game code to avoid lag. (otherwise the lag defeats the point of using internal subroutines.

u/p2 November 20, 2016, 05:10:53 PM

I ONLY did on-calc programming and the two things I hated most about it:
- scrolling through a 20line block of code and accidentally pressing CLEAR
- scrolling itself

also many LBLs and GOTOs (especially with conditions around them) make it possible to reduce the program size, but debugging that as as good as impossible...

u/Dream of Omnimaga November 21, 2016, 05:38:24 AM

It's not as bad nowadays on the monochrome calcs or the C Silver because of Doors CS' ability to scroll instantly to errors when choosing Goto, and I believe there was a tool to jump directly to specific Lbls in a program via a parser hook and key combo, but on the CE it's an absolute nightmare.

This was the same on monochrome calcs before Doors CS became stable enough to be useable in late 2010. The result is that we instead often merged multiple lines as you say, and the ensuing accidental CLEAR was annoying. The CLEAR button had the worst possible location and they should never have included 2nd+ENTRY inside the program editor. That was as bad as CLEAR.

Nowadays I prefer programming on a PC, but it took me about a decade before getting used to it and testing programs is annoying because I have to transfer them over and over to an emulator.

u/p2 November 21, 2016, 10:29:10 AM

Quote from: DJ Omnimaga on November 21, 2016, 05:38:24 AM
It's not as bad nowadays on the monochrome calcs or the C Silver because of Doors CS' ability to scroll instantly to errors when choosing Goto, and I believe there was a tool to jump directly to specific Lbls in a program via a parser hook and key combo, but on the CE it's an absolute nightmare.

This was the same on monochrome calcs before Doors CS became stable enough to be useable in late 2010. The result is that we instead often merged multiple lines as you say, and the ensuing accidental CLEAR was annoying. The CLEAR button had the worst possible location and they should never have included 2nd+ENTRY inside the program editor. That was as bad as CLEAR.

Nowadays I prefer programming on a PC, but it took me about a decade before getting used to it and testing programs is annoying because I have to transfer them over and over to an emulator.

yeah I killed hhuge parts of my programs like that (pressing clear) but actually I loved the 2ND+ENTRY as I often used it to copy almost similar blocks and paste them a couple of time

u/Dream of Omnimaga November 22, 2016, 05:14:19 AM

The problem with 2nd+ENTRY is that it erased the entire line of code as well. Also I think it cycled all the time, which was not very reliable when pasting the same thing over and over. I prefered making a separate program then using 2nd+RCL