Vectrex development (retro/old school)

[Chris]

Long time listener, first time caller.

So I'm currently well into a shmup for the Vectrex.

The Vectrex is an 8-bit console released in 1982. It is similar looking to the old Apple Macintosh computers. The built in monitor is a monochrome vector display - Think Asteroids, Gravitar or Battlezone. CPU is an MC6809 running at 1.5 MHZ. 64K ROM, <1K RAM.

Wikipedia:
http://en.wikipedia.org/wiki/Vectrex

Screenshot of game WIP:

http://i62.tinypic.com/mmq1jl.png

Youtube video of game WIP:
https://www.youtube.com/watch?v=rJxmtv8VF3E

If you don't have a Vectrex, several emulators are available including MESS, ParaJVE and VecX.

Due to the nature of the hardware (both the video hardware and the CPU) there are considerable limitations vs more modern consoles or PCs.

Namely:

Vector systems generally do not have video RAM and particularly anything resembling modern graphics cards. Rather, everything must be drawn to the screen in real time. This does have some benefits (no need to worry about un-blitting objects from the screen. They disappear in ~1/40th of a second if you don't redraw them). But this is far outweighed by having to spend a huge amount of your CUP time (as much as 80-90%) just drawing the screen.

This does not leave much time for in-game calculations. Collision detection on mass numbers of objects is potentially crippling (not to mention having to draw them all).

RAM is a bit undersized.

The display is black and white (various levels of brightness are possible). Colour can be provided using overlays (like Space Invaders or Battlezone) but that is obviously very restricted. This makes me very hesitant to do anything resembling pick-ups as it's just not possible to make "things that you want to hit" a contrasting colour with "things that will kill you".

The number of objects onscreen has rather hard limits. Frame rate is entirely under developer control. Standard is 50fps, I'm generally running 40fps as that's about as low as you can go before experiencing visible flicker. This gives you 37,500 cycles per frame to work with. Each object drawn to the screen is about 200-300 cycles for the drawing. However, you have various other overhead (joystick polling, sound, and of course game calcs). You can pretty much expect to run out of cycles. Always. Plus given the RAM restrictions (about 850 bytes) you can quickly get yourself into trouble there.

All that being said, the Vectrex is a really sweet machine to code for. The 6809 has IMO a really nice instruction set. The system is pretty unique for consoles. And it has a really dedicated fan base.

Currently my game engine is capable of about 50 objects onscreen (16 enemy shots, 30 ships, 4 player shots) though that depends on the specifics of the objects (highly detailed sprites take longer to draw than simple ones so a balance must be maintained or the number of sprites on display must be reduced).

There doesn't seem to be an attachment option here, though could be because I'm n00b. If anyone cares I'll find a host and post in .BIN.

[Chris]

Here are a couple video reviews of my previous Vectrex games. They're probably better background than the infodump above.

These were written and released back around 2000 to 2002. I'd been out of the Vectrex since then. I got into Atari 2600 programming for a while but hadn't done anything retrogaming in about a decade when someone messaged me on Facebook to ask me if I was "that guy" and pointed me towards the first of these videos. Which started getting me back into it - What had been retro 15 years ago was now itself retro with a whole bunch of people now into the console who weren't around back then.

https://www.youtube.com/watch?v=csAffWs5GKw

https://www.youtube.com/watch?v=S-VA4-0ux00

[spadgy]

Long time listener, first time caller.

How I wish we were running a radio show; then I'd be living a dream! Anyway... I'm fascinated by this one.

So you're using your own engine and codebase for this?

[Chris]

So you're using your own engine and codebase for this?

Yes - MC6809 assembly using a cross-assembler. There's a C compiler, but, IMO optimization is so important and so difficult to generalize in timing sensitive systems (Atari 2600 is similar due to lack of video RAM - You're pushing bytes at the raster in real time as it draws the screen) that's it's a non-starter for me.

The online Vectrex development community has been around since the mid-90's. There's considerable documentation available. The community is smaller than the Atari 2600 but Vectrex is arguably a "prestige" machine due to rarity/cost/uniqueness. The Vectrex is just such an amazing/bizarre little machine...

I have several other WIPs at the moment because, who doesn't?

Specter
Maze Shooter.
Core development is mostly done (still plan to have enemies shoot at you). Needs a bunch of level design which will require a 64K bankswitched ROM. I'm currently not setup for convenient hardware testing of 64K ROMS. (Should be by the end of the week).





Incursion
Scrolling tank shooter with destructible playfield.
Early development - No enemies yet. Just tank and scrolling destructible playfield.





Panic Attack!
Arena shooter.





There's a pretty active Vectrex proboards community, but I came here for a different take - Specialists vs generalists, really.

I'm most of the way through my core engine which is mostly dealing with technical issues and basic game book-keeping. As far as level design, scoring system and possibly other basic game mechanics I'm still in very early design stages.

As mentioned in the OP, the Vectrex (and indeed older hardware in general) have a number of restrictions. For example, the above mentioned monochrome screen probably means I'm not going to do anything resembling a Collect-‘em-Up - Too easy to be confused visually, especially while a lot is going on.

I can't really do huge auto-fire bullet streams from the player for two reasons:

- The time it takes to draw (it's a zero sum game a big player stream means less enemies and/or enemy shots which isn't much of a trade-off IMO)
- Collision detection. I'm using pretty simple/fast collision detection, essentially: if (((abs(y2-y1)<(height2+height1)) and (((abs(x2-x1)<(width2+width1))). However, I get to cheat a little in that everything's hit box is identical. Sprites are all very close to the same size. For technical reasons any larger enemies will be multi-sprite with each part of the whole doing its own collision detection (ok, having written that down that doesn't sound very efficient and needs a rethink). The actual calcs are so straightforward that I don't think I would benefit from doing any pruning or partitioning (the time spent doing either would, I think, be about the same as the actual collision detection) but as I'm sure everyone here is well aware that adds up quickly..

So at the moment, I have 4 player bullets and no autofire (I'll almost certainly add auto-fire).

There's a bit of a "medium is the message" here where it behooves me to work with the hardware limitations as much as possible and not fight them (too much) and particularly not over-design or over-complicate. It essentially needs to be low-fi design.

Scoring is pretty back of the envelope right now:

enemy value = distance*current_chain*base_value (closer is better)
end level bonus score = hits*hit%*longest_chain*died

Max chain = (?)
When chain is at max, player's ship blinks
Super-bullets available when at Max chain
Activating super bullets:
- Bullets are invulnerable; May make multiple hits.
- Chain bonus at double max
- Super bullets last for X seconds. After which chain = 0
(Need to balance between value of super bullets vs cost of losing chain)

Chain calculations:
If bullet hits enemy, chain=chain+1
chain=chain-1 per X frames

[opt2not]

Awesome! I'm happy there are still homebrewers for the Vectrex! I'll be watching this thread.

I've been playing Moon Lander by Clay Cowgill a lot lately, and so far it's my favourite homebrew aside from Protector. But I'd be really interested in seeing a vertical shmup of some kind done for it! Scramble just doesn't cut it for me.

[tiaoferreira]

As I said, on other topic, you are a hero, man!

[PC Engine Fan X!]

There's a tate Vectrex homebrew shmup by the name of Debris/Debris Revisited that was done by Revival Studios (that uses bit-mapped sprites for it's overall visual presentation as opposed to using vectors) + a bonus mini game as well.

PC Engine Fan X! ^_~

[suny]

Awesome ! Congrats, I'm really impressed.

Owning a vectrex was a child dream (still not fulfilled by the way...).
I love the fact that people are still making game on this sweet console.

And, as someone who has been active in the old amiga demoscene, I know that making something great on a fixed and limited hardware is the best thing in the world

S,

[PC Engine Fan X!]

Here's a link to that cool sd.bin d/l that Chris worked on back in 2014 -- it's a 64kb binary and works just fine on a VecMulti flash cart setup:

http://www.ctumber.com/234312344927515.html

(Simply point your cursor on the Vectrex subject heading, select "in Progress" and select the very last Vectrex game one on the bottom from within the webpage itself)

This little nifty Vectrex game binary really does show off what the Vectrex can do with a bullet hell or danmaku STG demo (a single stage complete with an end-stage boss to fight against) in the hands of a talented programmer. I'm sure with some added refinements such as scoring and a high score list would be feasible. I think if this sd.bin could approach the 50fps barrier, that'd certainly a plus/milestone.

PC Engine Fan X! ^_~