CodeWalrus

Development => Calculators => Calculator News, Coding, Help & Talk => Topic started by: xMarminq_ on November 17, 2016, 03:55:55 AM

Title: Advice for BASIC
Post by: xMarminq_ on November 17, 2016, 03:55:55 AM
Should someone like me who is making his first BASIC program separate it into bits that run as one or just one big program?
Title: Re: Advice for BASIC
Post by: SiphonicSugar on November 17, 2016, 03:59:38 AM
Bits, it keeps it more organized ,and less likely to slow down.
Title: Re: Advice for BASIC
Post by: xMarminq_ on November 17, 2016, 04:00:01 AM
How would I do that exactly?
Title: Re: Advice for BASIC
Post by: SiphonicSugar on 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.
Title: Re: Advice for BASIC
Post by: xMarminq_ on November 17, 2016, 04:05:18 AM
Planning for a huge 25k game.
Title: Re: Advice for BASIC
Post by: SiphonicSugar on 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
Title: Re: Advice for BASIC
Post by: xMarminq_ on November 17, 2016, 04:11:29 AM
Ill try a huge iceberg and the try to break it into icecubes
Title: Re: Advice for BASIC
Post by: Unicorn on 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 ;)
Title: Re: Advice for BASIC
Post by: p2 on 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 ^^
Title: Re: Advice for BASIC
Post by: xMarminq_ on November 19, 2016, 04:11:22 AM
Thanks! Should be done with some part of he game soon!
Title: Re: Advice for BASIC
Post by: Dream of Omnimaga on 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.
Title: Re: Advice for BASIC
Post by: p2 on 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... <_<
Title: Re: Advice for BASIC
Post by: Dream of 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.
Title: Re: Advice for BASIC
Post by: p2 on 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 ;D
Title: Re: Advice for BASIC
Post by: Dream of Omnimaga on 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
Title: Re: Advice for BASIC
Post by: p2 on November 22, 2016, 06:41:03 AM
I only did 2ND+INS --> 2ND+ENTRY...
using it directly would have been worse than pressing clear D:
Title: Re: Advice for BASIC
Post by: xMarminq_ on November 26, 2016, 04:03:02 AM
How about movable characters? (Like a one character sprite)
And boundaries for them?
Title: Re: Advice for BASIC
Post by: Unicorn on November 26, 2016, 08:18:27 AM
depends if you are using output or whatever,  but two varyables for X cord and H coord. You then use getkey and whenever an arrow key is pressed you increment or decrease the X or Y coord, depending on the key. at that point you have to check to make sure tht the char doesnt move out of the domain with if sgtatements. For example:


Repeat K=45
getkey->K
If K=uparrow and Y != 1
Y-1->Y
//add another if statement for moving down, increasing the Y, but not when it equals 10.
If K=rightarrow and X != 26
X+1->X
//add  another if statement for left arrows decreasing the x value, but not that it equals less than one.
Output(Y,X,"*
End


This code shoud work, even though it is untested, and be sure to remove the comments ;) You may also want to erasw things, amd this is very simple.
Title: Re: Advice for BASIC
Post by: xMarminq_ on November 26, 2016, 11:53:17 AM
So highscore systems would be saving the score values to strings and do a ton of if string < or > or = and then move them down?
How about making the arrow direction constant?
I always feel I have the concepts, but I always need your guys help in making them in action.
Title: Re: Advice for BASIC
Post by: Dream of Omnimaga on November 26, 2016, 09:45:12 PM
For highscores, have you considered storing them in a list? Ideally with a custom name, such as LHELLO .
Title: Re: Advice for BASIC
Post by: xMarminq_ on November 27, 2016, 03:37:59 AM
Quote from: xMarminq_ on November 26, 2016, 11:53:17 AM
How about making the arrow direction constant?

Pls someone tell me!

Would it be a get key and then repeat until another button is pressed?
Title: Re: Advice for BASIC
Post by: Dream of Omnimaga on November 27, 2016, 04:43:30 AM
Do you mean how when you start holding down the arrow, the character moves once, then stops moving for half a second, then suddenly starts moving rapidly non-stop until you release the key? Because it's impossible to remove the key delay in TI-BASIC. You would need to use C or ASM.
Title: Re: Advice for BASIC
Post by: xMarminq_ on November 27, 2016, 01:34:54 PM
Just one button sends it in a constant direction
Title: Re: Advice for BASIC
Post by: Dream of Omnimaga on November 29, 2016, 03:36:16 AM
In such case, you need to use an extra variable. That variable is zero upon game start. If you press Left, then the variable is set to -1, if you press right, then it's set to 1. You could make it so that if you press the opposite direction than the one you're moving in or press a different key then it sets it to zero. Then when the character needs to be moved around then you add the variable value to the character position.
Title: Re: Advice for BASIC
Post by: Unicorn on November 29, 2016, 04:10:09 AM
So, for example:


ClrHome
DelVar A
Repeat K=45
getkey->K
If K=leftarrowkey
-1->A
If K=rightarrowkey
1->A
If K=2nd
DelVar A
If A=1 and X<26
X+1->X
If A=-1 and X>1
X-1->X
Output(1,X"*
End

Just add the keycodes and erasing the text ;)
Title: Re: Advice for BASIC
Post by: xMarminq_ on November 29, 2016, 04:19:48 AM
How about up and down?
Title: Re: Advice for BASIC
Post by: Unicorn on November 29, 2016, 04:34:33 AM
Quote from: xMarminq_ on November 29, 2016, 04:19:48 AM
How about up and down?
Same thing, just change the Y instead of X and make the bounds 10 instead of 26.
Title: Re: Advice for BASIC
Post by: xMarminq_ on November 29, 2016, 12:29:04 PM
How about walls the sprite cannot pass?
Title: Re: Advice for BASIC
Post by: WholeWheatBagels on November 29, 2016, 03:46:09 PM
You could have a matrix that has the map in it.

(see here http://tibasicdev.wikidot.com/maps)
Title: Re: Advice for BASIC
Post by: xMarminq_ on December 09, 2016, 02:31:54 AM
Quote from: Unicorn on November 29, 2016, 04:10:09 AM
So, for example:


ClrHome
DelVar A
Repeat K=45
getkey->K
If K=leftarrowkey
-1->A
If K=rightarrowkey
1->A
If K=2nd
DelVar A
If A=1 and X<26
X+1->X
If A=-1 and X>1
X-1->X
Output(1,X"*
End

Just add the keycodes and erasing the text ;)

Do I need a new variable for up/down?
Title: Re: Advice for BASIC
Post by: xMarminq_ on December 24, 2016, 10:49:33 PM
Bump

How do you set a a one character sprite at a coordinate?
Whats the star at the end of the code I quoted?
:banghead: Too many questions
Title: Re: Advice for BASIC
Post by: E37 on December 24, 2016, 11:26:48 PM
Quote from: xMarminq_ on December 24, 2016, 10:49:33 PM
Bump

How do you set a a one character sprite at a coordinate?
Whats the star at the end of the code I quoted?
:banghead: Too many questions
The star appears the be the multiplication sign. Nothing special.

A one character sprite? Just do Text(x,y,"insert some string or character here")
If you want to do it on the home screen, Output would do fine.

Hope that helps!
Title: Re: Advice for BASIC
Post by: xMarminq_ on December 24, 2016, 11:27:55 PM
 :thumbsup:
Title: Re: Advice for BASIC
Post by: Dream of Omnimaga on December 30, 2016, 06:45:36 AM
I am a bit late, but if you use Text(-1,X,Y,"C" instead of Text(X,Y,"C", then large fonts are used.
Title: Re: Advice for BASIC
Post by: Unicorn on December 30, 2016, 08:58:45 AM
Quote from: xMarminq_ on December 09, 2016, 02:31:54 AM
Quote from: Unicorn on November 29, 2016, 04:10:09 AM
So, for example:


ClrHome
DelVar A
Repeat K=45
getkey->K
If K=leftarrowkey
-1->A
If K=rightarrowkey
1->A
If K=2nd
DelVar A
If A=1 and X<26
X+1->X
If A=-1 and X>1
X-1->X
Output(1,X"*
End

Just add the keycodes and erasing the text ;)

Do I need a new variable for up/down?

If you want it to be able to go up/down whenever, yes. Just be sure to change the bounds checking.
Title: Re: Advice for BASIC
Post by: 123outerme on January 20, 2017, 05:54:23 PM
Being that I've just released a large RPG calc project, I'd like to comment on this (I'm no means an expert obviously, but I have had some experience)
My experience is that most of the work going into an RPG will be on the content. Maps, story, items, etc. take up a lot of the work. In fact, I would design the world you're trying to build first, preferably on paper, before you even start work on your engine. You'll always have to keep in mind the limitations of your skills and the platform you're working on, but it's worth it.

That is, if you want to work on an RPG. You're going to be programming an RPG, which means, like I said, content is king. A small RPG first, where the time to make content about equals the time to make the engine, is your best bet to learning the type of RPG you want to make. I believe that your end goal in this small RPG is to learn how to organize your code, seperate your games into multiple interconnected pieces (aka overworld, battle screen, menu screen, map screen, etc.) and get it all working. After that, if you can take on the monumental challenge (It took me almost 1.5 years to finish up Sorcery of Uvutu, including the time that I took off of the project, sick of making maps)., I'd say go for it. Once you start to take on this large project, I'd always keep a side-project on the backburners, so while you're taking a break from your RPG, you have another way to refine your skills or generate new ideas. For a day or so a couple of months ago, I took time off of developing SoU to start work on Tourn 2, a fighting game. Different genre, so a way to break up the sluggish progression of your RPG with a project you can see results from immediately.
Title: Re: Advice for BASIC
Post by: Dream of Omnimaga on January 31, 2017, 10:39:32 PM
Yeah I really recommend starting with just 1 dungeon, even if it meeans no village/NPCs, first. Else if you start with something massive, you'll end up never releasing your first game.

You also need to keep as much walking engine content as possible outside the main walking loop, which should only include key detection, checking if you're heading outside the screen and if the next tile is solid. If that's the case or if the key pressed is CLEAR or ENTER then the loop should be exited and whatever needs to be done should be done outside. That will keep the map engine fast.