PDA

View Full Version : Recruiting



BlackAura
November 1st, 2004, 09:17
I have exams for the next couple of weeks. After that, I'm going to start working on the DC Basic interpreter I've been working on occasionally for the past several months.

Ideally, I'd like to be able to get a working version of the thing out before the end of the year. The problem is that just having the working interpreter isn't enough. I'd also need some documentation, both on the Basic dialect and the stuff that's being added to it, some tutorials on how to use the thing, some example games, some support utilities, and two different versions of the interpreter (one for the DC, and a development version for PCs), with one version hopefully being available and tested on multiple platforms (ideally, Windows, Linux, MacOS X).

That's probably a lot more than I can manage alone, especially considering all the other normal stuff I have to do, and the fact that I want to work on Genesis Plus as well. I could probably get one version of the interpreter done, but that really wouldn't be good enough. It's supposed to be fairly easy to use, and a lack of documentation or examples would kill that, as would the lack of a PC version for development (or the lack of a DC version, which would render the entire project pointless), as would the lack of tools to deal with the data files for games.

Essentially, I'm asking if anyone would be willing to give me a hand with this thing. There's a hell of a lot of work that needs to be done on it before I'd want to release it.

At this stage, what I've got is a working interpreter, with very little functionality attached to it. It can load textures, draw them to the screen with scaling and rotation applied, and draw simple untextured primitives. It works, but it would fairly tedious to actually use in a real game, the design is far too primitive and inflexible, and the implementation is just a mess.

Each port should have a back-end which implements the exact same interface, so the actual interpreter code can be kept clean of operating-system dependent code. It's a bloody mess as it is, and polluting it with unnecessary garbage isn't going to help matters. The back-end should implement roughly the following:
Filesystem
KOS-like virtual filesystem, which works identically on all platforms
Local filesystem support
Something like a compressed ROM disk. Either the game can be packed into a ROM disk, or it can load them at runtime.
Simple RAM disk
Copy files to a VMU (compressing them transparently), or from a VMU to the RAM disk (decompressing them transparently)
Standard boring file I/O operations
Programs should be runnable from files, ROM disk images, or maybe even an image file on a VMU

System interface
Detect what kind of system you're running on
Detect region (US, Japan, Euro) and language settings
Detect status of drive door, and turn on/off reset-on-eject
Timers
Probably some other stuff that I've forgotten

Translation support
Can store text in a text bank, in multiple languages
Retrieve text strings according to the DC's language setting
Can choose a specific language if you want

Controllers
Support for basic Dreamcast pad, mouse and keyboard

Video
Video API based approximately on the idea of a scene graph
Fundamentally 2D, but using 3D for object priorities
Can divide the screen into separate scenes
Contents of each scene can be scrolled, rotated or scaled at will
Some simple primitive drawing functionality
Pre-defined objects such as simple bobs, animated sprites, full background tilemaps, text objects, or whatever.
Object to Object collision detection
Can load BMP, PNG, JPEG and KMG
Support for RGB565, ARGB1555, ARGB4444, 4- and 8-bit paletted textures
Support for DC's hardware colour palette
Full (automatic) support for both PAL and NTSC systems

Sound
Simple sample-based sound effects
Support for uncompressed (16 or 8 bit) sound, and 4-bit ADPCM
Streaming music (MP3, Ogg Vorbis, some tracker formats)

Most of that's really not too difficult. The filesystem and translation systems should be 99% portable, except for the VMU stuff. The system interface and controller support are pretty much nothing on either platform. The sound system isn't all that hard, especially if we're using SDL mixer on the PC side.

That really just leaves the video system as the one that's going to be hard to implement, and also the only one that's even remotely difficult to design.

So, does anyone feel up to lending a hand on this thing? If I get time tomorrow (when I get fed up with revision, probably), I'll try to type up the design stuff I already have, and post it somewhere, and we'll see where it goes from there.

quzar
November 1st, 2004, 09:53
Well, I can offer some help with documentation and maybe an example or two. May I ask why you are creating your own whole new flavor of basic as opposed to selecing a preexitsing one and making an interpreter for it on the DC? (or is that what this is?)

BlackAura
November 1st, 2004, 19:06
Well, the interpreter itself is based on wxBasic, with all the wxWidgets bindings ripped out, and new ones put in their place. The only reason the Basic dialect needs some documentation is that it's a bit quirky, somewhat like a cross between Visual Basic and VBScript, with features not found in either of those, and a couple of things handled slightly differently.

http://wxbasic.sourceforge.net/

toastman
November 2nd, 2004, 10:22
I would like to help. Probably after the DCGP though (or until I decide that I won't be able to make the submission deadline).

And just to be clear, you are looking for people to implement the interpreter on other systems, right?

BlackAura
November 2nd, 2004, 20:31
I'm not completely certain. Basically, I can handle most of the interpreter except for the video system. That's pretty much the single largest component, and it needs to be done twice. So some help implementing it (either the SDL/OpenGL version or the DC version) would be nice. Since I've been using SDL and OpenGL for the PC stuff, it should be reasonably portable.

That said, if someone wanted to do a full, native Windows version using DirectX / Direct3D, that might be nice too. Some video cards work better with Direct3D than they do with OpenGL anyway (ATI stuff mostly).

Anyway, that's part of it. Once some of the interpreter is done, we'd still have documentation, examples, and utilities to do.

I'll post some more complete information when I have some...