|
Post by gtoal on Oct 9, 2017 18:49:29 GMT -5
PS Just looked at a video of the original Tailgunner - The placard does not rotate in perspective - it just "shrinks"... I've spent enough time on that rom to know this is not the case! freeze this about 7 seconds in. The perspective is obvious though perhaps not as marked as my current implementation: www.youtube.com/watch?v=V4hb9UJBs9k(I didn't record the vectors in mine from the original game - I recreated them from the data structure, so the distortion is more noticeable) G
|
|
|
Post by gtoal on Oct 9, 2017 21:09:37 GMT -5
I have a C question for Malban:
static const char ShipMesh3[23*2*3]
This has 138 elements and GCC complains that the size of the array is negative!
C:\Users\root\Downloads\Vide2.0_RC07\Tailgunner Intro\source\main.c:456: error: integer overflow in expression C:\Users\root\Downloads\Vide2.0_RC07\Tailgunner Intro\source\main.c:456: error: size of array 'ShipMesh3' is negative
Again, a side-effect of default 8-bit int types :-(
Is there a work-around or does gcc6809 simply not support arrays longer than 128 bytes?
|
|
|
Post by gtoal on Oct 9, 2017 21:17:53 GMT -5
Also... I hacked together a short dummy missile rotation. The missile was drawn pretty dumb it uses 8 different vectors, the routine therefor slows down pretty much - but anyway... Here is a bin and a project file (place it in ...Vide/project) if you want to look at it. Regards Malban vectrex.malban.de/tmp/TGMissile.zipvectrex.malban.de/tmp/TGMissile.binNot sure what I'm looking at - the bin appears to be some sort of dancing boomerangs :-) and although the main.c in the zip file looks more understandable - it's doing a 3D transform which is overkill - tailgunner fakes missiles with 2D and ignores the z axis in testing hits! I plan to do the same.
|
|
|
Post by Malban on Oct 10, 2017 3:24:38 GMT -5
Integer...
Just cast it to either "long" or "unsigned int" - looks stupid in the code - but works :-).
Malban
|
|
|
Post by gtoal on Oct 10, 2017 7:24:08 GMT -5
Integer... Just cast it to either "long" or "unsigned int" - looks stupid in the code - but works :-). Malban Wow - I'm surprised. If the expected type of an array index is an int, and you give it a long, I would have expected gcc to perform an implicit type cast on whatever you supply back to an int, and therefore lose any extra width from the long that you gave - exactly the same as if you passed a long to a procedure that was declared with an int parameter. However, regardless of whether it is logical, I'm glad it behaves that way because I need larger arrays!
|
|
|
Post by gtoal on Oct 12, 2017 8:18:24 GMT -5
Another binary to be tested. This is *solely* a speed test to see if there is noticeable flicker when the ships are on screen. (There is no ship motion yet) Adding ships has pushed performance a little below the target 50 FPS but only a little below, and since I'm running out of ways to optimise the vector display, I need to know if this is within the bounds of acceptability. All the components are in place here. If this works, I can make the whole game work, but only if I use pre-rendered vectors for the ships. Drawing them from scratch is currently so slow it's out of the question. What this iteration of the code does is draws one ship at startup and caches the result. This is only for display speed testing, that won't work in practice. I'll have to precompute the frames. Storage cost is 118 bytes for the larger ships and 82 bytes for the simpler ones, per ship, per frame. I think it is doable if we take advantage of scaling and restrict the ship paths to some carefully chosen fly-bys. I am having some major problems with the dynamic rendering but if it is going away anyway I may not need to fix them Pick up the new binary at gtoal.com/vectrex/tailgunner/main.bin and let me know what you think. I'm only asking about flicker, not drift. (I haven't put any time into drift correction yet) I know this iteration is out of spec, but I'm asking whether it is so far out of spec that it is annoyingly noticeable, or whether we can get away with it... (It looks OK to me on the emulators) thanks, Graham PS I'm considering renaming it "REAR GUNNER" and adjusting the intro placard to match.
|
|
|
Post by christophertumber on Oct 22, 2017 12:26:14 GMT -5
Adding ships has pushed performance a little below the target 50 FPS but only a little below FWIW, my target is always 40 fps. only if I use pre-rendered vectors for the ships. Also FWIW, all my sprites are pre-rendered in ROM.
|
|
|
Post by gtoal on Oct 22, 2017 14:04:12 GMT -5
Adding ships has pushed performance a little below the target 50 FPS but only a little below FWIW, my target is always 40 fps. that's encouraging. I can't really tell myself what level of FPS is necessary, as I've mislaid my vecram so I've been relying on folks here to test for me now and then. (My garden shed is currently stripped bare with all the shipping crates containing 20 years of junk spread out over our back lawn! I've been going through it all looking for the damned Vecram but haven't found it yet. It's looking like it's in the *other, larger* shed :-( Oh well, at least I'm getting some old junk cleared out at last... it's easier to throw things away if you haven't used them in 20 years! (Though I'm furious with myself for having put away so many electronic devices with batteries still in them - looks like I've ruined both my gp32 and my gp2x :-( ) Anyway, with that much slack available I'm a lot happier about the last phase of this project. My current plan is this: use a single simplified 2D view of the ships for the 1st phase of attack, where they enter from off-screen and dodge around a little while keeping Z constant (at maximum distance). Then they'll turn and face the bottom of the screen, where I'll switch to a set of 3D pre-rendered views as they straighten up and fly towards the viewer in a normal orientation, keeping X constant. I may need to restrict this to maybe 5 pre-defined lanes so that the perspective angle views are kept to a smaller set. (far left, mid left, center, mid right, and far right). There's a little bit of bobbing up and down in Y during this phase but that can use the same pre-rendered image set as is used in the switch from the x/y plane to the x/z plane. G
|
|
|
Post by hcmffm on Oct 22, 2017 16:13:43 GMT -5
My friend had sent me back my VecMulti and I just had a quick look: The graphics look quite good and very much like the original. My impression is that there is little flicker but graphics are a bit wobbly. Might well be that this is a problem of my Vectrex. Keep up the excellent work, Graham!
|
|
|
Post by gtoal on Oct 22, 2017 23:08:13 GMT -5
My friend had sent me back my VecMulti and I just had a quick look: The graphics look quite good and very much like the original. My impression is that there is little flicker but graphics are a bit wobbly. Might well be that this is a problem of my Vectrex. Keep up the excellent work, Graham! Thanks! The wobble/drift I was expecting - I haven't done anything yet to tackle that. Glad to hear that the flicker level is low - that's what I was worried about! G
|
|
|
Post by gtoal on Nov 1, 2017 23:48:52 GMT -5
The memory map for the Vectrex includes:
0000-7fff Cartridge ROM Space, the CART line is also gated with ~E to produce a signal that can be fed directly to the output enable of a ROM. This address range is not gated with the read-write line but this line is fed to the cartridge connector. (r/w)
8000-C7FF Unmapped space.
My question is whether the 8000-C7FF space can be used contiguously with the program code (specifically the output from GCC) - Does a program which exceeds 07ff work in the emulator by default or do you need to do something special to make it work; and will the same code work on the hardware, either with a standard cartridge or with some special cartridge?
I've just about got the ships ready for Tailgunner but it is without doubt going to blow past the 32K limit. It would be really nice if I can use 8000-C7FF rather than having to explicitly page data dynamically.
|
|
|
Post by gauze on Nov 2, 2017 1:43:03 GMT -5
I don't think it's possible because of the way the address decoding logic is set up, it's not a dedicated chip it's some TTL NAND and OR gates if you check the schematics for top 4 address lines (A12-A15) console5.com/techwiki/images/c/cb/Vectrex---Logic-Board.pngsomeone correct me if I am wrong, please.
|
|
|
Post by Malban on Nov 2, 2017 4:46:20 GMT -5
For "C"... The next Vide version support "C" via gcc compiler. But Vide will not support bankswitched code for "C" programs (yet). I might do that for a future version, but right now I am more concentrating on getting the current version finalized. Mind though: gcc offers options to compile to different sections and the linker also has the ability to cope. So in general it probably is possible to do bankswitched programs with C. You probably need a special crt0 or otherwise "fixed" library component to do the switching. For more insight to the gcc version you might look at: web.archive.org/web/20090201175459/http://www.oddchange.com/gcc6809/manual.htmlAnd there at the attribut "FAR". --- "The emulator" is a bit unspecific - but I think ANY emulator you might use will act the same way when you try to use memory above $7fff -> it will not work. For assembler programs in Vide you can generate example code for bankswitching (new project, + bankswitching). Although it is not unheard of, that "special" cartridges use the "upper memory" regions. E.g. - Spectrum RA uses $8000 - $87ff for additional extra RAM - SID cart is accessed with its registers mapped to $8000 - $801f Since I am not a hardware guy - I don't know how the carts are wired... Malban
|
|
|
Post by kokovec on Nov 2, 2017 9:28:13 GMT -5
I've used the $8000-C7FF as extra memory space in some of my projects. It's a whole 17K of untapped memory. The 3D engine that I designed a while back used it to store all of the matrices used for the transforms as well as all the transformed vector lists. The transforms would happen without halting the CPU and allow it to execute in the lower memory space while the transforms were happening. As for my experimental SID cart here's the logic used to select the SID registers. Memory_Logic_zpshlmfidrk by D S, on Flickr
|
|
|
Post by gtoal on Nov 3, 2017 19:26:14 GMT -5
OK, this helps! In your diagram, where do A15, E, and ENABLE come from on the edge connector?
Is A15 just pin 16? The docs I've seen aren't clear on the edge connector pinout...
E I think is pin 12 but are you inverting it (not in the diagram?) or using it directly?
And where is ENABLE? Is that pin 32 by any chance? Oh wait - ENABLE is the output, right? (I was fooled by the direction of the arrow on the label) So the input to this diagram is just the addresses A5-A15 and the E line, and ENABLE is the output?
I'm not following why the transistors rather than just TTL gates for decoding the Enable signal?
But if I've understood this correctly it should be possible to build a cartridge that supplies ROM data for accesses in the range 0000-BFFF in exactly the same way as current cartridges supply data for 0000-7FFF, right? Thus allowing 48K programs instead of 32K?
And the compiler doesn't care if a program exceeds 32K I presume; and there's no reason any emulators should either except that they probably have been coded to ignore the 8000-BFFF part of the address space, but I would imagine could be very easily tweaked to treat that space exactly the same as 0000-7FFF if we wanted to?
Regardless of whether I have to do all this for Tailgunner, it seems to me to be something that is worth doing anyway to allow us to write larger programs. In fact I'm really surprised it hasn't been done already. Or has it? Do any of the existing ram cartridges support non-paged 48K programs?
G
|
|