Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

Control Flow

2 (2.2%)

Arrays, Strings, Pointers, and References

8 (9%)

Functions

4 (4.5%)

Basic object-oriented programming

30 (33.7%)

A bit more advanced OOP (Composition, Operator overloading, Inheritance, Virtual Functions)

18 (20.2%)

Templates

8 (9%)

Other (Explain)

4 (4.5%)

Working with files?  (Streams)

15 (16.9%)

Total Members Voted: 89

[Siquo]

Too much code, I snipped it up into smaller parts, spreading it over many objects.
Perhaps I should concentrate all OpenGL stuff into one API, though.

Tonight I'll clean it up some and post it here, I'm at a total loss.

[Siquo]

So, what I know:
- SFML does open me a window
- I do get an OpenGL 3.2 context (from glew)
- the camera-position-data sent to gluLookAt() is correct
- I get the background color that I specified
- That's all I get. No polygons in sight.

Code: [Select]

// Init SFML

  sf::VideoMode mode;
  mode.Width = 1024;
  mode.Height = 768;
  mode.BitsPerPixel = 32;

  sf::ContextSettings settings;
  settings.DepthBits = 32;
  settings.StencilBits = 8;
  settings.AntialiasingLevel = 2;
  settings.MajorVersion = 3;
  settings.MinorVersion = 2;

  App = new sf::Window(mode, "SFML OpenGL", sf::Style::Close, settings);
  App->Create(mode, "SFML OpenGL", sf::Style::Close, settings);
  App->SetActive();
  Input = &(App->GetInput());

  if(glewInit() != GLEW_OK){
    std::cout<<"Glew Init Error!";
  }
  GLuint vboID;
  glGenBuffers(0, &vboID);
  std::cout<<"Glew version: "<<glewGetString(GLEW_VERSION)<<"\n";
  if (GLEW_VERSION_3_2){ std::cout<<"OpenGL 3.2!\n";}
  std::cout<<"glGenBuffers: "<< glGenBuffers <<"\n\n";

  glClearDepth(1.0f);
  glEnable(GL_DEPTH_TEST);
  glDepthFunc(GL_LEQUAL); // The Type Of Depth Test To Do
  glDepthMask(GL_TRUE);
  glShadeModel(GL_SMOOTH); // Enables Smooth Shading
  glHint(GL_PERSPECTIVE_CORRECTION_HINT, GL_NICEST); // Perspective Calculations

  glMatrixMode(GL_PROJECTION);
  glLoadIdentity();

  glMatrixMode(GL_MODELVIEW); // Select The Modelview Matrix
  glLoadIdentity(); // Reset The Modelview Matrix

  glEnable(GL_TEXTURE_2D);
  glTexEnvf(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_MODULATE);

  glViewport(0, 0, mode.Width, mode.Height);
  gluPerspective(45.f, (GLfloat)(mode.Width/mode.Height), 0.1f, 100.0f);
  std::cout<<"Open window:"<<mode.Width<<"x"<<mode.Height<<" \n";

  glClearColor ( 0.0f, 0.0f, 0.0f, 0.0f );
  glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);



And here's the renderloop, with a lot of extra muck in the spirit of "If I just throw a lot of stuff to OpenGL I'm sure not to miss any".

Code: [Select]


  glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
  glLoadIdentity();

  Vec3 p = camera->getPos();
  Vec3 l = camera->getDirection();
  Vec3 u = camera->upDirection;
  glViewport(0, 0, 1000, 1000); // Reset The Current Viewport

  glMatrixMode(GL_PROJECTION); // Select The Projection Matrix
  glLoadIdentity(); // Reset The Projection Matrix

  glMatrixMode(GL_MODELVIEW); // Select The Modelview Matrix
  glLoadIdentity(); // Reset The Modelview Matrix

  gluLookAt(p.x,-p.y,p.z,
    l.x,-l.y,l.z,
    u.x,-u.y,u.z);
  camera->frustum.setCamDef(p,l,u);


  glClearColor ( 0.2f, 0.2f, 0.4f, 0.0f );
  glColor3f(1.0f, 1.0f, 1.0f);


  glTranslatef(-1.5f,0.0f,-6.0f); // Left 1.5 Then Into Screen Six Units

  glBegin(GL_TRIANGLES); // Begin Drawing Triangles
glColor3f(1.0f,0.0f,0.0f); // Set The Color To Red
glVertex3f( 0.0f, 1.0f, 0.0f); // Move Up One Unit From Center (Top Point)

glColor3f(0.0f,1.0f,0.0f); // Set The Color To Green
glVertex3f(-1.0f,-1.0f, 0.0f); // Left And Down One Unit (Bottom Left)

glColor3f(0.0f,0.0f,1.0f); // Set The Color To Blue
glVertex3f( 1.0f,-1.0f, 0.0f); // Right And Down One Unit (Bottom Right)
  glEnd(); // Done Drawing A Triangle

  glTranslatef(3.0f,0.0f,0.0f); // From Right Point Move 3 Units Right
  glColor3f(0.5f,0.5f,1.0f); // Set The Color To Blue One Time Only
  glBegin(GL_QUADS); // Start Drawing Quads
glVertex3f(-1.0f, 1.0f, 0.0f); // Left And Up 1 Unit (Top Left)
glVertex3f( 1.0f, 1.0f, 0.0f); // Right And Up 1 Unit (Top Right)
glVertex3f( 1.0f,-1.0f, 0.0f); // Right And Down One Unit (Bottom Right)
glVertex3f(-1.0f,-1.0f, 0.0f); // Left And Down One Unit (Bottom Left)
  glEnd();


  App->Display();


[Supermikhail]

Hey, dudes. That's still about chars. My compiler says that

Code: [Select]

char *phrase = "hello world!\n";
is

Code: [Select]

deprecated conversion from string constant to ‘char*’
I think it means that I shouldn't be using that.

[Siquo]

Code: [Select]

char *phrase = "hello world!\n";


"hello world\n" is a literal expression, and char* is a pointer to a character.
This way, char* would be pointing to "h" of an expression that would be released from memory at the next statement... That the compiler warns you and you don't get a run-time segfault as soon as you use "phrase" is very nice of your compiler, actually

This works only if you do something like

Code: [Select]

function a (const char* a){}

a("hello world");
because "hello world" would exist for at least the duration (scope) of the function.

[Supermikhail]

It actually worked pretty nicely (several times, at that), for some reason, but the author of the book is still an asshole... Well, hopefully, used to be, as the book was published in 2001.

[Normandy]

As mentioned earlier, use either const char* or char[] for string literals.

[Virex]

Code: [Select]

char *phrase = "hello world!\n";


"hello world\n" is a literal expression, and char* is a pointer to a character.
This way, char* would be pointing to "h" of an expression that would be released from memory at the next statement... That the compiler warns you and you don't get a run-time segfault as soon as you use "phrase" is very nice of your compiler, actually

This works only if you do something like

Code: [Select]

function a (const char* a){}

a("hello world");
because "hello world" would exist for at least the duration (scope) of the function.

That'd however add the overhead of a function call, which is redundant for such a short phrase*.  As Normandy said, just assign it to a data type that does work properly for what you're trying to do.
*I know, readability and all, but if you were going to sacrifice speed for ease of programming, why use C instead of C++?

[eerr]

Let me assume the compiler did not give you an error, and actually let you compile this.
As-is.

A pointer is 32-bits, a char is 16.

You just copied 240 bits of data into a 32-bit pointer.


Not only did you just fill the pointer with the junk data 'he', you just copied the rest of the data into space that may or may not be initialized. As you don't have any other variables to ruin, the only spot you could possibly smash is some other program. Something that might be important.

This program could crash your computer, but probably won't do it consistently.
Plus its not that much data, so the computer is likely not to spaz out yet.

Oh but wait, theres more!

You pass a garbage pointer to printf();
You have a very significant chance of printing out random amounts of junk data. You may end before one character is printed. And you may get a segfault.

This does not exactly seem like what you wanted to do, so you should give the compiler a big hug.

[Supermikhail]

On that note, I'd like to congratulate the book's author again on being a jerk. Why does that not output anything?*

Code: [Select]

#include <iostream>
int main(int argc, char **argv)
{
    std::cout << "Received " << argc << " arguments...\n";
    for (int i=0; i<argc; i++)
       std::cout << "argument " << i << ": " << argv[i] << std::endl;
    return 0;
}

...And to thank the author of the book and everybody here, because Yes! Yesterday I finally finished streams, my dream, and...

NewbieCoder: Whoah. I know file output.
Morpheus: Show me.
 

...and gave a go to my undergraduate project. Until 4 a.m., but it worked. Laugh.

Code: [Select]

//element.hpp
#include <iostream>
using namespace std;

class Element
{
public:
Element() {}
~Element() {}

Element(char*, double , short* , short );

char* GetName() const { return itsName; }
double GetElectronegativity() const { return itsElectronegativity; }
short GetValnumber() const { return itsValnumber; }
void DisplayValencies() const;

private:
char* itsName;
double itsElectronegativity;
short itsValency[7];
short itsValnumber;
};

Element::Element(char* name, double electronegativity, short valency[], short valnumber)
{
itsName = name;
itsElectronegativity = electronegativity;
itsValnumber = valnumber;
for(int i=0; i<valnumber; i++)
{
itsValency[i] = valency[i];
}
}

void Element::DisplayValencies() const
{
for(int i=0; i<itsValnumber; i++)
cout << itsValency[i] << ", ";
}


Code: [Select]

#include <iostream>
#include "element.hpp"
using namespace std;

int main(int argc, char** argv)
{
char name[20];
double electronegativity;
short valency[7];
short valnumber;

cout << "Enter the desired element's name: ";
cin >> name;
cout << "\nEnter " << name << "'s electronegativity: ";
cin >> electronegativity;
cout << "\nEnter " << name << "'s overall number of valencies: ";
cin >> valnumber;
for (int i = 0; i<valnumber; i++)
{
cout << "Enter valency number " << i+1 << ": ";
cin >> valency[i];
}

Element newelem (name, electronegativity, valency, valnumber);

cout << "Element " << newelem.GetName() << "'s electronegativity is ";
cout << newelem.GetElectronegativity() << "." << endl;
cout << "Its overall number of valencies is ";
cout << newelem.GetValnumber() << "." << endl;
cout << "Its valencies are ";
newelem.DisplayValencies();
cout << "." << endl;

return 0;
}

I feel that I use here exactly what you told me not to, but I'm currently kind of in a fog and don't exactly understand how I managed to make it run.

*Whatever files I pass to it in the command line.

P.S. Yes, I tried to make a sizeless array of shorts through a pointer, as you can see in the first code portion. Is there actually a way to do it?

[eerr]

I don't see any arrays of size zero being created. It sounds you were planning to rely on that, but worked around it.

So this wasn't a C class?

shame, it sounds like you didn't properly learn about file I/O, streams, and variations on printf.

That is a double shame, considering they are rather simple.

[Supermikhail]

It's a book on C++, but I've read a couple of "books" (both of them were pretty short and introductory) on C, and even did a stupid book of exercises.

Actually, streams is the first lesson I did properly. That is, typed out most of the code from the book, because I was curious how it worked out. But it's still kind of scary. Well, maybe because I first got introduced to file operations through Delphi, then I went to C, and I recall file operations were kind of difficult in both of them.

Edit: Hm, that code post is misleading, if you think about it. I waited until after the streams lesson to start my project, because it's going to need that and lessons haven't been going very well (I just can't take as much code in one sitting as this book offers me). File input/output isn't there yet. I'd appreciate it if somebody could point out how I could make the existing code more efficient.

[Normandy]

@eerr:
Your explanations are a bit wrong.

@Supermikhail:
It's perfectly fine to use char[20] instead of char*, if you know that there will be a maximum name length. Especially if you're still in the learning stage, learning program structure is so much more important than learning little things like that. Do one thing at a time. Learn how to program first, then learn how to program C++.

Your existing code is fine. It gets the job done. It uses standard C++. Don't bother with "optimization" or "efficiency" until you're comfortable with your own code.

[Supermikhail]

Your existing code is fine. It gets the job done. It uses standard C++. Don't bother with "optimization" or "efficiency" until you're comfortable with your own code.

Er. I decided to replace most "endl" with "\n" . I guess it's kind of silly, but I suspect it gives me a few milli- (micro?) seconds advantage.

[Virex]

Get a profiler, it'll show you any bottlenecks in your code. Replacing endl with \n means squat if you're doing redundant square root calculations somewhere else . Also, I'm not experienced with C, but from what I know about assembly, the amount you save that way is probably in the order of 10 clock cycles, maybe 50, which on a 2 GHz computer is 20 to 100 nanoseconds.

[Supermikhail]

Hm. A profiler goes with an IDE? I can't find any for my Geany.

Also, well, I might have found a critical bottleneck (or something) in my very idea. Can somebody tell me if any shenanigans are involved in compiling code written on Linux, on Windows? Especially if it involves SDL.

Also, is there any advantage in using short over integer, even if hypothetical?