PDA

View Full Version : tutorial building for "Learning Modern 3D Graphics



tyro1
11-17-2011, 05:39 PM
The excellent online book "Learning Modern 3D Graphics Programming" by J.L.McKesson.
Could someone post a step by step outline (with code) of the procedure to build one of the tutorials ? (If I see one done I'm pretty sure I can do the remainder).
Thankyou in advance for any assistance.

Alfonse Reinheart
11-17-2011, 07:06 PM
It already has one. (http://www.arcsynthesis.org/gltut/Building%20the%20Tutorials.html) If that is insufficient, then can you suggest what information is missing?

tyro1
11-17-2011, 08:40 PM
Yes indeed. I have followed those directions using premake4 and have all the cpp files ready for build. When I put them in a project in code blocks they don't compile correctly which I'm sure is my fault. I was hoping that someone with more experience could actually go through the procedure step by step so that I could see how to do it correctly. Someone may even have an example already that they could show me. I really want to get these tutorials working so that I can continue my learning in graphics programming.
Thankyou.

Alfonse Reinheart
11-17-2011, 09:00 PM
When I put them in a project in code blocks they don't compile correctly which I'm sure is my fault.

Were there errors? What were those errors?


I was hoping that someone with more experience could actually go through the procedure step by step so that I could see how to do it correctly.

Again, what part of the procedure did I omit? In what way was it not step-by-step? At which part of the procedure did you encounter an error?

tyro1
11-18-2011, 08:51 AM
Sorry to have bothered you. I have only one more question. How do I cancel my registration to this site ?

Alfonse Reinheart
11-18-2011, 09:20 AM
Sorry to have bothered you.

Bothered? I'm trying to find out information about what it is that you're unable to do. I'm trying to help you, but to do that, you need to answer my questions.

zorobabel
12-07-2011, 03:15 AM
I am having the exact same problem as the user here: https://bitbucket.org/alfonse/gltut/issue/63/link-error-building-tutorials

I have downloaded the tutorial files. I have used Premake4 to build the tutorials. However, when I try to build/run any of the projects in MSVS2010, I get the error:

LINK : fatal error LNK1104: cannot open file 'glloadD.lib'

Any advice on where to go from here? Thanks and kind regards.

V-man
12-07-2011, 05:13 AM
It says it can't open glloadD.lib
Do you have that file?
Did you put it in a location where it can find it such as in Programs\MSVC\lib?

zorobabel
12-07-2011, 06:45 AM
Do you know where I could find that file? Googling only provides me with 8 results: 5 as bits of code of the same file, and the other 3 are linking to this thread.

Alfonse Reinheart
12-07-2011, 11:32 AM
LINK : fatal error LNK1104: cannot open file 'glloadD.lib'

You appear to have skipped a step in the process (http://www.arcsynthesis.org/gltut/Building%20the%20Tutorials.html). Did you build the SDK? The steps as outlined are in order.

tyro1
12-12-2011, 05:01 PM
Please see the attached file for details regarding the problem encountered.
Thankyou.

Alfonse Reinheart
12-12-2011, 05:34 PM
A PDF file? You can't put that into a post, or something that is more secure than a PDF?

I'm afraid that I don't download random PDFs.

tyro1
12-12-2011, 06:43 PM
Security ??? I used this format because it was approved by this website !!!
You may have written a good tutorial - however it seems that you are determined NOT to answer my question.
What a pity your manners lag your supposed programming skills.

Alfonse Reinheart
12-12-2011, 08:08 PM
PDF files are insecure. They can contain viruses and malicious code. How is it il-mannered to not accept a file format that is known to be a viral vector? I'm not saying you're intentionally trying to infect my computer. But that doesn't mean that I trust a random file handed to me by someone else either. Your computer could have something on it without your knowledge; I don't know, and I don't trust what I don't know.

Being paranoid about attack vectors is why the many computers I've had over the years have only gotten 2 viruses. And those were a website advertisement drive-by (a vector I have sense closed with various ad blocking software) and a Windows networking exploit that I had no control over.

If you want to submit a bug report, I ask you to do so via some kind of textual format. Why is that not sufficient for what you want to say; what do you need a PDF for?


however it seems that you are determined NOT to answer my question.

I'm determined not to answer your question? You haven't answered any of mine. You haven't explained the problem as anything more than "they don't compile correctly," which is helpful to neither of us.

If you want to get your problem fixed, then simply explain step-by-step what you did, where you ran into trouble, and what the trouble was, with any error messages. And not in a PDF; just paste the text into the text box.

If you cannot do that, then I cannot help you. It's that simple.

salamand4r
12-12-2011, 09:23 PM
I am having the exact same problem as the user here: https://bitbucket.org/alfonse/gltut/issue/63/link-error-building-tutorials

I have downloaded the tutorial files. I have used Premake4 to build the tutorials. However, when I try to build/run any of the projects in MSVS2010, I get the error:

LINK : fatal error LNK1104: cannot open file 'glloadD.lib'

Any advice on where to go from here? Thanks and kind regards.

I'm having this exact same problem. I've built the GLSDK but I'm getting the linker error. Any help?


EDIT: Sorry, I'm a derp. I was building it in release mode.

Also, being the nice guy I am, I've taken screen caps of tyro1's pdf and uploaded them here;

Page1: http://imgur.com/CIToR

Page2: http://imgur.com/jDYdn

tyro1
12-13-2011, 09:44 AM
@salamand4r

Thankyou for transforming my PDF and making it available in another format. However, I expect the self proclaimed "guru" to find some other excuse not to give a positive response.
Thanks to you anyway.

ZbuffeR
12-13-2011, 09:50 AM
I expect the self proclaimed "guru" to find some other excuse
Not sure you can convince someone to help you with this kind of talk. Posting the exact error messages you get in a real text format is mandatory for any kind of useful troubleshooting.

tyro1
12-13-2011, 12:59 PM
Sorry if I sound irritated (I am). Everyone on this forum has been most helpful (and polite) except for this one individual.
My initial request was for a step by step demo to compile one of the tutorials. As an answer I got told to read the list in the down load. Obviously (to me) there is a difference between a step by step demo and an instruction list. Secondly after reading the forum rules to see what attachments are O.K. I used PDF for ease of including both text and screen shots.This apperently did not suit his excellency. I hope you will appreciate that I had given up hope of any real cooperation from this individual BEFORE I wrote as I did.
Regards.

ZbuffeR
12-13-2011, 02:46 PM
You should not give up. If you have already tried to help people in forums on your free time, you already know it is hard. Questions about the context and details about the problem are important, it is not like you can peek above the shoulder to see what happens and when.

By the way, the title you see right below the user name is not self assigned, but automatically generated by the forum itself, with unknown rules (seem to be mostly related to total number of posts). Nothing to do with self-proclamation.

tyro1
12-23-2011, 09:45 AM
Wow! 658 views and not a single helpful hint!

all3fox
12-23-2011, 11:40 AM
Hi, sorry if i hijack this thread but my problem is identical: i fail to compile, build and run examples from the tutorial. Here is what i have:


uname -a
Linux faeton 3.0.0-14-generic #23-Ubuntu SMP Mon Nov 21 20:34:47 UTC 2011 i686 i686 i386 GNU/Linux


i download and extract both Tutorial 0.3.7 and premake-4.3 then carry out this sequence of actions:
go to glsdk subfolder in Tutorial and run

../../premake-4.3/bin/release/premake4 codeblocks
then go to the tinyxml folder and run the same

../../premake-4.3/bin/release/premake4 codeblocks
then go to Test and, guess what :), run

../../premake-4.3/bin/release/premake4 codeblocks
and run


codeblocks Test.workspace

then try to compile the Test project and get



||=== Test, Debug ===|
ld||cannot find -lglloadD|
ld||cannot find -lglimgD|
ld||cannot find -lglutilD|
ld||cannot find -lglmeshD|
ld||cannot find -lfreeglutD|
ld||cannot find -ltinyxml_pmD|
||=== Build finished: 6 errors, 0 warnings ===|


compiling the framework project succeeds but running it results in

You must select a host application to "run" a library...

i also tried
sudo ldconfig which didn't help (and i'm not sure if it was supposed to - i do sometimes fire sudo commands i don't really understand)

this is my k-th attempt to get the whole thing working and i did have some luck a couple of days ago by trying to compile the contents of Tut 01 Hello Triangle: i got "undefined __gle" something compilation errors but i can't replay them now - i don't remember what i did to get them.

Alfonse Reinheart
12-23-2011, 12:03 PM
Tyro1: Please take note on how to explain your problem. All3fox has clearly explained all of the steps he has done, and the errors in what he did are plainly evident. This allows me to effectively help him, rather than having to constantly ask him "what are you doing, what errors are you getting, etc."


then go to Test and, guess what :), run

Test is not for you ;) I will be deleting that directory from future releases. Yes, I know there's a Premake script in there and everything, but it's for testing purposes, not user purposes.

Note that the instructions (http://www.arcsynthesis.org/gltut/Building%20the%20Tutorials.html) don't mention the `Test` directory. Please try to follow the instructions more closely in the future.


and run


codeblocks Test.workspace


You skipped some steps. Remember: Premake4 doesn't actually make anything. All it does is generate build files. You still have to use the build files it generates to build that project.

After each execution of `Premake4`, you are supposed to use your build tools (Code::Blocks in this case) to build the project generated by it. So when you did:



cd //glsdk directory
../../premake-4.3/bin/release/premake4 codeblocks


It should have been followed by:



codeblocks glsdk.workspace


You build that project, in both debug and release. Only after this step is complete do you go on to build TinyXML. And again, you must load the TinyXML workspace after using Premake, and again you must build it in debug and release.

Once that's done, you're ready to build the tutorials.

all3fox
12-23-2011, 12:33 PM
Thanks! It nearly worked: i did as you said but when compiling freeglut project in glsdk workspace i got (sorry for partially russian)
||=== freeglut, Debug ===|
/Tutorial 0.3.7/glsdk/freeglut/src/freeglut_joystick.c|1430|оши&#10 73;ка: «O_RDONLY» undeclared (first use in this function)|
/Tutorial 0.3.7/glsdk/freeglut/src/freeglut_joystick.c|1430|зам&#10 77;чание: each undeclared identifier is reported only once for each function it appears in|
/Tutorial 0.3.7/glsdk/freeglut/src/freeglut_joystick.c|1448|оши&#10 73;ка: «F_SETFL» undeclared (first use in this function)|
/Tutorial 0.3.7/glsdk/freeglut/src/freeglut_joystick.c|1448|оши&#10 73;ка: «O_NONBLOCK» undeclared (first use in this function)|
/Tutorial 0.3.7/glsdk/freeglut/src/freeglut_joystick.c|1597|оши&#10 73;ка: «F_OK» undeclared (first use in this function)|
||=== Build finished: 5 errors, 0 warnings ===|


however now when compiling Tut 01 Main in Tutorial1.workspace i get just one single (and expected due to above failure) mistake
||=== Tut 01 Main, Debug ===|
ld||cannot find -lfreeglutD|
||=== Build finished: 1 errors, 0 warnings ===|


perhaps you know how to deal with this either? thanks in advance. (the reduced amount of mistakes indicates i've carried out your instructions correctly, right?)

Alfonse Reinheart
12-23-2011, 12:46 PM
It looks like this is something specific to Linux/Ubuntu with Code::Blocks and FreeGLUT.

How exactly did you get Code::Blocks installed on Ubuntu? I haven't managed to find a way to do that, so I've only been able to test the Code::Blocks build on Windows with MingW.

Until I can troubleshoot it, you may want to try using a regular makefile for the SDK rather than Code::Blocks. So use `Premake4 gmake` to create the makefile for the SDK, and then use `make config=...` to build Debug or Release.


the reduced amount of mistakes indicates i've carried out your instructions correctly, right?

You're doing everything correctly at this point.

carsten neumann
12-23-2011, 01:03 PM
Code::Blocks is a popular and large enough project that I'd expect Ubuntu to have packages for it - perhaps in a add-on package repository?

F_SETFL should be provided by fcntl.h (for me it is in /usr/include/bits/fcntl.h which is included by /usr/include/fcntl.h). On my system the package glibc-headers provides these files (on Fedora 16), Ubuntu probably has a similarly named package that provides system headers.

all3fox: Did you post the complete compiler output, specifically: is there no message about a file not being found?

all3fox
12-23-2011, 01:04 PM
How exactly did you get Code::Blocks installed on Ubuntu?
that was either
sudo apt-get install codeblocks
or (but i strongly doubt it) compiling from source.

i seem to have found the place in the manual

For GNU and makefile-based builds, this is “gmake”. This will generate a makefile. To build for debug, use make config=debug; similarly, to build for release, use make config=release.

Using the generated build files, compile for both debug and release. You should build the entire solution; the tutorials use all of the libraries provided.
but going to sleep now (it's past midnight already). Huge thanks for help!

all3fox
12-24-2011, 01:03 AM
Need a little help in here: industriousone.com/premake doesn't respond to me


all3fox@faeton:~$ ping industriousone.com
PING industriousone.com (204.11.246.1) 56(84) bytes of data.
^C
--- industriousone.com ping statistics ---
8 packets transmitted, 0 received, 100% packet loss, time 7054ms
all3fox@faeton:~$

while isup.me says it's down just for me. So could anyone please download premake4-3 for me (Ubuntu) and share it via something? I decided to make a clean attempt once again because compiling with gmake results in:


all3fox@faeton:~/Tutorial 0.3.7/glsdk$ ../../premake-4.3/bin/release/premake4 gmake
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
/bin/bash: /home/all3fox/Tutorial: No such file or directory
configure: WARNING: `missing' script is too old or missing
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... no
checking for mawk... mawk
checking whether make sets $(MAKE)... yes
checking for gcc... gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking for style of include used by make... GNU
checking dependency style of gcc... gcc3
checking whether gcc and cc understand -c and -o together... yes
checking for an ANSI C-conforming const... yes
checking build system type... i686-pc-linux-gnu
checking host system type... i686-pc-linux-gnu
checking for a sed that does not truncate output... /bin/sed
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for ld used by gcc... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking for /usr/bin/ld option to reload object files... -r
checking for BSD-compatible nm... /usr/bin/nm -B
checking whether ln -s works... yes
checking how to recognize dependent libraries... pass_all
checking how to run the C preprocessor... gcc -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking dlfcn.h usability... yes
checking dlfcn.h presence... yes
checking for dlfcn.h... yes
checking for g++... g++
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking dependency style of g++... gcc3
checking how to run the C++ preprocessor... g++ -E
checking for g77... no
checking for xlf... no
checking for f77... no
checking for frt... no
checking for pgf77... no
checking for cf77... no
checking for fort77... no
checking for fl32... no
checking for af77... no
checking for xlf90... no
checking for f90... no
checking for pgf90... no
checking for pghpf... no
checking for epcf90... no
checking for gfortran... no
checking for g95... no
checking for xlf95... no
checking for f95... no
checking for fort... no
checking for ifort... no
checking for ifc... no
checking for efc... no
checking for pgf95... no
checking for lf95... no
checking for ftn... no
checking whether we are using the GNU Fortran 77 compiler... no
checking whether accepts -g... no
checking the maximum length of command line arguments... 1572864
checking command to parse /usr/bin/nm -B output from gcc object... ok
checking for objdir... .libs
checking for ar... ar
checking for ranlib... ranlib
checking for strip... strip
checking if gcc supports -fno-rtti -fno-exceptions... no
checking for gcc option to produce PIC... -fPIC
checking if gcc PIC flag -fPIC works... yes
checking if gcc static flag -static works... yes
checking if gcc supports -c -o file.o... yes
checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes
checking whether -lc should be explicitly linked in... no
checking dynamic linker characteristics... GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking for shl_load... no
checking for shl_load in -ldld... no
checking for dlopen... no
checking for dlopen in -ldl... yes
checking whether a program can dlopen itself... yes
checking whether a statically linked program can dlopen itself... no
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... yes
configure: creating libtool
appending configuration tag "CXX" to libtool
checking for ld used by g++... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes
checking for g++ option to produce PIC... -fPIC
checking if g++ PIC flag -fPIC works... yes
checking if g++ static flag -static works... yes
checking if g++ supports -c -o file.o... yes
checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes
checking dynamic linker characteristics... GNU/Linux ld.so
(cached) (cached) checking how to hardcode library paths into programs... immediate
appending configuration tag "F77" to libtool
checking for X... libraries , headers
checking for gethostbyname... yes
checking for connect... yes
checking for remove... yes
checking for shmat... yes
checking for IceConnectionNumber in -lICE... yes
checking for XF86VidModeSwitchToMode in -lXxf86vm... no
checking for ANSI C header files... (cached) yes
checking GL/gl.h usability... yes
checking GL/gl.h presence... yes
checking for GL/gl.h... yes
checking GL/glu.h usability... yes
checking GL/glu.h presence... yes
checking for GL/glu.h... yes
checking GL/glx.h usability... yes
checking GL/glx.h presence... yes
checking for GL/glx.h... yes
checking fcntl.h usability... yes
checking fcntl.h presence... yes
checking for fcntl.h... yes
checking limits.h usability... yes
checking limits.h presence... yes
checking for limits.h... yes
checking sys/ioctl.h usability... yes
checking sys/ioctl.h presence... yes
checking for sys/ioctl.h... yes
checking sys/param.h usability... yes
checking sys/param.h presence... yes
checking for sys/param.h... yes
checking sys/time.h usability... yes
checking sys/time.h presence... yes
checking for sys/time.h... yes
checking whether time.h and sys/time.h may both be included... yes
checking for X11/extensions/xf86vmode.h... no
checking X11/extensions/XI.h usability... yes
checking X11/extensions/XI.h presence... yes
checking for X11/extensions/XI.h... yes
checking X11/extensions/XInput.h usability... yes
checking X11/extensions/XInput.h presence... yes
checking for X11/extensions/XInput.h... yes
checking whether gcc needs -traditional... no
checking for vprintf... yes
checking for _doprnt... no
checking for cos in -lm... yes
checking for gettimeofday... yes
configure: creating ./config.status
config.status: creating Makefile
config.status: creating doc/Makefile
config.status: creating include/GL/Makefile
config.status: creating include/Makefile
config.status: creating progs/Makefile
config.status: creating progs/demos/CallbackMaker/Makefile
config.status: creating progs/demos/Fractals/Makefile
config.status: creating progs/demos/Fractals_random/Makefile
config.status: creating progs/demos/Lorenz/Makefile
config.status: creating progs/demos/Makefile
config.status: creating progs/demos/One/Makefile
config.status: creating progs/demos/shapes/Makefile
config.status: creating progs/demos/smooth_opengl3/Makefile
config.status: creating progs/demos/spaceball/Makefile
config.status: creating src/Makefile
config.status: creating config.h
config.status: config.h is unchanged
config.status: executing depfiles commands
Building configurations...
Running action 'gmake'...
Generating Makefile...
Generating glload/Makefile...
Generating glimg/Makefile...
Generating freeglut/Makefile...
Generating glutil/Makefile...
Generating glmesh/Makefile...
Done.
all3fox@faeton:~/Tutorial 0.3.7/glsdk$ make config=debug
==== Building glload (debug) ====
==== Building glimg (debug) ====
==== Building freeglut (debug) ====
==== Building glutil (debug) ====
==== Building glmesh (debug) ====
all3fox@faeton:~/Tutorial 0.3.7/glsdk$ make config=release
==== Building glload (release) ====
==== Building glimg (release) ====
==== Building freeglut (release) ====
==== Building glutil (release) ====
==== Building glmesh (release) ====
all3fox@faeton:~/Tutorial 0.3.7/glsdk$ cd ..
all3fox@faeton:~/Tutorial 0.3.7$ cd tinyxml/
all3fox@faeton:~/Tutorial 0.3.7/tinyxml$ ../../premake-4.3/bin/release/premake4 gmake
Building configurations...
Running action 'gmake'...
Generating Makefile...
Generating tinyxml_pm.make...
Done.
all3fox@faeton:~/Tutorial 0.3.7/tinyxml$ make config=debug
==== Building tinyxml_pm (debug) ====
all3fox@faeton:~/Tutorial 0.3.7/tinyxml$ make config=release
==== Building tinyxml_pm (release) ====
all3fox@faeton:~/Tutorial 0.3.7/tinyxml$ cd ..
all3fox@faeton:~/Tutorial 0.3.7$ cd Tut\ 01\ Hello\ Triangle/
all3fox@faeton:~/Tutorial 0.3.7/Tut 01 Hello Triangle$ ../../premake-4.3/bin/release/premake4 gmake
Building configurations...
Running action 'gmake'...
Generating Makefile...
Generating ../framework/Makefile...
Generating Tut 01 Main.make...
Done.
all3fox@faeton:~/Tutorial 0.3.7/Tut 01 Hello Triangle$ make config=debug
==== Building framework (debug) ====
==== Building Tut 01 Main (debug) ====
all3fox@faeton:~/Tutorial 0.3.7/Tut 01 Hello Triangle$ make config=release
==== Building framework (release) ====
==== Building Tut 01 Main (release) ====
all3fox@faeton:~/Tutorial 0.3.7/Tut 01 Hello Triangle$ ./Tut\ 01\ Main
freeglut (./Tut 01 Main): glXCreateContextAttribsARB not found
all3fox@faeton:~/Tutorial 0.3.7/Tut 01 Hello Triangle$ ./Tut\ 01\ MainD
freeglut (./Tut 01 MainD): glXCreateContextAttribsARB not found


And if i'm doing something wrong again, please tell me. The current mistakes i get are trigured by the last two commands above.

UPD i scanned this forum and as far as i understand it's worth mentioning that i'm running on ASUS K40IJ notebook with Intel graphics which has kinda bad support for openGL, right?

Alfonse Reinheart
12-24-2011, 01:30 AM
i scanned this forum and as far as i understand it's worth mentioning that i'm running on ASUS K40IJ notebook with Intel graphics which has kinda bad support for openGL, right?

Yeah, it looks like Intel didn't attempt to implement GL 3.0 with your integrated chipset (even though they support D3D10). And these tutorials require GL 3.3 to run.

Sorry about that.

all3fox
12-24-2011, 02:53 AM
thanks a bundle, going to revive my decent desktop machine first.

all3fox
12-24-2011, 06:40 AM
ok, so i revived my desktop which is
Intel Core 2 Duo smth + motherboard ASUS P5QE + ATI Radeon HD 4870 (with an installed proprietary driver that has OpenGL 3.3.11318 Compatibility Profile Context)
and is now running a completely clear Ubuntu

all3fox@aldan:$ uname -a
Linux aldan 3.0.0-14-generic #23-Ubuntu SMP Mon Nov 21 20:28:43 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux

so i get Tutorial 0.3.7 and premake4 and make my first attempts to compile in glsdk subdirectory. These attempts fail because of several consequent codeblocks compilation errors (for some i found solutions):
1) Xlib.h no such file or directory

sudo apt-get install libx11-dev
2) GL/glu.h No such file or directory

sudo apt-get install libglu1-mesa-dev
3) this error actually bugged me: codeblocks said "/bin/sh: g++ not found"

sudo apt-get install g++
4) XInput.h no such file or directory

sudo apt-get install libxi-dev

and then i hit the fifth error that i had already encountered before:


||=== freeglut, Debug ===|
/Tutorial 0.3.7/glsdk/freeglut/src/freeglut_joystick.c|1430|оши&#10 73;ка: «O_RDONLY» undeclared (first use in this function)|
/Tutorial 0.3.7/glsdk/freeglut/src/freeglut_joystick.c|1430|зам&#10 77;чание: each undeclared identifier is reported only once for each function it appears in|
/Tutorial 0.3.7/glsdk/freeglut/src/freeglut_joystick.c|1448|оши&#10 73;ка: «F_SETFL» undeclared (first use in this function)|
/Tutorial 0.3.7/glsdk/freeglut/src/freeglut_joystick.c|1448|оши&#10 73;ка: «O_NONBLOCK» undeclared (first use in this function)|
/Tutorial 0.3.7/glsdk/freeglut/src/freeglut_joystick.c|1597|оши&#10 73;ка: «F_OK» undeclared (first use in this function)|
||=== Build finished: 5 errors, 0 warnings ===|

i googled it more aggresively than before but the only decent thing i found was that guys from some other project encountered it a year or so ago and their solution, as far as i understood, was to throw the freeglu_joystick.c out from freeglut.
here is their debating http://code.google.com/p/box2d/issues/detail?id=77#c10
i'd be happy to hear any explanations for this but meanwhile i'll try to compile it with gmake.

all3fox
12-24-2011, 07:02 AM
great news (at least for me) - after compiling for gmake and running the Tut 01 Hello Triangle i finally see this bloody white triangle on black font. Thanks to everyone :) Can finally start reading about OpenGL now.


all3fox: Did you post the complete compiler output, specifically: is there no message about a file not being found?

sorry i didn't notice that question at night. Yes, it was the complete output from codeblocks. No "file not found" or other messages.

Brandon J. Van Every
12-24-2011, 11:11 AM
You build that project, in both debug and release. Only after this step is complete do you go on to build TinyXML. And again, you must load the TinyXML workspace after using Premake, and again you must build it in debug and release.

Once that's done, you're ready to build the tutorials.

Hi again. In another thread you emphasized ease of use for your SDK. The above is why people typically ship binaries in a SDK. So that people with no deep investment in figuring out how to use stuff, can understand the essentials of what is offered without having to deal with build issues. Once people have made it past that point and decided a SDK is "worth it," of course the build should be easy to do, so long as one is willing to understand Premake etc.

Another reason for shipping binaries, is it proves that the SDK was buildable, at least at some moment in time. If binaries are released frequently, then it's proven at a recent moment in time.

Alfonse Reinheart
12-24-2011, 02:47 PM
I don't see how that would help in this case, since virtually no Linux-based library ships binaries. This is primarily because Linux binaries don't work very well on different machines. Even within the same distro, different machines will have different libraries and such installed.

When you're shipping something for a single platform like Windows, it's theoretically possible to ship binaries. When you're dealing with being multi-platform, it's simply untenable. On Linux, the most effective way to ship someone a library is as source code and let them build it themselves. Even on Windows it's non-trivial, as you need library variants for different compilers and such.

More importantly, this is a tutorial, not an SDK. The SDK is just used by the tutorial. And the build is less complex than it was before the SDK.

Brandon J. Van Every
12-24-2011, 03:59 PM
I don't see how that would help in this case, since virtually no Linux-based library ships binaries. This is primarily because Linux binaries don't work very well on different machines. Even within the same distro, different machines will have different libraries and such installed.

I'm not a Linuxer, I tend to try it every few years and run away. But your comment doesn't make sense to me, because I know there are distros, and people use them. People don't just spend all day rebuilding distros, unless they're serious tweakers who've just got to get that last optimization flag in there. So packages abound. Packaging on Linux is very modern compared to open source on Windows, where it's a joke (not counting Cygwin). Since I don't quite believe you, but I'm not really sure, I guess I'll go look for counterexamples of common libraries that have Linux packaging. Or even Linuxy ideas about SDKs. EDIT: Ok right didn't believe you. :) Ogre 1.7.3 SDK has a prebuilt Ubuntu package (http://www.ogre3d.org/download/sdk), research concluded.



Even on Windows it's non-trivial, as you need library variants for different compilers and such.

This I can speak to, because Windows is the primary open source drill I've done. Yes the work is non-trivial, but that's why a good SDK does the work, so that the consumers benefit and don't have to do it themselves.


More importantly, this is a tutorial, not an SDK. The SDK is just used by the tutorial. And the build is less complex than it was before the SDK.

Well admittedly I did not read the whole thread. I was just searching for all of your posts about glload to understand your SDK objectives. Half of the thread seemed pertinent enough, so I replied.

As for making a tutorial, I don't think the point is lost, however. Are you trying to teach OpenGL? Or are you trying to teach build systems? If the former and not the latter, it would be better to ship binaries and generated project files. My meager understanding is that premake4 can do that. You get standalone project files out the other end. Whereas the end results from CMake still have CMake as a final component.

all3fox
12-25-2011, 04:05 AM
Come on, Brandon J. Van Every, don't be that in love with shipping things in binary! Looking back on the build instructions for this particular tutorial i realize that everything was in its' rightful place so that to make the building process less painful. The fact that i kept failing meant only my lack of experience in building stuff which also means that i've learnt something.

Are you trying to teach OpenGL? Or are you trying to teach build systems?
both, sure. And that's a huge plus not a minus as you try to convince us. A plus because everything is decently documented.

Brandon J. Van Every
12-25-2011, 04:34 AM
The fact that i kept failing meant only my lack of experience in building stuff which also means that i've learnt something.

I suppose it's good that you value a learning curve, but many people don't. Either because they have too little experience, or they have too much experience. If you want the maximum uptake for something, make it as easy as possible for people to get going.

Alfonse Reinheart
12-25-2011, 12:06 PM
Ogre 1.7.3 SDK has a prebuilt Ubuntu package, research concluded.

That certainly is a package. But I don't see the "prebuilt" part. As I understand it, PPAs for libraries are perfectly capable of doing the building as part of the install process.

Also, Ogre isn't a tutorial; it's an SDK. You need to be able to build tutorials, because you will want to play with the example code. Thus, shipping a build process with full source code is very important.


As for making a tutorial, I don't think the point is lost, however. Are you trying to teach OpenGL? Or are you trying to teach build systems? If the former and not the latter, it would be better to ship binaries and generated project files.

A tutorial is not a series of programs that you run to see cool stuff. That's called a demo or example code. That's what you get from here (http://www.g-truc.net/project-0026.html#menu) (no offense intended; example code is important, for the purpose that it serves). Tutorials exist to do something very different. The most important parts of a tutorial are, in this order:

1: The text that explains how it works. Without this, actually learning why the particular code is where it is becomes virtually impossible.

2: The code that implements it. The salient points are covered in the text, but it's always nice to see the full code example.

3: The compiled binaries that show what the tutorial does. Without this... well, you could look at the pictures embedded in the text of the tutorial and follow along with little problem.

In short, the need to actually run the code is a distant third on the scale of "what actually matters for learning." Sure, you need to be able to build the projects to do the exercises at the end of the chapters. But in terms of following the tutorial itself? Not the most important thing in the world.

Does Premake4 allow you to ship build files? Sure. But the whole point of it is that you don't have to. They can make the build files for their particular build system with a single command line. If someone still uses VC6, they can get their project files. If someone uses Code::Blocks, they can get their workspaces. If someone loves Make, they can get makefiles.

Here is a list of the possible combination of OS and build files that I support by shipping a simple Premake4 script:

1: VC6
2: VC2002
3: VC2003
4: VC2005
5: VC2008
6: VC2010
7: Windows Make via Cygwin
8: Windows Make via MingW
9: Windows Code::Blocks
10: Windows CodeLite
11: Linus Make
12: Linux Code::Blocks
13: Linux CodeLite

That's thirteen separate build options. And since many of these use the same filenames, I would have to generate these into separate directories, thus creating 13 separate directories for each of the (currently 16) tutorials, the SDK, and TinyXML. That's a lot of clutter to look though, especially since each user is only going to be looking for their particular build tool.

Or I can just ask the user to type a simple command-line. A process that I take time out in the text to actually explain. This is not a Herculean effort requiring god-like strength. It's "premake4 platform", where `platform` is well-defined by a direct link to the Premake documentation. That's how Premake is intended to work.

That's the thing: we are not talking about an onerous process. We're not talking about forcing people to have to cobble together a build from loose files and some overly-simplistic directions (see the Lua distro if you want to see a really crappy build process). We're talking about one command. Execute it once, and you get your build files.

There are levels to "ease of use". Currently, I would say the tutorials and the SDK are "reasonably easy". I simply do not feel that attaining the level of "ease of use" you're talking about is worth the time, effort, or the problems that come along with it (large downloads. Shipping 10 separate windows binaries for 45+ executables in debug and release isn't small. Not to mention DLL-hell, since you keep wanting those).

Brandon J. Van Every
12-25-2011, 01:28 PM
Ogre 1.7.3 SDK has a prebuilt Ubuntu package, research concluded.

That certainly is a package. But I don't see the "prebuilt" part.

If you follow the link to the Ubuntu package (https://launchpad.net/~ogre-team/+archive/ogre) that's on that Ogre SDK page, you will see a nice text that says


Contains prebuilt Ubuntu packages for the Ogre library and its components (http://www.ogre3d.org).

To install the dev libraries, type:
> sudo apt-get install libogre-dev


I took that comment at face value. I don't know if it's true. I'm not a Linuxer, you can go test it. Even if it isn't prebuilt, it's claiming that you invoke one apt command and you're done. That's how things should be. No work, you're a build system, do it for me.



In short, the need to actually run the code is a distant third on the scale of "what actually matters for learning."


Only you say so. Everyone else wants to know that their learning curve isn't going to be a pointless waste of time. Clicking on a prebuilt binary sets a goal: this is what you're aiming to complete.



Does Premake4 allow you to ship build files? Sure. But the whole point of it is that you don't have to.

No, that's not the whole point. The point is you can make one build description that's cross-platform, cross-IDE, written in a sane language, and produces standalone build files. Actually, "the point" doesn't have to include all of that. I'm mainly interested in the sane language, I'm not going to learn MSBuild. If you don't want to ship binaries that's your point, not "the whole" point.


If someone still uses VC6,

then maybe they should be in a nursing home. :) Ok ok, maybe part of the Space Shuttle runs on VC6. Wait, they retired those. Ok! Some part of someone's ancient OpenGL infrastructure somewhere actually runs on VC6, and it's crucial to national security. I'm sure someone does it but it's not what I'd call an important case use.


That's thirteen separate build options.

Welcome to build engineering. ;-) It's a good practice to support all the ones that are mainstream. Do you want to talk about automated nightly builds and test suites?


That's a lot of clutter to look though,

The world manages. Go look at some of the bigger CMake driven open source projects.



Or I can just ask the user to type a simple command-line. A process that I take time out in the text to actually explain.


I think one verdict on that was had at the beginning of this thread. You "solved" the problem by insisting that someone RTFM. He got angry. Regardless of the ethics or morality of it, it says to me your approach is not as simple as you claim.

Look all we're actually arguing about at this point is how much work you personally care to do. Your gruntwork vs. how much you want people to utilize your SDK. If you want maximal adoption, you can adopt the practices that the largest, most popular cross-platform open source projects use.

Alfonse Reinheart
12-25-2011, 06:35 PM
Only you say so. Everyone else wants to know that their learning curve isn't going to be a pointless waste of time. Clicking on a prebuilt binary sets a goal: this is what you're aiming to complete.

Yeah, I guess you're right. I mean, I'm obviously a fool for spending all that time writing over three hundred pages of text, spending hours making charts and diagrams to explain points. Editing passages to make sure they're clear to a new user. Rearranging text so that each topic flows properly into the next, so that each tutorial builds on and properly reinforces its predecessors. That was a complete waste of time for a project intended for someone to learn from.

I mean, who needs detailed explanations for things when you can just ship binaries? I mean screw that whole teaching people how to use shader-based OpenGL; we've got to get some friggin' binaries out to people!

Oh, and if you're saying that you were talking about my SDK and not the tutorial, don't bother. You clearly said, "As for making a tutorial, I don't think the point is lost, however. Are you trying to teach OpenGL? Or are you trying to teach build systems? If the former and not the latter, it would be better to ship binaries and generated project files." And my point was that building the code is not the most important thing for learning with my tutorials.


No, that's not the whole point. The point is you can make one build description that's cross-platform, cross-IDE, written in a sane language, and produces standalone build files. Actually, "the point" doesn't have to include all of that. I'm mainly interested in the sane language, I'm not going to learn MSBuild. If you don't want to ship binaries that's your point, not "the whole" point.

Similarly, your interest in "the sane language" is also not "the whole point". It's a good point, but only using Premake4 because it's a nice build language misses a lot of its utility.

I use Premake4 as a way to support build systems that I have neither the time nor inclination to use. That's the whole point for my projects. It's a clean way to allow the user to pick their favorite build tool.

We have different needs. That's fine. What makes your needs so much better than mine?


then maybe they should be in a nursing home. smile Ok ok, maybe part of the Space Shuttle runs on VC6. Wait, they retired those. Ok! Some part of someone's ancient OpenGL infrastructure somewhere actually runs on VC6, and it's crucial to national security. I'm sure someone does it but it's not what I'd call an important case use.

And that's the whole point. You believe that VC6 users are not "an important case use".

I don't agree. The thing I hate the absolute most when working with Open Source projects is being told what build system to use. I hate projects that don't come with Visual Studio builds (or something that can generate them, like CMake/Premake). I hate the arrogance of OSD people who think that Make is all everyone should use, and screw those Windows developers for their fancy IDEs; just use VI like everyone else.

I don't use VC6. And I don't think that people should. But I do not believe it is my right to tell them that they shouldn't. I will make no special effort to ensure my code compiles on VC6; it is not officially supported. But I will also make no special effort to stop them.

If someone hates VC7+, who am I to say that they're wrong? Who am I to say that they shouldn't have a build system where they use VC6 as their IDE (and therefore need VC6 project files), but they actually hook into VC2010's compiler via various means? I may not use VC6, but I will not deliberately hurt them if I can avoid it.

Yes, I don't support every possible IDE. But I do use Premake4, which supports a hefty number of builds. That is, as far as I'm concerned, doing diligence as far as supporting builds.

I will make my projects available according to the values to which I hold. I believe that a project should be self-contained, affecting as little as possible on a user's system. I believe that a project should have a build system that accommodates the user's preferred tool path as much as possible, not tell them how to build their stuff. And yes, I believe that the build system should be reasonable straightforward and centralized as much as possible. Premake4 offers that.


I think one verdict on that was had at the beginning of this thread. You "solved" the problem by insisting that someone RTFM. He got angry. Regardless of the ethics or morality of it, it says to me your approach is not as simple as you claim.

That is not a reasonable conclusion given the available evidence. This thread contains exactly three people who ran into a problem. Two of them were easily and quickly helped. One of them could not be helped because he refused to actually say what the problem was in a reasonable way.

The only way to know whether the process is "as simple as (I) claim" is to match the number of build failures to the number of successes. Since neither of us has any particular knowledge of how many build successes I've had (I can give you download stats of around a thousand or so for the SDK, and half that for any given version of the tutorials. But a download does not necessarily mean a success), any attempt at a factual statement one way or another is false.

Trust me: people like `tyro1` exist. And they will have problems with the simplest install procedure. No matter how foolproof you make a system, someone will be a bigger fool. You can only look to how many people successfully use the system vs. failures.

And people for whom the system works don't need to make posts or file bug reports.


If you want maximal adoption, you can adopt the practices that the largest, most popular cross-platform open source projects use.

Which:

1: is no guarantee of "maximal adoption".
2: requires more time than I care to invest.
3: requires doing things that are against my personal beliefs.

Thank you for the advice. But I'll keep going with what I have, if it's all the same to you.

Of course, there's nothing stopping you (or anyone else) from using the existing distro to make and distribute binaries if that's what you really think would help. Many, many projects work this way, where the primary developers make the real code and others create various binary distros and such for those who want simpler installations (though most of the time, it is for much more complicated build systems).

In fact, if you took the time you spent writing messages and spent it on "build engineering" for my current SDK distro, I bet you'd have a couple of binary packages available by now ;)

I'm not going to do it. The only reason the SDK even exists is because it's derived from my tutorial framework. I felt that I could wrap it up in a nicer package and let people use it directly. If it helps someone, great. If it doesn't, that's fine. But I've invested about as much attention on having a reasonable build system as I'm going to.

Brandon J. Van Every
12-25-2011, 08:37 PM
Only you say so. Everyone else wants to know that their learning curve isn't going to be a pointless waste of time. Clicking on a prebuilt binary sets a goal: this is what you're aiming to complete.

Yeah, I guess you're right. I mean, I'm obviously a fool <snip>

Alfonse, here is my constructive feedback about your approach to all these things. You are a man of very strong, distinct opinions about how anything "should be done." I'm pretty sure this blinds you to other people's modalities of engagement. Whether it's a newbie in this thread trying to use your stuff that gets angry about how you speak to him, or some other person with an idea about opengl32.dll that you give a harsh critique to, or other such as I've seen in these forums while researching your posts and coding efforts. You have a lot of energy and drive, and sometimes you have good engineering taste. Other times you just have "your" engineering taste, and it seems like you haven't spent much time in other areas of public engineering practice. Maybe you took issue with something at some point and decided your way was the "right" way. It really doesn't matter, as you're the only one who's going to work on your tutorials and SDK, so long as you insist on your idiosyncracies. I'm just trying to tell you how other people see things; I can't make you see or agree.


We have different needs. That's fine. What makes your needs so much better than mine?

I've been trying to figure out if you have any popularity goals typical of SDKs. I conclude that you don't. There's a certain way that people bob and weave when they're trying to get everyone to adopt their stuff.


And that's the whole point. You believe that VC6 users are not "an important case use".

I don't agree. The thing I hate the absolute most when working with Open Source projects is being told what build system to use.

That's a rather emotional, theoretical, ideological objection. How many VC6 users are actually out there now? It's open source, they can code it up themselves if they want something particularly weird. Open source is supposed to be a profitable activity. It's not profitable if you're doing lots of extra work for weird corner cases that very few people actually need. By "profitable" I mean that anyone's effort should be weighed against the $X/hour they could be making doing something else.



One of them could not be helped because he refused to actually say what the problem was in a reasonable way.

Actually he could be. You just didn't want to do it on his terms. "I wrote TFM; you must RTFM." Well, maybe TFM isn't as good for a newbie as you believe it to be. Sure you asked him what he thought was wrong with TFM, but you were testy and standoffish about it. As though you really didn't want to hear that there was something inadequate about it, and just wanted him to get with the program and do his homework.



In fact, if you took the time you spent writing messages and spent it on "build engineering" for my current SDK distro, I bet you'd have a couple of binary packages available by now ;)


You're not the kind of project leader I'd hitch my wagon to, frankly. More like a code fork if I cared enough to solve OpenGL's problems. I don't know that I want that job. Thanks at least for licensing your code sanely; none of the other extension wrapper projects do.


The only reason the SDK even exists is because it's derived from my tutorial framework.

Well that explains a lot, if the tutorials came first. You're into writing tutorials, not SDKs.

Alfonse Reinheart
12-26-2011, 12:19 AM
I'm just trying to tell you how other people see things

No, you're telling me how you see things. Then you extrapolate from this, proposing that your view is universal and I'm wrong if I don't follow along.

That doesn't mean you aren't right. But it also doesn't mean that you are right. It is simply your perspective.


That's a rather emotional, theoretical, ideological objection.

Yes it is. I have no problems making decisions based on emotional, theoretical, and ideological bases.

And again, we're not talking about some onerous burden here. It's one command line. So I don't see how it's such a big deal.


Thanks at least for licensing your code sanely; none of the other extension wrapper projects do.

GLEW: uses what is effectively the BSD license, though they don't exactly call it that.

GLee (effectively defunct): uses the modified BSD license. Equivalent to MIT.

GL3w: Public domain.

GLxx: BSD license (though GPL for the actual build scripts).

So what extension wrapper projects are you talking about? The Klay Game Engine's GLloader library (I have no idea what license it uses; I saw a 100MB zipped download and decided against it)?

Brandon J. Van Every
12-26-2011, 03:32 AM
GLEW: uses what is effectively the BSD license, though they don't exactly call it that.

GLee (effectively defunct): uses the modified BSD license. Equivalent to MIT.

Codegen in both of these is GPL. I guess you never drilled down that far?

BTW Glee shows updates to Sourceforge as recent as September 2011. Commit comments claim to support OGL 4.2. The webpages that turn up when you Google for GLee, however, are quite stale.



GL3w: Public domain.


I forgot about that one. Too many of these things.



GLxx: BSD license (though GPL for the actual build scripts).


Like I said.



The Klay Game Engine's GLloader library (I have no idea what license it uses;


GPL.

maybe
12-30-2011, 08:58 PM
Hi, I'm trying to build the first tutorial using vs2010. I've done all the stuff from Building the Tutorials but when I try and run it in vs2010 I get a Unable to start frameworkD.lib message. The specified file is an unrecognized or unsupported binary format. Tried running the .exe and it flashes a cmd window at me which I think says Unable to generate context.

rili1111
10-18-2012, 08:56 AM
hi guys, im am also a newbie in opengl, i came across this tutorial a couple of days before and i am truying to build the unofficial opengl sdk and then after that the tutorials arcsynthesis. I decided to learn form this tutorial cause it is well build and it uses the best, like glm or the like... so new the big question: i also have problems buiding the unofficial opengl sdk and i also get the error message:

Unable to start program
'C:\arcsynthesis\Tutorial\glsdk\glload\lib\glloadD .lib'
The specified file is an unrecognized or unsupported binary format

i am using a macbook pro, and i am running windows7 64-bit, Visual Studio 2010.

what i actually do is:
1. download the source distribution, unzip
2. navigate to the glsdk form command prompt
3. run the command: premake4 vs2010 (i also tried premake4 --platform=x64 vs2010). After this step premake generates the glsdk visual studio 2010 project
4. open the project with the visual basic 2010 and then start the debugging

after this step i get an error message dialog with the message i wrote above

and the output of visual studio shows this message

1>------ Build started: Project: glload, Configuration: Debug Win32 ------
1> wgll_ext.c
1> gll_gl_ext.c
1> gll_c.c
1> Generating Code...
1> gll_cpp.cpp
1> glload.vcxproj -> C:\arcsynthesis\Tutorial\glsdk\glload\lib\glloadD. lib
========== Build: 1 succeeded, 0 failed, 0 up-to-date, 0 skipped ==========

after this i repeat the same steps with the tutorials:

2. navigate to the Tutorial form command prompt
3. run the command: premake4 vs2010 (i also tried premake4 --platform=x64 vs2010). After this step premake generates the AllTutorials visual studio 2010 project
4. open the project with the visual basic 2010 and then start the debugging

after this step i get again an error message like the one above:

Unable to start program
'C:\arcsynthesis\Tutorial\framework\lib\frameworkD .lib'
The specified file is an unrecognized or unsupported binary format

so i hoppe someone can give a hint and tell me what to do... thanks in advance

Alfonse Reinheart
10-18-2012, 10:05 AM
open the project with the visual basic 2010 and then start the debugging

The SDK is a library; you can't execute a library. You compile it.


open the project with the visual basic 2010 and then start the debugging

Start debugging what? There are 45 separate executables in that project. Did you tell the IDE which specific project you wanted to debug? Because it defaults to the Framework library, which again is a library and cannot be debugged.

If you want to execute a particular project, you have to right-click on it and make it the active project.

tksuoran
10-18-2012, 10:26 AM
As it is, this tutorial is way too difficult to get to build.

In a tutorial like this - and any project really - building should work out of the box with a single step. In Visual studio this would mean a solution with proper dependencies to projects and build steps. CMake could do it - I am not impressed by this premake thing.

Alfonse Reinheart
10-18-2012, 10:58 AM
Way too difficult? It's two steps. First you build the SDK. Then you build the tutorial of interest.

And that's not even his problem. His problem is attempting to execute a library. So your suggestion wouldn't even help.


CMake could do it - I am not impressed by this premake thing.

I could set Premake up to include the SDK as part of each tutorial's build. I didn't because that's really stupid. Libraries exist for a reason.

thekend
10-18-2012, 01:22 PM
As it is, this tutorial is way too difficult to get to build.

In a tutorial like this - and any project really - building should work out of the box with a single step. In Visual studio this would mean a solution with proper dependencies to projects and build steps. CMake could do it - I am not impressed by this premake thing.

I don't agree. It's more elegant and future proof to create these premake scripts and get ready for dozens of DEV tools. If you add VS solutions and projects, then for what version of VS? What if the user has an older version of VS? Using premake4 is not too dificult. Imho using premake is much more simple then using makefiles and CMake.

TheFritz
10-24-2012, 04:22 AM
Having only written some Java or C# code within a pleasant IDE might not provide enough background for the tutorial (I don't know, I haven't finished the tutorial yet). But in case somebody wonders what to do with the solution files premaker outputs, here is, what works in my case for Visual Studio 2010 (being a IDE-spoiled beginner myself):

- do every step as in the tutorial. When you have gotten the .sln files from premaker: open the .sln belonging to the glsdk in Visual Studio, click "built->configuration-manager" chose "debug", built the project. Click "built-> configuration-manager" chose "release", built the project.
- do the same thing ("premaker", Visual Studio: build "debug" and "release") for all tutorials.
I believe this is essentially what is written in the "Building the tutorials", just applied to VS2010.
You will find different places in the VS2010 where words like "release" and "debug" appear. I found this entry helpful:
http://social.msdn.microsoft.com/Forums/is/vssetup/thread/c89a6ad3-1858-4689-92b0-d222811f6036

By the way, it seems to be the right place to say "Thank You!" to Mr. McKesson for undertaking the work of writing the book an putting it online.

tksuoran
10-25-2012, 04:25 AM
Way too difficult? It's two steps. First you build the SDK. Then you build the tutorial of interest.

And that's not even his problem. His problem is attempting to execute a library. So your suggestion wouldn't even help.

I was not replying to his post, I was replying to the whole thread.


I could set Premake up to include the SDK as part of each tutorial's build. I didn't because that's really stupid. Libraries exist for a reason.

I agree that libraries exist for a reason. However, I consider that an orthogonal to the build system. If you include libraries as source in your distribution package, I see no reason why the build system can not simply do the right thing. When libraries are used, I would expect the meta build tool (cmake, premake, configure script etc.) to locate the libraries and configure executable builds so that they work - or - report an error locating / configuring dependencies. Isn't this the whole point in meta build tools?

The tutorial is very nice, that is the reason why I hope it would build without a hassle.

tksuoran
10-25-2012, 04:30 AM
I don't agree. It's more elegant and future proof to create these premake scripts and get ready for dozens of DEV tools. If you add VS solutions and projects, then for what version of VS? What if the user has an older version of VS? Using premake4 is not too dificult. Imho using premake is much more simple then using makefiles and CMake.

I was perhaps a bit too brief. I did mention cmake, and the idea is that you can make cmake to produce VS solution with proper project dependencies. You make all executable projects depend on the libraries they need. You can even do this with both libraries which you include as part of your source, and also with external libraries which are located during cmake configuration step. I see no reason why a build should end in an error due to missing dependency. Such errors should be reported by the meta build tool, which should also do some effort to locate the libraries during configure step.

centarix
10-25-2012, 04:41 AM
- do every step as in the tutorial. When you have gotten the .sln files from premaker: open the .sln belonging to the glsdk in Visual Studio, click "built->configuration-manager" chose "debug", built the project. Click "built-> configuration-manager" chose "release", built the project.
- do the same thing ("premaker", Visual Studio: build "debug" and "release") for all tutorials.
I believe this is essentially what is written in the "Building the tutorials", just applied to VS2010.


Thanks TheFritz, this solved my problem with building the tutorials in Visual Studio . Another thing to keep in mind, make sure you set your startup project (right-click project in Solution Explorer and click Set as Startup Project)to the tutorial you are trying to view. Otherwise you will get the misleading "Unable to start program (..)/frameworkD.lib"

limeforce
02-22-2013, 10:03 PM
Hey!
I also had trouble with building the tutorials. When I figured out how to do it, I wrote a little guide to help people who are struggling with the build process. It's written primarily for Windows 7 and Visual Studio 2010, but most of the concepts apply on all platforms! Here's the URL: emillindfors.fi/blog/building-gltut

Hope this helps someone!

korialis
03-06-2013, 06:25 AM
Hello!
I'm new to the forum and to OpenGL too...that's why I'm trying to get these tutorials work.

Anyway it seems i didn't catch something or doing wrong cause when I build the files using "premake4 xcode3" in glsdk for example I get these lines:

Building configurations...
Running action 'xcode3'...
Generating glload/glload.xcodeproj/project.pbxproj...
Generating glimg/glimg.xcodeproj/project.pbxproj...
Generating freeglut/freeglut.xcodeproj/project.pbxproj...
Generating glutil/glutil.xcodeproj/project.pbxproj...
Generating glmesh/glmesh.xcodeproj/project.pbxproj...
Done.

but after that I can't move onward:
I understood I have to compile it...the problem is I don't get any file in the folder to compile, just .xcodeproj files in every subfolder, and if I try to compile them one by one some of them work and some else give errors..

PS: Trying to perform actions like "premake4 vs2008" or "premake4 gmake" works different...creating a .sln file or a MAKEFILE respectively.. (In the main folder!)

Hope I've been clear
Waiting for an help.

Alfonse Reinheart
03-06-2013, 10:57 AM
Waiting for an help.

There's not much I can do to help here. MacOSX is not supported by my code, for several reasons. First, I don't have ready access to MacOSX, so I can't actually test anything there. Also, I don't know anything about XCode or Premake's support for XCode. Second, my code uses OpenGL 3.3, and MacOSX only support 3.2 (for some reason). So it wouldn't run anyway.

I'm sorry, but there's nothing I can do.

korialis
03-06-2013, 12:56 PM
I'm sorry, but there's nothing I can do.

:( Hoped there was a solution for this...anyway thank you for your answer ;)....guess i'll have to switch to my win partition or follow the tutorials on my desktop during weekends when I'm back home then!

ggrosso
05-09-2013, 01:36 PM
I think I'm having the same basic problem that many others are having when trying to build the tutorials in CodeBlocks on Windows 7.
Here's some background:
I followed the instructions to download and build the OpenGL SDK, and Premake4.
I used Premake4 with premake4 codeblocks command in the SDK folder and it created a CodeBlocks file for me.
I opened this file in CodeBlocks (v12.11) and started a build.
I also downloaded the Tutorials and used Premake4 in that folder to make a codeblocks file.
I opened the tutorial file in CodeBlocks and tried to build.

I get a compile error for the ld.exe file that says "cannot find -lglloadD"

I read through this thread, but I cannot get this issue solved. Can someone please help me to diagnose and resolve this error.
I still new to C++ so these kinds of errors knock me out.

Thanks.

korialis
06-28-2013, 12:16 AM
There's not much I can do to help here. MacOSX is not supported by my code, for several reasons. First, I don't have ready access to MacOSX, so I can't actually test anything there. Also, I don't know anything about XCode or Premake's support for XCode. Second, my code uses OpenGL 3.3, and MacOSX only support 3.2 (for some reason). So it wouldn't run anyway.

I'm sorry, but there's nothing I can do.
Finally I have free time to spend at home and can use my desktop!
Tonight i tried to build the tutorials so I could start your book, anyway I have encountered a problem while trying to build the tutorials under VS2010:

Building the glskd all went well, but when i try to build the tutorials, i.e. as an unique project (but one by one is the same) the framework would build, but none of the Tut builds getting this error [ LINK : fatal error LNK1123: errore durante la conversione in COFF: file non valido o danneggiato ] (in english LINK : fatal error LNK1123: error during COFF conversion: file not valid or damaged )

Hope you can help solving this, thank you!


[EDIT] Seem to have solved!, thank you anyway!

Kophay
07-17-2013, 06:12 AM
Hello,

I 'm building the tutorials on ubuntu 12.10. Premake runs fine. Then I run make: it builds tutorials 1 and 13 and then spits the following error:


==== Building Tut 12 Scene Lighting (debug) ====
Lights.cpp
In file included from Lights.h:12:0,
from Lights.cpp:13:
../framework/Interpolators.h: In instantiation of ‘void Framework::ConstVelLinearInterpolator<ValueType>::SetValues(const BidirectionalRange&, bool) [with BidirectionalRange = std::vector<glm::detail::tvec3<float> >; ValueType = glm::detail::tvec3<float>]’:
Lights.cpp:66:35: required from here
../framework/Interpolators.h:183:5: error: ‘distance’ was not declared in this scope, and no declarations were found by argument-dependent lookup at the point of instantiation [-fpermissive]
Lights.cpp:38:7: note: ‘float distance(const vec3&, const vec3&)’ declared here, later in the translation unit
In file included from Lights.h:12:0,
from Lights.cpp:13:
../framework/Interpolators.h: In instantiation of ‘void Framework::TimedLinearInterpolator<ValueType>::SetValues(const BidirectionalRange&, bool) [with BidirectionalRange = std::vector<std::pair<glm::detail::tvec4<float>, float> >; ValueType = glm::detail::tvec4<float>]’:
Lights.cpp:149:41: required from here
../framework/Interpolators.h:76:5: error: ‘GetValue’ was not declared in this scope, and no declarations were found by argument-dependent lookup at the point of instantiation [-fpermissive]
Lights.cpp:133:7: note: ‘float GetValue(const MaxIntensityData&)’ declared here, later in the translation unit
In file included from Lights.h:12:0,
from Lights.cpp:13:
../framework/Interpolators.h:77:5: error: ‘GetTime’ was not declared in this scope, and no declarations were found by argument-dependent lookup at the point of instantiation [-fpermissive]
Lights.cpp:134:7: note: ‘float GetTime(const MaxIntensityData&)’ declared here, later in the translation unit
In file included from Lights.h:12:0,
from Lights.cpp:13:
../framework/Interpolators.h: In instantiation of ‘void Framework::TimedLinearInterpolator<ValueType>::SetValues(const BidirectionalRange&, bool) [with BidirectionalRange = std::vector<std::pair<float, float> >; ValueType = float]’:
Lights.cpp:155:58: required from here
../framework/Interpolators.h:76:5: error: ‘GetValue’ was not declared in this scope, and no declarations were found by argument-dependent lookup at the point of instantiation [-fpermissive]
Lights.cpp:133:7: note: ‘float GetValue(const MaxIntensityData&)’ declared here, later in the translation unit
In file included from Lights.h:12:0,
from Lights.cpp:13:
../framework/Interpolators.h:77:5: error: ‘GetTime’ was not declared in this scope, and no declarations were found by argument-dependent lookup at the point of instantiation [-fpermissive]
Lights.cpp:134:7: note: ‘float GetTime(const MaxIntensityData&)’ declared here, later in the translation unit
make[1]: *** [obj/Debug/Tut 12 Scene Lighting/Lights.o] Error 1
make: *** [Tut 12 Scene Lighting] Error 2

One more question. Why the C headers? Surely you realise that these tutorials are visited by many who asprite to learn c++ and opengl all at once. The mixture of languages is pretty confusing.

Alfonse Reinheart
07-17-2013, 12:34 PM
spits the following error

You should probably submit a full bug report on that (https://bitbucket.org/alfonse/gltut/issues?status=new&status=open), rather than just making a post here.


Surely you realise that these tutorials are visited by many who asprite to learn c++ and opengl all at once.

If you try to learn C++ and OpenGL "all at once", you won't learn either one very well. That's why I told people up front not to do that. And I quote (http://www.arcsynthesis.org/gltut/About%20Need.html): "You are expected to be able to read C and reasonable C++ code. If “Hello, world!” is the extent of your C/C++ knowledge, then perhaps you should write some more substantial code before proceeding with trying to render images. 3D graphics rendering is simply not a beginner programming task; this is just as true for traditional graphics learning as for modern graphics learning."


The mixture of languages is pretty confusing.

The mixture of languages is pretty standard. C++ contains much of C and is language-compatible with it. OpenGL is usually defined in terms of C, so that's how it gets used.

Kophay
07-25-2013, 10:11 AM
I 'm not on bitbucket. You 're aware of it at least.



The mixture of languages is pretty standard.

That does not preclude it from being a bad standard.

Alfonse Reinheart
07-25-2013, 10:33 AM
I 'm not on bitbucket. You 're aware of it at least.

I am whenever I read this thread. But when I decide to take time to implement more stuff in the tutorial or fix bugs, I won't necessarily remember it because I'll be working from the actual bug list on Bitbucket. For example, I had completely forgotten about this issue until you posted this reply.

Also, you don't need a Bitbucket account to post a bug report (although it wouldn't be a bad idea, since it becomes impossible to get additional information from anonymous bug submissions).


That does not preclude it from being a bad standard.

The greatest strength of C++, and the principle reason it has survived for as long as it has, is that it can natively and easily talk to compiled C code with minimal effort. If you consider this a bad standard, that says more about you than it does about C++.

RigidBody
07-26-2013, 07:54 AM
brilliant thread.
it has heroes and villains, it has drama, and it is about opengl.
oh wait, now it seems to be about c and c++ too.
and it is 2 years old now.
i love it.

rsanchezsaez
09-01-2013, 01:41 PM
A little bit off topic, specially after all the epic adventures, but I will chime in with a little contribution.

I had lots of trouble trying to make FreeGLUT work on OS X. It seems that X11.org doesn't support OpenGL 3.2 contexts on OS X and you need that in order to use FreeGLUT with these tutorials.

Because of that I'm redoing the tutorials using FLGW3. I only adds parts from McKesson's framework as needed, so the simpler tutorials are easier to compiler and understand. I'm only providing an Xcode project (works straight away on OS X), but the code should be pretty much cross-platform and a Makefile should not be difficult to write.

In case anybody is interested, you can find it here: https://github.com/rsanchezsaez/gltut-glfw

Hope it helps.

andy zhao
10-03-2013, 06:35 PM
Hi V-man.
I have a MSVc2010 project converted from Vc6.0,and what I want to do is to reconstruct the 3D image using openGL. It function well in Vc6,but now something is wrong. The compiler says no error but the reconstructed 3D image can not be seen. The display part is black and sometimes I can see a flickering reconstructed 3D image. Can you please give me some advices about why? Thank you very much.