I haven’t had as much spare time lately as I would have liked – and in my spare time I did not do much Vectrex – so the given time scale some time ago is not valid anymore.
I will probably have a chat with my co “workers” in the next month to talk about next steps.
What I did do were some tiny steps towards a game “engine”.
It still is not really usable I think – and the way I am thinking now – I am not sure it ever will.
At least not in a way I’d like it to. As shown some blog entries ago it is a tile engine. There are a couple of things I need (want) to pull of:
- level sizes arbitrary
- level sizes larger than one screen, so the level should scroll
- I really ould like to do smooth scrolling, this also needs clipping at the edges
- I want a main “sprite”, and several “enemy” sprites
- I want background music
- I want sfx
- I want to keep everything within 50Hz
What I still am experimenting with is a tile display engine that is fast enough to be usable. As it turns out the clipping is not the cycle eater I once imagined. The main “eater” is the sheer amount of tiles that must be displayed at once to make a “jump and run” a “jump and run”. Each tile (at the moment) is placed on the screen individually.
The tile engine I have here now is pretty configurable – I can have any number of horizontal and vertical tiles (in arbitrary sizes) and an arbitrary size of the playfield. The demo file below is a 10×10 tile field displaying a viewport of a 80×80 level.
All updates are in 50Hz – but barely. To be usable in a “real” game, not just a demo I must further enhance it.
The most occupied areas of the demo level use about 29900 cycles (when all sides are clipped) and about 22000 when not clipped. My estimate is, that I must get the whole thing about 10000 cycles faster to be any good for the purpose I want to use it.
Since:
- music must be played: 1500 cycles
- main sprite displayed: 2000 cycles
- sfx playing: 1000 cycles
- each enemy: 1500 cycles
- some shots: 500 cycles
- score and level: 2000 cycles
I have not tried to optimized the tile printing yet, my estimate is, that that can be optimized for about 4000 cycles. The rest must be “magic” of some kind I do not know yet.
Thoughts of things that *might* be optimized:
- defining tiles that are larger than one “grid” space, this would save one posititioning, but makes clipping more complicated
- each grid position is reached with the same “large” scale factor. Theoretically the inner grid positions can be reached with lower scale factors. The thing is, for that to work I have to test for the grid position of each tile. And this again eats the saved cycles. Also the grid position is not a constant – due to “smooth” scrolling the grid has a “coarse” position and a “fine” position. To respect those is even more complicated (= cycle using).
What I discovered is, that different optimization technics seem to cancle each other out – which is a shame – as I had many other thoughts.
Here a bin file that uses the new engine. Analogue joystick is still supported for fast and slow scrolling the level. Smooth scrolling and clipping is enabled. The playfield as of now is with 10×10 tiles rather small. But displaying it a little bigger (with still 10×10 tiles) is not really a problem – that takes only a couple of 100 cycles. The scale and size of vectors is also non optimized yet, this is finetuning when I have reached a point that I deem the engine “usable”. This “small” version is the one I have handy right now.