|
Post by gtoal on Sept 6, 2017 21:35:00 GMT -5
FYI, I'm offering a cash bounty for a Tail Gunner game on the Vectrex32. This was not prompted by your post about working on Tail Gunner, so it's not intended to step on your toes; I've been planning this for a while and I always expected to announce it after Labor Day in the US (the unofficial end of summer). You can see the details at vectrex32.com/the-v-prize. - Bob I was reading your spec just now and wanted to point out a couple of details of Tailgunner that you might want to add to the specification... > Three ships fly towards the player at a time, each twisting and turning in three dimensions to make them a difficult target. There's an initial phase where the ships fly in 2D as viewed from above, on the back plane. Then they adjust their direction and turn into the Z direction flying towards the viewer, while adjusting their attitude during the transition from one plane into the other, so that they are flying level after they've made the turn. > There’s a button on the controller to fire. When firing, two cannon shots appear from the lower corner of the screen and move towards the crosshair. A sound effect accompanies the firing. They are more like guided missiles than ballistic cannons - they adjust their trajectory towards the crosshair dynamically, rather than aiming towards the location where the crosshair was when the firing trigger was pulled. Graham
|
|
|
Post by gtoal on Sept 6, 2017 22:33:10 GMT -5
OK, I've done as much as I can do on this code for the moment and plan to take a few days off from it to clear my head. This is based on earlier code that has been through at least two translations into other programming languages, with the result that it's a bit piecemeal in places and not as well structured as perhaps it ought to be. The most recent version of this code before this conversion back into C was in a language called Scratch (from scratch.mit.edu) and that code worked reasonably well - certainly well enough to be a really good starting point for a more vector-perfect clone of the game. HOWEVER Scratch was an interpreted system using 96 bit floats for everything, and to run on the Vectrex I had to recode a *lot* of maths to be 16 bit - as well as moving from using geometry based on 360 angles in a circle to a scheme where we use 256 angles in a circle in order to use 8-bit data and a processor lacking a divide instruction! So somewhere in that conversion, the code has broken. I'll be quite frank and admit that my math skills are nowhere near as good as my programming skills, and that I'm finding it quite hard to get my head around the remaining problems which I strongly suspect are in the matrix manipulation area. It's probably quite a simple issue that is keeping the code from running properly, but I can't see it, and at this point I would really appreciate a fresh set of eyes on the problem. Something to watch out for is my conversions of sin, cos, asin and atan from Scratch into C. I added some diagnostics to the Scratch version of the game and made sure that things like the signs of these functions were correct for the quadrants where angles can exist, but there's a possibility that this is only true for the quadrants that were ever exercised by the running code - for example spaceships never flew backwards or upsides down so it is not impossible that if they did, the results of those functions *might* have the wrong sign. I don't know. Could be the problem is elsewhere entirely, I'm just pointing out issues I know about that could be relevant. If anyone would like to help out with this game, the help will be gratefully received and of course fully credited. This source file compiles under linux using gcc and requires Open GL to run. I strongly suspect it will also run easily under Windows, and all the machine-dependent parts are in one place so converting to X, SDL, or Allegro for example ought to be trivial. The use of a Vectrex and the 6809 processor is not required at this point in order to debug the game play, and indeed I have no idea whether this code will run on the 6809 at this stage of development. The Scratch code, for comparison, can be viewed at scratch.mit.edu/projects/33089150/#editorand the game played either there or at this alternative system: sulfurous.aau.at/versions/v0.86/html/app.html?id=33089150&turbo=false&full-screen=true&aspect-x=4&aspect-y=3&resolution-x=&resolution-y= Please post any progress in the thread at: vectorgaming.proboards.com/thread/2003/working-on-tailgunner-again (or mail gtoal@gtoal.com) I realise that most of the people here probably specialise in 6809 coding specifically, rather than game algorithms, so if you have any friends who are good with matrices and 3D motion, who might be willing to help, please do point them at the code: gtoal.com/vectrex/tailgunner/tgvectrex.c (or gtoal.com/vectrex/tailgunner/tgvectrex.c.html ) This code is 95% of the way towards a good Tailgunner clone. I'm not too proud to ask for help for the remaining 5%. sincerely, Graham
|
|
|
Post by Malban on Sept 7, 2017 2:02:19 GMT -5
Comparing the current C to "scratch" is realy weird. Scratch is not something that is realy easy to compare to - at least for someone who has never seen it befor.
Do you have some c, java or otherwise "readable" form of code you know that works that one can compare it to?
Or is there some easy way to get an actual sourcecode from scratch that a non kid human can read .-)? The closest thing to a source I could see was when I downloaded the scratch package, unziped it and found some json file inside.
|
|
|
Post by gtoal on Sept 7, 2017 4:46:58 GMT -5
Comparing the current C to "scratch" is realy weird. Scratch is not something that is realy easy to compare to - at least for someone who has never seen it befor. Do you have some c, java or otherwise "readable" form of code you know that works that one can compare it to? Or is there some easy way to get an actual sourcecode from scratch that a non kid human can read .-)? The closest thing to a source I could see was when I downloaded the scratch package, unziped it and found some json file inside. clicking the 'see inside' button and looking at the scratch blocks is the usual way, but if you have saved the ".sb2" file (where you found the json representation) then you might try running Tosh at tosh.tjvr.org/app/ and load the saved sb2 file in to there (using 'open' menu option) - you'll get a more traditional representation that can be edited and run. Not very well documented however, it's a new and somewhat experimental system... Graham
|
|
|
Post by kokovec on Sept 8, 2017 1:52:37 GMT -5
I realise that most of the people here probably specialise in 6809 coding specifically, rather than game algorithms, so if you have any friends who are good with matrices and 3D motion, who might be willing to help, please do point them at the code: A long time ago I built out a Vectrex 3D engine that used quaternions that were developed in C. I'm way too rusty to be useful at this point but I used quats to avoid gimbal lock. Oddly enough the first example I published showed multiple rotating Tailgunner enemy ships on screen. Using the Vectrex 32 should make quick work of a proper Tailgunner game. Otherwise you'll be stuck having to contend with so many lookup tables to handle the transforms.
|
|
|
Post by gtoal on Sept 8, 2017 14:44:08 GMT -5
|
|
|
Post by gtoal on Sept 8, 2017 15:30:25 GMT -5
|
|
|
Post by gtoal on Sept 9, 2017 10:28:16 GMT -5
FYI, I'm offering a cash bounty for a Tail Gunner game on the Vectrex32. This was not prompted by your post about working on Tail Gunner, so it's not intended to step on your toes; I've been planning this for a while and I always expected to announce it after Labor Day in the US (the unofficial end of summer). You can see the details at vectrex32.com/the-v-prize. - Bob Hey Bob - it just occurred to me that you don't have the size limitations on code for Vectrex32 that we have on the native Vectrex, so this implementation of Tailgunner could probably be made to work with a couple of days effort: gtoal.com/athome/tailgunner/gp32/It's a translation of the Cinematronics ROM into C. Typical code generated is below and should be easy to convert into Basic. (Hopefully your Basic has something equivalent to a switch statement implemented using a jump table) All you have to do is replace the interface code that draws the vectors. It's not hard - Norbert Kehrer did it once for Java. If the GP32 implementation isn't a good starting point for you, I can find others - maybe gtoal.com/athome/tailgunner/tailgunr-ops.c.html which uses actual labels rather than switch jumps, mostly. Really the only part you would want to keep is the actual translated code, which all looks like this excerpt below... switch (register_PC) { case 0x0000: /* Invariants: register_P = 0x0 register_I = 0x00 register_A = 0x00 */; /* opNOP_A_B (57) */ /* opLDAimm_B_AA (00) */ flag_C = acc_a0 = register_A; cmp_old = register_B; /* step back cmp flag */ register_B = cmp_new = 0; /* opLDAimm_A_AA (0f) */ cmp_old = flag_C = acc_a0 = register_A; register_A = cmp_new = 0x0f00; /* opADDimmX_A_AA (20) */ cmp_old = register_A; cmp_new = 0x01; register_A = flag_C = acc_a0 = 0x0f01; /* opLDJimm_A_A (48) */ register_J = 0x0008; /* opLDPimm_A_A (80) */ case 0x0008: /* Invariants: register_P = 0x0 */; /* opSTAdir_A_A (d0) */ ram[register_I = 0x00] = register_A; /* store acc to RAM */ /* opLDIdir_A_A (c0) */ register_I = ram[0x00]&0xff; /* set new register_I (8 bits) */ /* opNOP_A_B (57) */ /* opSTAirg_B_BB (e6) */ ram[register_I] = register_B; /* store acc */ /* opADDimm_A_AA (21) */ register_A = (flag_C = ((cmp_old = acc_a0 = register_A) + (cmp_new = 0x1))) & 0xFFF; /* add values, save carry */ Since the translator itself is also available it wouldn't be too hard to modify it to generate basic, rather than translating the generated code from C to basic. This could be a much faster route to getting an exact emulation running... obviously not one I can use myself since the generated C code is way too large for the 6809 native Vectrex. G
|
|
|
Post by gtoal on Sept 14, 2017 16:58:43 GMT -5
I should probably start a new thread for discussions about compilers, but until someone complains I'll keep it in this thread ... I was looking into the possibility of adding some external peepholing to the CMOC workflow. Before considering taking on a project to write one, I though I'ld look around to see what already existed. Although a lot of work was done in this area in the 70's, there's not much code to be found. But I did find one, "copt" in ftp.cs.princeton.edu/pub/lcc/contrib/ - it does arbitrary string matching and replacement. I knocked up a quick rules file for the 6809 and it did OK. However it had a few limitations that pretty much mean if I want this done right, I'm going to have to do it myself. 1) Doesn't allow for any programmatical tests of matched parameters (eg if a constant is in a particular range) - only worked around by massive rule duplication. 2) Almost impossible to do multi-stage pipelines of rules. 3) Line at a time, sequential processing, which exacerbates problem (2) above 4) No regexp matching of parameters which exacerbates problem (1) above 5) No mechanism for remembering register values, noting if instructions affect registers, or doing arithmetic 6) No arbitrary code execution to either inhibit matches or to generate parameterised replacement code Nevertheless, even a really dumb peepholer was able to salvage quite a few bytes. Talking of which, I'm a bit out of practice with 6809 assembly. Is this a correct optimisation?: LEAU ,S LEAS -2,S => LEAU ,S-- Graham
|
|
|
Post by Malban on Sept 14, 2017 17:58:16 GMT -5
Theoretically yes - but, There is no such thing as "S--" There is only "S++" or "--S"...
|
|
|
Post by gtoal on Sept 14, 2017 20:28:12 GMT -5
Theoretically yes - but, There is no such thing as "S--" There is only "S++" or "--S"... Ah! That's why the compiler didn't already do it :-) I did say I was a little rusty! Thanks...
|
|
|
Post by gtoal on Oct 5, 2017 22:09:47 GMT -5
All right folks, a quick status update for anyone interested. I've had quite a bit of help from Malban and Peer which has been really helpful - thanks guys - and I'm starting to have some runnable code that shows potential. There are tweaks still to be made that I know about and others that will be needed that I don't know about. It's not quite fast enough yet but it is getting there. So far I have an attract mode demo - the binary is in gtoal.com/vectrex/tailgunner/main.bin and the corresponding source is gtoal.com/vectrex/tailgunner/main.c.html - I'm trying to keep it compatible with both GCC and CMOC... I haven't yet added any ships (which is going to be a real challenge), and the starfield is drawing individual dots rather than using an array drawing call - that is currently the critical path call that keeps the frame rate below 50FPS. If anyone wants to look at the code and suggest (or implement) significant improvements, be my guest :-) The next thing I'll be working on is throwing in a few calls to recalibrate the beam to reduce vector drift. Graham
|
|
|
Post by gauze on Oct 6, 2017 14:41:38 GMT -5
I remember when you started this project waaaaay back. If you stall long enough and actually release the game you might beat my slacking "record" of 16 years from code start to release for "Spudster's Revenge". Something to shoot for.
|
|
|
Post by hcmffm on Oct 6, 2017 17:53:38 GMT -5
Good to read that you still work on Tailgunner, Graham. I've tried to download the binary but atm there is no main.bin (your site doesn't display 404 errors, btw. This might be on purpose but a bit confusing.). Would be cool if you could provide the binary for trying out.
|
|
|
Post by gtoal on Oct 6, 2017 19:49:00 GMT -5
Good to read that you still work on Tailgunner, Graham. I've tried to download the binary but atm there is no main.bin (your site doesn't display 404 errors, btw. This might be on purpose but a bit confusing.). Would be cool if you could provide the binary for trying out. Yeh, sorry about that. The demo was slow and flickery, and Malban recommended that I don't post a binary until it is running acceptably - I think he didn't want my lack of coding skills to be mistaken for a deficiency in his C environment, and it's true that once you put an image out there it never goes away from the net :-) I'll be happy to send you a copy by email if you contact me and tell me where to send it or you can pick up yesterday's source from that directory and compile it yourself. (My email is gtoal@gtoal.com ). As it happens I found a way to speed it up significantly late last night after posting that, so another reason I took it down was that I want to wait until I've got this new code behaving correctly. It's the starfield implementation - the previous version drew the stars one at a time, partly in order to be able to fade them out individually as they approach the distance (ie center of the screen). I *could* have drawn them all as a single object with one bios call, but that didn't allow for fading proportional to distance. Last night I had a brainwave and came up with a hybrid algorithm that allows for fading while still getting much of the benefit of the list drawing call: I define a smaller list of stars that fits in a sort of rectangular doughnut shape (a bit like a thick picture frame) and I nest 4 of these within each other. Then I reduce the scale, and as the center one gets very small, I remove it and replace it on the outside of the concentric doughnuts. That way I can fade each of the 4 annular rings of stars individually, and it's a good enough approximation to distance from the center that I think it will work for TG. Also with a bit of chicanery I believe that I can position the rescaled doughnuts at appropriate positions to simulate a decreasing linear speed as the stars approach the center, to match the perspective-based approach I used with the individual stars. The perspective within a ring won't change but careful placement of the stars within each concentric ring should avoid that problem. And it is *MUCH* faster. I'm around the 50Hz mark now. However there's a couple of issues with the code I want to work on tonight: 1) the starfield code I just wrote *does* speed up the program considerably, but for now it is a naive implementation that merely loops continuously. The replacement doughnut is identical to the one that shrunk into the center - so a pattern in the stars is obvious. I want to rewrite it so the incoming stars are randomised. and 2) I got the code to draw a list of dots working under VIDE/GCC but *not* under CMOC. Can't work out what's wrong with it. (Actually if anyone here has the CMOC code for drawing a list of dx,dy points with n-1 as a parameter to the call, could you post that please?) The code is 28/29K (depending on GCC/cmoc) which means that to add the enemy ships I'll need to move on to bank switching. I have no idea what I need to do, to do that in C! Anyone have any pointers? Graham
|
|