Mastering InForm: building "Gravitation Simulation"

[Qwerkey]

This post is directed at Fellippe (alone).

Fellippe, you told me elsewhere that images in InForm are hardware-accelerated, as opposed to software.  But when I tried to load an image as hardware-accelerated, it would not display.

Code: QB64: [Select]

1. DIM SHARED Earth&
2.  
3. ': External modules: ---------------------------------------------------------------
4. '$INCLUDE:'InForm\InForm.ui'
5. '$INCLUDE:'InForm\xp.uitheme'
6. '$INCLUDE:'GravitationSimulation.frm'
7.  
8. ': Event procedures: ---------------------------------------------------------------
9. SUB __UI_BeforeInit
10.     Earth& = _LOADIMAGE("The Earth.png", 32)
11. END SUB
12.  
13. SUB __UI_OnLoad
14.  
15. END SUB
16.  
17. SUB __UI_BeforeUpdateDisplay
18.     'This event occurs at approximately 30 frames per second.
19.     'You can change the update frequency by calling SetFrameRate DesiredRate%
20.  
21.     BeginDraw PictureBox1 'Replace PictureBox1 with the actual ID of the desired PictureBox
22.     'Drawing code goes here
23.     _PUTIMAGE (200, 200), Earth&
24.     EndDraw PictureBox1
25. END SUB

In this code, you get a nice picture of the earth, displaced in the PictureBox1.  If, however, the line Earth& = _LOADIMAGE("The Earth.png", 32) is replaced by Earth& = _LOADIMAGE("The Earth.png", 33), nothing is displayed.  If it is a requirement to only load as type (,32) then I'm happy to do so.

I'm sorry that you have keep spoon-feeding the clinically stupid.

Richard

[FellippeHeitor]

Hi Richard,

All controls are rendered as hardware images on InForm generated apps, but the PictureBox control's drawing surface is a software image internally identified as .HelperCanvas, so you must draw to it (and _PUTIMAGE software images as well) which InForm will later convert to hardware images to display.

That aside, I see you're continuosly redrawing the PictureBox in SUB __UI_BeforeUpdateDisplay, but that's not required, as the PictureBox control will retain its contents across cycles, unless you manually use CLS in a BeginDraw/EndDraw block.

Another thing: if, at design time, you specify an image file to be loaded into a PictureBox control, that image will be loaded automatically when the program is run, without you having to manually use _LOADIMAGE/_PUTIMAGE. If you choose to do so, you'll notice that there will be a call in the .frm file to InForm's internal method LoadImage, which will do just that:

Fellippe.

[Qwerkey]

Thanks, Fellippe, I understand.

To All Other Memebrs:  Fellippe & I will use this post to disuss my InForm requirements and he has to do a lot of teaching, so you do not need to waste your time revisiting this as the number of replies increases.

While you were replying, I discovered the CLS thing myself.  As it seemed software images were required, I assumed that you had already coded the CLS per cycle somewhere else.

This code is only a trial (for me to see how images are working).  In the actual program, the Earth and other Solar System bodies will be moving (under Newtonian Gravoty) and so the image printing will need to be updated regularly.

Richard

[FellippeHeitor]

Post remains open, of course! The more folks learning/using Inform, the merrier.

[Qwerkey]

Everybody is, of course, welcome, but under no obligation!

[Qwerkey]

Ah, Fellippe, I think that I have managed to fall at the first hurdle.

The program which I am creating requires _MAPTRIANGLE (3D) - at least I had hoped to do it with _MAPTRIANGLE (3D).  But we found from Petr the other day that _MAPTRIANGLE (3D) requires hardware imaging.  And we found yesterday that InForm images into a PictureBox must be software.  I have verified this in my trial program: _MAPTRIANGLE (3D) does not work with InForm.

The program I'm creating is an updated version of an old SDL program of a general gravitation simulation.  In that original program, I used my own method to convert the 3D coordinates into the 2D screen dimensions.  It looks as if I'll have to use that method here - rather a pity as I had wanted to remove the conversion routine away from the calculations routine.

Your users always come up with impossible requirements.

Richard

[FellippeHeitor]

Ah, Fellippe, I think that I have managed to fall at the first hurdle.

The program which I am creating requires _MAPTRIANGLE (3D) - at least I had hoped to do it with _MAPTRIANGLE (3D).  But we found from Petr the other day that _MAPTRIANGLE (3D) requires hardware imaging.  And we found yesterday that InForm images into a PictureBox must be software.  I have verified this in my trial program: _MAPTRIANGLE (3D) does not work with InForm.

The program I'm creating is an updated version of an old SDL program of a general gravitation simulation.  In that original program, I used my own method to convert the 3D coordinates into the 2D screen dimensions.  It looks as if I'll have to use that method here - rather a pity as I had wanted to remove the conversion routine away from the calculations routine.

Your users always come up with impossible requirements.

Richard

A while back user Unseen Machine did some hacks to his local copy of InForm to be able to use OpenGL 3D statements in an InForm program. It was quite cool. I assume it could allow using hardware images as you need to.

It could also be something else entirely, and I'll be glad to investigate, but maybe he can come along and remind us what tweaks were required.

[Qwerkey]

Fellippe, I attach the latest Form & bas.  The  SUB __UI_KeyPress subroutine now has many CASES from all the 77 text boxes which the user will fill in.  And this is by no means complete yet.  I don't mind carrying on with Copy & Paste & Edit, but if you had any ideas how to trim things down, please let me know - don't spend a lot of time on it.  With the given files, you can Click on the 11-body simulation Radio Button, fill in how many bodies you want and then fill in individual body parameters (press Return after each entry) and when all bodies are complete, the program will go to the Execute sub-rotuine.  Thanks, Richard (generator of mamoth projects).

[Qwerkey]

I have completed the input checking using the existing Control names, so no extra work required from Fellippe (nothing could be done, anyway we assume).  I am now pressing on with the complicated stuff of the gravitational execution and display in absence of _MAPTRIANGLE(3D).  Richard

[Qwerkey]

If you are interested, I have combined the gravitation code into the InForm Gravitation program.  If you run this preliminary code, the only working buttons are Execute/Stop & Exit.  Pressing Execute will start the Solar System moving, the initial data are taken from JPL Ephemeris data of 07 Jun 2013, and then all motions are by Newtonian gravity.  The sun (yellow) is in the centre and moves but little, Mercury is grey/blue, Venus is orangy, the Earth is the Blue Planet moving along with the grey/yellow Moon, and Mars is red (of course!).  Jupiter is pinky/white and her moon Elarus spirals around her.  Saturn is grey, Uranus light blue and Neptune royal blue.  Pluto is in the system but can't be seen in this view as she is too far out and at a large angle to the ecliptic.  After about 7 minutes (dependent upon machine speed), Uranus completes one revolution and Neptune reappears in the distance.  Isn't Mr. Newton a marvel?

I now have to complete all the InForm side of the project, so there is proper user input: setting all parameters and scenarios.  Thanks, Fellippe, I'll look into your efficient array handling method.  This will be a Captain Oates project (I may be some time).

The calculations run slower than outside InForm (I believe).  I'll investigate by how much.  The final graphics will have displayed size dependent upon perspective distance (size is not related to actual body size).  If only we have _MAPTRIANGLE(3D), it would do all that automatically!  The graphics sit beautifully behind the InForm controls.  I say, again, it is a marvel Fellippe.

Richard

[Qwerkey]

O pequeno problema de hoje (I have no skills in Portuguese, that's Google Translate's best effort).

With the attached Form/.bas, the Time and Number of Cycles RadioButtons should change the shown and allowed controls in the Simulation Limit Frame below.  Clicking on Number of Cycles RadioButton should change to Number of Cycles Label and Textbox which it does first time, and then clicking on Time RadioButton should change back, which does not happen - although after a long period of time it may happen.  The two RadioButtons no longer work properly.  I suspect that the problem arises because two pairs of the controls lie on top of each other, even though two of them are Hidden and Disabled.  Will I not be allowed to do this?  The code lines pertinent are at line 282.

Incidentally, if you click Execute, the Solar System display is improved but don't spend time on that.  None of the Frames are in their final positions.

Richard

[Qwerkey]

OK, solved that one.  I've had to create two separate Frames - one for Time Limit Input and another for Cycles Limit Input.
No extra work required for anybody.  Richard

[FellippeHeitor]

Thanks for the effort with Portuguese, Richard. Much appreciated.

You know how UiEditor has some internal "dialogs" that pop up when needed inside the main interface? These are the Open dialog and also the Z-Ordering edit dialog. The way I have them currently is to keep them always visible (as in not .Hidden = True) but I relocate them when not needed to coordinates off-screen.

I admit that two controls positioned exactly on top of each other should not affect each other if one of them is .Hidden; that's something worth investigating and I thank you for your report.

Now for a control that doesn't seem to update immediately, although I have tried to detect most changes automatically in the drawing module, you can resort to a force update request. Do so by setting the .Redraw property of a control to True:

Code: QB64: [Select]

1. Control(myControlID).Redraw = True

That should do it.

[Qwerkey]

Fellippe, I have just completed the coding for the progress bar.  Such simple code (one line!) and it works beautifully, as all things InForm.  Richard

[Qwerkey]

My (mammoth) Gravitational Simulation program is getting near to completion.  As it is an InForm program, I'd like to show off InForm to its best, but I'm not a very good graphic designer.  So, I'd be grateful if you give this a try and let me know of improvements.

The program should be more-or-less self-explanatory, but I will issue proper instructions with the released version.  You can simulate The Solar System (default), input body data manually, perform a simulation of a collapsing star system (this will proceed very slowly to begin with, so don't spend any great time with this), load from a previous file or (in the final version) run a demo.  These are selectable at program start, and other conditions can be set.  I have not got the demo part working yet.  That will be a project in itself.

Manually putting in body data is quite a skill and will often lead to the body system completely disappearing (or appearing to), so probably don't seriously try that at the moment.  However, under the 11-body manual selection Click on Allow Collisions and Allow Computer to Set Values, then Execute.  You get some quite interesting patterns.  You may notice a popping sound when bodies collide.

Put the extracted folder into the QB64 folder.

Thanks, Richard