Login [Register]
Don't have an account? Register now to chat, post, use our tools, and much more.
Hey everybody.

I'm hard at work on Skyrim CE, mostly on the planning phases, and wanted to ask you guys for some help with speeding up data decompression.

Currently, I have data from a 7x21 matrix for each sector being compressed into a list, one column per list entry (2 digits per matrix elements x 7 rows = 14 digits per list entry, backwards). Taking some tips from lirtosiast, here's what I've got for decompression:

Code:
PRGM:θSKGU
:For([recursiven],1,21
:L₁([recursiven]
:For(M,1,7
:sub(Ans→[A](M,[recursiven]
:iPart(Ans
:End:End
:E2fPart([A]→[A]


A few trials showed that this decompression takes ~1.5 seconds to run, and I am wondering if I can reduce this even by a little bit. Thanks!
Honestly, what you've got looks pretty quick. I can't think of any improvements, although I'm sure if Lirto gets his slimy hands all over it, then it will get quicker Evil or Very Mad

This is absolutely cheating, but


Code:
PRGM:θSKGU
:prgmSANIC
:For([recursiven],1,21
:L₁([recursiven]
:For(M,1,7
:sub(Ans→[A](M,[recursiven]
:iPart(Ans
:End:End
:E2fPart([A]→[A]


where


Code:
PRGM:SANIC
Asm84CEPrgm210500E03601C9
mr womp womp wrote:


Code:
PRGM:SANIC
Asm84CEPrgm210500E03601C9


Might I ask what exactly this does?
mr womp womp wrote:
...if Lirto gets his slimy hands all over it


Hey, I wash my hands frequently!

Anyway, either of these should work (7-800 ms). The key is reducing interpreter overhead, and the only command that does converts lists to matrices without loops is List>matr(. In fact, due to them being simply data-copying routines, List>Matr( and ^^T are very fast.


Code:
List>matr(10^(seq(X,X,~2,~14,~2)),[C]  //column vector
List>matr(L1,[B]  //B^^T is row vector
int(|E2fPart([C][B]^^T->[A]



Code:
List>matr(L1|E~2,L1|E~4,L1|E~6,L1|E~8,L1|E~10,L1|E~12,L1|E~14,[A]
int(|E2fPart([A]^^T->[A]
kg583 wrote:
mr womp womp wrote:


Code:
PRGM:SANIC
Asm84CEPrgm210500E03601C9


Might I ask what exactly this does?

It changes the wait-states setting for the flash to 6 rather than 9, effectively making the calculator not wait as long as it normally would when accessing the flash. 6 seems to be about as low as you can go, any lower and the calc just crashes immediately.
I don't think that lowering the flash waitstates to 6 is safe. Back when the C toolchain set this value, there were some user reports of programs unexpectedly crashing. After this was changed to a value of 8 instead, such reports seemed to stop.
I'm constantly reducing the wait states of my calculator and I've personally never had an issue with the calculator randomly crashing. The worst I've ever experienced (and I can not confirm it's even caused from reducing wait states) is my graph screen displaying some unmapped memory or some Y vars being filled with a few thousand bytes of random tokens. It makes sense that the lower you go, the less stable your calculator will be, however I think swapping to 6 wait states for a short amount of time shouldn't be an issue for most people. Smile
  
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
Page 1 of 1
» All times are GMT - 5 Hours
 
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

 

Advertisement