Comments Please

Submitted by Scoot on
Forum
Programmers

I am interested to see the comments of some other people in relation to this program: http://www.smcmillan.net/scenerenderer.html .
Suggestions as to any additions or changes to the web site would also be welcomed. I guess it's a bit rough at the moment.

The program is not actually a game, just a simple scene viewing/editing system using a library I've made. Most of the library features have been designed to allow implementation of a game I want to make, but there are still a few more features to implement (and then the actual game to make) so I've been progressively updating this scene renderer program to use for testing purposes. The program primarily allows me to easily produce scenes that you can then watch.

I try to make it sound good on the web site, but I'd like to know what other people think I need to change or add, given that I would like to use this in my CV.

If I had to point out bad features at the moment (given the requirements and purpose of the scene renderer application) I'd probably say:
-The content needs to be upgraded in a major fashion. The two included scenes were just the most reasonable looking of those I was using for testing. The graphics quality should get a major boost when I finish creating this new content. There are also changes required to things such as some fragment shader code. E.g., tangent space normal mapped items with specular highlights are not ever "fogged".
-The menu system used was designed for a game. It's only really used because I wanted to test the game code library progressively during development. A standard MFC interface would have been a lot better (and a LOT easier). How bad does it seem? I'm used to it by now.
-If you want to create a new scene you need to add an XML file to the correct directory, not just choose a "New" menu item or something. There are also simple XML files that need to be configured to get other data into the program (e.g., models). I.e., adding new scenes or new content to place in the scenes requires some amount of knowledge, though reasonably small. This hasn't really bothered me because it's far quicker to add in a few small files and do the important editing operations in the program rather than spend the time writing and debugging import/export/new functions. Again this feature is also not required in the game code library. I guess it's a bit dodgy though.

Thanks to anyone who goes to the effort of looking at this program. If it crashes (noooooooooo!) please press "Yes" when it asks you if you want to send me an error log. The minidump file it sends could be very helpful in getting rid of a bug. Any other bugs you notice I would like to hear about too (they are lurking around somewhere in there I'm sure).

Submitted by Scoot on Thu, 03/03/05 - 12:16 AMPermalink

I updated the program a bit recently. I would appreciate any small comments what-so-ever. You don't even need to download the program if 6.5 MB is too much, just visit http://www.smcmillan.net/scenerenderer.html and click on the link to go to the Read Me file. A quick browse of that will give you a fair idea. I mainly just want to know what it looks like I've done right/wrong, whether the program looks advanced or basic, etc.

Thanks for any replies,
Scott McMillan.

PS: here's a picture.
[img]http://www.smcmillan.net/programming_page_files/scenerenderer3.jpg[/img]

Submitted by davidcoen on Fri, 04/03/05 - 5:44 AMPermalink

heh, cute to see that someone else has debug std::ostream output for there classes, looks neat~ after finishing it, what are your thoughts on code style? that looks a little messy to work on a big project with, but then again, i was not looking at your sample code in a IDE....

Submitted by Scoot on Sat, 05/03/05 - 10:15 PMPermalink

Thanks for the feedback.

I have found the code style to be quite good actually, it seems quite neat and easy to follow to me. It's consistent throughout the entire program. The guidelines are documented here http://www.smcmillan.net/programming/scenerenderer/0.9.2/nongenerateddo… . I am open to any suggestions for improvements. So far as I know it's pretty standard though, generally following the style guidelines I picked up in textbooks at university. I figure that the generally accepted conventions have evolved since before I was born and would have reached a pretty good state by now.
There were a couple of things that I learnt the importance of due to this being the largest program I've written though:

  • prefixing member variables with m_ is extremely useful when you come back to some code you haven't been working on for a few months. It's even more useful when you don't have the luxury of a nice IDE like Visual C++.
  • you need to have standard conventions for naming things such as enum values. If I know a MaterialVertexData enum is going to contain values prefixed with MVD_, I can just type that and press control+space to get a list. Sometimes you can't choose the names you want due to clashes, but it's a lot better than nothing.

Those were the only two things I changed.

Posted by Scoot on
Forum
Programmers

I am interested to see the comments of some other people in relation to this program: http://www.smcmillan.net/scenerenderer.html .
Suggestions as to any additions or changes to the web site would also be welcomed. I guess it's a bit rough at the moment.

The program is not actually a game, just a simple scene viewing/editing system using a library I've made. Most of the library features have been designed to allow implementation of a game I want to make, but there are still a few more features to implement (and then the actual game to make) so I've been progressively updating this scene renderer program to use for testing purposes. The program primarily allows me to easily produce scenes that you can then watch.

I try to make it sound good on the web site, but I'd like to know what other people think I need to change or add, given that I would like to use this in my CV.

If I had to point out bad features at the moment (given the requirements and purpose of the scene renderer application) I'd probably say:
-The content needs to be upgraded in a major fashion. The two included scenes were just the most reasonable looking of those I was using for testing. The graphics quality should get a major boost when I finish creating this new content. There are also changes required to things such as some fragment shader code. E.g., tangent space normal mapped items with specular highlights are not ever "fogged".
-The menu system used was designed for a game. It's only really used because I wanted to test the game code library progressively during development. A standard MFC interface would have been a lot better (and a LOT easier). How bad does it seem? I'm used to it by now.
-If you want to create a new scene you need to add an XML file to the correct directory, not just choose a "New" menu item or something. There are also simple XML files that need to be configured to get other data into the program (e.g., models). I.e., adding new scenes or new content to place in the scenes requires some amount of knowledge, though reasonably small. This hasn't really bothered me because it's far quicker to add in a few small files and do the important editing operations in the program rather than spend the time writing and debugging import/export/new functions. Again this feature is also not required in the game code library. I guess it's a bit dodgy though.

Thanks to anyone who goes to the effort of looking at this program. If it crashes (noooooooooo!) please press "Yes" when it asks you if you want to send me an error log. The minidump file it sends could be very helpful in getting rid of a bug. Any other bugs you notice I would like to hear about too (they are lurking around somewhere in there I'm sure).

Submitted by Scoot on Thu, 03/03/05 - 12:16 AMPermalink

I updated the program a bit recently. I would appreciate any small comments what-so-ever. You don't even need to download the program if 6.5 MB is too much, just visit http://www.smcmillan.net/scenerenderer.html and click on the link to go to the Read Me file. A quick browse of that will give you a fair idea. I mainly just want to know what it looks like I've done right/wrong, whether the program looks advanced or basic, etc.

Thanks for any replies,
Scott McMillan.

PS: here's a picture.
[img]http://www.smcmillan.net/programming_page_files/scenerenderer3.jpg[/img]

Submitted by davidcoen on Fri, 04/03/05 - 5:44 AMPermalink

heh, cute to see that someone else has debug std::ostream output for there classes, looks neat~ after finishing it, what are your thoughts on code style? that looks a little messy to work on a big project with, but then again, i was not looking at your sample code in a IDE....

Submitted by Scoot on Sat, 05/03/05 - 10:15 PMPermalink

Thanks for the feedback.

I have found the code style to be quite good actually, it seems quite neat and easy to follow to me. It's consistent throughout the entire program. The guidelines are documented here http://www.smcmillan.net/programming/scenerenderer/0.9.2/nongenerateddo… . I am open to any suggestions for improvements. So far as I know it's pretty standard though, generally following the style guidelines I picked up in textbooks at university. I figure that the generally accepted conventions have evolved since before I was born and would have reached a pretty good state by now.
There were a couple of things that I learnt the importance of due to this being the largest program I've written though:

  • prefixing member variables with m_ is extremely useful when you come back to some code you haven't been working on for a few months. It's even more useful when you don't have the luxury of a nice IDE like Visual C++.
  • you need to have standard conventions for naming things such as enum values. If I know a MaterialVertexData enum is going to contain values prefixed with MVD_, I can just type that and press control+space to get a list. Sometimes you can't choose the names you want due to clashes, but it's a lot better than nothing.

Those were the only two things I changed.