64-bit vs 32-bit app performance, heavy in 64-bit FP

[Rick C. Hodgin]

I've written a simulation for my Solar System Assembly Line theory in
Open GL. You can download the EXEs here. And please report any errors
in getting it to run.

32-bit:
http://www.3alive.org/ssal/earth_solar_system_open_gl__32_bit.zip
64-bit:
http://www.3alive.org/ssal/earth_solar_system_open_gl__64_bit.zip

You might need to install the Microsoft Visual C Runtime distribution
files if your machine doesn't already have them installed:

Microsoft DLLs (x86: vc_redist.x86.exe, x64: vc_redist.x64.exe):

https://support.microsoft.com/en-us/help/2977003/the-latest-supported-visual-c-downloads


And you can also view the latest simulation videos here if you don't
want to download and run the EXE:

Orthographic: https://www.youtube.com/watch?v=deQAjOvcmwI
Perspective: https://www.youtube.com/watch?v=Ahoi9OVFoos

-----
On our local gaming laptop test machine, the 32-bit and 64-bit versions
offer vastly different performance and frame rates:

32-bit: 45 seconds per cycle*
64-bit: 29 seconds per cycle*

* A cycle is the time it takes for the simulation to see
the full 7,000 year cycle + PE transfer + reduction (as
the PE enters PE-3 Saturn).

The 64-bit version is 16 seconds faster per frame, or about 33%.

The EXE versions published above are compiled in Visual Studio 2019 and
are written in mostly C with a few C++ extensions and relaxations used
(for function overloading, relaxed syntax constraints, tighter type
checking, anonymous unions, and line comments).

The simulation relies heavily on 64-bit floating point math. Even
though the 32-bit version is compiled to use SSE2 / vectors where
possible, I was still quite surprised at the benefits of seen in the
64-bit code.

I am developing this product on an older desktop machine using Visual
Studio 2008. Its Open GL 3D graphics card is by far the greatest
constraint as I only get about 3 fps without anti-aliasing on either
32-bit or 64-bit compile. But on our production machine where we
generate the videos, it's a huge difference in performance. We've been
running the VS 2008 32-bit and 64-bit versions and they offer similar
performance to the VS 2019 versions.

I was wondering if anyone else has seen such a huge difference in any
apps comparing 32-bit to 64-bit compiles? Up until now, I have never
seen more than a 5% or maybe 10% variation on rare occasion, but most of
my C/C++ apps until now have been business apps using databases,
networking, and basic business logic.

I have done some gaming development, but never with a high-end graphics
card, so I've never seen the performance constraints revealed to such a
degree. My son and I both had our jaws drop when we ran the 64-bit
version and visibly saw the speedup. Quite a thing.

--
Rick C. Hodgin

[Bart]

On 24/10/2020 13:29, Rick C. Hodgin wrote:
> I've written a simulation for my Solar System Assembly Line theory in
> Open GL.  You can download the EXEs here.  And please report any errors
> in getting it to run.
>
>     32-bit:
> http://www.3alive.org/ssal/earth_solar_system_open_gl__32_bit.zip
>     64-bit:
> http://www.3alive.org/ssal/earth_solar_system_open_gl__64_bit.zip

I tried the 64-bit version. It started, and I got a picture that looked
like the first frame of your video, but it didn't do anything.

After a few seconds it disappeared. If I tried to start it again, it
said Access Denied (and there were no orphaned processes that I could
see still running. But I was able to delete the binary. When I
reinstalled it, it did the same thing. This is on Windows 7.

> Up until now, I have never
> seen more than a 5% or maybe 10% variation on rare occasion, but most of
> my C/C++ apps until now have been business apps using databases,
> networking, and basic business logic.
>
> I have done some gaming development, but never with a high-end graphics
> card, so I've never seen the performance constraints revealed to such a
> degree.  My son and I both had our jaws drop when we ran the 64-bit
> version and visibly saw the speedup.  Quite a thing.

When I want from 16 bits to true 32 bits (not just 32-bit ops in 16-bit
mode), my main application was 50% faster.

I no longer any means of producing both 32 and 64-bit binaries with the
same compiler, so can't compare any more.

[Mr Flibble]

On 24/10/2020 13:29, Rick C. Hodgin wrote:

Dis-liked and commented.

/Flibble

--
¬

[Mr Flibble]

On 24/10/2020 13:29, Rick C. Hodgin wrote:

Couldn't run it locally as my anti-virus doesn't like it, or your god, mate.

Filename: earth_solar_system_opengl.exe
Threat name: WS.Reputation.1Full Path: C:\Users\leigh\Downloads\earth_solar_system_open_gl__64_bit\earth_solar_system_opengl.exe

____________________________

____________________________


On computers as of
24/10/2020 at 16:01:05

Last Used
24/10/2020 at 16:03:06

Startup Item
No

Launched
No

Threat type: Insight Network Threat. There are many indications that this file is untrustworthy and therefore not safe


____________________________


earth_solar_system_opengl.exe Threat name: WS.Reputation.1
Locate


Very Few Users
Fewer than 5 users in the Norton Community have used this file.

Very New
This file was released less than 1 week  ago.

Medium
This file risk is medium.


____________________________


http://www.3alive.org/ssal/earth_solar_system_open_gl__64_bit.zip
Downloaded File from 3alive.org
Source: External Media

earth_solar_system_opengl.exe

____________________________

File Actions

File: C:\Users\leigh\Downloads\earth_solar_system_open_gl__64_bit\ earth_solar_system_opengl.exe Removed
____________________________


File Thumbprint - SHA:
9bc820ca5349f68bad2e7f0490a2d5d5076d78028d80813eb7629d2b004f8a87
File Thumbprint - MD5:
004d14ac233ed9985eab297d417c6bb0

/Flibble

--
¬

[Bonita Montero]

https://www.virustotal.com/gui/file/9bc820ca5349f68bad2e7f0490a2d5d5076d78028d80813eb7629d2b004f8a87/detection

[Juha Nieminen]

In comp.lang.c++ Rick C. Hodgin <rick.c...@gmail.com> wrote:
> I've written a simulation for my Solar System Assembly Line theory in
> Open GL.

Amazing how much work you put into absolute insanity.

[Rick C. Hodgin]

On 10/24/20 10:54 AM, Bart wrote:
> On 24/10/2020 13:29, Rick C. Hodgin wrote:
>> I've written a simulation for my Solar System Assembly Line theory in
>> Open GL.  You can download the EXEs here.  And please report any
>> errors in getting it to run.
>>
>>      32-bit:
>> http://www.3alive.org/ssal/earth_solar_system_open_gl__32_bit.zip
>>      64-bit:
>> http://www.3alive.org/ssal/earth_solar_system_open_gl__64_bit.zip
>
> I tried the 64-bit version. It started, and I got a picture that looked
> like the first frame of your video, but it didn't do anything.

It has controls. Spacebar pauses, -+ to make it wider/narrower, */ make
it taller/shorter, 1,2,3 for perspective, ortho, and motion.

It sounds like anti-virus killed it.

> After a few seconds it disappeared. If I tried to start it again, it
> said Access Denied (and there were no orphaned processes that I could
> see still running. But I was able to delete the binary. When I
> reinstalled it, it did the same thing. This is on Windows 7.
>
>> Up until now, I have never seen more than a 5% or maybe 10% variation
>> on rare occasion, but most of my C/C++ apps until now have been
>> business apps using databases, networking, and basic business logic.
>>
>> I have done some gaming development, but never with a high-end
>> graphics card, so I've never seen the performance constraints revealed
>> to such a degree.  My son and I both had our jaws drop when we ran the
>> 64-bit version and visibly saw the speedup.  Quite a thing.
>
> When I want from 16 bits to true 32 bits (not just 32-bit ops in 16-bit
> mode), my main application was 50% faster.
>
> I no longer any means of producing both 32 and 64-bit binaries with the
> same compiler, so can't compare any more.

--
Rick C. Hodgin

[Rick C. Hodgin]

I'm prepared to accept it's not a valid theory, but not based on opinion
or beliefs. I'm looking for hard scientific data which disproves it, or
overt Biblical passages / doctrine which categorically refutes it.

I've studied this theory for 10 years now, and I am not aware of any. I
am asking for other people to help me break the theory and disprove it.
I would like to be free from it, as it's a burden that follows me around
in my life.

--
Rick C. Hodgin

[Richard Harnden]

On 24/10/2020 17:04, Rick C. Hodgin wrote:
> On 10/24/20 11:48 AM, Juha Nieminen wrote:
>> In comp.lang.c++ Rick C. Hodgin <rick.c...@gmail.com> wrote:
>>> I've written a simulation for my Solar System Assembly Line theory in
>>> Open GL.
>>
>> Amazing how much work you put into absolute insanity.
>
> I'm prepared to accept it's not a valid theory, but not based on opinion
> or beliefs.  I'm looking for hard scientific data which disproves it, or
> overt Biblical passages / doctrine which categorically refutes it.

Occam's razor?

>
> I've studied this theory for 10 years now, and I am not aware of any.  I
> am asking for other people to help me break the theory and disprove it.
> I would like to be free from it, as it's a burden that follows me around
> in my life.
>

You have wasted ten years, then, sorry.

[Rick C. Hodgin]

On 10/24/20 10:54 AM, Bart wrote:

> On 24/10/2020 13:29, Rick C. Hodgin wrote:
>> I've written a simulation for my Solar System Assembly Line theory in
>> Open GL.  You can download the EXEs here.  And please report any
>> errors in getting it to run.
>>
>>      32-bit:
>> http://www.3alive.org/ssal/earth_solar_system_open_gl__32_bit.zip
>>      64-bit:
>> http://www.3alive.org/ssal/earth_solar_system_open_gl__64_bit.zip
>
> I tried the 64-bit version. It started, and I got a picture that looked
> like the first frame of your video, but it didn't do anything.
>
> After a few seconds it disappeared. If I tried to start it again, it
> said Access Denied (and there were no orphaned processes that I could
> see still running. But I was able to delete the binary. When I
> reinstalled it, it did the same thing. This is on Windows 7.

I don't think you use Visual Studio, but I'll post the source code so
people can compile it for themselves. I develop it in VS2008 in a
specific folder, and have some paths hard-coded for that development.
It's part of my LibSF software project, so it goes here:

\libsf\source\earth_solar_system\c++\earth_solar_system_opengl\

And it copies its output to:

\libsf\source\earth_solar_system\c++\test_opengl\
\libsf\source\earth_solar_system\c++\test_opengl\x64\

And in those two folders I have the DLLs it needs for 32-bit and 64-bit
access. Those are the folders I ZIP'd up today after building with VS2019.

I'll put it on a GitHub page so people can download it and test it. I
don't have GitHub presently, so I'll have to get it all setup. I'll
also remove the hard dependencies and make them relative so it can be
immediately loaded, compiled, and ran.

To my knowledge, there's nothing malicious in anything I've published.
If there is something, it might be from the DLLs I use as those were
taken from the web several years ago (Free GLUT). I haven't had any
issues with them and my own AV does not flag them (in Windows 7 or
Windows 10). My son's computer initially flagged them when running an
app this 3D engine I've created is based on. It was a test of a Mario
World like side-scroller. He added an exception for that executable,
and hasn't had any issues since. He gets an update on the Earth Solar
System Open GL exe on an almost daily basis, and his AV has not
complained since.

If you're daring, add an exception. If not, wait for the source code
and compile it in Visual Studio 2008 or later from the solution, or
probably almost any version of Visual Studio 2003 or later otherwise.

--
Rick C. Hodgin

[Lew Pitcher]

On Sat, 24 Oct 2020 17:23:40 +0100, Richard Harnden wrote:

> On 24/10/2020 17:04, Rick C. Hodgin wrote:
>> On 10/24/20 11:48 AM, Juha Nieminen wrote:
>>> In comp.lang.c++ Rick C. Hodgin <rick.c...@gmail.com> wrote:
>>>> I've written a simulation for my Solar System Assembly Line theory in
>>>> Open GL.
>>>
>>> Amazing how much work you put into absolute insanity.
>>
>> I'm prepared to accept it's not a valid theory, but not based on
>> opinion or beliefs.  I'm looking for hard scientific data which
>> disproves it, or overt Biblical passages / doctrine which categorically
>> refutes it.
>
> Occam's razor?

Russell's teapot: the philosophic burden of proof lies upon a person
making unfalsifiable claims.

[snip]




--
Lew Pitcher
"In Skills, We Trust"

[Rick C. Hodgin]

On 10/24/20 12:29 PM, Lew Pitcher wrote:
> Russell's teapot: the philosophic burden of proof lies upon a person
> making unfalsifiable claims.

I have laid everything before people, and am finalizing a book that will
be published for free which holds the entire concept in a 300 page package.

Are you able to prove something true? Newton's theories of motion are
correct, but they are incomplete. It took Einstein coming along to
extend Newton to different velocities and gravitational environments.

This theory I have takes what we have been given and puts it together
into a package which aligns Biblical teaching with real-world
observation through our probes and landings and gazing through
telescopes. It answers questions which cannot be answered today. It
puts philosophical meaning behind our existence. It does a lot to
address the needs of science and religion.

But how do you prove it's true? I'm only looking for something in
science or in the Bible which will disprove it. That should be doable
if it's wrong.

--
Rick C. Hodgin

[Mr Flibble]

On 24/10/2020 17:25, Rick C. Hodgin wrote:
> To my knowledge, there's nothing malicious in anything I've published. If there is something, it might be from the DLLs I use as those were taken from the web several years ago (Free GLUT).  I haven't had any issues with them and my own AV does not flag them (in Windows 7 or Windows 10).  My son's computer initially flagged them when running an app this 3D engine I've created is based on.  It was a test of a Mario World like side-scroller.  He added an exception for that executable, and hasn't had any issues since.  He gets an update on the Earth Solar System Open GL exe on an almost daily basis, and his AV has not complained since.
>
> If you're daring, add an exception.  If not, wait for the source code and compile it in Visual Studio 2008 or later from the solution, or probably almost any version of Visual Studio 2003 or later otherwise.
>

If I ever add an exception to my AV so I can run any of your fucktarded software, mate, then someone needs to shoot me as I have obviously completely lost it.

/Flibble

--
¬

[Rick C. Hodgin]

On 10/24/20 12:45 PM, Mr Flibble wrote:
> If I ever add an exception to my AV so I can run any of your ..

> software, mate, then someone needs to shoot me as I have obviously
> completely lost it.

I would expect no less from you, Leigh. You do not seek the truth. I
do not expect you to be a part of this project, but only to sit on the
outside screaming at the top of your lungs against it, posting negative
comments, spewing hate, fomenting discord ... all the things one
compromised by sin in this world would do.

It won't get you anywhere, and it will cost you everything in the end.

Good luck.

--
Rick C. Hodgin

[Rick C. Hodgin]

On 10/24/20 12:25 PM, Rick C. Hodgin wrote:
> I'll put it on a GitHub page so people can download it and test it.  I
> don't have GitHub presently, so I'll have to get it all setup.  I'll
> also remove the hard dependencies and make them relative so it can be
> immediately loaded, compiled, and ran.

This will be the GitHub page:

https://github.com/RickCHodgin/Earth_Solar_System_OpenGL

I haven't pushed the source code yet. But, it will be up there sometime
soon (Lord willing, James 4:15). :-)

--
Rick C. Hodgin

[Rick C. Hodgin]

Code is pushed. I can get it to compile on my machine, but I also have
the other files there.

If someone could pull this repository:

https://github.com/RickCHodgin/Earth_Solar_System_OpenGL.git

Open this Visual Studio solution. It's VS2008 you may have to upgrade
if you don't have that version:


\Earth_Solar_System_OpenGL\c++\03_earth_solar_system_open_gl\earth_solar_system_opengl.sln

-----
Sorry for all the Earth Solar System Open GL levels. :-) Once you open
it up once, it will be in your most recently used list. You'll never
have to worry about it again.

The code compiles and goes to these two folders:

\Earth_Solar_System_OpenGL\c++\test_opengl\
\Earth_Solar_System_OpenGL\c++\test_opengl\x64\

There's where you can run the executables. They are self-contained
except for the DLL dependencies. The graphics are compiled into the
binary through the graphics\ folder .BAT files and raw 24-bit BMP files.
I use that format because it doesn't have any OS dependencies for
decompression, and it's lossless.

Please report any troubles compiling or bugs. I'll get them fixed later
on this afternoon. Have some stuff to do outside right now.

--
Rick C. Hodgin

[Bart]

On 24/10/2020 17:25, Rick C. Hodgin wrote:

I turned off AV and this time it stayed on-screen. But it didn't much.
The keyboard controls all worked except '3'.

Does it update each time there's a new frame? If so there should be an
indication such as a frame counter, if the difference is too subtle to
notice.

Whatever it is that's making it slow, I don't think it's OpenGL.

I also tried it with glut32.dll (also a free download from somewhere),
renamed to freeglut.dll, and that was OK.

(One technical note about glew.dll (is that yours?); it exports over
3000 names, but only 7 of those are functions. The rest are variables.

I suspect a lot of variables either don't have 'static', or are shared
across modules of this library, but are not intended as exports from the
DLL.)

[Rick C. Hodgin]

On 10/24/20 4:08 PM, Bart wrote:
> I turned off AV and this time it stayed on-screen. But it didn't much.
> The keyboard controls all worked except '3'.

This version is not on a frame per second governor. It runs as fast as
your video card and CPU can render it. As I say, on my dev machine it's
about 3 fps due to a 2007 video card limitation.

> Does it update each time there's a new frame? If so there should be an
> indication such as a frame counter, if the difference is too subtle to
> notice.

If your video card's a bottleneck, it won't show much variation between
32-bit and 64-bit. I used my cell phone's stop watch app to time them.
Just under 29 seconds for 64-bit, and just under 45 seconds for 32-bit.

> Whatever it is that's making it slow, I don't think it's OpenGL.

It does a lot of 64-bit FPU computing. Every vertex is recomputed for
planetary rotation, plus axial tilt, plus the position / track along the
assembly line.

> I also tried it with glut32.dll (also a free download from somewhere),
> renamed to freeglut.dll, and that was OK.

freeglut.dll was designed to be a drop-in replacement for glut32.dll.
They should work interchangeably.

> (One technical note about glew.dll (is that yours?); it exports over
> 3000 names, but only 7 of those are functions. The rest are variables.

glew.dll is part of the GLU toolkit. It enables some shortcuts for the
complexities of programming OpenGL. I use gluLookAt(), for example,
which gives me an eye position, a camera position, and which directions
are considered up, and it computes the rest of the projection in OpenGL
terms.

I'm not very good with OpenGL. I have only hacked at it and gotten
things to work. I still don't compute normals correctly, and my
rendering is based on quads, triangles, and lines, rather than strips.
It could have much greater performance. But, it works, and on a fast
GPU it's quite speedy (especially in 64-bit mode).

> I suspect a lot of variables either don't have 'static', or are shared
> across modules of this library, but are not intended as exports from the
> DLL.)

I don't know. For me it was a black box that did what I needed. I'd
like to switch over to pure OpenGL but I'd need a video tutorial and
probably someone to help me translate a teaching into the way I learn.

--
Rick C. Hodgin

[Bart]

On 24/10/2020 23:49, Rick C. Hodgin wrote:
> On 10/24/20 4:08 PM, Bart wrote:
>> I turned off AV and this time it stayed on-screen. But it didn't much.
>> The keyboard controls all worked except '3'.
>
> This version is not on a frame per second governor.  It runs as fast as
> your video card and CPU can render it.  As I say, on my dev machine it's
> about 3 fps due to a 2007 video card limitation.
>
>> Does it update each time there's a new frame? If so there should be an
>> indication such as a frame counter, if the difference is too subtle to
>> notice.
>
> If your video card's a bottleneck, it won't show much variation between
> 32-bit and 64-bit.  I used my cell phone's stop watch app to time them.
> Just under 29 seconds for 64-bit, and just under 45 seconds for 32-bit.
>
>> Whatever it is that's making it slow, I don't think it's OpenGL.

I tried once more, and stared at it for several minutes looking for a
change.

Then I discovered that I had to press Space to start it. I hadn't tried
that before because you said if pauses it, which is not quite right.

Then it took 75 seconds on my 64-bit machine to go through the whole cycle.

[Rick C. Hodgin]

On 10/24/20 7:21 PM, Bart wrote:
> I tried once more, and stared at it for several minutes looking for a
> change.
>
> Then I discovered that I had to press Space to start it. I hadn't tried
> that before because you said if pauses it, which is not quite right.

It pauses and un-pauses it. I apologize if that wasn't clear. LOL. I
can actually see how it might not be. On the website it had the pause
and un-pause reference.

> Then it took 75 seconds on my 64-bit machine to go through the whole cycle.

I'm not sure how long it takes on mine. Will test it tomorrow. It's
quite a while. Build in debug mode and it almost doubles the slowness.

--
Rick C. Hodgin

[Chris M. Thomasson]

On 10/24/2020 9:20 PM, Rick C. Hodgin wrote:
> On 10/24/20 7:21 PM, Bart wrote:
>> I tried once more, and stared at it for several minutes looking for a
>> change.
>>
>> Then I discovered that I had to press Space to start it. I hadn't
>> tried that before because you said if pauses it, which is not quite
>> right.
>
> It pauses and un-pauses it.  I apologize if that wasn't clear.  LOL.  I
> can actually see how it might not be.  On the website it had the pause
> and un-pause reference.
>
>> Then it took 75 seconds on my 64-bit machine to go through the whole
>> cycle.

Why not try to move the calculations to the GPU?

[Paul]

Chris M. Thomasson wrote:
> On 10/24/2020 9:20 PM, Rick C. Hodgin wrote:
>> On 10/24/20 7:21 PM, Bart wrote:
>>> I tried once more, and stared at it for several minutes looking for a
>>> change.
>>>
>>> Then I discovered that I had to press Space to start it. I hadn't
>>> tried that before because you said if pauses it, which is not quite
>>> right.
>>
>> It pauses and un-pauses it. I apologize if that wasn't clear. LOL.
>> I can actually see how it might not be. On the website it had the
>> pause and un-pause reference.
>>
>>> Then it took 75 seconds on my 64-bit machine to go through the whole
>>> cycle.
>
> Why not try to move the calculations to the GPU?

Maybe using a profiler would tell you where the time
is being spent.

Paul

[Bonita Montero]

> The 64-bit version is 16 seconds faster per frame, or about 33%.

Maybe because of SSE has twice the number of registers in 64 bit mode.

[Rick C. Hodgin]

On 10/25/20 12:38 AM, Chris M. Thomasson wrote:
> Why not try to move the calculations to the GPU?

Because I don't know how to do that. :-) I've reported on things like
OpenCL before, but I've never programmed with any of those GPU libraries.

It would lend itself well to parallel processing as I have hundreds of
vertices that all need to have the same operations performed. I need to
use atan2() to get the angle theta, and another atan2() to get rho, and
then rotate them, recompute sin() and cos() on both to reposition for
rotation and axial tilt.

That's the bulk of the transformations.

--
Rick C. Hodgin

[Bart]

If rotating by the same angle lots of times, presumably you set up a
transformation matrix first? If not, you presumably don't recalculate
sin/cos with the same angle?

A transformation matrix can combine several operations (multiple
rotations, shearing, moving) into one matrix. OpenGL I think has
facilies to apply such a matrix.

[Rick C. Hodgin]

On 10/25/20 12:27 PM, Bart wrote:
> On 25/10/2020 16:11, Rick C. Hodgin wrote:
>> On 10/25/20 12:38 AM, Chris M. Thomasson wrote:
>>> Why not try to move the calculations to the GPU?
>>
>> Because I don't know how to do that. :-)  I've reported on things like
>> OpenCL before, but I've never programmed with any of those GPU libraries.
>>
>> It would lend itself well to parallel processing as I have hundreds of
>> vertices that all need to have the same operations performed.  I need
>> to use atan2() to get the angle theta, and another atan2() to get rho,
>> and then rotate them, recompute sin() and cos() on both to reposition
>> for rotation and axial tilt.
>>
>> That's the bulk of the transformations.
>
> If rotating by the same angle lots of times, presumably you set up a
> transformation matrix first? If not, you presumably don't recalculate
> sin/cos with the same angle?

Each planet rotates by its rotational rate in the simulation. If you
look near the top of the earth_solar_system.cpp file in the main()
function you'll see where the multiple iBuildSphere() functions are
called. They have rotation rate.

Each vertex is rotated by that amount. You can search for the
iRotateZ() and iRotateY() functions to find them. This performs
arbitrary rotation on the Z or Y axes.

> A transformation matrix can combine several operations (multiple
> rotations, shearing, moving) into one matrix. OpenGL I think has
> facilies to apply such a matrix.

I've never understood how those kinds of matrices work. I've tried
reading through some tutorials a handful of times over my life, but it's
always been confusing to me. It would be better to see the example, and
then see the assembly instructions it would generate on a CPU, while I
also recognize that in a GPU it performs them as a single operation.

I understand quite well trigonometry and the unit circle (and unit
sphere). So, I've been able to operate within those boundaries just
fine to date, but it is slower. And, as I say, on our gaming laptop
with a high-end Nvidia graphics card, I am able to get a 29 second
cycle, which is actually too fast. We had to slow it down a little for
the videos.

I'll put a fps setting on there, but just don't have it yet. I'm also
not working on that repository for my active development. That's just a
snapshot taken at a given time for public consumption.

The work I'm doing now is in creating a triangle map of the land area of
the Earth, and then flattening it out so rather than being curved around
the sphere / globe, it's as though you took something like a shape in
the shape of Australia and then laid it on a flat surface. It changes
its geometry a little. Then, I'm taking it and placing it somewhere
arbitrarily on the surface of the sphere and having it wrap back around
the curve of the sphere's surface. By doing this, I'm able to move
continents about to other places on the globe.

Baby steps.

--
Rick C. Hodgin

[Chris M. Thomasson]

On 10/25/2020 9:11 AM, Rick C. Hodgin wrote:
> On 10/25/20 12:38 AM, Chris M. Thomasson wrote:
>> Why not try to move the calculations to the GPU?
>
> Because I don't know how to do that. :-)  I've reported on things like
> OpenCL before, but I've never programmed with any of those GPU libraries.

At the least, think about:

http://www.opengl-tutorial.org/beginners-tutorials/tutorial-3-matrices/
(read all)

The think of a MVP. Model, View, Projection.