That depends on whether you're talking about sound effects or music. For sound effects, I'd like something like SFXr that generates VSU code like your non-real-time emulator. Music should obviously be synthesized by the VSU, so you have to start with a "music language" of some kind. A member named "mic_" posted about adding VB support to his MML compiler. Then there's DanB's unreleased MIDI playing code. Also, I've chatted a bit with Kitaro (who helped get Bound High working) about music playing on the VB. I seem to recall him saying something about having VB code that can play music in a format similar to that used in Bound High (which I believe is also a version of MML).
Thanks for the links... I hadn't seen SFXr before... that's pretty cool (interesting how it smartly randomly generates stuff that actually sounds good ;) ). Also, on the same page is musagi, which looks pretty nice for creating music as well.
So, you're going with the assumption that it's better to create VB music rather than convert it from something else? I do think that's the case here... like my wav converter works fine for small amounts of speech, but that'd be horribly inefficient and bad sounding to do a whole music track and sound effects like that. And I'm not sure that FFT sequences are up to the task of converting music (that's how I did the some music and the sound effects in Mario Kart).
And yeah... a MIDI player may be nice, though that's what I did with most of the Mario Kart music, as well as the demo song in my first sound tester app. The problem is that MIDI instruments are much more capable than the VB waveforms, as well as having more channels, so they don't always work out. And yep... I believe BH did use MML, which of course is great, except how do we generate MML? My skill level is in line with placing Smiley Faces, Marios, Cats, Dogs, etc on a Mario Paint screen ;) .
I think the thing about Grit is just getting it set up in a makefile and designing your code/work-flow around naming the input image files and using the generated variable/constant names. It should be a mostly hands-off process, where you just dump images in a folder with your code and have them converted when you rebuild.
Wait... you're saying to convert files with Grit on the fly, rather than just using it as a tool to create graphics .h files? That's an interesting thought, though I kinda like to have real-time control (like in VIDE I usually end up converting my files several times to get the brightness/contrast levels correct to make a good conversion, as well as visually seeing that I'm making efficient use of chars... which is why I'd like a nice GUI for tweaking).
This is also a very confusing topic to me. Parasyte started working on a shell script that downloads, patches, and builds everything. That's a good way to go for the Linux camp. I think the best distribution for Windows would be a set of pre-compiled, native win32 (and win64?) binaries, linked against only the MS run-times, so it can be used with the Mingw versions of make, etc. from the Windows command-line, or integrated into things like Notepad2, etc. We should also look into the Eclipse thing mbuchman mentioned, of course.
I currently use a version built in cygwin, which means I have to use the bash shell provided with cygwin to run it, instead of having it integrated into my text-editor. It's just a bit less convenient than I'd like.
I'm also using a cygwin build (somewhat old DT version)... it seems like there's been talk of newer builds with various patches, but unfortunately I haven't paid much attention. I agree, a precompiled downloadable zip would be nice. Maybe someone who's running a newer patched version can chime in?
I've got a working, albeit not comprehensive, version I split into .C and .H files. I've been slowly cleaning it up and adding to it. It might be a good base to work from.
Yeah, if you've got a good base, please post it here, or you could email to me if you'd prefer.
I've started work on a "virtual timer" library that allows a number of "events" to be triggered at different times by a free-running timer kernel based on the timer interrupt. It's a simple idea: set the timer to some fixed rate (that won't take too much CPU time for servicing the interrupts) and then decrement a number of counters, calling function pointers when they reach zero.
Cool, yeah... that's one thing I was thinking would be good for the timer... basically creating periodic functions, so one "function" doesn't hog the only timer. I use those in RTOSes, though I'm not sure how many things need to be periodic on the VB. Sound is really the one that comes to mind, though I'm unsure that it needs more than 50Hz update (a 20ms note is pretty short). A lot of the periodic things really could (and probably should) be synced to the game frames. Like controller reads, graphics drawing, game timers, etc.
But yeah, that'd be nice to be able to basically "add" a periodic function... just tell it how many ticks and pass a pointer to the function to call.
I doubt if there's any "boiler-plate" solution that would work for every situation. We should just make it easy to understand how the subsystem works, and make efficient access functions, constants, etc. with which to access them.
Yep... but I don't think we're there yet. BGMaps are VERY easy to deal with... OBJs aren't, IMO. I think this could use a little work in the improved library.
One of the first things I thought of upon seeing Fwirt's BGMap pixel routines was making a variable-width font renderer (with a compressed, i18n-compatible font format, of course ).
¿qué? I'm just thinking something like what we have with bgmap_print() and itoa(), but with a smaller font table and more friendly usage (annoyances like negative numbers show up as really large numbers, then when you go back positive, it only overwrites the characters used, leaving a mess). I've made quick hacks to some of these functions for specific purposes, but something a little more standard would be nice.
Using user input isn't necessarily game-specific, as long as most games include some form of warning, IPD, and "activate auto-pause?" screens. If we standardize that code (while allowing custom imagery/text), we could incorporate a high-speed counter for random seeding.
True, though assuming you press start to get through the warning screen, you have to verify that holding start doesn't automatically skip that screen (basically check for not pressed, then pressed). And yeah, you'd want that counter as fast as possible, or to modify the seed several times during startup or throughout gameplay to give the best randomness.
Definitely. Get to work on that j/k.
Yep... that's one of the first things on my list for putting into the library. I'll probably be looking for input once I get working on it.
I agree: audio is still very much a "black art" among most VB devs, and severely lacking in the existing homebrew library. I can somewhat grasp the basics of the VSU, but my complete lack of musical talent provides a rather large barrier to getting anything written. We need a way to let the "artistic" folks do their thing in a way that can be easily incorporated into a game.
Yeah, musical talent is what usually holds me back too :P . Like you said, if we had a way for musically talented people to make stuff (or remove the need for music talent ;) ), we'd be in good shape.
That being said, you also have a point about a clean, easy to follow library/code-base to work from... And then there's the compiler situation... Hmm, quite a lot to do before beginning the "uber homebrew project" but I think we're up to it!
Yep... when it's me coding for myself, I tend to just hack stuff together, but if we're going to make a large collaborative project, we really need a well structured and clean base. I think audio handling and a better/common library are critical.