Skip to main content
gamedev.net
🔒 Locked

Code-structure

Started by BBB Jan 14, 2007 at 5:38 PM 6 replies 300+ views
Original Post
BBB
BBB
On the latest meeting as well in the thread "Status report" we had a debate on what structure to use for the introcode and we decided to vote on the forums so that everyone can say their opinion. So please read the status-thread as well as the log of the latest meeting. Basicly, it is Kazade's:
Quote:
SDL/ SDL/lesson01/lesson01.h SDL/lesson01/lesson01.cpp SDL/lesson01/framework/basenehelesson.h SDL/lesson02/ etc. GLX/ GLX/lesson01/lesson01.h GLX/lesson01/lesson01.cpp GLX/lesson01/framework/basenehelesson.h GLX/lesson02/ etc. WIN32/ WIN32/lesson01/lesson01.h WIN32/lesson01/lesson01.cpp WIN32/lesson01/framework/basenehelesson.h WIN32/lesson02/ etc. This means that we can just zip up each lesson folder for each framework and upload to the site.
Versus mine:
Quote:
/introcode/ /introcode/nehewindow/ /introcode/nehewindow/nehewindow.h|.cpp /introcode/nehewindow/glx/neheGLXwindow.h|.cpp /introcode/nehewindow/sdl/neheSDLwindow.h|.cpp /introcode/lessons/ /introcode/lessons/baselesson/nehebaselesson.h /introcode/lessons/baselesson/defaultlesson.h /introcode/lessons/lesson01/ /introcode/lessons/lesson01/main.cpp /introcode/lessons/lesson01/projects/ et.c. /introcode/license.txt
If everyone wants to have, besides an uber-package with everything, independant standalone packages for every lesson, then I can move everything in /introcode/lessons/ to /introcode/. That way you can create lessonX.zip simply by: #1: Create lessonX.zip #2: Add nehewindow/ #3: Add license.txt #4: Add baselesson/ #5: Add lessonX/ #6: Upload file to website. My structure sacrifices some time creating the zip to save LOTS of time when maintaining the code as (vs Kazade's) you won't have lots of duplicates of both the shared files such as nehebaselesson.h as well as window-backends. If we update something in say nehebaselesson.h then we will have to copy that new file numBackends * numLessons. This is a very bad practice IMO. With my structure we won't have to copy anything at all. The only thing we will need is to recreate the zips, but we obviously will also need to recreate them with Kazade's structure. Everyone please read the meeting log as well as the Status Report-thread and then vote or ask questions/leave comments. I, obviously, vote for my structure [smile]. Edit: Forgot: #1: My is a little less space-efficent because when you download the framework-folder you download all the backends, but this isn't a problem as its just some source-files. Fact is, it might actually be better for GD's servers as they will only need to handle one download per lesson instead of every lesson * every backend the user wants. Not that this really matters as our code is so small. #2:
Quote:
Original post by Kazade I believe the new stucture is clean and modular, and also the base-class header and source files are in the framework directory, leaving just the lesson code and the backend code in the parent folder, this is perfect because it hides from newbies what they dont need to know. Once they grasp how to create a window, or spin a cube they can look into the inheritance and the OO design if they want to.
I'm going to move nehebaselesson.h and nehedefaultlesson.h to /introcode/baselesson/, but I can also move that folder into /nehewindow if everyone wants that. However, I don't think that is a good idea. The lesson-interface isn't part of nehewindow and thus logically shouldn't be in /nehewindow (I think this might confuse people later on). Also, we can simply mention:
Quote:
The baselesson-folder is part of the OO-design of the introcode. It will be explained later on, just make sure you have it there for now.
[Edited by - BBB on January 16, 2007 7:15:28 PM]
Kazade
Kazade
The only reason I disagree with BBBs structure is there is a lot of this going on in the files:

#include "../nehewindow/nehewindow.h"
#include "../" ..etc

I do however agree that my structure is not the best for SVN and development, and not right for the super-package.

I propose therefore a compromise. We use BBBs structure on SVN, it WILL save time developing and updating, and we use BBBs structure when releasing a super package. However when we create the individual zip files we use my structure as it is designed for a single lesson.

I dont mind being responsible for creating these ZIP files if anyone thinks it will take time. But I do believe it is the best format for the individual lessons as it is simpler and cleaner. If someone only wants one lesson there's no reason to complicate the folder structure to support multiple ones.

The other thing to bare in mind is alternative languages that will be submitted to us, where do these fit in the structure of things?

In summary I vote for a compromise.
Member of the NeHe team.
Kazade
Kazade
BBB and I have been brainstorming this a little bit and we've come to the following structure for the super-package and SVN.

~/lesson01/projects/VC7/lesson01.proj
~/lesson01/projects/make/makefile
~/lesson01/lesson01.h
~/lesson01/lesson01.cpp
~/lesson02/projects/VC7/lesson01.proj
~/lesson02/projects/make/makefile
~/lesson02/lesson02.h
~/lesson02/lesson02.cpp
~/framework/nehebaselesson.h/cpp
~/framework/nehebasewindow.h/cpp
~/neheSDLWindow.h/cpp
~/neheGLXwindow.h/cpp
~/neheWin32window.h/cpp
~/glxmain.cpp
~/sdlmain.cpp
~/win32main.cpp

and this would then be simplified for individual lesson and backend packages like so:

~/lesson01/projects/VC7/lesson01.proj
~/lesson01/projects/make/makefile
~/lesson01/lesson01.h
~/lesson01/lesson01.cpp
~/framework/nehebaselesson.h/cpp
~/framework/nehebasewindow.h/cpp
~/neheSDLWindow.h/cpp
~/sdlmain.cpp

We both agree that this is a far better way of managing the code. So what does everyone else think?
Member of the NeHe team.
Ravuya
Ravuya
To avoid the problems with Kazade's solution that I identified (having to duplicate folders, etc for each architecture) I propose we use SVN symlinks instead of just simply copying the 'engine' folders to each lesson. That way, SVN will automatically check out the proper engine folder when you check out a lesson, without having to update each engine folder in turn.

This is way better because we can keep one engine project around, and just reference it from all the lessons, and it'll get checked out automatically -- so we can structure it exactly like Kazade's thing without the code duplication.

This way we can also branch NeHeLib for large architecture changes in case someone gets their horn out for it, and the people on that branch will have their lessons update transparently, so major engine changes can happen without disturbing the lesson development.
Caste
Caste
hey guys,
I was fiddeling around with symlinks on SVN and thought about that structure:
/SDL//SDL/basecode//SDL/basecode/neheSDLwindow.*/SDL/basecode/nehebaselesson.h/SDL/basecode/nehebasewindow.*/SDL/basecode/nehekeydef.h/SDL/lesson01//SDL/lesson01/main.cpp/SDL/lesson01/lesson01.*Symlink: /SDL/lesson01/basecode/SDL/lesson01/build.../SDL/lessonXX...


and the same for GLX and WIN, is that okay with you all?
I'll create this in /introcode/branches/luke2/

EDIT: Finished the SDL folder, the other two will follow

[Edited by - Caste on January 16, 2007 12:11:49 PM]
Ravuya
Ravuya
Like I've said several times, I'd prefer you two to come to a conclusion independently than me having to force something.
Kazade
Kazade
Um... before I agree with anything, I want to take a look at Castes branch under luke2 (mentioned above). I cant do that right now, perhaps tonight.
Member of the NeHe team.

Topic Locked

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

Sign in to reply to this topic.