Delgine 3D Tools & Content DeleD Community Edition
Forums
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

A few questions about the source

 
This forum is locked: you cannot post, reply to, or edit topics.   This topic is locked: you cannot edit posts or make replies.    DeleD Community Edition Forum Index -> DeleD Development
View previous topic :: View next topic  
Author Message
chronozphere
DeleD PRO user


Joined: 20 Jun 2006
Posts: 1010
Location: Netherlands

PostPosted: Tue Jan 19, 2010 8:27 pm    Post subject: A few questions about the source Reply with quote

Hey guys

I'm reviewing the source as I want to organize it. And I have quite alot of questions. Smile

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. Wink

Thanks.
Back to top
View user's profile Send private message
Paul-Jan
Site Admin


Joined: 08 Aug 2004
Posts: 3066
Location: Lage Zwaluwe

PostPosted: Wed Jan 20, 2010 8:40 pm    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website
Jeroen
Site Admin


Joined: 07 Aug 2004
Posts: 5332
Location: The Netherlands

PostPosted: Wed Jan 20, 2010 9:42 pm    Post subject: Reply with quote

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. Wink 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. Smile
_________________
Check out Figuro, our online 3D app! More powerful 3D tools for free.
Back to top
View user's profile Send private message Send e-mail Visit poster's website
chronozphere
DeleD PRO user


Joined: 20 Jun 2006
Posts: 1010
Location: Netherlands

PostPosted: Fri Jan 22, 2010 9:57 am    Post subject: Reply with quote

Thanks for your answers! Smile

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
View user's profile Send private message
Display posts from previous:   
This forum is locked: you cannot post, reply to, or edit topics.   This topic is locked: you cannot edit posts or make replies.    DeleD Community Edition Forum Index -> DeleD Development All times are GMT
Page 1 of 1

 
Jump to:  
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