DSP Robotics Support

tulamide wrote:A simple tip, if I may. You both are trying it pixel-based (grid-based). In game development, it is all about moving graphics around as fast as possible, and as similar as possible. The latter means, the game should behave the same, no matter if played on a 1 GHz processor, or a 3 GHz processor. Makes sense, right?

Thank you, Tula, for someone with absolutely no formal training in programming languages (me, noob)...I do learn new things every day.

same here.

Thank-you

I’m so sorry but I can’t make this work tulamide. I know almost no Ruby though so I guess it’s not surprising

I have some questions:

@t += dt * @rate :

- dt is undefined in Ruby so I substituted fixed values, like 0.01, 0.1 etc but I suspect there’s more to it than that.
- What stops the above counter and why wouldn’t it carry on forever?
- dt is a small time increment added on every draw call. Does this mean on every screen refresh or only when a change of input maybe triggers a re-draw? If it’s the latter wouldn’t we again be dependant on green timing?

It would help me bigly if you could throw together a working demo so I could see where I’m going wrong and hopefully learn something.

Cheers

Spogg

You really should start learning Ruby Spogg . . it takes Flowstone to a whole new level! I started learning it about 18 Months ago and I hardly use greens at all now. It's not difficult at all . . (I'm a similar age and background to you by the way )

Spogg wrote:I’m so sorry but I can’t make this work tulamide. I know almost no Ruby though so I guess it’s not surprising

I have some questions:

@t += dt * @rate :

- dt is undefined in Ruby so I substituted fixed values, like 0.01, 0.1 etc but I suspect there’s more to it than that.
- What stops the above counter and why wouldn’t it carry on forever?
- dt is a small time increment added on every draw call. Does this mean on every screen refresh or only when a change of input maybe triggers a re-draw? If it’s the latter wouldn’t we again be dependant on green timing?

It would help me bigly if you could throw together a working demo so I could see where I’m going wrong and hopefully learn something.

Cheers

Spogg

Indeed it is not surprising. How do you think to understand a language, if you are not yet familiar with its syntax? That's like trying to speak German without ever having learned how a German sentence is constructed.

"My lovely Mr singing club"

Does this make any sense to you? Of course not. It is a German saying that I translated literally, word by word, without considering English syntax.

"Mein lieber Herr Gesangsverein"

Somebody from Britain had a few German lessons in school, but 20 years later, when we met, he couldn't remember much from it, and the few bits in his mind were additionally twisted. And so he said "Ich bin ein Spiegelei auf dem Boden". Now, this doesn't make any sense. It means "I'm a fried egg on the floor". Obviously he once had a lesson where somebody let fall a fried egg. But he couldn't remember the whole sentence and his mind filled in the gaps.

What I want to say is, learn the syntax first. How Ruby expects you to talk to it, and how Ruby will talk to you. Aspects like local-, global-, class- and class-instance-variables, constants, methods, arguments, the "everything is an object" concept.

Then you will be able to learn from other people's code.


The post I made was not about a fully featured, working example. It was about the principle. You could do the very same in green as well. Just the principles of time-based movement. So, of course it doesn't work right out of the box. I didn't see the need for code that doesn't deal with the principle of time-based movement, but with setting colours or drawing something.

Having said all that, I have made a (VERY SIMPLE!!) example. A fully working Ruby example (only tested in v3.0.6). I interrupted two works for other people on the forum (you know one of them), so I hope they don't get mad at me for the delay.


And Tiffy, I'm sorry for hijacking your thread. I hope you aren't angry and can learn from the example

Thanks so much tulamide, that looked like a lot of work and I didn’t expect that, but I really appreciate it very much.

Yesterday I started to look into Ruby, because I had no idea what I was doing with your code, and I can now see just how impressive a language it is.
I can also see that I had no chance without even the basics in place. However, my pathetic and frustrating attempts have aroused my curiosity and desire to learn.

Cheers

Spogg

[quote=And Tiffy, I'm sorry for hijacking your thread. I hope you aren't angry and can learn from the example [/quote]

First of all, Tula, thank you so much for your help and all the effort you put into helping others.

Not at all, how can I ever be 'angry' at someone offering help?

I just want to explain the reason why I opened this main post under one heading and also under "General" and not under "User Examples" - I really don't want people to get a misunderstanding about this. I did so because I consider my uploads as being too incomplete (as I am still in a learning process) to mess up all those nice User Examples from the Gurus. It is not that I am trying to be different, selfish or separate from others, it is the only reason, I have nothing against anyone really I don't. On the other hand (this was also one of my considerations then), if Admin one day decide to delete all the crap I uploaded so far, it would be just a matter of pressing one 'button' as they are all in one handy location - and as for myself handy in one location if I ever lose some schematic I can quickly download it from this forum.

BOOLEAN SWITCH & BOOLE TO TRIGGERS:

Although the “Boolean Switch” (i.e. the Boolean Data Component) is a simple concept it is also extremely useful. Thus, I posted this for those of us not officially trained in Electronics or Programming.

When you switch the “Boolean switch” On (i.e. to True) it provides a Trigger on the rising edge (i.e. positive going edge) of the square wave pulse and when you switch it Off (i.e. to False) is also provides a useful Trigger on the falling edge (i.e. negative going edge) of the square wave pulse. Thus, the complete square wave pulse from the “Boolean Switch” (i.e. Boolean Data Component) provides us with two useful Triggers (You can verify this by connecting a “Trigger Counter” primitive to its output) which can be individually separated from one another – and sometimes you only need one of those two Triggers, not both.

There are instances when you need just one (or both, depending on the application) of those two Triggers from the “Boolean Switch” to Reset/Switch Off/Switch On something else elsewhere in a larger schematic. This is where the two “Boole to Trigger” primitives comes in very handy. Using either the “Boole to True trigger” primitive or the “Boole to False Trigger” primitive we can extract any of the two Triggers or both Triggers as shown in the simple schematic provided below. This is handy when for instance you want to Reset/Switch Off/Switch On another section of a schematic on a specific instant of time (i.e. rising or falling edge of the square wave) by using the square wave pulse from the “Boolean Switch” together with the “Boole to True Trigger” or/and “Boole to False Trigger.”

I have found this useful on many occasions and I thought that I should share – not for the guru’s as they know this very well and some may even laugh at this.

Note: Sometimes us novices notice a Trigger on the Falling Edge (i.e. when switching to False) coming from the “Boolean Switch” and then (for some unknown reason) we may temporarily (I hope) get confused (sometimes the most elementary things in life can confuse us) by thinking that the specific Trigger during the Falling Edge can only be used to Reset/Switch Off some part of a schematic but that is not true as that same Trigger (i.e. when switching to False) can also Switch On some other section of a schematic. A Trigger on the Positive going Edge or a Trigger on the Negative going Edge are both just a Trigger at different instances of time. (Thanks to Tulamide who directed my attention to the importance of triggers some time ago. Triggers can be extremely useful but unwanted or excessive Triggers can also be a nuisance – also see Troggs Trigger Tutorial).

STEREO AUDIO MP3 PLAYER-AMPLIFIER v112G (PICTURE ONLY):

Changed the GUI of the Stereo Audio MP3 Player.

Love the Boole Switch. Have used these in my projects when that special condition arises.

The 'Trigger Counter' is another of the most used PRIMs I use during Dev. I've forgotten who wrote THE article [on the SM forum], but it is a fundamental concept within the schematic.

If those are 'your' Boole Switches, Tiffy. Big Thanks.