I know it has been requested many times and you answered "It is not any slower than the old method" but could you add an option to disable the progress bar while compiling ? I compiled Pokemon with 1.0.5 and with 1.1.2 and it takes longer with 1.1.2 (or maybe I counted faster ).

(I recorded gifs but they have to start at the same time if you want to compare speed).

Hmm... I guess I did have it update twice as often to make it smoother, so I can reduce the updating a little more to be like how it was.  However, I was actually thinking of optimizing the peephole opts into a lookup-table so that it performs significantly faster than the current linear search through all the opts.  It might even be possible to compile at nearly the same speed as the zoom option, in which case I could remove that feature, but that's optimistic, we'll see.

And Darl, I see what you mean now.  Since the size is now computeable during the first pass, I can show the message during the 2nd pass rather than after.  That's a good idea, I'll add this in the next update.

Quote from: Quigibo on March 18, 2012, 05:20:08 pm

Hmm... I guess I did have it update twice as often to make it smoother, so I can reduce the updating a little more to be like how it was.  However, I was actually thinking of optimizing the peephole opts into a lookup-table so that it performs significantly faster than the current linear search through all the opts.  It might even be possible to compile at nearly the same speed as the zoom option, in which case I could remove that feature, but that's optimistic, we'll see.

And Darl, I see what you mean now.  Since the size is now computeable during the first pass, I can show the message during the 2nd pass rather than after.  That's a good idea, I'll add this in the next update.

I wouldn't remove the Zoom option. It's useful for checking to see if the bug was caused by the peephole ops.

Ideally, there will eventually be no bugs caused by the peephole optimizer system. Not having to handle both compilation types would save size as well, allowing for new features.

Why can't custom constant names start with a lowercase letter? I feel like the reason for not allowing this was only to deal with binary numbers being represented as starting with b, but they aren't any more.

There isn't a syntax reason.  Mostly, it allows me to use them for other purposes in the future if I ever decide on a use them (such as low level register access, low or high byte access for variables, tables, etc.

To bring back another issue, I am basically going to have to write my own assembler or part of an assembler to build binary trees and hash tables because otherwise it would take forever to code it by hand and have to change every time I add new things to the lists.  But it should be fun.  I'll probably use python since it can do that kind of stuff with just a day or two of coding.  Ignore this statement if you have no idea what I'm talking about, but the biggest part of the compiling time is searching through lists, and this should make that faster.

Is there any reason against using letters or other characters for Fix codes?

Wouldn't 2-digit Fix codes break the syntax that sets multiple Fix settings at once? Or was that syntax removed at some point?

It's a pain to type it out. I'd go with letting Fix [letter], myself.