Planet Virtual Boy

DogP wrote:
Well... not so much interested in an actual IDE... but more in what tools/libraries/etc are missing from being able to have a collection of software that someone could use to create a complete commercial quality game... without needing to write tools themselves, or knowing every single detail of the hardware/memory map like the back of their hand.

This is going along the same lines as creating a community game, though I think that may be a little bit ambitious at the moment, because of what I'm looking to discuss in this thread.

I think we need a good base for building a game before just jumping in. I'd like to work that out here... gather useful snippets of code, work out a common library (Ha! I know ;) ), figure out what's difficult to use (and why), what tools are needed to make our job easier, etc.

So... I'm gonna start listing stuff that I can think of... feel free to jump in and add comments, suggestions, and ideas.

Tools:
Audio Converter
-from what format?
-how to audio people make actual sounds before conversion to VB (programs, converters, etc)?

Graphics
-I've found Grit to be very powerful, but not very user friendly, so I always go back to VIDE, which has some limitations and annoyances. Is it possible for a VB version of WinGrit (or does it already exist)?

Compiler:
What's the latest version, any problems, how to install, creating makefiles, etc?

Code NOT in .h files
-While maybe it doesn't matter, it has always bothered me that we include .h files, which has the code in it, rather than just function prototypes, and compiling the library source files seperately.

Code/library:
Audio Player
-I've used timer interrupts, though does audio normally need to change more than 50 times/sec? Could we just update between game frames? Of course depends on some sort of converter output

Game Frame stuff

Descriptive macros for common stuff
-Display sync
-Controller reads - yes, while(!(vbReadPad()&(K_ANY))); works... but why not WAIT_PAD_ANY; or something?
-Framebuffer control

Optimized chunks of commonly used code (that may need to be fast)
-memory copies
-framebuffer draws

Calibrated time delay functions
-We need to kill vbWaitFrame() :P. If we regularly use game frames, we shouldn't need them to throttle main loops, but a calibrated wait would be nice for things like wave playback (short durations), forcing a screen to be read for a few seconds (long durations), etc.

Objects
-I personally find objects to be a pain to manage... is it just me? Is there a way we can make these easy?

Text
-We have several functions, though they're not great IMO... and I think the ASCII table uses too much char memory (with unneeded chars)

H-Bias, Affine
-We have some Affine code, but slow because floating point
-Is there any H-Bias lib code, or is it just so easy you do it manually?

Random Numbers
-make it simple so you can just do rand(), and is there a better random seed than CTA? Possibly user input, but that's game specific.
-Probably should have a better PRN generator.

Link
-I'm not sure that there's really any helper functions written for using the link. While it's pretty easy to use, a simple set_master(), send(), receive(), COMCNT_stat(), etc would be nice.

Basically, I think it'd be great to write a very clean example using all kinds of stuff from a new library, and using new tools. Maybe we could teach the new VB devs on that, and us old farts could work on making the transition. I've personally been stuck to my old ways, writing dirty code, and being limited to old tools for too long... I'm ready to make the step.

So... any comments? What do you think is most important? IMO, easy audio is the most lacking, though code cleanliness is important to keep large projects from becoming unworkable.

I'm going to look around at some sample code/libraries and see if I can get some ideas, and maybe create what I'd call an "improved" library to post here for comment. Looking though the compo entries, DanB's Hunter code looks nicely ordered, multiple c files, seperated library, makefile, etc. Nice job :) .

DogP

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).

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).

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.

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'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.

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.

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.

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 ).

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.

Quote:

Link

Definitely. Get to work on that j/k.

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.

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!

DogP wrote:
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 ;) .

Quote:

I think the thing about Grit is just getting it set up in a makefile...

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).

Quote:

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.

Quote:

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...

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.

Quote:

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.

Fwirt wrote:
Graphics:
I've never used Grit, how does it work? It looked to me like a "dumb" tool that would just convert an image into something that can be used in VRAM. I'd like something that gives you full control over VRAM tiles. The problem with VIDE is that it's really clunky when it comes to Chars. You can't even move them around once you've placed them. If you look at the Mandelbrot explorer source folder, you can see that I was actually using the GIMP to lay out tiles, and then just using VIDE as a go-between. Another thing (sorry, I'm on a rant) is that VIDE "links" BGMaps to CharSets, and limits BGMaps to the Chars in that set, when a BGMap tile actually has access to all the tiles in Char RAM. I'd like to write a utility if I get the time.

Objects:
I actually prefer objects over BGMaps because of their versatility, but they are a bit of a pain to manage. If you want to "generalize" object management, you have to come up with some way of allocating objects, and then keeping track of them. This should be easy, but might have some nasty overhead. I have my own more hackish solutions to this problem...

As a parting note, I would prefer it if whatever gets added to the pool is not tied down to an IDE. Personally, I develop in Vim and terminal, so having to use an IDE would be frustrating for me.