HotCompiler Optimizations

Moderator: TGRDM3 Team

Locked
User avatar
Tiger
Developer
Developer
Posts: 856
Joined: Thu Feb 25, 2010 3:44
Location: United States

HotCompiler Developer Menu [DevOp]

Post by Tiger » Mon Dec 05, 2011 5:14

Implement a dedicated 'developer menu' [Developer Options] which carries the follow:
  • CHOICE /listen: 1,2,3,4,5 /t 0
    • Rebuild cache data
    • Rebuild cache and compile //STORE; less CPU intensive.
    • RAW Compile [Hybrid]
    • Compile [STORE] in PK3
    • Return to 'Standard Menu'
This will allow ease use of the HotCompiler when altering OSC's within the .\Trunk dir. To access this menu from the standard compiling menu, plausibly press 'd'.
Nicholas "Tiger" Gautier

User avatar
Tiger
Developer
Developer
Posts: 856
Joined: Thu Feb 25, 2010 3:44
Location: United States

HotCompiler Optimizations

Post by Tiger » Sun Dec 11, 2011 5:46

Keeping brief, utilize static variables for trimming down the FilePaths within the directories and have two new .bat for testing the integrity of the compiled build and for the duplication process (caching). Stepwise refinement is really in mind with this tool, lets keep it consistent. Additionally, might be able to gain a few bytes in the end, but not really worth mentioning.
Nicholas "Tiger" Gautier

User avatar
Tiger
Developer
Developer
Posts: 856
Joined: Thu Feb 25, 2010 3:44
Location: United States

Re: HotCompiler Optimizations

Post by Tiger » Mon Jan 02, 2012 14:08

A few more optimizations to consider:
  • Win5.x compatibility mode (Check CHOICE)
  • Allow choice for verbose mode before duplication and through-out the program
  • Self-Check during start-up. Check to assure all methods can be called correctly.
  • Sub-menus for each compression type: PK3, PK7, and PK3-Developer. This will not only avoid intimidation and avoid common minor mistakes, but can leave room for better options!
  • Allow the user to choose wither to utilize 'all' cores during compiling {64Bit}
  • Descriptions on each action (selectable, not forced). This can help users to understand what is happening and what they are doing within the program.
Nicholas "Tiger" Gautier

User avatar
Tiger
Developer
Developer
Posts: 856
Joined: Thu Feb 25, 2010 3:44
Location: United States

Re: HotCompiler Optimizations

Post by Tiger » Sun Jan 08, 2012 6:51

Merged HotCompiler Developer Menu [DevOp] with this topic as both of these topics will be involved within the updates.

Notes: Hybrid compiling maybe a massive risk factor in the long run when the project further escalates.
Nicholas "Tiger" Gautier

User avatar
Tiger
Developer
Developer
Posts: 856
Joined: Thu Feb 25, 2010 3:44
Location: United States

Re: HotCompiler Optimizations

Post by Tiger » Fri Jun 01, 2012 8:27

As HotCompiler 2 already covers most of these, I will go ahead and close this entire thread.
Tiger wrote:Implement a dedicated 'developer menu' [Developer Options] which carries the follow:
No, instead - this is generally done.
Tiger wrote:CHOICE /listen: 1,2,3,4,5 /t 0
NO! The entire rewrite of HC2 does not support nor utilize the CHOICE external command at all.
Tiger wrote:Return to 'Standard Menu'
Done
Tiger wrote:Compile [STORE] in PK3
Supported
Tiger wrote:RAW Compile [Hybrid]
Not happening, too much work and easy to break when escalating.
Tiger wrote:Rebuild cache and compile
Supported
Tiger wrote:Rebuild cache data
Supported.
Tiger wrote:utilize static variables for trimming down the FilePaths within the directories
Done
Tiger wrote:Allow choice for verbose mode before duplication and through-out the program
With the Windows Shell, this is not as easy to accomplish without further bloating the code. As a result, I will not bother implementing this feature.
Tiger wrote:Self-Check during start-up. Check to assure all methods can be called correctly.
Partially implemented.
Tiger wrote:Sub-menus for each compression type: PK3, PK7, and PK3-Developer. This will not only avoid intimidation and avoid common minor mistakes, but can leave room for better options!
This, I handled differently. The program should not 'drive' by archive type, but by the options available and process everything at the end. Thus, meaning, Archive type and compression passing options are just standard options and does not depend on what 'archive' type is selected until compiling the build.
Tiger wrote:Allow the user to choose wither to utilize 'all' cores during compiling {64Bit}
Supported.
Tiger wrote:Descriptions on each action (selectable, not forced). This can help users to understand what is happening and what they are doing within the program.
This can be accomplished later in the future.
Nicholas "Tiger" Gautier

Locked

Return to “Closed Feature Requests”

Who is online

Users browsing this forum: No registered users and 1 guest