 |
DeleD Community Edition
Forums
|
| View previous topic :: View next topic |
| Author |
Message |
chronozphere
DeleD PRO user
Joined: 20 Jun 2006
Posts: 1010
Location: Netherlands
|
 Posted: Tue Jan 19, 2010 8:27 pm Post subject: A few questions about the source |
 |
|
Hey guys
I'm reviewing the source as I want to organize it. And I have quite alot of questions. 
1. What is the purpose of TBVHNode, located in unit_BVH (not included in project)? Should it be removed?
2. unit_GeometryManipulator.pas seems not to be included in the project. Should it be removed?
3. I noticed the following comment in the TBufferedStringStream class:
| Quote: |
Line 49: // INFO, PJ: Design flaw, if you task this through TStringStream interface you will get the wrong datastring!
|
How do we deal with these comments? Should these issues be adressed?
4. What is the purpose of the TCommandAllowance class?
5. Can I consider TColorControl a GUI element? Where is it used?
6. I notice there are alot of *builder* classes (e.g TAnimationBuilder). When are they used? Is this the "builder" design pattern you are using?
7. TFloatTextureLoader? Where does DeleD use floating point textures?
8. IMPORTANT: How do the classes defined in unit_Generics.pas and the ones defined in unit_Types.pas relate (for example: TGenericVertex and TVertice)?
I need some brief answers to (most of) these questions to be able to categorize files and to understand the source better.
I'm now halfway reviewing the files, so more questions will follow. 
Thanks. |
|
| Back to top |
|
 |
Paul-Jan
Site Admin
Joined: 08 Aug 2004
Posts: 3066
Location: Lage Zwaluwe
|
| Posted: Wed Jan 20, 2010 8:40 pm Post subject: |
|
|
Picking some of those:
Ad 1 & 2) The most efficient answer: try it. If it still compiles, removing them is fine. If it doesn't compile, add them to the project.
3) No, unless they cause you direct pain. "INFO" means "INFO", extra info that cannot be deducted directly from the code but might save you some pain. "TODO" means "hit the developer who committed the source in this state and left it this way". They are followed by the developer shortcode, PJ in my case.
The only one who uses these kind of prefixes (there are a couple more) is me, it's the corporate standard at my dayjob, and it's actually not conform the DeleD code-style (jeroen decided to just use plain text comments). It's what you get for sneaking in 5 minutes of DeleD after 12 hours of grinding for a deadline.
If these annoy you, remove them. Then again, I'd rather have you focus on different stuff.
7) The raytracer is HDR by design so it uses it, with plans to apply it to both the lightmapper and the actual textures used in the scenes.
8 ) The classes defined in unit_types are the _core_ classes used in the Primitives (rendering and manipulation). However, when you are doing calculations (like csg), they are a bit heavyweight and cumbersome. To be able to write code more efficiently, Jeroen introduced a more lightweight version of the classes in unit_Generics. |
|
| Back to top |
|
|
Jeroen
Site Admin
Joined: 07 Aug 2004
Posts: 5332
Location: The Netherlands
|
| Posted: Wed Jan 20, 2010 9:42 pm Post subject: |
|
|
To elaborate on PJ's comments:
| Paul-Jan wrote: |
Picking some of those:
3) No, unless they cause you direct pain. "INFO" means "INFO", extra info that cannot be deducted directly from the code but might save you some pain. "TODO" means "hit the developer who committed the source in this state and left it this way". They are followed by the developer shortcode, PJ in my case. |
My shortcode is JC. Do note that I sometimes use the TODO shortcode for things I would like to implement. It doesn't always mean it has to be implemented. So, whenever you come across a TODO, JC statement, feel free to ask me what the h*ll I actually meant. You might also come across the NOTE shortcode. I use that one to emphasize some comment is especially important.
| Paul-Jan wrote: |
8 ) The classes defined in unit_types are the _core_ classes used in the Primitives (rendering and manipulation). However, when you are doing calculations (like csg), they are a bit heavyweight and cumbersome. To be able to write code more efficiently, Jeroen introduced a more lightweight version of the classes in unit_Generics. |
Heavyweight is indeed the right word here. TVertice/TPolygon/TEdge objects involve many references to each other (as in, vertex x is used by polygon y and edge z etc etc) and include some pretty complicated routines to guard the entire integrity of primitives where references are concerned. Whenever a change in the geometry happens, the entire structure around the modified area might need to be updated and those references allow us to quickly identify affected geometry. You probably can imagine you don't really want such behavior when performing heavy-duty CSG.
_________________
Check out Figuro, our online 3D app! More powerful 3D tools for free. |
|
| Back to top |
|
|
chronozphere
DeleD PRO user
Joined: 20 Jun 2006
Posts: 1010
Location: Netherlands
|
| Posted: Fri Jan 22, 2010 9:57 am Post subject: |
|
|
Thanks for your answers!
I've taken a closer look at the TColorControl class, and I think it's redundant. I have seen different kinds of color selection and I think we should have only one. This method seems ok to me:
| Code: |
procedure TfrmScreenshotOptions.imgWatermarkColorClick(Sender: TObject);
var
colorDialog: TColorDialogEx;
begin
colorDialog := TColorDialogEx.Create;
try
colorDialog.Color := imgWatermarkColor.Canvas.Brush.Color;
if colorDialog.execute then begin
fWatermarkColor := colorDialog.Color;
UpdateWatermarkColor;
UpdateWatermarkPreview;
end;
finally
FreeAndNil(colorDialog);
end;
end;
|
Any reason we should keep TColorControl? |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
