Is there a 'best' way for optimizing code?

[garryg]

I generally follow the - plan it out - hash it up the easiest most straightforward way I can - test and edit it until it works - and then start the 'normal' optimizing stuff...

By 'normal' optimizing stuff I mean change it to, or check, the  things people normally say, e.g. use ripped RAM versions of the ROM drawing routines where you can, make sure you are scaling as best you can, and that all scaling is the same, use pre-rendered 'sprites' for rotation, and try to eliminate any drift without adding any flickering, and anything else that springs to mind as I'm looking at the code.
So I'm basically fiddling with the 'working' code after I have (more or less) completed the game.

But is this the best approach?

I usually write the game in 'modules' broken over different text files anyway.
So should I be trying to optimist and test each part as I go - almost to the point of writing unit testing type code where possible?
Does anyone actually program the Vectrex like this, and if so does it really make for a better end product?

[christophertumber]

Write modular code and re-use key subroutines as much as possible. If you figure out a way to optimize them it's automatically applied across current and upcoming projects. If you need to customize for a specific project you can do so without impacting anything else. But things like your basic drawing routines or sprite routines shouldn't change very often.

[garryg]

Thanks, that's good advice.

I used a modular code approach for making Vectrex Circus, and Trapped. But it never occurred to me to write the basic drawing and sprite routines etc as separate modules, these could be written in a separate file, optimized, and then tested with a simple test program before being added to a game development.

I tend to have each logical part of my games in separate file anyway, the main game loop file doesn't have much in it, as it calls everything else.

This way I should need less optimization at the end of development

[kokovec]

Sometimes I find that I have to sacrifice memory for speed by using in-line code though.

[christophertumber]

FWIW, I use inline macros a lot. And try to reduce reliance on loops. Overhead from subroutines and loops can add up quickly.

[mikiex]

If you use AS09 make it also output the LST file and you can see your cycle counts next to the code.
One thing I wish you could do is self modifying code. I have a friend doing Dragon32 stuff and he uses it all the time. Unless you run some code from precious ram on the vectrex you can't do it

[kokovec]

You can with my NVRAM cart

[thomas]

I also use macros myself for inlining code where necessary, do 'sacrifice' memory for speed (tables..) and use custom draw routines.
With custom routines you not only get the option to change the appearance brightness-wise to your liking but are able to use
the otherwise unused wait cycles to do a lot more, here's a typical routine overview:

a) START_MOVE_TO_POSITION
b) hit detection and movement calculation
c) WAIT_FOR_END_OF_MOVE
d) draw (maybe with varying scale factors, depends on what you want to do)
e) ZEROREF

and a/c/e are simple macros. This alone gives you a .very. nice perf. boost. You can start this on emulation but have to finish
on real hardware - the timing is slightly different and the shift reg not handled correctly. You are also in better control of the
'scale' register for the draw this way: since this is the lo timer you wait until a line is done you want it to be as low as possible for speed.
Or higher for higher brightness.

All my 'sprites' in Robot Arena are handled this way, almost the entire logic is done while the beam moves to a position.
There's also more going on game-engine wise but this mechanism can be used everywhere.

and to give you an idea: not using macros alone for 60 sprites/shots at 60Hz would use up 172800 cycles per sec for 4 jsr/rts pairs (12 cycles),
already 11% of 1.5million..