Localization Legend "Supper the Subtitler" has "joined the club" in being targeted for CD-pressings by bootleg master Tobias/PCEWorks! His projects like Private Eyedol, Galaxy Fräulein Yuna 1 & 2, etc. are now being sold on Chinese factory-pressed CDROMs...
IMG
Main Menu
Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - Hu-man

#1
So, I've only posted here a few times, but I follow all of your work a lot. My goal is to pop out of the woodwork one day and say, "Hey! Look at what I made on the PCE!" and then have everyone respond in unison, "What a piece of shit!" But till then, I'm mostly just a reader.

And before I go on my rant about MML, I should preface it by saying that I don't have much experience with trackers, and that my PCE stuff is the only experience I have with making music on a gaming platform.

That said, for someone who can read music, MML seems like a pretty decent notation. In fact, I'm hard-pressed to think of a better way. It's pretty close to modern musical notation, and that's been around for maybe a thousand years, so you'd think it'd at least be fairly good.

As far as my process is concerned, I'll usually just write on a real instrument then transfer it directly to the MML file, but sometimes I'll use a Finale NotePad-like tool to notate the music and then export to MIDI. I mention this because Finale NotePad has a free download and might help some of the people that are having a hard time with MML but can read music.

And as far as the readability of the MML is concerned, I agree that it can be kinda tough. But when it all comes down to it, it's being used to represent instructions you're giving the processor (code). So, like all code, it's easier to read when formatted. I often do something like 1 or 2 measures per line and use whitespace between notes to visually inspect that the timing matches up.

I think one of the reasons you don't hear about more people using it is that most people aren't the pros who post here most often. Compared to all the successes of everyone here, it seems to be taking me far longer than I would've expected - both in the time to develop a game and the time to figure out how to work around all of the PCE's/HuC's idiosyncrasies. Even yesterday while reading the "The new fork of HuC" thread, I saw Dave Shadoff's message about parameter-passing being bad, then I saw Elmer's message on the switch-statement being bad, and I thought, "Well that sucks for me."

So, as a verified non-pro, I find that Squirrel is probably one of the friendlier tools out there for PCE development. You don't need to worry about pointers, memory management, two's complement, or (may god have mercy on us all) learning assembly. You just feed it the MML, tell it when to play, and you're done! For the novice, learning HuC is probably enough, so I'll probably never be interested in writing a custom sound engine when all of the hard work seems to have been taken care of already. My personal opinion is that most of the non-vocal folks aren't writing in machine language, and those same folks would rather spend a little time learning MML over the (IMHO) steep learning curve that'd be required to reinvent the wheel.

Also, I could be totally wrong about this, but it kinda seems like Squirrel is the only game in town for making both music and sound effects on the PCE (other than custom sound engines). If not Squirrel, what are most developers using? And even if one uses CD-Audio for homebrews as Elmer suggests, what are people doing for sound effects?

I'm not on this forum as much as some of you other guys, but the only other sound tool I can remember was BT Garner's SoundGen tool, which I found extremely cumbersome. Also, it seemed like it took a very long time for ANY sound tools on the PCE to come around, so I don't know that waiting around for a new tool is a feasible option, especially when that theoretical tool will yield the same end result.

That said, here are my complaints about MML/Squirrel:
  • Not that it's impossible, but getting triplets isn't straightforward, nor are a weird/staggered beats (I'm thinking the nasally horn riff in the lava level of Bomberman '94).
  • MagicEngine doesn't emulate it faithfully (which I guess is actually a complaint about MagicEngine).
  • And to Bonknuts' point, "what you hear is what you get" would be really REALLY nice, especially so that you could hear the waveform/envelope combinations. Still, I don't know if that's really the point of Squirrel. Maybe that'd be for another GUI for the future, but I kinda see Squirrel as a jam-in-an-MML-file-and-it'll-give-you-music-on-the-PCE tool.
Most other complaints seem to be around the fact that people want a GUI to write music, but there's a lot of them out there that will let you output your song to MIDI, so I don't know what the benefit of yet another GUI would be (except for the aforementioned emulation of envelope/waveform combos). If people want to use trackers to create songs, do none of them have the ability to output a MIDI file? Again, since I only have limited experience, I guess I don't really understand the benefit.

But, yeah, take all of what I say with a grain of salt. I don't have a vast knowledge of all the possibilities that are out there. I'm not trying to diss anyone or stroke anyone's ego (especially Arkhan's  :P ). I just think that MML and Squirrel are pretty solid, and I wouldn't want people being discouraged from using them or told to only use CD-Audio (not that this should at all be construed as a dig on you, Elmer, I think you're rockin it with your work on the HuC fork) when MML and Squirrel are totally viable options. Squirrel has made developing on the PCE easier for me, and I think other people might agree if they give it a shot.

Anyways, that's the end of my rant. Talk to you guys in five years or so!
#2
If I'm breaking my functions into multiple smaller functions, do I need to worry about the number of calls that can be pushed onto the execution stack?
#3
Thanks for the help!

I didn't know that about the function size. I'll break them up!

I guess I was thrown off by the fact that my compiled code grew 30KB just by changing to a smaller datatypes. Implicit casting was the only thing I could think of that could have caused the big jump in size.
#4
Hey folks!

I've been fooling around with HuC and have been attempting to squeeze my code into the 256KB system 3 card limit to test on real hardware. I figured that converting my variables from int (16-bit signed) to char (8-bit unsigned) would save some space, since all of the documentation I've read suggests that. However, my compiled code is now actually 30KB larger than before.

I'd assume that HuC implicitly casts a char to int and vice versa when a function requires that datatype, but does it also cast for other operations? For example, I believe it does when incrementing (i.e. char++) and when using a char as an array index (i.e. x[char]). Is there a list of operations where HuC will cast the variables to int? I could do a lot of testing to figure it out, but I don't really want to reinvent the wheel if I can avoid it.

For those of you who know Assembly, here's another question. Keep in mind that I have absolutely no assembly experience, so be gentle.

In the assembly code generated by HuC, I've noticed that incrementing a char variable requires 2 operations (__addwi 1 and stx) whereas an int only requires 1 (incw). Are these 2 operations (and their 8-bit counterpart operations) still faster than incw? Do they take less space? I'm assuming that just because the generated assembly is smaller doesn't mean that it's faster/uses less memory.

Also, it seems that when doing an operation like multiplying a char, _ldwi and _pushw are being used. Am I correct in assuming that the "w" is for "word" and these are the 16-bit operations being used for the 8-bit char? Does this have any negative effect?

As it is, I'm really not seeing any advantage to using char instead of int. Am I missing something?
#5
What a success for me! :wink:

Regarding Aetherbyte.com's forum, I too am having an issue with the visual confirmation code, but I'll register ASAP.
#6
Hello, all!

I've been following you guys for a while now, but this is my first post.

First off, Squirrel is the probably biggest step forward in PC-Engine dev tools since HuC. Arkhan, you're a damn good programmer, and this was a huge undertaking. Thanks for all the time you spent on it! Your balls are bigger than all of the enemies in Vigilante, including the final boss.

That said, I have only attempted to use it a couple of times, and I'm not actively using it for any of my games just yet.

What deters me is that it "sort of supports" HuCards. I don't know exactly what that means, but I don't particularly want to find out the hard way. I'm currently coding for HuCard exclusively because it's the easiest for me right now. HuC is kinda flakey as it is, so I don't want to throw another wrench in the works just yet.

Also deterring me is the fact that the current version doesn't really support sound effects. I don't want to use both BT Garner's "snd.c" and Squirrel. It just seems a little redundant.

Personally, I'd prefer a newer version that resolves my two concerns, but I'll still use it when I'm farther along in my development even without one.