Sunday, May 19, 2019

Digest for comp.lang.c++@googlegroups.com - 25 updates in 9 topics

Sal LO <gegefffffff@gmail.com>: May 19 03:00PM -0700

https://youtu.be/O909xMoMfKk
Sal LO <gegefffffff@gmail.com>: May 19 03:00PM -0700

https://youtu.be/O909xMoMfKk
Sal LO <gegefffffff@gmail.com>: May 19 02:59PM -0700

https://youtu.be/O909xMoMfKk
Sal LO <gegefffffff@gmail.com>: May 19 02:58PM -0700

https://youtu.be/O909xMoMfKk
Sal LO <gegefffffff@gmail.com>: May 19 02:58PM -0700

https://youtu.be/O909xMoMfKk
Sal LO <gegefffffff@gmail.com>: May 19 02:58PM -0700

https://youtu.be/O909xMoMfKk
Sal LO <gegefffffff@gmail.com>: May 19 02:57PM -0700

https://youtu.be/O909xMoMfKk
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: May 19 01:27PM +0200

On 19.05.2019 00:21, fir wrote:
> 3) i could turn it to dll library allowing some do defining its ovn constructs and test it
> 4) etc
 
> so maybe some opinions/hints what to do with that?
 
An executable and screenshots/video is not very relevant to comp.lang.c++.
 
How about posting the C++ source code for review?
 
 
Cheers!,
 
- Alf
fir <profesor.fir@gmail.com>: May 19 05:06AM -0700

W dniu niedziela, 19 maja 2019 13:27:59 UTC+2 użytkownik Alf P. Steinbach napisał:
 
> > so maybe some opinions/hints what to do with that?
 
> An executable and screenshots/video is not very relevant to comp.lang.c++.
 
> How about posting the C++ source code for review?
 
i could do that eventually but in fact im not thinking it is quite true
 
i mean discussing some ideas and algorithms (in a head) may be more useful and pleasurable than 'reiewing' source which
a) is harder for read (than ideas to discuss)
b) will not give much becouse source is just a 'cast' of algorithms and is kinda strightforward
c) ideas are more funny
d) it is fun so it is relevant
 
first of all though,m this app should be run, and seen.. then i could say more on it if someone curious
fir <profesor.fir@gmail.com>: May 19 05:53AM -0700

W dniu niedziela, 19 maja 2019 14:06:55 UTC+2 użytkownik fir napisał:
> c) ideas are more funny
> d) it is fun so it is relevant
 
> first of all though,m this app should be run, and seen.. then i could say more on it if someone curious
 
if someone is interested in those algorithms/ideas:
 
GRAPHICS
 
I) the graphics part is i think to strightforward to more widely describe (you simply fire drawing calls, transform if form global coordinates to camera cordinates, and draw it as 2d routines on screen)
 
here i use my own rasterizer which is even kinda messy and maybe even slightly buggy (i cast 3d balls as a 2d balls which is afair not proper, also i cast 3d line as a 2 points to 2d than draw 2d line which also is not proper)
 
i also got a messy block of code related to 'mouse wrapping' which sometimes scaries me (but tnk to the windows for it [longer story])
 
PHYSICS
 
II) physical part is just like that, if
balls overlap i generate force equal to
 
float force = (pen*.3)*(pen*.3)
 
where pen is this penetration (balls overlaping in neutral units) this .3 was taken experimentally
 
then i change velocity from newton law
 
ball[i].vx+= (dx/d)* force /Mi;
 
//dx/d is a part of 'normal' (unity vector) just pointing the direction
 
thats about it (it taked some think to think it up but finally it showed thsi works fine)
 
as to border collisions:
 
ball[i].vx += H* pen ;
 
where pen is wall penetration and H = - 1.0; in that case
 
as to link forces (last form 3 that are acts here, two mentioned was ball-ball, ball-wall) it is
 
ball[i].vx+= -(dx/d)*force/Mi;
 
where that link force is in that case
 
force = (dev*.9)*(dev*.9)*sign(dev);
 
where dev is in that case 'deiation' (?)
from the distance that 'join' (link) prefers to keep between balls
 
 
thise all 3 magic numbers and all formulas i worged out experimentally
 
i could also give you numbers on sizes and masses but i need rest a bit
 
the containing box is from -700 to 700
in all 3 dimensions
 
ball radiuses are 8, 16, 18 and 20
 
most join distances are keeped at 100
masses of balls are usually set to 18 or 20
 
i give those numbers btw as quality of simulations seem to depend on them, and its important to find some well chosen valiues (what i set is not quite carefully chosen)
 
also maybe should note i calcilate 7 physical iteretions on one graphical draw of frame, and also dumping force of
ball[i].vx*=0.99990;
is set
fir <profesor.fir@gmail.com>: May 19 07:14AM -0700

some potential question:
 
fron the equations of those sources it
come thet when ball is placed in some locations, like out of the bos or one in another or (most annoying) distant from its join preffered distance, the ball takes very strong force, reaches immediately extreme velocity, and that makes kinda bug
 
this makes i must then set initial bals with care,
question what is the most soft end easy
way of resolving it? (easy to code and making most good behaviour in cases of mislplaced initialisations?)
fir <profesor.fir@gmail.com>: May 19 01:19PM -0700

i upgraded this a little by adding gravity
 
and as i must said when i initialy moved that thing to 3d i was initially dissapointed, as it initially was not looking good in turn, oppositely, gravity looks better than i thought
 
http://minddetonator.htw.pl/ballz3d2.zip
 
especially it looks cooll when you throw some tens or hundreds balls and then press a d (increasa a dump for a moment)
 
it looks a bit like neo stopping the bullets and lettin them fall down
 
also generally low gravity looks like underwater sometimes also cool
 
the problem is hovever at about that
amout of balls/bills
 
http://minddetonator.htw.pl/graity.png
 
(this is also apropos sand topics)
the simulation begen to strongly choke
 
(50 ms per frame is upper choking limit)
Sal LO <gegefffffff@gmail.com>: May 19 02:57PM -0700

https://youtu.be/O909xMoMfKk
Bonita Montero <Bonita.Montero@gmail.com>: May 19 06:34AM +0200

> language issues that make the /code/ non-portable (for example, on my
> system long is twice the size of float) but there are also endian issues
> that make the output non-portable.
 
No, there aren't any endianess-issues that makes the example non-por-
table because the long as well as the float have the same endianess.
blt_h4ci3@48h2n_3.edu: May 19 09:20AM

On Sat, 18 May 2019 21:33:09 +0100
>in the object. Not that that's any more portable! Not only are there
>language issues that make the /code/ non-portable (for example, on my
>system long is twice the size of float) but there are also endian issues
 
That is a good point, I should have used int. Its almost always the same
size as a float. But nontheless, the point is that a float is simply a load
of bytes, there's nothing magical about it and it can be stored with no loss
of precision quite easily.
Bo Persson <bo@bo-persson.se>: May 19 11:43AM +0200

On 2019-05-19 at 06:34, Bonita Montero wrote:
>> that make the output non-portable.
 
> No, there aren't any endianess-issues that makes the example non-por-
> table because the long as well as the float have the same endianess.
 
There are no guarantees about that in the language. But unless you use a
VAX (or some odd ARM systems), it might just accidentally work.
Bonita Montero <Bonita.Montero@gmail.com>: May 19 11:44AM +0200

>> table because the long as well as the float have the same endianess.
 
> There are no guarantees about that in the language. But unless you use
> a VAX (or some odd ARM systems), it might just accidentally work.
 
Not because of the language. But there never has been an architecutre
that has split endianess for integers and floating points.
Bonita Montero <Bonita.Montero@gmail.com>: May 19 11:49AM +0200

> size as a float. But nontheless, the point is that a float is simply a
> load of bytes, there's nothing magical about it and it can be stored with
> no loss of precision quite easily.
 
You can do this more reliable by storing it as a uint32_t. I think
there isn't any platform that is or will be supported by a current
C++-compiler and where the floating-point-types aren't IEEE-754-com-
patible, although there are some specialities like the Arduino-plat-
form where fload and double are both single-precision values.
Bo Persson <bo@bo-persson.se>: May 19 12:36PM +0200

On 2019-05-19 at 11:44, Bonita Montero wrote:
>> a VAX (or some odd ARM systems), it might just accidentally work.
 
> Not because of the language. But there never has been an architecutre
> that has split endianess for integers and floating points.
 
Except for the ones I mentioned. :-)
 
 
https://en.wikipedia.org/wiki/Endianness#Floating_point
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: May 19 01:30PM +0200

On 19.05.2019 12:36, Bo Persson wrote:
>> that has split endianess for integers and floating points.
 
> Except for the ones I mentioned.  :-)
 
> https://en.wikipedia.org/wiki/Endianness#Floating_point
 
:-o Learned something new today, assuming that Wikipedia is correct here.
 
Wow, holy mackerel!
 
 
Cheers!,
 
- Alf
Ben Bacarisse <ben.usenet@bsb.me.uk>: May 19 12:40PM +0100

>> that make the output non-portable.
 
> No, there aren't any endianess-issues that makes the example non-por-
> table because the long as well as the float have the same endianess.
 
That may be widely true now, but I recall problems in the past. I think
the VAX copied the PDP-11's strange mixed-endian order for 32-bit floats
whilst "fixing" the mixed byte-order for longs that the PDP-11 used.
Mind you, it might have been the other way round, with the PDP-11 having
a plain byte ordering for floats, but remember a miss-match when
transferring data in the way.
 
--
Ben.
David Brown <david.brown@hesbynett.no>: May 19 01:46PM +0200

> size as a float. But nontheless, the point is that a float is simply a load
> of bytes, there's nothing magical about it and it can be stored with no loss
> of precision quite easily.
 
Smaller processors can have "int" that is 16-bit. The most reasonable
assumption is that a float is the same size as a uint32_t - that will be
valid on all but the strangest of targets (I think there was a Cray
machine with 64-bit "short", which would not have a uint32_t type at
all, but you are unlikely to meet one in practice). But whatever
assumptions you make, state them in a compiler-checkable manner.
 
And use a union for type punning.

#include <stdint.h>
 
static_assert(sizeof(uint32_t) == sizeof(float),
"Checking type sizes");
 
union raw_float { float f; uint32_t raw; };
 
raw_float rf;
rf.f = 1.234;
cout << hex << rf.raw << endl;
blt_a937@_cuytv9ga8ib68xe.net: May 19 04:03PM

On Sun, 19 May 2019 13:46:59 +0200
>> of bytes, there's nothing magical about it and it can be stored with no loss
>> of precision quite easily.
 
>Smaller processors can have "int" that is 16-bit. The most reasonable
 
I can't imagine C++ gets used too often on 8 or 16 bit machines. Even getting
all of the core non C part of the language to work would be a struggle IMO (the
virtual function table would be fun to implement for a start) and the STL and
2011+ would be next to impossible.
 
>all, but you are unlikely to meet one in practice). But whatever
>assumptions you make, state them in a compiler-checkable manner.
 
>And use a union for type punning.
 
You could, but my example was 1 line which was the point.
Marcel Mueller <news.5.maazl@spamgourmet.org>: May 19 06:33PM +0200

> I didn't even know hexfloat existed. It seems a spectacularly useless
> manipulator. What on earth is the point of it?
 
IBM used hex float format in hardware also. I.e. the exponent counts in
hex digits. But the resulting scaling precision has some disadvantages.
 
 
Marcel
David Brown <david.brown@hesbynett.no>: May 19 09:10PM +0200

> all of the core non C part of the language to work would be a struggle IMO (the
> virtual function table would be fun to implement for a start) and the STL and
> 2011+ would be next to impossible.
 
Well, it turns out that C++ /is/ used regularly on such systems. People
tend to be careful about the use of some C++ features - exceptions and
RTTI are usually disabled, for example, and virtual functions will only
be used if they are really useful. And use of standard containers
(except perhaps std::array) will be limited. But there is a lot of C++
used nonetheless. (A great many C++11 features are zero cost at
run-time, at least with a reasonable compiler.)
 
>> assumptions you make, state them in a compiler-checkable manner.
 
>> And use a union for type punning.
 
> You could, but my example was 1 line which was the point.
 
One /incorrect/ line is not very useful. It is better to have a few
lines that work than a single line that does not.
 
(And that's not just theory - faffing around with casting pointer types
as you did does not work on anything but the most limited of compilers,
and usually only with optimisations disabled.)
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com.
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)