Miloch Posted April 8, 2007 Share Posted April 8, 2007 By "three of those points" I would guess you're referring to lines of code, mod file size and download speeds. Agreed, those are all the same, or related at least. But how is going from... COPY_EXISTING_REGEXP GLOB ~^_?davaeo\.cre$~ ~override~ READ_LONG 0x2b8 "slot_offset" READ_LONG 0x2bc "item_offset" READ_LONG 0x2c0 "item_number" WRITE_SHORT ("%slot_offset%") "%item_number%" WRITE_LONG 0x2b8 ("%slot_offset%" + 0x14) WRITE_LONG 0x2c0 ("%item_number%" + 1) INSERT_BYTES ("%slot_offset%") 0x14 WRITE_ASCII ("%slot_offset%") ~cdioun2~ #8 BUT_ONLY_IF_IT_CHANGES To... ACTION_IF FILE_EXISTS_IN_GAME ~FW0100.ARE~ THEN BEGIN OUTER_SPRINT ~tsu~ ~_~ END ELSE BEGIN OUTER_SPRINT ~tsu~ ~~ END COPY_EXISTING ~%tsu%davaeo.cre~ ~override~ REPLACE_CRE_ITEM ~cdioun2~ #0 #0 #0 ~NONE~ ~HELMET~ BUT_ONLY_IF_IT_CHANGES ...increasing lines of code/file size? Math isn't my strong point, but I think we go from 10 to 8 lines. Incidentally, you only need the ACTION_IF block once, and you can reduce both the regexp/globbing and the lines of code with R_C_I on every single CRE where it's relevant. As for decreasing margin of error, I meant it's easier to look at the latter in a glance to tell if it's bunk rather than the former. Now I'm not saying you *should* do this - my motto tends to be "if it ain't broke, don't fix it"* - I'm just saying optimizing code isn't a bad thing. Assuming one does even a halfass job of code proofing and testing (hopefully, one would do that for a new version anyhow ). Feel free to move this to some other forum, since it's wandered rather far afield from the river plug key getting pinched by Bigby's Invisible Groping Hand or whatever it is. * Except for Fixpacks of course. How many things we're fixing are genuinely broken, strictly speaking? Link to comment
CamDawg Posted April 8, 2007 Share Posted April 8, 2007 R_C_I is shorter, yeah, and produces identical results to the code that's already working. For the vars, it's substantially longer--plus you're forgetting that BGT also uses the BG prefix in some places. It's trivial to handle this in a regexp, but requires yet more variables and definitions for the alternative. Wasn't this supposed to be an optimization? Are my WHILE loops next, or my long variable names? Link to comment
Miloch Posted April 8, 2007 Share Posted April 8, 2007 R_C_I is shorter, yeah, and produces identical results to the code that's already working. For the vars, it's substantially longer--plus you're forgetting that BGT also uses the BG prefix in some places. It's trivial to handle this in a regexp, but requires yet more variables and definitions for the alternative.Wouldn't call it "substantially" longer. Just an extra line or two, either at the beginning of the component or the mod (in an ALWAYS section):OUTER_SPRINT ~tsb~ ~_~ //Tutu OUTER_SPRINT ~tsb~ ~BG~ //BGT COPY_EXISTING ~%tsb%xan.cre~ ~override~ Even if it did increase overall code size, given the install speed improvements over regexp globbing, I'll take the couple extra lines . Wasn't this supposed to be an optimization? Are my WHILE loops next, or my long variable names? Your long variable names . Like I said, I wasn't intending a code review (like I'm even qualified for that - hell, I've probably stolen half my code from yours) - it was just a suggestion. Link to comment
Recommended Posts
Archived
This topic is now archived and is closed to further replies.