#propboe

I like to go through each step of my thought process just in case someone else is coming across the same issues.  At this point, my biggest issue is spaghetti code.  So the latest suggestions from Roy and Whisker were that I needed to get rid of the stack overflow issues.  

Essentially with my last code, it was sent out from one function to another to another, without ever coming back to step one.  So you'd end up with a queue of functions - like premain, main, standby, hunger, maintwo, etcetc.  And eventually the program would stop working.

So I moved around a few items:

I renamed Premain to Initialize.  And called it once in the Main function.  

I also realized that I was repeating the age analysis with every hunger/poo/standby pub - so I decided to just have the program set that variable in the Main function.  This made the action pubs much shorter.  Here's an example of how those look now:

So you'll notice that I did a few more things.  

First I took out the debug display and made a new function out of it - then called it from the Main function (as Display).

Then I took out all of the MainSecond/MainThirds etc. and moved the comparisons (if > x, then do this) to the main function.  This was contingent on learning that when code gets to the end of that function, it goes back to where it was in the code that called it.

You'll also notice that instead of having the code write out (via text.str) action specifics, I took advantage of the uniformity of the Dat section.  For example.  If a pet was hungry:

Instead of setting Function as @VYHungry - Main Pub's already set Function as @VY way in the beginning.  So instead of depicting VYHungry and needing to change that variable anytime it was sleepy or pooing, I used @VY as a starting point.  And fortunately, I had already standardized the spacing and number of responses by age in the DAT section.

So I'd know that from the first line of @VY or @Y or @A:

+ 0 = Standby face 1

+ 9 = Standby face 2

+ 18 = Hungry face 1

+ 27 = Hungry face 2

And so on.  So I made the action pubs all go off of the first DAT line of the correct age.  I was able to shorten up the code for the button push monitoring as well with the same DAT section monkeying!

Hardware Hookup: VGA + 5position switch on the Propeller Board of Education

Code: http://pastebin.com/WSXtq5RF

So now, that we've analyzed the flow, there's another portion, and that's monitoring the button push.  This function was called in the PreMain function.

So we use the Spin command "Case" to monitor the button.  We first make the local variable ButtonPush monitor the input coming into pins 0 to 4 (which is where the 5 position switch connected to).

And what case does is essentially state, okay. If buttonpush sees something coming through pin Zero (%11110 - where 0 is pushed), Funct is set at that Dat point and then whatever is at that Dat point is written. 

Game-wise, say you were to press the switch to the right.  The code would see 0 being pressed.  It would then direct to the statement "Feed Me?".  It would go to WaitPub:

It says - look at the center switch until it's pressed.  When it is pressed, then take whatever dat point we were at, add 21 to go to the next dat point, and print that out, then go back to where you were in the code.  In this specific instance, that would be going to ZeroPub:

So here, we look at Exp again and depending on what it is, it shows a differently-aged eating animation.  It adds 5 exp to the scorecard for your mad skills at feeding the pet as well!  The emoticons are referenced in the Dat section via Blurb, Blurb + 9, etc.

So the subsequent ones follow the same equation (poo/sleeping) - and each time you feed, clean, or allow for sleep - you get 5 exp!  And yes, you can power level :p

But now. I need to improve the code!

Hardware Hookup: VGA + 5position switch on the Propeller Board of Education

Code: http://pastebin.com/WSXtq5RF

Okay so! We looked before at whether the pet was sleepy or not.  If not, we go back to the Main function:

And if the pet was sleepy:

Again, same exact code as Hunger and Poo Pub.

So you can see there's a lot of room for improvement here.  Since the code run is pretty much all the same, I could probably put it all in the Main Pub - with the Main pub referencing other functions. *ponders*

Hardware Hookup: VGA + 5position switch on the Propeller Board of Education

Code: http://pastebin.com/WSXtq5RF

So we finished up with the Hunger and StandbyPub yesterday.  Today:

So MainSecond was called by both Standby and Hunger, and again runs the debug values.  Then it looks at the Poo values.  If less than 50, it goes to MainThird and if greater than 50, it goes to the PooPub where the pooing faces are made:

Main Third runs the debug values again and then compares the Sleep value.

And with PooPub - it pretty much looks exactly like HungerPub.  It looks at the pet's Exp level and depending on that, Function (the variable) is different.  It then shows the face and goes to Main Third.

Part 4 next and sleeping!

More code analysis for the propeller-based pet game:

Again, the hookup is per the VGA and 5 position switch posts, and we're continuing with my flowchart of what's going on with the pet game.

Code: http://pastebin.com/WSXtq5RF

So we're to the increment levels and hunger stage:

The top bit is where I wanted to have some form of debug text where I could see the values of the pet's hunger/poo/sleep levels to make sure the faces were how I'd expect them to be.  And since I knew that at the end of this logic tree, this main function would always run, I knew then I'd always see the text in at least one spot time-wise.

Then remember where I talked about the balance of numbers and incrementing values for Hunger/Poo/Sleep?  Here I decided to increment Hunger by 2, Poo by 3, Sleep by 1.  I figured it'd probably poo more than be hungry, and be both more than sleepy.

So after that, I checked to see if the Hunger value was greater than or less than 75.  If it wasn't hungry, I'd have to go to the Standby Pub and if it was hungry, it'd go to the HungryPub, which was responsible for making the hungry face.  

Standby Pub:

Hungry Pub:

So. I had the StandbyPub show the debug numbers again.  Then in both Standby and Hunger, I had them check to see what the Exp level of the critter was.  Depending on that level, the pet would either be a youngn', teen, or adult.

And then when it had gone through two iterations of showing the face, I had both going to MainSecond (or to the Poo portion)

If you've been following the generation of the Propopet on First Spin, you'll know that it's a Prop-based Tamagotchi style pet that I wanted to write up for funsies:

Using the hardware hookups from my previous posts on setting up VGA on the Prop and 5 position switch, I was able to make my first draft of a fairly functional game. But I should clarify that this is spaghetti code - not at all an indication of good coding habits :p.  I just wanted something on paper, so to speak.

So here's the code: http://pastebin.com/WSXtq5RF

I'll do some preliminary analysis by showing a flowchart of how my logic went:

So if you look at the code.  My initialize section looks like this:

As always we set up the CON section, put any objects in the OBJ section that we'll use, and variables into the VAR section that we need.  In the Premain or Initialize step, I let the object know which pin starts everything off (pin 8), I clear the screen with text.out(00) and then start a new cog that monitors the 5 position switch.

Then I decided to set all of the values to 0 for Hunger, Poo, Sleep, and Exp.  The range is 0 to 100 (or more) where 0 is not hungry and closer to 100 is hungry.  Same goes for poo and sleep.  Then I call on the Main function.

One thing to note with this is that there's a fine balance between when you want the pet to get hungry vs poo vs sleep.  Clearly you don't want the pet to be hungry, pooing, and sleeping at the same time.  So how you set your ranges is based on that.

Part 2 next!

So as we've been chatting on First Spin, we realized we hadn't addressed the TV/VGA capabilities on the Propeller.

You notice that on the Propeller BOE (the board I use most often) - we have a VGA connector on the left.  Per an appnote: "This is a convenient port for Propeller microcontroller applications that display data and graphics on devices with VGA inputs, such as certain computer monitors and televisions.  Signals are applied to the VGA driver circuits by running jumper wires from Propeller I/O pin sockets (15) to VGA inputs on the 2x10 socket (18).":

And then in the middle you notice those two headers.  On the left is the "VGA Socket" and per the appnote: "The VGA sockets are connected to active-high, color-coded LEDs and buffered inputs that drive the VGA Video Output Port (3) channels.  

R1 and R0 are red channel inputs and drive red indicator LEDs.  

G1 and G0 are green inputs and have green indicator LEDs

B1 and B0 are blue inputs and have blue indicator LEDs.  

The horizontal and vertical channel inputs are labeled H and V, and have yellow indicator LEDs."

We've used the LEDs in other projects too - never knew there was a reason to their coloring (Though I should have guessed as such :p)!

Anyway - in order to use the VGA properties of the pins/board - you need to connect the VGA header to the pins on the Propeller.  The following link is a good resource for figuring it out but in case you don't want to download it - the gist is:

And you keep connecting the pins in that left header to Propeller pins until you finish with the V header slot.

Code: http://obex.parallax.com/objects/70/

Now in the code you'll need to change the line text.start(16) to text.start(8) - because we've changed the VGA to start working from pins 8-15.  Note, for this code, I believe all wires have to be consecutive.  You can't go pin 4 for one thing, then pin 8 for another.

What it looks like:

So there's a new module in the Tymkrs house - the polar heart rate receiver!  It seems that this works with the polar heart rate transmitter which you put around your chest - elastic waistband style.

According to the KickStart:

Receives heart beat signals from a compatible sensor transmitter

Indicates a received heartbeat signal using a LOW/HIGH output signal

Wirelessly interfaces to transmitter with a range of up to four feet

The Polar Heart Rate Receiver is designed to receive heart beat signals from compatible Polar heart rate sensors. Together, the sensor and receiver provides a low-cost and convenient heart rate monitoring system that can be connected to most any microcontroller. Example uses include home exercise and sports training.

Hardware:

The code can be found on the site as well and when you run it, you get:

So everytime your heart beats, it shows up on the serial terminal.  I think it may be more useful if something happens where it counts how many beats you have and tells you your beats per minute.