|
Post by cNp on Nov 14, 2017 17:27:38 GMT -5
Just ran the latest demo on real hardware, very nice how the ship flies in... good work!
|
|
|
Post by gtoal on Nov 15, 2017 0:36:17 GMT -5
I've deleted a lot of the cruft from www.gtoal.com/vectrex/tailgunner/main.c.html so it should be a little easier to follow now. (It's not "release-tidy" but it is "hacker-tidy") It now requires Malban's latest Vide beta to run under emulation as the rom image exceeds 32K. I plan to spend the next couple of weeks finishing off all the incidental stuff that makes it a proper game, while leaving the really tough part (multiple ships) until last. So next improvements will be: missile hit detection, exploding ships, ships bouncing off shields, making all the counters work (score, shield values etc), better missile trajectories, and maybe sound. And drift reduction. Hmmm, now I spell out all the pending jobs, it'll probably keep me busy for more like a month! G
|
|
|
Post by Malban on Nov 15, 2017 3:49:12 GMT -5
Hi Graham,
I know you put your heart and soul into bringing your vision of Tailgunner to the vectrex. Which I admire a lot.
Nonetheless I would like to tentativly suggest to overthink the current approach.
"Recording" the output of the actual original and playing them back on a vectrex certainly guarantees original "feeling" and recognition.
Personally I think the current approach "feels" a bit like "Dragons Lair". Recording pre rendered scenes and playing them back with a little input of the user.
My own approach when writing Vectrex stuff always has been "it should run on a base vectrex".
Yes, the term "base" can be stretched. - bankswitching is a modification none of the original cartridges had (although I never used bankswitching)
Also there are "cool" inventions which I like and support, like a SID chip on a cartridge or the Vectrex32. For me these are cool technological toys - I even thought a while about Vectrex32 and the StarTrek challenge (which perhaps I still pick up at one point - but I have to ask Bob to support VecVox :-) ).
But doing a rather "simple" game and possibly using several 100Kb to bring pre recorded vectorlists to the screen is for my personal taste "to much". At the moment it sounds like you either NEED a VecFever to run it - or use a special as yet to be manifactured cartridge.
While I fancy technology advances - also concering vectrex, this does not feel like an advancement, it more feels - sorry to be blunt - "helpless". You have put so much energy in duplicating the visuals and before in trying to translate the original ROM routines to be runnable (in speed) on a vectrex - that my personal observation is, that you perhaps lost sight of the Vectrex - and coding OWN routines - which I am very sure you are well capable of.
If you plan an own cartridge or VecFever only - than REALLY take advantage of that. Put in an ARM chip and do lots of 3d routines which rotate and have hidden line removal or whatever - something that really only can be done with supportive hardware (but than you are at Vectrex32).
The only other (to me) known "rom" that uses the kind of RAM you are talking about is the (really cool) movie recording done by SpritesMod - something to think about.
Malban
|
|
|
Post by gliptitude on Nov 15, 2017 13:22:59 GMT -5
On the other hand there are many ways to justify a project. In this case we are talking about a copy of a game that already exists, and even is about to also exist as another programmer's complete release for the same Vectrex platform, (Tailgunner Zero Hour), not to mention the standing offer for a Vectrex32 port.
Is graphics "recording" an original concept in this application? Could this technique be demonstrated more readily and completely with a different project specifically scaled to Vectrex? Could you take a break from Tailgunner to do a different graphics demo, start to finish and <32K?
I regret that I can't test these recent versions on my Vectrex. But I do think that a nuclear cartridge Tailgunner release would be excellent, no matter how obscure or unreasonable the apparatus, or limited distribution - IF IT COMES TO COMPLETION.
|
|
|
Post by gtoal on Nov 15, 2017 22:06:51 GMT -5
I am determined to complete this project one way or another. At the moment, using the VecFever seems the most direct route to getting something running that is as fun to play as the original. With Thomas's recent software tweaks, I'll just be using it initially as a simple ROM cartridge with 48 - 50K of rom, something that ought to be easy to replicate with a standard cartridge, a 27512, one logic chip, and a few bent pins. I'll use that to finish the gameplay and look&feel using only 1 or 2 recorded videos. This version will also work in Malban's recently updated emulator.
Then (probably with Thomas's help to understand the VecFever options) I'll take advantage of the VecFever's advanced features and add more ship videos - I hope I can do that using 32K of resident ROM and multiple 16K banks of switched ROM. Depending on his firmware maybe that 32K/16K split line might move up a bit to say 38K/10K if I need more code and less video.
Assuming this all works, then people with VecFever cartridges will be able to play it.
If the feedback from the VecFever users is positive and encouraging, then we move on to some serious hard work to render the ships in code rather than as recordings. This may be possible but it might need more skilled coders than me to work on it. It would be nice to hear if Fury Unlimited's in-progress game has succeeded yet in rendering ships fast enough. George has had a couple of years to work on it, so should have a good handle on the technical issues. I rather sat on this project for a few years thinking Fury's version was due Real Soon Now but I finally decided to bite the bullet and do it myself.
My gut feeling is that drawing the ships on the fly may be possible, but adding the computation of the flightpaths and ship orientations at the same time may be pushing it too far - however the data for storing and/or interpolating position and orientations for the ships is a whole lot less than for storing vector video, so I think there is a chance of doing a hybrid in a standard bank-switched ROM which computes the 3D projection but stores precomputed flightpath info.
(I know Fury put a marker down for Tailgunner some years ago and I don't want to step on his toes, and likewise with whoever holds any residual rights to the original, so my version will eventually be called "Rear Gunner" rather than Tail Gunner, and as I've said before, it will be open source and not for sale. If cartridges are needed to run it, that's between the user and the cartridge vendor who can give the game away free when selling empty carts - I'm not going to be involved.)
Somewhere around "Plan D" is a cop-out version that doesn't emulate the original so closely - does more flying in the distance in 2D before turning towards the player for one final attack with very few different angles of view of the ship and a lot more use of scaling to fill in the gaps. Different gameplay, but reminiscent. This version would probably fit in a standard 32K cartridge.
No offence taken at Malban's comments - I understand the purism of staying true to the original - but that ship has sailed. We're already committed to using modern technology even if it is just a 48K cartridge - so a 4MB cartridge is just different in degree, not philosophy :-) And the game isn't over yet. VecFever is an expedient solution right now; in the long term, maybe it ca be done the way he suggests. We'll never know unless we keep plugging away at it incrementally and see what clever ideas come up along the way.
gliptitude: tempting as it is to take on a smaller side project, I am trying to resist repeating the mistakes of my youth and letting myself get sidetracked. But it's a good idea - bell that cat!
G
|
|
|
Post by Malban on Nov 16, 2017 3:05:53 GMT -5
Ok than :-)!
Wish you success with your enterprises. The offer for help still stands. If I can make your life easier with small changes in Vide - say so.
I never implemented any VecFever bankswitching - perhaps I'll interview Thomas at some time how he triggers the "upper" banks.
Malban
|
|
|
Post by gtoal on Nov 16, 2017 14:53:58 GMT -5
I never implemented any VecFever bankswitching - perhaps I'll interview Thomas at some time how he triggers the "upper" banks. Yes, please do - that would definitely encourage people to develop in C for the VecFever - admittedly they do have hardware to test on, but the compile/edit/run loop is likely to be significantly shorter with an emulator. G
|
|
|
Post by Malban on Nov 16, 2017 15:27:52 GMT -5
Vide and VecFever are a very good coupling, there is virtually no delay between a compile and seeing the result on a vectrex. Since Vide feeds the Ramdisk of the thing automatically and starts the developed program on the real machine (via VecFever) right after the compile. (if configured)
This works for all "normal" programs. For bankswitch 64k and for the new 48k. If - or when - Thomas decides to add some other scheme - I am sure we can work something out. Malban
|
|
|
Post by gtoal on Nov 18, 2017 12:14:09 GMT -5
My EPROM burner just arrived today. Learned a bunch of stuff about it *after* having made a bid for it on eBay - turns out there was a good hardware engineer by the name of Willem who designed an open-source burner some time before 2010 or so, but the guy died and the Chinese companies who had copied the design and were selling it were not competent enough to upgrade the design over the years. I got one advertised as "designed in the USA" which finally added USB to the design last year, but it is clearly not _made_ in the USA - there are visible dry joints and it's all obviously hand-soldered, by someone with even less soldering experience than myself. When I used to make ram/rom boards for the bbc micro I would always trim the excess socket leg length off the underside of the board but there's none of that on these - very spiky...
still, it'll be nice to be able to burn roms again, and I'm looking forward to making the proof of concept 48K cartridge this weekend.
|
|
|
Post by VectorX on Nov 18, 2017 12:51:53 GMT -5
Good luck. Shame the burner is a bit sub-par than what you were lead to believe though.
|
|
|
Post by gtoal on Nov 18, 2017 13:55:33 GMT -5
Good luck. Shame the burner is a bit sub-par than what you were lead to believe though. I know. But on the other hand, $50? !!! These things used to cost thousands :-) It's a wonderful time to be alive :-) I'm finally catching up on all the hobbies of my youth that I couldn't afford when they were new... (Ah, the joy of early retirement...)
|
|
|
Post by gtoal on Nov 20, 2017 3:27:43 GMT -5
(I haven't actually done the wiring yet as I can't find the ZIF I thought I had, so have ordered a new one on Ebay.) Here's the changes to the 27256 'clockwork robot' cartridge. Anyone willing to check it for me and make sure I got it correct? Edge Connector pin 16 (upper side) signal A15 originally connected to 27256 pin 20 (E' or Chip Select). Cut that track and redirect the signal from the edge connector to both 27256 pin 1 (A15) and the input of an AND gate. If 27512 pin 1 was connected to the PCB, sever it. (Vpp - shouldn't be used, might be tied to ground? I'll check with a meter...) Edge connector pin 33 (lower side) signal A14 was originally connected to 27256 pin 27. Take a flying lead and also route it to the other input of the AND gate. Route the output from the AND gate to 27512 pin 20 (E' or Chip Select) Connect power and ground to AND gate. ( If I can't find an AND gate, use a NAND gate, and feed its outputs into both inputs of another NAND gate to use as an inverter then just treat the combination the same as a single AND gate. ) The edge connector pin numbering is: with component side up and pins facing towards you, left hand pin is 36 and right-hand is 2. Flip it over and pins still towards you, left hand side is 1 and right hand side is 35. Rather than cut tracks on the board, what I'm looking at is: 1) solder a 28 pin ZIF to the board (all pins). This will let me use the cartridge as originally intended. 2) using 2 or 3 28 pin sockets, remove and/or bend legs out from the sockets to break circuits or solder flying leads to, so that the modifications are completely reversible. (This style of hack: www.arcade-cabinets.com/board_hacks/galaxian/images/stacked.jpg ) - a long time ago I used to make eprom emulators out of 62256 ram chips using this technique! Update: pins pulled, legs bent, flying leads attached: Socket pins all checked for shorts to neighbours and through continuity.
|
|
|
Post by gtoal on Apr 25, 2018 17:39:38 GMT -5
|
|
|
Post by gtoal on Apr 25, 2018 17:49:42 GMT -5
I regret that I can't test these recent versions on my Vectrex. But I do think that a nuclear cartridge Tailgunner release would be excellent, no matter how obscure or unreasonable the apparatus, or limited distribution - IF IT COMES TO COMPLETION. Have you been following the stuff that Thomas Sontowski has been doing with the Vecfever cartridge. It's looking very possible that a variant of his cartridge will be able to run the full Tailgunner, via my automatic translation to C. He's already run Tailgunner successfully under Mame using the Vecfever as a vector generator and a PC as the processor. I don't know when or if a standalone version will happen but I am saying that I'm pretty sure that it is now possible with his super-powered cartridge tech. In the mean time I'm plodding away on other approaches, but that's the one I'm holding out for in the long term to get vector-perfect emulation. (The difference in screen layout is something that can be trivially fixed by tweaking some of the generated code.) G
|
|
|
Post by gliptitude on Apr 26, 2018 20:03:15 GMT -5
I haven't followed the Vecfever project closely. It seemed like there was a big frenzy and facebook crowd that I thought I'd wait for them to get their's and hope there was one left for me after everything calmed down.
The variant does sound cool. I guess if the Vecfever was the vector generator then the display was a Vectrex?
|
|