Project DS... oh, what the heck

This forum is for discussion pertaining to homebrew and indie software for the Dreamcast, such as homebrew games, emulators/interpreters, and other homebrew software/applications. Porting requests and developmental ideas are not to be made here; you can make those here. If you need any help burning discs for homebrew software, this is the place to ask as well.
Strapping Scherzo
DC Developer
DC Developer
Posts: 2285
https://www.artistsworkshop.eu/meble-kuchenne-na-wymiar-warszawa-gdzie-zamowic/
Joined: Fri Feb 21, 2003 7:37 am
Location: Chicago, IL
Has thanked: 0
Been thanked: 1 time
Contact:

Project DS... oh, what the heck

Post by Strapping Scherzo »

I feel it's kinda retarded on my part to keep this project a mystery. Retarded, selfish... whatever...

nakamichi and jtnewman pretty much nailed the intent of the project. I intend to make development of homebrew easier for people without much experience in programming. People who use this will also avoid having to setup a unix-ish environment and cross compiler.

DS stands for DreamScript. I have ported the KJS JavaScript engine found in KDE's web browser, Knoquerer, with promising results. So far, I have implemented objects for video, images, controllers, and mice and I've done a some simple tests.

I've always liked JavaScript. It has a nice syntax similar to C/C++, useful core objects, and is very flexible. The way I see it, it's a perfect candidate for a scripting language on DC. A good number of you have probably done web development which involved writing some JavaScript. So it's syntax and behavior should be well known.

Using a scripting language provides that extra layer that will allow me to write a PC based application that duplicates what would happen on the DC. So instead of constantly uploading your new script to the DC, you can test right on your PC until you are ready. And KJS easily makes true step-by-step debugging possible. So I will defintely write a cross platform IDE for DreamScript. Maybe in Java?

So far I only have 2D homebrew in mind. I'm not sure if the extra overhead of the script engine will allow for complex 3D games. I still have to find out the limits of scripting 2D.

If I keep the API generic enough, it could conceivably be ported to other systems in the future.

Here's a WIP document that gives a logical description of the classes and objects that will be available.

Code: Select all

DreamScript API Specification
by Scherzo

The following class and function definitions are only logical and are not any actually implementation of
any language.

class DSGlobal
{
	enum { DM_320x240, DM_640x480, DM_800x608, DM_256x256, DM_768x480, DM_768x576 };
	enum { FILE_READ, FILE_WRITE, FILE_BINARY };
}

// Completed!
class Image
{
	Image();
	
	String toString();
	Boolean load(String fn, Number list, Number filtering, Number alpha);
	Undefined unload();

	Undefined draw(Number x, Number y, Number scale, Number a, Number z);
	Undefined drawWH(Number x, Number y, Number width, Number height, Number a, Number z);
	Undefined drawRotated(Number x, Number y, Number scale, Number a, Number z, Number pivotu, Number pivotv, Number angle);
	String getFilename();
	Number getWidth();
	Number getHeight();
};

// Completed!
class Controller
{
	Undefined poll();
	
	Boolean a;
	Boolean b;
	Boolean x;
	Boolean y;
	Boolean start;
	Boolean up;
	Boolean down;
	Boolean left;
	Boolean right;
	
	Number joyx;
	Number joyy;
	Number ltrig;
	Number rtrig;
}

class Keyboard
{
	Undefined poll();
	
	
}

// Completed!
class Mouse
{
	Undefined poll();
	
	Number dx;
	Number dy;
	Number dz;
	Boolean lbutton;
	Boolean rbutton;
	Boolean sbutton;
}

singleton class Input
{
	Boolean rescanDevices();
	
	Array<Controller> pad;
	Array<Keyboard> keyboard;
	Array<Mouse> mouse;
}

singleton class Video
{
	Boolean setMode(Number mode);
	Number availableMemory();
	String toString();
	Undefined frameBegin();
	Undefined frameFinish();
	Undefined listBegin(Number list);
	Undefined listFinish();
}

singleton class System
{
	Number availableMemory();
}

singleton class Audio
{
	Boolean init(Number freq = 44100, Boolean stereo = true);
	Boolean shutdown();
}

class MP3
{
	MP3();
	
	Boolean load(String fn);
	Boolean play();
	Boolean stop();
}

class OGG
{
	OGG();
	
	Boolean load(String fn);
	Boolean play();
	Boolean stop();
}

class WAV
{
	WAV();
	
	Boolean load(String fn);
	Boolean play(Number chan = -1); // between 2 and 63. -1 means next available channel
	Boolean stop(Number chan = -1); // If -1 specified. Will stop play on lasst channel used
	static Boolean stopAll();
}


singleton class FileSystem
{
	Boolean resetCD();
}

class File
{
	File();
	
	Boolean open(String fn, String mode);
	Undefined close();
	
	Boolean seek(Number offset, Number origin);
	Number tell();
	
	Number ReadInt8();
	Number ReadInt16();
	Number ReadInt32();
	Boolean WriteInt8(Number n);
	Boolean WriteInt16(Number n);
	Boolean WriteInt32(Number n);
	String ReadString();
	Boolean WriteString(String str);
	String ReadChar();
	
	static String ReadContents(String fn);
}
It's far from complete. I need some functionality for VMU at least. I'm thinking about re-writing the menus and other functionality of NesterDC SE using DreamScript. Maybe I won't because I do want to finish that soon.

That covers it for now. I welcome any input.
Image
abydos1000
DCEmu Super Poster
DCEmu Super Poster
Posts: 1237
Joined: Tue May 25, 2004 3:09 pm
Location: Here
Has thanked: 0
Been thanked: 0

Post by abydos1000 »

That's great news, and a really good idea (though I was really looking forward to Dream Season...hehehe).

I would like to see this crossplatform someday. Should be possible. Apple pretty much ported much of Konquerer over to OS X with their Safari Web Browser without needing KDE or qt for that manner. (though I don't know if they stuck with Konquerer's Javascript engine or are using their own). I'll probably get other forms of fruit thrown at me, but I don't plan on going Windows as a main OS anytime soon, and from what little I can tell, setting up a DC dev system on a Mac isn't trivial despite it being esentially another UNIX OS.
Strapping Scherzo
DC Developer
DC Developer
Posts: 2285
Joined: Fri Feb 21, 2003 7:37 am
Location: Chicago, IL
Has thanked: 0
Been thanked: 1 time
Contact:

Post by Strapping Scherzo »

Actually, the version of KJS that I obtained came from Apple's open source site. So, yes, they stuck with KJS for OS X.

My first attempt was with SpiderMonkey, the JS engine for Mozilla, which I've had success with in the past in Windows projects. It was a headache to port and seemed to crash for no reasons that I was willing to figure out. So I gave KJS a try and it worked right off the bat... pretty much.
Image
typoEDR
Insane DCEmu
Insane DCEmu
Posts: 117
Joined: Tue Dec 16, 2003 1:46 pm
Has thanked: 0
Been thanked: 0

Post by typoEDR »

Very... very... very... interesting. Could prove to be very, very useful.

There. There's my supply of the word "very" for the day.
Midgey34
Insane DCEmu
Insane DCEmu
Posts: 261
Joined: Sat Feb 08, 2003 1:02 pm
Has thanked: 0
Been thanked: 0

Post by Midgey34 »

Wow thats an awesome idea, very nice way to open the floodgates for even more great homebrew projects. And whats better I now have a new reason to try to learn java. :D Good luck on this and your other current projects.
Remember, the quickest way to a girl's bed is through her parents. Have sex with them and you're in.
Strapping Scherzo
DC Developer
DC Developer
Posts: 2285
Joined: Fri Feb 21, 2003 7:37 am
Location: Chicago, IL
Has thanked: 0
Been thanked: 1 time
Contact:

Post by Strapping Scherzo »

Midgey34 wrote:Wow thats an awesome idea, very nice way to open the floodgates for even more great homebrew projects. And whats better I now have a new reason to try to learn java. :D Good luck on this and your other current projects.
Thanks, but I just want to point out that Java and JavaScript are very different.
Image
User avatar
Ender
DCEmu Super Poster
DCEmu Super Poster
Posts: 1314
Joined: Mon Dec 10, 2001 4:01 pm
Location: Canada, first igloo on your left.
Has thanked: 0
Been thanked: 0
Contact:

Post by Ender »

Why not php? ;)
Image
Strapping Scherzo
DC Developer
DC Developer
Posts: 2285
Joined: Fri Feb 21, 2003 7:37 am
Location: Chicago, IL
Has thanked: 0
Been thanked: 1 time
Contact:

Post by Strapping Scherzo »

I won't argue that PHP is the best there is right now in fast and affordable server side scripting. I suppose I could have looked into PHP but I just dig JavaScript. One reason, although superficial, is that I don't like writing dollar signs before my variables. But you certainly have me thinking though. From what I understand, the PHP interpreter is quite fast. I might go peaking around the PHP source in the next few days. I wonder how easily I can get just the interpreter without the core library functions.
Image
Ian Micheal
Soul Sold for DCEmu
Soul Sold for DCEmu
Posts: 4865
Joined: Fri Jul 11, 2003 9:56 pm
Has thanked: 2 times
Been thanked: 4 times

Post by Ian Micheal »

Nice i really like JS as well. I could do some games in that much easyer. I think it's a great idea. :D
Dreamcast forever!!!
User avatar
emptythought
DC Developer
DC Developer
Posts: 2015
Joined: Wed Jan 30, 2002 9:14 am
Location: UNITED STATES NRN
Has thanked: 0
Been thanked: 0
Contact:

Post by emptythought »

You get this JavaScript project out, I'll definatly try and release something.
BlackAura
DC Developer
DC Developer
Posts: 9951
Joined: Sun Dec 30, 2001 9:02 am
Has thanked: 0
Been thanked: 1 time

Post by BlackAura »

It's kinda scary looking over your class definitions here. They're very similar the ones I'm using for a BASIC interpreter, except mine have some additional functionality, and some things that aren't in classes. That's two project we're each working on where we seem to have had nearly the exact same ideas.

The only thing really holding mine back is that I was trying to get it working on a PC using OpenGL, which is turning out to be pretty difficult to do. It makes a lot of Dreamcast-specific assumptions, so converting that to OpenGL is pretty difficult to do.

The BASIC interpreter I'm using certainly isn't fast enough to do a decent 3D game, so I'm just not going to do it. There are probably better ways to do a 3D game anyway - instead of having a scripting language driving everything, you have the main game engine calling the scripting engine when it wants to do something.
weeperofsouls
DCEmu Nutter
DCEmu Nutter
Posts: 911
Joined: Tue Jul 06, 2004 3:35 am
Has thanked: 0
Been thanked: 0
Contact:

Post by weeperofsouls »

hm, i think metafox once said a long time ago that he was working on something like this. i wonder whatever became of it...
User avatar
emptythought
DC Developer
DC Developer
Posts: 2015
Joined: Wed Jan 30, 2002 9:14 am
Location: UNITED STATES NRN
Has thanked: 0
Been thanked: 0
Contact:

Post by emptythought »

Not too long ago, he gave a status of all of his projects that he's announced. He's still working on it. I think the topic was over at ConsoleVision if you don't mind searching for the topic on the forums over there.

BlackAura - What's the reasoning for converting it to OpenGL? What would be another option to do if you were not trying to use OpenGL?
BlackAura
DC Developer
DC Developer
Posts: 9951
Joined: Sun Dec 30, 2001 9:02 am
Has thanked: 0
Been thanked: 1 time

Post by BlackAura »

BlackAura - What's the reasoning for converting it to OpenGL? What would be another option to do if you were not trying to use OpenGL?
To get it to run on a PC, not just a Dreamcast. On the Dreamcast, I'm not using OpenGL anyway.
User avatar
emptythought
DC Developer
DC Developer
Posts: 2015
Joined: Wed Jan 30, 2002 9:14 am
Location: UNITED STATES NRN
Has thanked: 0
Been thanked: 0
Contact:

Post by emptythought »

BlackAura wrote:
BlackAura - What's the reasoning for converting it to OpenGL? What would be another option to do if you were not trying to use OpenGL?
To get it to run on a PC, not just a Dreamcast. On the Dreamcast, I'm not using OpenGL anyway.
Ah, I see. So if you make a game, you can play it on the Dreamcast and PC? Seems to be a bit more complicated than I initially thought.

If you didn't bother with getting it to work on to PC along with playing on the DC, is it possible to create a working game? I'm just curious on how far you've gotten with it. :wink:
BlackAura
DC Developer
DC Developer
Posts: 9951
Joined: Sun Dec 30, 2001 9:02 am
Has thanked: 0
Been thanked: 1 time

Post by BlackAura »

Well, developing stuff only on the Dreamcast would be really difficult. There's no editor or anything, and that's what the PC version was for. Having to burn a CD every time you want to test something, or even check that the code is valid, would get really, really tedious, especially considering the complete lack of any kind of useful debugging information from the Dreamcast. If something goes wrong, it just crashes.

As for actually developing games with it... you could, if I hadn't ripped out most of the graphics code. It was actually quite trivial to implement, but it was far too difficult to do an OpenGL version, so I dropped it.
speud
DCEmu Uncool Newbie
DCEmu Uncool Newbie
Posts: 1459
Joined: Sat Dec 27, 2003 10:40 pm
Has thanked: 0
Been thanked: 0
Contact:

Post by speud »

that sound like a great project, i like js too so this could be interesting to use, good luck !
Ender wrote:Why not php?
thats what i was thinking, plus the GD functions would make 2d games very easy to do.
http://blueswirl.fr.st - DC Online Tools and Downloads

thx to Wack0 for the avatar ;)
User avatar
emptythought
DC Developer
DC Developer
Posts: 2015
Joined: Wed Jan 30, 2002 9:14 am
Location: UNITED STATES NRN
Has thanked: 0
Been thanked: 0
Contact:

Post by emptythought »

Yeah, that makes a lot of sense. Thanks for the insight, and I wish you and scherzo the best of luck with your projects.
Strapping Scherzo
DC Developer
DC Developer
Posts: 2285
Joined: Fri Feb 21, 2003 7:37 am
Location: Chicago, IL
Has thanked: 0
Been thanked: 1 time
Contact:

Post by Strapping Scherzo »

Hey, that's cool, BlackAura. I definitely anticipate similar problems with creating the PC version DreamScript. OpenGL seems to be the only choice if I want to leave the possibility of 3D in the future.

I know what you mean about the Dreamcast specific assumptions. Like the different list types (PVR_LIST_OP_POLY, etc). I'm thinking maybe I should change the API so the user doesn't have to worry about that. I could just queue up all the different images the user intended to draw, and then when he calls frameFinish(), make sure that they're submitted inside of the correct lists. After I got rid of that, I think my API looks pretty generic and could be implemented just about anywhere.

There's also the issue of the VMU or just plain saving in general; a way to deal with the different ways a DC and PC (and possibly other systems) save game information. I think what I'll do is chroot the filesystem that is visible to the script. On the DC, that means that paths will be relative to "/cd/gamename" and "/vmu/a0". When a user opens a file for reading, it'll first look on the VMU and then in the game's directory on the CD. When a user opens a file for writing, DreamScript will do so automatically in the VMU. This effectively merges the two together and makes it behave like a PC file system.

Anyways, I should begin to write the PC version and get it to where the DC version is instead of doing the whole thing all at once.

It's cool that you guys will be willing to give it a shot when it's ready. On initial release, I want to make several tutorial projects and demos. Maybe some of you would be willing to help out with some of them?
Image
BlackAura
DC Developer
DC Developer
Posts: 9951
Joined: Sun Dec 30, 2001 9:02 am
Has thanked: 0
Been thanked: 1 time

Post by BlackAura »

I know what you mean about the Dreamcast specific assumptions. Like the different list types (PVR_LIST_OP_POLY, etc). I'm thinking maybe I should change the API so the user doesn't have to worry about that. I could just queue up all the different images the user intended to draw, and then when he calls frameFinish(), make sure that they're submitted inside of the correct lists.
That's what I'm trying to do. On the Dreamcast, it starts off in the OP list, and anything that's opaque is drawn immediately. Anything that's supposed to be in the TR or PT display list is stored elsewhere. Then, at the end of the frame, it submits all the stuff in the right order. KOS can actually handle all that for you, so it takes virtually zero additional code.

On OpenGL, I don't worry about different display lists as such, but I do separate opaque polygons from translucent ones. All drawing occurs at the end of the frame, starting with all opaque polygons in any order, and then all translucent polygons (with blending enabled) sorted by depth. Not very efficient, but a typical PC is several times faster than a DC, and the graphics hardware is similarly quick, so I don't think it'll matter too much.

Additionally, I'm going to have the ability to let the engine handle much of it for you. After you load an image, you could draw it to the screen manually, or you can create a sprite object. Sprite objects are automatically drawn at the end of each frame, and you can scale/rotate/move them around the screen fairly easily. Should be easier to use, because you won't have to re-draw everything on each frame.

On top of that, I'm probably going to implement some kind of animation. So, you can load an animation from a file, and it'll load a series of images, and then some information on how to composite those images to form each frame of animation. You can then tell a sprite object to use an animation instead of a static image, and animate the sprite by changing the frame numbers. That needs an editor though, because doing that kind of thing manually is fairly difficult.
There's also the issue of the VMU or just plain saving in general; a way to deal with the different ways a DC and PC (and possibly other systems) save game information.
What I did is port the entire KOS VFS module over to the PC, which was suprisingly easy to do. For all file access, I use fs_???? instead of the standard open or fopen calls. Then I have a filesystem connected to /cd which contains the current directory, the ROM and RAM disk modules, and (although I haven't written one yet) I could put something into /vmu.

However, I think the easiest way to actually handle saving would be to forget about going through the filesystem. Let the program build a save game file in /ram somewhere, and then have a function to copy it over to the VMU. This function compresses it using zlib, then adds a VMU header, and stores it on the VMU. Then you have another few functions to load it back.
It's cool that you guys will be willing to give it a shot when it's ready. On initial release, I want to make several tutorial projects and demos. Maybe some of you would be willing to help out with some of them?
Same goes for me...
Post Reply