|
Post by hcmffm on Nov 17, 2015 8:05:12 GMT -5
|
|
|
Post by centaura on Nov 17, 2015 8:36:59 GMT -5
Fantastic resources, I have to take a look because a C compiler could be a great vectrex programming tool. In a certain way, the coding phase would be a bit more "comprehensive", if you are able to get a very refined code.
|
|
|
Post by hcmffm on Nov 17, 2015 17:12:59 GMT -5
Fantastic resources, I have to take a look because a C compiler could be a great vectrex programming tool. In a certain way, the coding phase would be a bit more "comprehensive", if you are able to get a very refined code. Thanks for the positive feedback, centaura. I was quite surprised myself to find that many small projects using C. Looking at some of the C code (e.g. Sebastian Mihai's Scalar Ownage) programming looks clear, simple, and feasable to me. (Well knowing that programming good and fast code will still be a challenge and that things look simple when they are done.)
|
|
|
Post by scotthuggins on Nov 29, 2015 19:38:59 GMT -5
While I get it that you are wanting to get an easier way up the mountain, so to speak, but you are limiting yourself by going the C programming route. Way, way too many unnecessary pushes and pops to the stack. Lots of wasted cycles in each frame.
6809 Assembly language, to me, at least, is actually fairly easy to get a hold of.
Good luck if you wanna go the "C" route. I'd like to see a fully finished game using C at some point.
|
|
|
Post by centaura on Nov 30, 2015 13:58:28 GMT -5
scotthuggins, that remember me those Computer-consoles like Sinclair ZX Spectrum: you could program with a embeded BASIC compiler, but the best result was always by using the native ZX-80 machine code. That´s why I told about be able to get a very refined code; the (manual) debugging phase is a "must" programming into C. But beyond theory, good coding might be possible.
|
|
|
Post by vectrexrc on Dec 1, 2015 19:13:29 GMT -5
|
|
|
Post by mountaingoat on Dec 3, 2015 7:42:48 GMT -5
Very cool, will check these out.
I would be slightly worried though about getting the code bloated for every function call/etc.
After having written 2.5 games (one is in the making) I usually end up changing even the direct addressing page for some routines and seeing if I get any cycles out of it. You would not be able to do that using C.
That being said, I will most certainly look into this.
|
|
|
Post by Malban on Jan 8, 2016 18:19:41 GMT -5
|
|
|
Post by nes4life on Jan 11, 2016 11:09:55 GMT -5
|
|
|
Post by mikiex on Jan 21, 2016 16:57:36 GMT -5
There have been a few examples in C and even a couple of games. I'm certainly interested to see where this goes. At the same time I agree with Scotts reservations.
6809 is pretty easy to learn, putting more layers between you and the metal might mean more bloated code and slower performance. If you are going to code at low level with a low memory system I'm not sure C will help you in the long run.
Out of interest nes4life, your pong bin is about 5k where does the size of that come from, do you include copies of bios source in that binary or do you call the bios for some functions? 5k seems quite big for pong?
|
|
|
Post by christophertumber on Jan 21, 2016 20:58:06 GMT -5
IMO, the best use cases for high level languages are:
- Offline tools like vector editors, bitmap converters, sound/song converters, level editors - Relatively complex routines that are not real-time dependent. ie; in a game with procedurally generated levels/words where those are generated at the start of the game/level. Or turn based strategy game where the opposing AI is written in a high level language.
I believe the playfield clipping routine in Gravitrex is written in C but generally speaking using any such routines in any kind of main loop is going to be difficult to manage. And even when used otherwise (second point above) you're going to need to be careful on the resource use (ROM and RAM).
|
|
|
Post by mikiex on Jan 22, 2016 18:59:03 GMT -5
Chris I think you mean Thrust - that scrolls, not Gravitrex (flips between screens)
I can see C also being useful if you can generate the assembler output, then edit it.
|
|