Post by: Qwerkey on August 16, 2018, 11:13:18 am
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]
- ': External modules: ---------------------------------------------------------------
- '$INCLUDE:'InForm\InForm.ui'
- '$INCLUDE:'InForm\xp.uitheme'
- '$INCLUDE:'GravitationSimulation.frm'
- ': Event procedures: ---------------------------------------------------------------
- SUB __UI_BeforeInit
- SUB __UI_OnLoad
- SUB __UI_BeforeUpdateDisplay
- 'This event occurs at approximately 30 frames per second.
- 'You can change the update frequency by calling SetFrameRate DesiredRate%
- BeginDraw PictureBox1 'Replace PictureBox1 with the actual ID of the desired PictureBox
- 'Drawing code goes here
- EndDraw PictureBox1
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
Post by: FellippeHeitor on August 16, 2018, 11:52:10 am
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.
Post by: Qwerkey on August 16, 2018, 12:06:27 pm
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
Post by: FellippeHeitor on August 16, 2018, 12:23:58 pm
Post by: Qwerkey on August 16, 2018, 12:45:40 pm
Post by: Qwerkey on August 17, 2018, 05:43:17 am
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
Post by: FellippeHeitor on August 17, 2018, 07:15:52 am
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.
Post by: Qwerkey on August 20, 2018, 12:26:55 pm
Post by: Qwerkey on August 22, 2018, 06:04:24 am
Post by: Qwerkey on August 24, 2018, 06:57:16 am
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
Post by: Qwerkey on August 25, 2018, 09:43:28 am
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
Post by: Qwerkey on August 25, 2018, 12:52:44 pm
No extra work required for anybody. Richard
Post by: FellippeHeitor on August 25, 2018, 11:37:31 pm
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]
- Control(myControlID).Redraw = True
That should do it.
Post by: Qwerkey on August 27, 2018, 06:34:15 am
Post by: Qwerkey on September 01, 2018, 10:56:04 am
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