Long time BASIC programmer now using thinBasic

[BradleyH]

Hi fellow programmers -

I was looking at several BASIC versions in the past year.
My aim was to see if there's a suitable Windows BASIC so
my electronic circuit simulator could run on PC's.

For 20 years I've used a Macintosh Basic called FutureBasic.
It served well as I created a number of useful programs with it.

I've worked on my electronics simulator until it now has 9,000
lines of code.

I tried demo versions of XBasic, PureBasic, GLBasic, Basic4GL,
FreeBasic, RealBasic, etc. These are popular versions I see
on various lists at websites having to do with BASIC
programming.

ThinBasic seemed to be newer and not as well-known as the others.
Nevertheless ThinBasic turns out to have a well-designed
programming environment. It has a large command set.
And it's free. (So far.)
I was impressed at your sample scripts.
And also the YouTube videos showing eye-popping
animations done in ThinBasic.

Anyway I've spent the last two months converting my program
to ThinBasic syntax. It's at a point where it's starting to resemble
the version I made on the Mac.

I still have a ways to go before the PC version is fit for
marketing. I plan to follow through using ThinBasic.
It appears to have sufficient capacity for the job.

Thanks,

Bradley

[Michael Hartlef]

Hello Bradley,

welcome on the forum. You seem to have a nice app there. Which modules are you using for it?

Cheers
Michael

[zlatkoAB]

Hi Bradely...
Im interested for circuit simulator to.
If i understand you correctly this sim will be comercial?
is your sim based on net list interpreter ?

[BradleyH]

Thanks.
My circuit simulator can be seen in several videos I posted on YouTube under the name patientbrad.

As to what modules I use...

I quickly found out I need the UI and CONSOLE modules. Once I found out a console window is similar to a DOS window, I decided it was easiest to use that for my general purpose message box.

I added the UIAdv module because somewhere I read it has additional needed functions.

I added the FILE and FILELINE modules because my program reads circuits from disk. (These are in custom ascii format). I read that FILELINE is needed to make linefeeds compatible across Mac and PC and Linux platforms.

TBGL was vital to continuing this project in ThinBasic. (As I describe below.)

I added the MATH module even though I'm not certain I specifically need it for my program but only because my program does a few sines and cosines.

And to add more to my story...

My learning time was greatly condensed thanks to Lydia's
elaborate user interface (under she posted under the topic 'first ui').

Her code shows how to perform a great many menu functions
which I use in my own program. I would have needed a long time
to locate the tutorials telling what's the proper syntax and sequence
for setting up the menu, window, user-interaction, etc..

However all I had to do was to start with Lydia's program...
Then simply substitute my own titles, etc.
Thank you Lydia.

I also want to mention the speed increase when I switched to using TBGL.

My electronic circuit simulator draws 2D shapes of various kinds.
The aim is to use simple shapes to achieve a high frame rate.

The regular ThinBasic command set appeared sufficient.
It even has an arc-drawing command. (Arcs are useful to portray
lines of flux around an inductor.)

So I figured out the proper syntax for drawing 2D primitives.
I was hoping I could get by without needing to learn TBGL commands.
After all I didn't need to draw 3D, nor use textures, shading, lighting, etc.

After a couple weeks of conversion effort, I got my animation to run.

And the frame rate seemed to be fast enough.
I was getting 20 frames per second with a single wire on the board.

However when I added another wire...

The frame rate dropped to half as fast. I added another wire and it was
a third as fast. Four wires yielded only 5 frames per second.

I was disappointed. I had more complex circuits I wanted to run
eventually. Already it was plain they would bog down to an
unacceptable crawl.

So it had me thinking I had to give up on ThinBasic.
Maybe I'd resort to splurging on PureBasic or GLBasic after all.
They are compiled BASICs.
Conversely we are told that ThinBasic is scripted not compiled.
For that reason we should not expect it to operate as fast as a
compiled Basic interpreter.

But I thought a little longer... and I wondered, how you did you get
those incredibly speedy animations in ThinBasic?

And I see in different places you mention TBGL as the module for handling
graphics and animations.

Then it dawned on me...

TBGL code must be in machine language, optimized for speed.

It was worth a try. So I looked up the TBGL commands for
drawing the shapes. I replaced the 'CANVAS' draw commands
with TBGL commands.
I build the polygon and vertex list through an iteration. Then
I execute them all by one use of the TBGL_DrawFrame command.

Wow! My frame rate shot up 50 times. Over 300 f per second.
Magnificent! Just the improvement I needed.

So I'm going ahead and porting my program to ThinBasic on the PC.

My PC machine is a 2003 vintage Compaq Presario. 1600 Mhz.
Even with more complex circuits I was getting 50 frames per
second.

But then I detected a problem: The CPU was burdened such that
the fan would come on and blow hot air as soon as it started
animation mode.

I was concerned that I would burn up the CPU prematurely.
So I used the DIALOG SET TIMER command so as to limit animation
rate to 20 iterations per second. I saw that command used in
someone's drawing program posted at this board.

There are many sample programs here which I found invaluable for
showing me how to use ThinBasic.

Funny how after needing years to grow in my ability to write code to
do what I want, that I expected it to be possible to convert 9,000 lines
of code to ThinBasic syntax in a week or two.

[zlatkoAB]

TBGL is Petr Schreiber implementation of OpenGL interface.
Yeah thinBasic is very cool language and simple enough to learn.
You somwhere in text say that is slow try once use python
interpreter then you will see what is slow,even thinbasic is
interpreted on the fly i bet that is faster then pyton.
I found somwhere source code for (i forget name) electronic
simulator written in python and as i espected nothing work... :roll:

so keep up the work on sim...

[Petr Schreiber]

Hi Bradley,

I am happy TBGL helped you rendering at desired speed. There are multiple approaches allowing to further tweak the speed, but I guess 300 FPS is quite enough.
As Zlatko correctly said, TBGL is built on top of OpenGL, but it is not just wrapper. It adapts to hardware it runs on to get optimal performance and offers lot of functionality beyond classic OpenGL.
Some parts are assembly optimized (thanks to our wizard Charles Pegge)

To prevent CPU melting, it is perfectly legal to use TIMER approach, it is generally accepted way. To minimize CPU footprint during the frame render itself, you may consider caching the geometry to display lists. This way you can perform drawing whole geometry using single line of code later. Another way are geometry buffers, which are highly optimized approach which can outperform even the display lists in many situations. To limit FPS to display refresh rate, you might consider using vertical synchronization, implemented as

TBGL_UseVSync(1)

To learn TBGL, feel free to ask, and you can also study from:
ThinBASIC Journal (http://community.thinbasic.com/index.php?board=160.0) - this is not just about TBGL, but also about ThinBASIC in general
TBGL website with articles and tutorials (http://psch.thinbasic.com/)
TBGL bonus pack (http://www.thinbasic.com/index.php?option=com_jdownloads&Itemid=95&task=viewcategory&catid=5) - lot of examples from various areas by me, Matthew, Mike Hartlef, Kent and many other coders.

Regarding CANVAS commands - even they can be fast. The key is to use double buffered approach - you draw just to memory and then you flush the bitmap at once.
The key to double buffering is correctly attaching the CANVAS:


Canvas_Attach(hDlg, %myCanvas, %TRUE) ' -- TRUE says we want double buffered drawing

' -- Draw here, nothing will update on screen as we draw in memory actually

Canvas_Redraw ' -- This will copy the drawing from memory to surface of the control in a snap

This approach is significantly faster, as there is no need to update screen after each graphic primitive is added, all is performed at once, which also looks better.

The advantage of TBGL could be the simplicity of various transformations - you can draw the whole circuit in custom coordinates, and just by moving camera (no calculation on CPU) you can zoom in/out or scroll.

I checked the videos on youTube, they looked good! We had similar software on University, but it completely lacked the animation of flow through the wires, which made it harder to understand comparing to your solution.


Petr

[BradleyH]

Hi Bradely...
Im interested for circuit simulator to.
If i understand you correctly this sim will be comercial?
is your sim based on net list interpreter ?


It's been a hobby project of mine for the past 15 years.

Only gradually have I thought it could be made suitable
to market.

I'm not a commercial distributor as yet.

I'm an electronics hobbyist who wondered 'Why is
there no computer program depicting what goes on
in, say, an oscillator circuit? It would clarify a lot
for students and experts alike.'

So the simulator started as an experiment in
programming. Bit by bit the program gained
user interactive features, diskfile saving,
reading, etc.

It's not perfect but it's at a stage where I think
I can hope to make it good enough to market it.

I believe it's unlike anything else out there.
It's totally original. And much easier to use than
Spice.

And it shows what's going on more clearly than
a few website Java applets I've played with.

[zlatkoAB]

When we can espect demo?

[BradleyH]

Replying to Petr Schreiber's message...

Great to get a welcome from one of the developers.

Many good tips in your message.

From the beginning one of the essential tutorials I needed has been your program demonstrating screen buffering. It shows a number of things including how to reduce screen flicker by using double buffering rather than single buffering. At first I had a problem with flicker when I was getting a speedy frame rate.

Your program also shows how to use DIALOG SET TIMER. Also how to create a CALLBACK routine to draw a frame.

In my early efforts to limit the frame rate I remember I tried using TBGL_UseVSync (1). Also used various other values based on RefreshRateInHz divided by Factor as the Help manual recommends.

However it didn't seem to change the speed of my animation.

I changed the usage to TBGL_UseVSync IIf (FrameRate < 5, 0, 1). It also does not alter the speed of my animation.

I guess I need to get more familiar with the way TBGL operates.

You suggested I cache my geometry to display lists. Also to use geometry buffers. Are you referring to TBGL_NewList / TBGL_PushMatrix/ TBGL_PopMatrix/ TBGL_CallList / etc.?

I have just discovered these commands and I plan to experiment with them. My hope is that it will allow me to store my stationary 2D shapes in memory and redraw them quickly.

Thank you Petr for your reply.

[Petr Schreiber]

Hi Bradley,



In my early efforts to limit the frame rate I remember I tried using TBGL_UseVSync (1). Also used various other values based on RefreshRateInHz divided by Factor as the Help manual recommends.

However it didn't seem to change the speed of my animation.


The VSync is very powerful, but the problem is driver can force it on or off, depending on factory setup or user setup. Maybe this happened in your case.
The most safe approach to limit frame rate is using timer - then you have direct control of top speed you draw images on screen.

Regarding geometry definition and its optimization - thanks for giving me idea what will the October TBGL article could be about :)
I will prepare comparison of available methods (immediate mode/models/GBuffers/display lists) for one sample geometry.


Petr

[Michael Clease]

Hello Bradley

Here is a simple example using

TBGL_Periodic function
Entity system
Display List
Texture

once the screen is built its just a case of changing the texture of the entity, the textures are a free set of IEC symbols which need some tweaking but good for an example.

[zlatkoAB]

It looks that this zip file is broken i cannot open this in 7zip
archiver?

[Petr Schreiber]

Hi Zlatko,

it seems there is problem with every ZIP attachement lately, I think it might be because of the recent forum database problem.
ZIP files hosted on the thinBasic server, but not bound to forum system, can be downloaded without single problem.

Before this gets fixed, I would like to offer "attachement on demand" service - email me the ZIP you need to attach here, I will upload it to my website, sending you link back.
I cannot guarantee I will react immediately, but will try. The email address is petrschreiber@thinBasic.com.

Another option is using free file hosting servers and again placing link here.


Petr

[Michael Clease]

Just a quick test its a 7z with a .rar extension so just rename - the .rar

[zlatkoAB]

Again is broken ,try use some free file hosting or if you maby have
website put them there...

[Michael Clease]

This should fix the download problem it seems to be adding an extra character at the start of the file.



Uses "FILE","UI"

Dim FileName As String
Dim Buffer As String
Dim FileHandle As DWord
Dim Status As DWord
Dim sFilter As String = "All Files (*.*)|*.*"

FileName = Dialog_OpenFile(0, "Open a file", DIR_GetCurrent, sFilter, "tBasic", _
%OFN_FILEMUSTEXIST Or %OFN_HIDEREADONLY Or %OFN_ENABLESIZING)

FileHandle = FILE_Open(FileName, "BINARY") ' Open file for reading
Status = FILE_Seek(FileHandle, 2) ' Set the current read position to 2nd byte in the file
Buffer += FILE_Get (FileHandle, FILE_LOF(FileHandle)-1) ' Length of file -1
Status = FILE_Close(FileHandle) ' Release File
Buffer += Chr$(0) ' add last byte

Status = FILE_Save(FileName, Buffer)

MsgBox 0, Filename+" Should be fixed now :)"