|
|
Post by garryg on Sept 22, 2019 8:53:53 GMT -5
When I first started programming for the Vectrex Machine language (Assembly) appeared to be the only real option.
Now I see people talking about programming the Vectrex with C, Basic, and even Fortran!
So are these options now comparable with using Assembly? How is optimisation handled with these languages?
Is MC still the best, most viable option?
I ask as I'm giving much consideration to making VecWars-II (That's " I I " two, as in two joysticks ) and am looking at quite a lot of maths for this one.
|
|
|
|
Post by gtoal on Sept 22, 2019 19:16:14 GMT -5
Not aware of basic or fortran - would be interesting to get a pointer to those. (other than basic on the vec32 and any language with an Arm compiler on the vecfever). I only know of C, 4th and Logo of sorts for the 6809 vectrex. That said, C is your only serious option outside of assembler. It'll help make large programs more manageable but it won't speed your maths up significantly, assuming you need either fixed point or floating point. My advice: code your core maths first and time it, then worry about the rest of the program. When I tried to write tailgunner for the vectrex I did all the rest of the program first and thought I could optimise the maths at the end, and boy was I wrong about that  Using gcc on the vectrex you *can* do 16 bit and 32 bit integer arithmetic (long, and long long would you believe...) which *may* be easier than doing it in assembler, but it's 50-50 whether it helps. On the other hand there are lots of old-school ways to *avoid* the expensive maths, so if you give us a bit of a description of what you're trying to do maybe we can help with some tricks for how to do it... G |
|
|
|
Post by gauze on Sept 23, 2019 17:31:00 GMT -5
I think it's worth noting Forth is "even worse" than the BASIC option to program since you have to modify the system BIOS to run a program unless I misunderstood what I read about it.
Logo (as far as I know) has no method to save or load programs so you'd have to re-enter your program each time to run it so there is no developer's distribution path for anything you "code" for it.
|
|
|
|
Post by garryg on Sept 25, 2019 17:54:29 GMT -5
Looks like it's still Assembler then. That's OK I kind of like Assembly language anyway.
I was playing around with circular and sine-wave based movement patterns for the aliens this time, using C# on a PC.
Why C#? Because that's what I have and generally use for work so I'm used to it.
I think I just have to have a poke around with the Vextrex and see what I can realistically come up with.
Like the first game, which was an early attempt for me, the second game keeps the graphics simple, with much of them being reused from the first game. The firing system and aliens is different although I am still basing it on a limited laser type weapon.
But it's all vert early just now, my first attempt on this, that I started some time ago, was abandoned.
|
|
|
|
Post by D-Type on Sept 26, 2019 1:10:47 GMT -5
I think it's worth noting Forth is "even worse" than the BASIC option to program since you have to modify the system BIOS to run a program unless I misunderstood what I read about it. You misunderstand it, calling BIOS functions from Forth is similar to C, in that some of the registers need to be saved to the stack before you call a BIOS function. Luckily the flexible push/pop to stack options, plus the fact there are two stacks, make the 6809 very Forth-friendly in that respect - one of the 6809 designers was a Forth guy. For C, Peer & Malban made some workarounds to the compiler to not clobber the stack, with Forth you just use push/pop in your calling function. Forth is a useful addition when developing game programs, several of the big arcade manufacturers used it later on in the 8-bit era mostly, almost like a super-macro assembler and development environment, Atari used 2 or 3 custom Forths developed for arcade and home computer, notably "Coin-op Forth", this is documented on archive.org and comp.lang.forth. Several Atari home computer games were written directly in Forth and I know arcade Gorf was written directly in Forth and using the built-in Forth assembler. Forth is able to compile code from a command prompt that runs on the target and run interactively, or be cross compiled from a PC. It's an incremental compilation with lots of jumps, which has a performance penalty, so then for greater speed you can create optimizers e.g. inlining code or peephole optimization or stack usage elimination or change the compilation method to use subroutine threading etc. On PC, these have already been done, the fastest Forth compilers produce code with performance close to native assembly code. On 6809 no optimizations are written yet on free compilers, so you write your own optimizations or you simply write your program in Forth code and optimize by recoding the slow parts in assembler. On Vectrex, if you want fastest performance, assembly is best, if you want faster development time, C is an option. Forth is another way of doing things, it's a development environment that lets you choose what parts of your program to code quickly (pure Forth) and what you want to code for speed (using Forths built-in assembler). Any of the code can be tested interactively at a command prompt as you write it, which is Forths greatest asset. You can also use Forth to call other compiled code written in other languages, like a local OS would, and write hardware device drivers e.g. for SD card, many of these are ready to cut and paste for 6809 The Forth I'm using as the basis of my "VecForth" is CamelForth, which is a Direct Threaded Code type and has a PC cross compiler. It was written in the 90's. Eventually it'll be made available for Vectrex on GitHub. |
|
|
|
Post by gtoal on Oct 23, 2019 22:24:13 GMT -5
I was playing around with circular and sine-wave based movement patterns for the aliens this time, using C# on a PC. Have a look at recent postings about Minsky's algorithm. VERY cheap integer-based circular-like movement (OK, ellipsoid really) Practical for both assembly and C. Of course, tables are trivial but it's fun to be able to avoid even that much space overhead with some truly old-school algorithms. C# is just bastardized C. Use C. G |
|
|
|
Post by garryg on Oct 25, 2019 14:52:55 GMT -5
Like it or not C# is now the 'in' evolution of C as far a business programming is concerned. You don't really get a choice of which language to program in with in most business. I used VB.NET for years because that's what the business I was in used at the time. Now I use C# because that's what the business I work for now uses. Unfortunately that's how it works in the real world.  |
|
|
|
Post by D-Type on Oct 25, 2019 15:58:42 GMT -5
My firm (50,000 staff) is IBM PL/1 and Java and moving to everything open source as quickly as possible. There seems to be so many new languages available these days, it's interesting to see which ones will get traction. I hear Rust is the new 'safe-to-use' C? And maybe Java has had its day?
|
|
