What are you programming now?

[jfmateos]

I am just programming VECPONGTREX: a PONG game to teach myself the inners of VECTREX.

[kokovec]

I've been noodling around with some possibilities for a new adapter.
So far it has an SD CARD for loading ROMS and a 1-bit audio decoder (for playing short audio samples).
I've started to work on the following:

• Adding VecVoice with a SpeakJet
• Encryption for ROM binaries files. This would allow developers to distribute downloadable ROMS that are only playable on the adapter (for beta and GA)

I'm thinking of making it modular so that you can purchase most of the parts yourself and only for those features that you want. That would also allow for future expansion modules.

[jfmateos]

Hi kokovec, I have also thought a method that would allow a programmer to distribute a rom in a way that could only be played when stored in a specific adapter.

The main issue is that whatever encryption we use, the Vectrex must have access to the un-encrypted data and, consequently, a EEPROM reader would also be able to access that un-encrypted data... so the question is how to differentiate a genuine Vectrex from a EEPROM reader

[kokovec]

The way it would work is through symmetrical keys.
The developer would run the ROM file through an application that encrypts it using one of his private keys.
The encrypted ROM is then sent to the client.
The client loads the encrypted ROM file onto an SDCard.
The adapter can then decrypt the ROM file and dump it to the onboard SRAM which only holds the un-encrypted data while powered on by the Vectrex.
Of course someone could attempt to access the SRAM data in some nefarious manner or if they replaced the SRAM with some type of non-volatile ram chip.
However the ROM file remains secure as long as the private key is never revealed.
Also, we could use some type of fingerprinting technology to find the source file if someone were to leak an un-encrypted version.
In any case it would be allot safer than burning onto an EEPROM and the user can keep the encrypted ROM file.

[xefned]

I like your thinking but I'm getting the idea that Vectrexers like dedicated cartridges for their homebrew purchases.

Is it not sufficient to enable the copy-protection bit when burning an EEPROM? I've never seen the copy protection cracked except by very skilled surgeons.

[kokovec]

I was thinking about that and was thinking of having a cart version of the decryption adapter.
The encrypted ROM file could be loaded onto a PROM.

The SD card version is nice because beta versions can be released to testers without fear of it going viral.

[vectrexrc]

Here is the Beamrider game I am working on...

m.youtube.com/watch?v=5ydGw_y514A

Hopefully to be completed sometime towards end of the year and will be available on cart.

[jfmateos]

Hi vectrexrc, It looks promising...
Would you like to contribute to this thread (http://vectorgaming.proboards.com/thread/826/vectrex-programming-learning-resources) explaining how you program

[cNp]

Hi, good to see a few different people starting out developing.

I started properly on Sunday (mostly setting up the dev environment (yes Windows 7 bootcamp partition with 134 software updates I'm looking at you!)) and hacked Manu's sample code to have my own 'sprite' and work a little differently.

Last night I wrote more or less from scratch putting a different character on the screen and making it move in relation to different button presses... compiled and ran first time!

So I'm starting on two projects, one will be public as it progresses and the other I will keep under wraps until it's mature enough (whatever that means).

The public project my 8yo son came up with the idea for but looking at Vectorzoa's page I think it's the sort of thing he had in mind for one of his future games. The player is a Scuba Diver who has to catch or photograph different underwater animals whilst staying out of the way of sharks.

I have a diver that can be moved with the controller and a fish that moves in relation to him (not in an intelligent way... yet).

Next up is:

Collision detection between diver and fish
Make the diver face left when moving left; right when moving right
Make the fish try to escape from the player
Add a shark
Make shark stalk the player
Handle life loss when shark gets you
Animate the diver (at least)
Add scenery
...
Then score, lives, levels, etc.

I have a programming background that goes back to C64 BASIC days so the structure and logic is all fine... only did a tiny bit of assembler at University but it makes sense. Looking at the steps the Bloxorz dev mentions about getting C compiling makes it seem like something I would never get up and running without giving the whole thing up! But C would probably be easier for certain bits as I did more C in the past. For now the plan is pure assembler.

I absolutely intend to make a full cart/box/overlay release of my game when the time comes but that could be a loooooooong time in the future! Hopefully with an active community of 'beginner' programmers we can avoid getting stuck on problems that grind us to a halt!

cNp