| Age | Commit message (Collapse) | Author |
|---|
|
|
|
With this change we avoid all memory allocations. Everything is
pre-allocated. It makes the frame-rate stay steady with no drops
produced by the GC. In order to test this, `gcprof` can be used from
`statprof` module.
|
|
This makes the process a little bit lighter, but it doesn't have a huge
impact in the performance. Looks like we are avoiding a memory
allocation without the `values` call.
|
|
Accessing the memory directly instead of an intermediate bytevector
makes things easier but still this looks like it's the bottleneck of the
whole thing.
|
|
The program counter must be reset after each frame, and it's not
supposed to be set after each instruction execution.
We were setting the PC from the C value of the instructions but that's
not what we need to do. The C value is only used for a jump and then, in
the next frame the PC must be reloaded from its value in the memory.
The only way to change the PC in the program is using it in the B
argument of the instructions, which would overwrite it with an arbitrary
value (stored in A).
|
|
|
|
|
|
|
|
|
|
|
|
- This changes happens to slow down the whole system a lot.
Also add a test for the PC.
|
|
Fixes access to bytes and instruction calls
|
|
Looks like the colors were unpacked incorrectly after the changes and
red and blue where inverted.
|
|
|
|
|
|
Using bytevectors inside makes the process way faster and now can be
safely used in the loop, not only for debugging purposes
|
|
Cleans the code generation and controls the formats better.
I'm not sure if this really improves performance, but it looks cleaner
so ¯\_(ツ)_/¯
|
|
Palette works, but the instruction execution loop doesn't.
Needs further research.
Sound and keys are not implemented either.
|
