warnings. Using snprintf directly would be a little bit more tricky,
because once again Microsoft decided to avoid followind standards and
provide _snprintf instead. We could use this, too, but this would
require an additional autoconf check, which I'd like to avoid, if
possible.
Note: If VS *still* issues warnings, but this time about vsnprintf,
somebody should add some pragmas or whatever is needed to shut up that
warning, it would be silly.
git-svn-id: https://svn.code.sf.net/p/freeglut/code/trunk@783 7f0cb862-5218-0410-a997-914c9d46530a
* Use vertex attribute arrays.
* Use our own projection matrix.
* Do not use deprecated vertex/fragment shader variables.
git-svn-id: https://svn.code.sf.net/p/freeglut/code/trunk@778 7f0cb862-5218-0410-a997-914c9d46530a
Red Book. What has been done already:
* Explicitly request a forward-compatible 3.0 context
* Report GL errors, if any, at a few crucial places
* Replaced gluOrtho2D with a home-grown matrix + glLoadMatrixf
What remains to be done:
* Use vertex shaders and fragment shaders
* Use vertex buffer objects
git-svn-id: https://svn.code.sf.net/p/freeglut/code/trunk@774 7f0cb862-5218-0410-a997-914c9d46530a
window and, upon command, renders a similar offscreen display and writes
the result to disk.
Also, modified the build structure for UNIX_X11 to autobuild the demo.
(Not done for WIN32 at this time.)
Also, forgot to previously commit the updated freeglut_ext.h include.
Eeep.
git-svn-id: https://svn.code.sf.net/p/freeglut/code/trunk@465 7f0cb862-5218-0410-a997-914c9d46530a
* CallbackMaker defined, but did not use, the Joystick() function
(a callback for the freeglut joystick interface). I uncommented
the callback-registration. I assume that it was commented out
because it was spammy. (freeglut does joysticks by polling with a
timer.) Perhaps a longer interval than 10ms would be advisable?
* fractals.c used strcpy() without getting the prototype. Added
#include <string.h> at the top.
* fractals_random.c had the same problem as fractals.c.
git-svn-id: https://svn.code.sf.net/p/freeglut/code/trunk@415 7f0cb862-5218-0410-a997-914c9d46530a
* 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
