0 Members and 4 Guests are viewing this topic.
How about having a variable that tells the program what type of delay to do? I mean that for example the default state is 0 so that each time a grayscale is run, it uses the 6MHz delay. However, if you put 1 into it, then the grayscale commands will be using 15MHz delays. And maybe have it so that 2 different programs are compiled when the variable is modified.Dunno if I made myself clear.
I prefer to keep my 15 MHz games cross-compatible, even if it means they run twice slower on older models.
One thing about the new update:Can someone please tell me how the new commands would be used?More specifically, conj()r and the bitwise "and", "or", and "xor".
Hmm...What are the applications of such?I only see redundancy as of right now.
QuoteI prefer to keep my 15 MHz games cross-compatible, even if it means they run twice slower on older models.What you can do is this:prgm15MHZ:Full<some code>:Normal:DispGraphr:Full<more code>That way it will do all the game calculations in 15MHz mode but still update the graph in 6MHz mode. The 6MHz and 15MHz DispGraph routines take the same amount of time since they are limited by the same LCD delay in both cases.Quote from: Raylin on May 10, 2010, 03:24:09 pmOne thing about the new update:Can someone please tell me how the new commands would be used?More specifically, conj()r and the bitwise "and", "or", and "xor".This is a good explanation for the bitwise features:http://en.wikipedia.org/wiki/Bitwise_operationAs for conjr, these are the same:conj(L1,L6,100)conj(L1+99,L6+99,100)rIt copies the 99th byte first then the 98th, the 97th, ... to the 0th byte instead of the other way around.