BlackAura
November 1st, 2004, 08: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.
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.