We can replay Monty Python's Four Yorkshiremen sketch if you like, but I think that you might find that my battle-stories win.
Couldn't give two shits less, as I wasn't really interested in battle stories, or some sort of competition. I am just pointing out, from a "stuff has been completed" standpoint, that symbolic debugging isn't a dire requirement...
Also, I find Monty Python to be boring, so, your reference is lost on me there.
Yes, you can do all of those things, and there are also other old tricks that you haven't mentioned.
But why not make it easier on yourself?
We've passed those days when "real men don't each quiche", and "real programmers" should be able to rattle off every hexadecimal opcode of their favorite processor.
Being able to step through the code as it runs and see your source code and comments is really nice ... it makes the whole job faster and more pleasant.
I wasn't around for the whole "real programmers" thing. I was born in 1988.
I'm just saying, for such simple, self contained little things like PC Engine games, doing the whole debug-printout/test case/etc. thing really isn't that big of a hassle. I actually find it a bit less of a pain in the ass to setup the screen to print values out, and then I manipulate things with the controller and watch what happens.
This is for me at least. Maybe the way I write games is different than others who would really like step-through-able-with-symbols coding.
Like I said, I rarely use it on a platform (MSX) that has it readily available.
If you write such clean code that you never have bugs ... then you're a much better man than I am.
Much of my code is written out on paper/diagrams/planned before it hits the screen. So a lot of bugs are sorted out with a pencil+eraser.
I'm happy to spend the time to fix up some of the HuC equates and library files so that they work with CA65. It's good practice, and someone may find it useful.
But I'm really not interested in taking the time to get a CC65 setup fully working on the PCE, and especially not in trying to set it up to work just like HuC ... which people other than you have complained about.
CC65 and LD65 seem to offer a lot more flexibility than HuC. Since I don't know/use HuC, I'm entirely the wrong person to set up CC65 to try to overcome what some guys feel are weaknesses in the HuC setup, and to take advantage of some of the strengths of CC65.
You maybe misunderstood what I meant by "like HuC". I just mean "A C environment that supports writing PCE games". It doesn't have to function exactly like HuC. It'd be better if it didn't, as you've noticed.
HuC's biggest weaknesses are doofy pointers, no structs, and slow as shit array access. These are not life-shattering issues though. You can work around them pretty reasonably, once you know how to access an array with ASM.
But if you want to use C on a platform that I feel that isn't suited to it ... then please don't expect me to do the heavy lifting.
Noted. It's just, you said you wanted to encourage PCE development. The whole "accessible C environment" thing would probably go a longer way in encouraging new people since:
1) Assembly is daunting to new people (especially 6502). If they're not already excited about ASM, this just provides them with another confusing option, lol.
2) Those of us who are already doing it have projects already tied up in HuC/PCEAS's ways, so that counts those out if those projects can't easily shimmy over to a supposedly better toolchain.
3) As was noted before, and has proven extremely true in practice, C, while not really well suited to 6502, is great for prototyping and testing before optimizing.
Also, the whole "C is bad on 6502" concept doesn't seem to really take into account the fact that the PCE has a faster-than-average 6502 CPU in it. You can actually get some solid speed going with C and no ASM on the PCE. I am honestly leaning towards expecting my next game to function without any heavy optimizing.
So, you'd basically be working on an ASM setup for the not-so-plentiful bunch of budding 6502 ASM PCE coders, or the people who are mostly just hacking/toying around.
This doesn't sound like encouragment or kickstarting to me, is all. I would've figured if you truly want to give PCE development an encouraging kick in the tits, you'd want to provide readily available C stuff to provide a better alternative than what is already there.
But, if you're not into that, the open-source-ness of what you're doing will at least leave the door open for somebody to come in and fart around with it.
If you want to step up and help make CC65-on-the-PCE happen, then I'm willing to help you out with my advice and some of my time.
If you're not, and nobody else is, then I expect that HuC/PCEAS is going to continue to be your best choice.
I'm not going to invest time writing C compiler crap. I honestly find it a bit mind numbing and boring, and would rather divert the time to my game projects, as I have a few going.
You sound like you are into that stuff more than anyone around here, honestly. If you're not going to bother, I wouldn't hold my breath for any of the current PCE people to bother.
No toolchain is ever "complete" ... there are various levels of works-well-enough, and then you keep on improving over time.
Yeah. You knew what I meant.
Constant relearning is a part of the games world, and life in general.
You mean constant *learning*. Not relearning. Relearning is the result of disabilities.
Learning is for new hardware. This is the same hardware, with a possible newish backend. The API would want to be reasonably similar, or you're possibly discouraging the current people (like myself) from adopting the new thing in the first place. I personally don't have a strong tickle in my pants to take steps backwards for in one regard, so I can take steps forward in another regard. Don't see a huge gain there.
I just think going in a radically different direction than MagicKit's library+HuC's layer-on-top might not be a great idea.
I really appreciate your offer, but I'm afraid that those conditions don't work for me, or for anything that I intend to publicly release.
Ah yeah, I forgot you're releasing it this way. Oh well. I guess if you get it all done, we can see about shoehorning it into whatever you setup as a separate fork that's Squirrel Ready.
BTW ... I've written a number of soft-synths over the years. They're not that hard to do, and I have a lot of existing code to refer to. While it would be very nice indeed to use one that's been tailored to the platform and is already known ... it won't be a huge hardship to have to write another one.
Fair enough, and have fun.
There's more to it than writing the player portion that produces convincing beepboopery.
Squirrel comes with a complete MML compiler so you can make the songs in a meaningful way and get them quickly playing. Sound effects included.
Squirrel makes use of the hardware's PSG player built into the BIOS and recreates it in the absence of the CD hardware (for HuCard games). It's all done straight from Develo+Hu7's CD documentation, and it operates fairly similarly to commercial MSX MML setups with regards to creating music and SFX.
So, it's a decades-old, proven process for putting tunes/sfx into a game with little headache/pain.
Probably the best available option, really.
