I was asked for some optimization hints for a “C” project. I made a video of some of my findings. See link below.
Some additional points:
- “dp_” only really works for VIA IO ports (and BIOS RAM locations), since these are defined by Peers “C” system
- the player-shot is a “Star” which consists of 12 vectors. One such shot takes about 1300 cycles to draw – and it is really fast and not discernable. If it were a “rotating triangle”, I don’t think the player would notice – but would probably save at least 2000 cycles for 3 displayed shots
- other characters also have “many” vectors. the bee e.g. has nearly 30 vectors, which on a real machine are also barely discernable. Half the size would probably suffice.
- for the small sprites – try to use the vectorlists which do not need to “sync”. This can be done by either setting the sync max in vecci, building shorter lists – or just DELETE the sync entries. Each sync costs about 200 cycles. Good taste and manual optimizations come in handy here :-).
- Look at the vide profiler:
- here one can see that these tiny little sprites (player + enemies) 7 at the moment use 10872 cycles to be drawn (first in list) – which is MORE than the complete web. These sprites have just to many vectors.
- It seems the “hit_object” is not the huge cycle waster – 14 tests only need 2187 cylces.
- If strengths of vectors are really big and scale is really low (<6?) -> the resulting list will look “broken” – this you have to test on a real vectrex. There can be function written especially for those lists – but I have at the moment (I think) not made them public in/with “C”