Skip to main content
gamedev.net
🔒 Locked

Announcement: Beta code release

Started by BBB 36 replies 32.6k views
Original Post
BBB
BBB
Those of you who've been following the progress of the NeHe site will be aware that some time ago a team of skilled volunteers was formed with the intention of producing fresh, up-to-date content for the site. Until recently we've unfortunately not had much in the way of progress visible to the public and we would like to take this opportunity to thank people for thier continued patience with the work the team has been and continues doing. Producing a good quality set of lessons that's worthy of carrying on the NeHe legacy is a large task, especially for a team of people doing this in what spare time they have available, but rather than compromise on quality the team has been hard at work to produce the best possible results. You may have noticed some recent updates to the NeHe site. You're now able to submit OpenGL related-news which if approved will be posted to the NeHe front page. The code for the site itself has also been cleaned up somewhat to improve stability and response time, and work on this front continues to go on behind the scenes. We're also happy to announce that the code for the first five of the new lessons has reached a stage where we're releasing it for public beta. At this point we must stress that this is a beta version of the code and as such may still contain bugs; if you encounter any problems or have feedback or questions about the code, please respond to this topic in the NeHe discussion forum, making sure to give plenty of detail of any bugs you may be reporting. Download the sample code here How the files are structured: Known issues with the current sample code include: #1: The #ifdefs are a temporary solution. This will be adressed before the final version. Please wait with submitting your project-files. #2: Some keys in the GLX-backend aren't translated (I couldn't make all of them work. These are clearly marked and help would be appreciated). #3: Improperly placed VisualStudio project-files. If you take a look under each lesson-directory you will see a /project-directory, and these contain sub-directories for specific window-backends and IDEs. So for example if you have made a project file for SDL and VisualStudio 8 then it should go in /lessonX/projects/windows/sdl/vc8. However, as mentioned earlier, we might do some final adjustments to the structure so please wait with making project-files for each lesson. We hope to have the accompanying lesson text available for public review shortly and will keep you updated on progress. In the meantime, we look forward to feedback on the beta code.
Caste
Caste
Quote:
Original post by BBB
Quote:
Original post by Anonymous Poster
One gripe though: you should not use hard tabs to indent code.


Yhea, I agree with you (not sure about the rest of the team but I think they would too).

Um BBB, perhaps you forgot we had a vote on this and most of us voted for tabs, not spaces [wink]. But if that's the only criticism on the code, I'm very glad though..
llvllatrix
llvllatrix
Nice job guys [smile] Code looks solid.
lc_overlord
lc_overlord
Quote:
Original post by Anonymous Poster
One gripe though: you should not use hard tabs to indent code.


well it was discussed in one of our earliest design meetings.
The main argument against hard tabs are that they indent to much (up to 8 characters), and this is especially a problem in heavily nested code (and code shouldn't really be that nested), however, this is only a problem in some editors as the majority of (c++) editors takes this in consideration and only use like 4 characters.
On the other hand in heavily nested code you also would need a LOT of spaces, like 9-12 compared to 3-4 tabs, there could literally be more spaces than code, there is also the problem of extra spaces when copying code.
Hard tabs are also auto formating in editors like VC++ meaning comments line up nicely even while editing the code(slightly), this might be possible with soft tabs, but it would make the whole thing a bit more complicated.
Ultimately we decided on hard tabs, though it is really a matter of taste(like Pepsi vs Cola or VI vs Emacs) and will not actually impact the code at all except for the formatting issues.

Edit: Besides my typewriter teacher always said "use tabs instead of spaces", but then again she also claimed that ordIII on the ABC 806 computer in a terminal server config was the ultimate word processor.
DevLiquidKnight
DevLiquidKnight
Good to see so far we have a positive response. Even though it’s only been out for a short time frame. The idea of using tabs was decided early on in the design process when we were devising a coding standard. It will most likely stay that way in order to have consistency.
Thorgrim
Thorgrim
Well on the subject of tabs, I think most people will be fine with whatever, as long as you are consistent... which you have not been so far it seems. Most of the files have a mix of both tabs and spaces, and some comments are lined up, and some are not (which looks a bit messy to me). Many people like a tab size different to 4, and at the moment that messes some of the code up a bit.

Also it would be nice if you were consistent with the end of line characters. I would suggest you stick with the windows ones (like you have in main.cpp) and remove all the unix eol characters.

Anyway, those kind of problems aren't too important.

More importantly I think you should be focusing on the comments etc... which I think are a bit lacking, unless you plan to add a bit more? The comments throughout the methods are ok, but I think you really need some overview type comments, explaining the flow, what the purpose of each method is etc. This is particularly important for the early lessons, so people don't get lost, and also for the more complex lessons so people can have a quick glance through and find the parts they are interested in.

It's a good start though.
jbadams
jbadams
Quote:
Original post by Thorgrim
More importantly I think you should be focusing on the comments etc... which I think are a bit lacking, unless you plan to add a bit more? The comments throughout the methods are ok, but I think you really need some overview type comments, explaining the flow, what the purpose of each method is etc.
I believe the intent is that this will be explained by the accompanying lesson text, rather than cluttering up the sample code with too many comments that wouldn't actually be there in production code, but if there are specific areas that could be better commented I'm sure the team will be open to suggestions.
- Jason Astle-Adams
evolutional
evolutional
Code looks good to me guys, great work!
lc_overlord
lc_overlord
Quote:
Original post by Anonymous Poster
I can't wait to see more complex lessons


Same here, and i will probably write most of them.
But even so, i think we have a pretty even phase of lessons planned, sure there are a handful of them that constitutes a larger step than most, like tga texture loading(05) and model loading (for now 16) since we can't split them in to smaller bit's, but all in all it shouldn't be that intimidating or complex compared to the previous one.
Shadowrom
Shadowrom
First of all i'd like to say:

very very very nice work guys!

I am working on a Portable Game Engine for Win64 and Win32 atm and found some portability issues.
They're not critical but give ugly compiler warnings when compiling for WIN64.

The compiler complains about the OnKeyXXX(int ...) functions maybe you should change them to OnKeyXXX(WPARAM ...) .

this leads us to the nehekeydef.h:

the definitions have other values when using WPARAM (eg. NK_F1 = 112)

and last but not least in the neheWin32Window.cpp file you should replace

GWL_USERDATA with GWLP_USERDATA to avoid compiler errors when compiling for a WIN64 target.

that is about it and you're almost ready for 64bit ;-)

But besides this your new tuorial codes look very good.
lc_overlord
lc_overlord
The thing about keys on win32 is a known issue, the thing is that for the ascii keys all systems return the same value, but F1 is not an ascii key and therefore we need to add a translation matrix in there for each system, and for win32 that has not been done yet, but it's not that hard.
_the_phantom_
_the_phantom_
I knew there was something I meant to give feedback on;

// Really Nice Perspective CalculationsglHint(GL_PERSPECTIVE_CORRECTION_HINT, GL_NICEST);


Get rid of this.
It is redundant and all vaguely modern hardware and drivers completely ignores it anyways.
Srki_82
Srki_82
I made a port of nehebeta to Lazarus/FPC. Currently only SDL window manager has been ported (Win32 and GLX will be ported later).

Download the sample code here
Hybrid666
Hybrid666
Hi,

I was just wondering if this code has been run on Vista in fullscreen mode?
I have tried running old NeHe basecodes on Vista, and found them to run fine in wondowed mode but in fullscreen just display a black screen!

Is this a known issue at all?

Hybrid
Lazy Foo
Lazy Foo
Is there an estimated time of completion? Winter or next Spring maybe?
Learn to make games with my SDL 2 Tutorials
Caste
Caste
We can't give you an exact date for completion because we all are rather busy at the moment, but due to the fact that we only have to fix some bugs in the code, add some more comments and review all the lesson texts I hope we'll release before next winter [wink]..
(Well.. apart form that we're having 2 inches of snow right now, thats why I wrote next winter..)

@Srki: The Lazarus/FPC port looks good and runs fine, but much slower than the C++ code, did you notice any speed losses? (Mandriva 2007, FPC 2.0.4)
Srki_82
Srki_82
I have tested FPC port only on Windows, and performance is nearly the same as original C++ code.

Maybe someone that has Linux could debug FPC port and find that slowdown.
Willbo_
Willbo_
Everything seems to work fine in both fullscreen and windowed mode on Vista 32-bit running on a nVidia 8800GTX card.
Willbo_
Willbo_
Sorry, I forgot to mention that. Yes, I was running the Win32 backend.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.