|
Post by gauze on Apr 26, 2018 21:33:26 GMT -5
glip check malban's blog he has a post about it w/ pics
|
|
|
Post by D-Type on Apr 27, 2018 7:55:32 GMT -5
Thanks for the link. I read it through years ago, but a reminder is good and more on-topic for me as I now have a Vectrex and especially as there is real code provided to look at. The matrix bit is interesting to me as that gets discussed sometimes on the comp.lang.forth newsgroups I read and my interest at the moment is getting Forth running on the 6809/Vectrex. The 3D aspect of programming is a little way down the road for me at the moment, but a fun topic for one day!
|
|
|
Post by gauze on Apr 27, 2018 10:26:08 GMT -5
|
|
|
Post by gliptitude on Apr 28, 2018 19:46:53 GMT -5
Thanks gauze. Indeed I am jealous.
|
|
|
Post by mikiex on May 8, 2018 7:10:29 GMT -5
Going back to what Malban was saying. If I was making this I would split it into a few methods.
#1 have every rotation of the enemies required stored, observing the arcade you do not need every direction.
#2 Store paths for the enemy, each xyz point on the path also points to a rotation in a table.
#3 Interpolate enemy along path xyz, also interpolate rotation table.
#4 Project the enemy in perspective.
|
|
|
Post by gtoal on May 11, 2018 22:59:38 GMT -5
Going back to what Malban was saying. If I was making this I would split it into a few methods. #1 have every rotation of the enemies required stored, observing the arcade you do not need every direction. #2 Store paths for the enemy, each xyz point on the path also points to a rotation in a table. #3 Interpolate enemy along path xyz, also interpolate rotation table. #4 Project the enemy in perspective. You all may have noticed a stall in development since I brought this subject up last year - although a part of that was down to illness and for the next month due to vacation, the main reason for lack of progress has been my vacillation between several diametrically opposed methods of implementation. Here's a summary: 1) a complete reimplementation from scratch in the traditional arcade game programming style - the bottleneck for this is rendering 3 ships at once at arbitrary orientations, at a sufficiently fast rendering speed. Looking at the cinematronics hardware in comparison, this *ought* to be possible on a 6809 but I fear is beyond my ability. People have posted saying they think it's possible and I'ld like to see what they can do. Also I'ld love to see if Fury, who has been working on this longer than I have, has managed to handle three simultaneous ships. 2) When I found out about the existence of cartridges with lots of space for data (eg Vecfever) I then shifted focus to a version that used the space to draw ships from vectors which had been recorded from playing the real game in a modified emulator. I got as far as a version that ran in a 48K eprom (rather than the previously assumed max size of 32k) which showed that I could handle one ship smoothly within the frame rate. Since then I spent some time recording more flight paths but have not yet converted them into a form that I can use in code, which now requires bank switching in a VecFever. 3) Seeing that the previous option was starting to gobble up huge amounts of space even on the large Vecfever, I sidetracked a little at this point to explore a variant of precomputed flight paths: precomputed renderings at a varied set of fixed angles, and at a fixed software scale, to be rendered using hardware scaling. This is my current best guess for a workable solution using the 6809. (This is basically what mikiex is suggesting above, but with the projection being precomputed rather than just the rotations) 4) at this point Thomas added a serial connection to his own Vecfever and experimented with using the vecfever as a vector generator for an attached PC or Mac. This was a success and could be what we finally go with, but I would like a solution to be entirely within a cartridge. One way would be to add a second CPU to the vecfever rather than a cable to a PC, but that's a major undertaking and I can't see Thomas taking that on... 5) BUT there is an alternative: the tailgunner code could run on the vecfever's CPU itself. Although the vecfever CPU may not have the speed (or RAM) for a pure emulation, it definitely has the capacity to run my static binary translation of Tailgunner which I created some years ago - in fact I released a version for the GP32 once, which is a 133MHz ARM. So I *know* it can run the code fast enough, all it has to do is present the vectors to the vectrex via its eprom emulation mechanism 6) or... instead of emulating an eprom, a modified vecfever - or an entirely new cartridge - could use a trick to disable the vectrex's internal 6809 and the processor in the cartridge could drive the 6809 as a peripheral. This is actually one of the things that Clay Cowgill's test cartridge already does, so it is also a contender for this avenue. Thomas says he can do this with the VecFever but doesn't think it's needed since the existing mechanism works quickly enough. A solution that relies on a modified Vecfever or a modified Cowgill test cart obviously relies on cooperation with other people that I'm not in a position to ask for or expect, though I do hope that at some point either of them will find it an interesting enough project to take on - in the meantime I'm going to fall back to plan (3) above, but some time after I get back from vacation in about a month or so, I'm also hoping to have a go at building an ARM-based cartridge myself - I think it can be done with existing parts on a breadboard, but clearly it's still a major project for someone like myself so I'll probably take it on in parallel with the fall back plan. But it is 100% clear to me at this point that a cartridge-based implementation of tailgunner that emulates the original is technically possible, and I am determined to see that it happens - whether I do it myself or this effort prods someone else into doing it, I don't care - I just want to see it done. G
|
|
|
Post by D-Type on May 12, 2018 1:03:54 GMT -5
Sounds to me that you don't have your goal clear in your mind.
It's either to have an almost arcade perfect version of TG running on the Vectrex in a standalone cart, or an as close as you can get it version running in not too difficult to distribute form, perhaps as a VecFever v4e or standard Vectrex memory space cart, perhaps with bank switching.
It all depends on what your interest is. For me, I like the latter goal, because anything else is just using the Vectrex as a vector monitor. The challenge for me is really the existing 6809 hardware and it's limitations, seeing really what you can make it do. Plus, this option also allows you to share your results with the most people.
JMHO :-)
Either way, it's an interesting thread to follow, keep it up!
|
|
|
Post by mikiex on May 13, 2018 5:57:44 GMT -5
Gtoal has a goal that is clear, Tailgunner on the Vectrex no matter what. How he gets there is whats not clear
|
|
|
Post by gauze on May 13, 2018 14:05:11 GMT -5
design is often the toughest part, 'cause you need a design that works and also beats the clock, so to speak, to fit in one frame. No rush K Tuts takes years to do his games no reason why you and me can't do the same thing.
|
|
|
Post by kokovec on May 19, 2018 14:39:00 GMT -5
Going back to what Malban was saying. If I was making this I would split it into a few methods. 4) at this point Thomas added a serial connection to his own Vecfever and experimented with using the vecfever as a vector generator for an attached PC or Mac. This was a success and could be what we finally go with, but I would like a solution to be entirely within a cartridge. One way would be to add a second CPU to the vecfever rather than a cable to a PC, but that's a major undertaking and I can't see Thomas taking that on... G A few years back (or perhaps a few more than that) I built a prototype 3D accelerator for the Vectrex. It worked passively: - You loaded all of your 3D vector lists into certain expanded areas of memory - You loaded pointers to the lists in another area of expanded memory (an index) - Then you loaded a transform command into an area of expanded memory associated with the list A transformed list would then be placed into an area of expanded memory and set a flag when it was done. This allowed the main program to do other tasks while the transforms were being computed. The main program didn't have to wait for the transform to complete as the expanded area of memory could be switched over to the microcontroller. You had the choice of transforms using 3(standard) or 4(quaternion) dimensional matrices. It was fast and smooth (much like its creator). At the time it would have cost too much to manufacture as the microchip itself cost $25 and was on a 100 pin TQFP which is a nightmare to solder by hand.
|
|
|
Post by gtoal on Jun 20, 2018 23:29:29 GMT -5
Hey guys - I have some major progress to report! Remember reading about the Vecfever being used as an output device for Mame (running on a Mac system)? It was implemented using a USB to TTL adapter that Thomas attached to his cartridge. Well, I've been working on a variation of that technique; instead of using a Mac or other PC as the host, I'm using a Raspberry Pi, and instead of connecting via USB adapters, I've wired the GPIO pins on the Pi directly to the GPIO pins on the Vecfever. It was a remarkably easy modification - just three pin headers to the underside of the Vecfever PCB and matching neat holes in the underside of the cartridge shell to push the jumper wires through. I.e. easily reversible by just pulling the jumper wires off again. Currently the Pi is powered by a USB power supply, but it should be fairly easy to power it from 5V stolen from the Vecfever, coming ultimately from the Vectrex's edge connector. Currently I'm using a full-sized Pi 3 but when I power it from the cartridge I'll switch to a Pi Zero W - at which point this thing is basically just an extended cartridge -- the Pi Zero is tiny - less than the width of the cartridge and may be able to actually fit inside the Vecfever, though probably requiring a slightly redesigned shell to hold it. On the software side - for this project I'm not running Mame, but just a custom emulation of just Tailgunner itself - it's not actually an emulation as such, more accurately it is a static binary translation of the Cinematronics code back into C. Thomas's Vecterm implementation allows me to read back the Vectrex joystick and buttons. It works! I've been playing it for hours :-) There's still work to be done to make it slick - such as tweaking some of the screen layout to better fit the Vectrex's screen aspect ratio - but basically it works. The digital joystick is a little rough but I'm not sure if that's the fault of using digital joysticks with Tailgunner or (more likely) the fault of my rather dilapidated Vectrex controller. I'm fairly confident that Mame could be ported to this configuration too, but I'll probably leave that for someone else to tackle later - I have my hands full with Tailgunner for now. So there we have it. We have the makings of a stand-alone Tailgunner cartridge for the Vectrex! Graham
|
|
|
Post by gtoal on Jun 20, 2018 23:33:24 GMT -5
PS Note that since the Pi Zero W has built-in Wireless (and Bluetooth), this will also mean that those of you who wanted a networked Vectrex should finally be able to have one!
|
|
|
Post by hurraybanana on Jun 21, 2018 3:02:42 GMT -5
great effort
|
|
|
Post by D-Type on Jun 21, 2018 3:24:27 GMT -5
Very cool...but I was hoping for a 6809 port. You know, do more with less and all that :-)
Looking at the game, I reckon the Vectrex 6809 with ample ROM potential for pre-compiled animations could support a great version.
Not that I've ever developed anything that advanced/performant with 6809 assembler or C, you understand. Not yet, anyway :-)
|
|
|
Post by gtoal on Jun 23, 2018 15:09:37 GMT -5
A follow up on progress: Tailgunner+Vecfever works quite nicely with both a Pi3 and Pi0W - but it looks like it won't be possible to power either of the Pi's from the Vectrex's 5V bus - which kills the idea of fitting the Pi0W inside the vecfever cartridge. However the project continues, with the Pi outside the case and externally powered. Although not as aesthetically appealing as being built in to a single cartridge, I'm sure a neat solution can still be engineered with the Pi and the wires tucked neatly out of sight. btw video of tailgunner on the Vectrex: www.facebook.com/gtoal/videos/10217076818092326/
|
|