Project forums > Q-Gears

How about OGRE3D?

<< < (4/4)

halkun:
I think this bickering is getting redundant without a vaiable soultion.

Let's worry about this later.

Right now the only real module on the table is the menu. This subsystem reqires no massive engine to move a little finger to select varibles. (The menu system is a little more complex than that, but in the end it's a 2D system.) We should worry about this when it's time to parse the field script and we have to render an entity on the screen.

If it becomes a challange to render an overhead view of cloud and yuffie in the STARTMAP debug room, then we can persue technologies needed. As for now, the loading of window.bin and maybe a text test should be in order.

sfx1999:
Well, I just think it would be good if you could leave space for plugging the module into another engine, if you do come to that point.

halkun:
Each module should be as orthogonal as humanly possable. This is a rule I'm holding steadfast too.

Orthogonal code: from the Pragmatic Programmer


--- Quote ---"Orthogonality is a critical concept if you want to produce systems that are easy to design, build, test, and extend. However, the concept of orthogonality is rarely taught directly. Often it is an implicit feature of various other methods and techniques you learn. This is a mistake. Once you learn to apply the principle of orthogonality directly, you'll notice an immediate improvement in the quality of systems you produce.

What Is Orthogonality?

"Orthogonality" is a term borrowed from geometry. Two lines are orthogonal if they meet at right angles, such as the axes on a graph. In vector terms, the two lines are independent. Move along one of the lines, and your position projected onto the other doesn't change. In computing, the term has come to signify a kind of independence or decoupling. Two or more things are orthogonal if changes in one do not affect any of the others. In a well-designed system, the database code will be orthogonal to the user interface: you can change the interface without affecting the database, and swap databases without changing the interface. Before we look at the benefits of orthogonal systems, let's first look at a system that isn't orthogonal.

In computing, the term has come to signify a kind of independence or decoupling. Two or more things are orthogonal if changes in one do not affect any of the others. In a well-designed system, the database code will be orthogonal to the user interface: you can change the interface without affecting the database, and swap databases without changing the interface."


--- End quote ---

Mixing our dependincies is going to cause havac. All calls must be handeled though the kernel, not to a supporting lib that has it's hands all over the codebase. It's a bad concept and I don't like it. If you want to add functioanlity, add it to the kernel. This is going to be the basis for adding other modules and supporting other games then FF7. You want to make FF9?  You will have to rewrite the fieldscript system a little, but the kernel calls should be the same. That the kind of modularity I'm looking for. Graphics is handled though one module, the kernel, that's it. The text boxes are rendered with it, the text is drawn by it, the 3d models are popped out by it.

Q-gears *is* an engine. It's silly to think we are writing an engine with an engine. You guys are talking about step 689 and we are on step 4. I'm going to guess by the time we need the technology to do what we need, it most likely will already be there.

Navigation

[0] Message Index

[*] Previous page