* Updated shapes.c. I think that it's just reformatting and the addition
of some comments.
* Added shapes.dsp, a Microsoft Visual C++ Developer Studio Project file
for building shapes on WIN32 with MSVC++.
git-svn-id: https://svn.code.sf.net/p/freeglut/code/trunk@381 7f0cb862-5218-0410-a997-914c9d46530a
few in the "one" demo, it seems, and some more crept back into
freeglut_(ext|font).c, presumably due to my own edits when I forgot to
use the "freeglut-c-mode" in EMACS.)
git-svn-id: https://svn.code.sf.net/p/freeglut/code/trunk@339 7f0cb862-5218-0410-a997-914c9d46530a
glutInit() in general, since it allows the user to override settings via
{argc, argv} command-line params.)
git-svn-id: https://svn.code.sf.net/p/freeglut/code/trunk@338 7f0cb862-5218-0410-a997-914c9d46530a
Plus updated *.dsp and *.dsw files to reflect the new freeglut header
file.
NOTE: The prior version of the *.dsw file does not in fact have CRs. I
thought that it did. For consistancy, I am not putting them in in this
version, either. (At least one person said that his MSVC++ system is
happy with the current files. If there are problems, we can easily add
the CRs, but that should be a separate commit...)
git-svn-id: https://svn.code.sf.net/p/freeglut/code/trunk@333 7f0cb862-5218-0410-a997-914c9d46530a
This demo shows the use of every callback that you can register with
freeglut, and also generates event reports so that you can see what is
happening to the program as it runs.
Not much to look at, but both utilitarian and a practical example.
Please double-check that I updated everything that needs to be updated.
I reran autogen.sh and ./configure, and it built okay for me. (^&
git-svn-id: https://svn.code.sf.net/p/freeglut/code/trunk@332 7f0cb862-5218-0410-a997-914c9d46530a
Previously, it picked out two adjacent bits in the result of rand().
Unfortunately, these adjacent bits (at least on NetBSD) have a certain
amount of dependance. After a period (perhaps a thousand or so?), it
starts to repeat the pattern of those two bits. (I think; I haven't
actually tested that directly.) This presumably is locking it into a
an an N-way attractor on the "snowflake", such that if you zoom in a
ways, you will start to see some spots *quickly* are colored, and
others are *never* colored.
What I've done now is to pick up two widely-spaced bits in a single
rand() call. (Perhaps we would do as well to pick up something like
bit #16 from two consecutive rand() calls?) These widely-spaced bits
have a lower statistical dependance on one another (if I can get away
with using that term for an arithmetic operation; though since stats
has more to do with sampling and less to do with true randomness, I
may be safe).
The net effect, at leats on NetBSD, is far better snowflake if you zoom
in on it.
git-svn-id: https://svn.code.sf.net/p/freeglut/code/trunk@324 7f0cb862-5218-0410-a997-914c9d46530a
I [John] converted everything to double precision to avoid compiler
warnings. I also added a feature to check for memory leaks under
Windows and removed a memory leak (surprise!).
git-svn-id: https://svn.code.sf.net/p/freeglut/code/trunk@296 7f0cb862-5218-0410-a997-914c9d46530a
Modified the two Fractals* demos so that they only clear (for the random
one) or redraw (for the non-random one) if there is need to do so. (E.g.,
pressing the space bar should not clear and redraw the random fractal since
no parameters are altered.)
git-svn-id: https://svn.code.sf.net/p/freeglut/code/trunk@231 7f0cb862-5218-0410-a997-914c9d46530a
* glutInit*() calls should preceed glutInit(), per se, generally.
This is so that glutInit()'s configuration (which picks up on user
parameters) can override application defaults.
* glutInit() should be called before ANY attempt to process {argv, argc}.
This is because there may be GLUT/freeglut parameters (such as
"-display" on X11).
* If the window is tall and skinny, rather than short and squat, we need
to handle aspect ratios differently.
The first is a user-interface bug. The second is a serious bug (especially
since the demo assumes that argv[1] contains a filename). The third is a
display bug.
git-svn-id: https://svn.code.sf.net/p/freeglut/code/trunk@218 7f0cb862-5218-0410-a997-914c9d46530a
* GLUT_SINGLE now should behave more or less correctly.
Thanks to Brian Paul!
* Sleeping is now cognizant of outstanding redisplays.
* Fractals_random has been restored more or less to as-before, save that
it uses the more minimal glFlush() rather than glutSwapBuffers().
glutSwapBuffers() was only required when freeglut was incorrectly
handling promotion to double-buffering.
git-svn-id: https://svn.code.sf.net/p/freeglut/code/trunk@202 7f0cb862-5218-0410-a997-914c9d46530a