Open Ruby Game Scripting System

[fugibo]

Open Ruby Game Scripting System (or ORGSS) is a specification I am currently working on in my spare time that intends to be 100% compatible with RGSS 1.02e, with the exception of Win32API, with several API modifications to extend the system's capabilities.

Any suggestions, recommendations, or corrections are very welcome.

Current progress (parity with RGSS 1.02e has not yet been achieved; however, I intend to synchrnosize this with work on RGame, a Mac implementation of RGSS 1.02e I am also working on in my spare time):

Terms

Terms: ShowHide

• "Library:" "Library," when used in an ORGSS context, refers to the underlying implementation of ORGSS. For example, RGSS102E.dll forms the "library" for RGSS 1.02e.

Graphics Module
The Graphics module is used to control framerate and display settings.

Methods: ShowHide

• Graphics.fullscreen?: Returns true if the library currently displays in fullscreen mode, false otherwise.


• Graphics.fullscreen=(argument): Sets the current fullscreen state to the single argument. If the argument evaluates to true, the library will begin displaying in fullscreen mode, if possible. Returns the current fullscreen state in a fashion equivalent to Graphics.fullscreen?.


• Graphics.update: Commands the library to update the display, rendering all sprites and viewports. A call to this method will also block Ruby-side execution in an effort to throttle the frame rate.

Input Module
The Input module is used to gather keyboard input data.

Methods: ShowHide

• Input.update: Updates the current Input state, replacing the Input data with new information gathered since the last call.


• Input.trigger?(...): Takes one or more arguments, all of which should be strings. If at least one character from any of the strings corresponds to a key has been pressed down between the last call to Input.update and the one preceding it, returns true; otherwise, false.


• Input.release?(...): Similar to Input.trigger?; takes one or more arguments, all of which should be strings. If at least one character from any of the strings corresponds to a key that has been released between the last call to Input.update and the one preceding it, returns true; otherwise, false.


• Input.press?(...): Similar to Input.trigger? and Input.press?; takes one or more arguments, all of which should be strings. If at least one character from any of the strings corresponds to a key that is currently pressed, returns true; otherwise, false.

Audio Module
The Audio module is used to play audio files.

Methods: ShowHide

• Audio.play_bgm(name, volume, pitch): Attempts to load and play the BGM file corresponding with name at a volume volume and pitch pitch.


• Audio.stop_bgm: Stops playing the current BGM, if any.


• Audio.play_bgs(name, volume, pitch): Attempts to load and play the BGS file corresponding with name at a volume volume and pitch pitch.


• Audio.play_me(name, volume, pitch): Attempts to load and play the ME file corresponding with name at a volume volume and pitch pitch.


• Audio.play_se(name, volume, pitch): Attempts to load and play the SE file corresponding with name at a volume volume and pitch pitch.


• Audio.stop_se: Stops playing the current SE, if any.

[Blizzard]

Using strings as comparison arguments? That's... a really bad idea. You just don't do that. That's like... a beginner's mistake. :/ Enumerated constants are the way to go. The only way where pure strings should be used as an actual part of a system is when you have some kind of object manager and you want to have access to specific objects by using the object name. That makes sense. Everything else makes it so easy to make a mistake and cause bug-hunting of hours. :/

[fugibo]

Using strings as comparison arguments? That's... a really bad idea. You just don't do that. That's like... a beginner's mistake. :/ Enumerated constants are the way to go. The only way where pure strings should be used as an actual part of a system is when you have some kind of object manager and you want to have access to specific objects by using the object name. That makes sense. Everything else makes it so easy to make a mistake and cause bug-hunting of hours. :/

How so?

The current implementation in RGame is:

VALUE RGC_Input_trigger ( int argc, VALUE *args, VALUE self ) {
	int l;
	char *p;
	char c;
	
	while ( argc-- ) {
		l = RSTRING(args[argc])->len;
		p = RSTRING(args[argc])->ptr;
		
		while ( l-- ) {
			c = p[l];
			
			if ( RGC_Keyboard_state_n[c] && RGC_Keyboard_state_l[c] ) {
				return Qtrue;
			}
		}
	}
	
	return Qfalse;
}

Note that it's been forever since I thought about this, I basically jotted that down as my "ideal" API back when I was still an active scripter. I'd obviously use constants for non-typable characters, though (i.e. shift/tab/arrow keys/&c.).

[Blizzard]

You should try to use constants wherever you can. Obviously that's a bit hard if you have letter buttons. So yeah.
Looks good so far. :3

[fugibo]

You should try to use constants wherever you can. Obviously that's a bit hard if you have letter buttons. So yeah.
Looks good so far. :3

Thanks. I plan on flushing out Input/Audio and then heading straight for RPG, since the rest of Graphics will take forever (I haven't decided how to implement Bitmap yet [I'm leaning towards pbuffers, but that'd suck VRAM like crazy] and viewports/&c. would require tons of sorting code, which I've never done before, so I'd have to learn).

[Blizzard]

You could use quads with 4 vertices. :3

[fugibo]

You could use quads with 4 vertices. :3

I'm already doing that for sprites; the thing is, using plain textures for the bitmaps would mean that I'd have to shuffle the bitmap data back and forth each time it would need to be edited. Hence why I'm looking into pbuffers; editable textures.

[Blizzard]

Right, spriters, not bitmaps.
You have to use VRAM here either way.

[fugibo]

I'm adding RGame (now OpenRGSS, since RGame is already taken) to Google Code. Right now I've only pushed the "core," which only links against Ruby and can be used with any frontend; in the init function it takes lists (in the form of structs) of function pointers that implement platform-specific functions. I'll be adding the Mac frontend and starting an SDL one soon.

http://openrgss.googlecode.com/

EDIT:
A working core is uploaded, along with an Xcode project file and the beginnings of a Mac frontend. I might be going on a tech hiatus soon, but if I don't I'll have SDL started ASAP. If you can, please review my code. This is the first real project I've released, so the code might be absolutely horrid. Tear me to shreds if it is.

[Ryex]

so RGame is for Mac?

[fugibo]

so RGame is for Mac?

At the moment, it's the only version there is. I'll be making an SDL version soon, though, which should compile on Linux and Windows as well.

EDIT: Huh, SDL 1.2.14 isn't building for me. Odd. This _might_ indicate a setback, but I've also got Kubuntu and Windows installs available, so I guess I'll just use those for SDL development instead.

[Fantasist]

This might be a n00b question, but why not use OpenGL? Unless I'm wrong SDL doesn't support hardware acceleration. It might not be as cross-platform compatible as SDL, but it's still better than DirectX anyway.

[Blizzard]

You could use APRIL with ATRES and... shit, I forgot the name of the GUI system. I think Kreso put them up on friday.

[fugibo]

This might be a n00b question, but why not use OpenGL? Unless I'm wrong SDL doesn't support hardware acceleration. It might not be as cross-platform compatible as SDL, but it's still better than DirectX anyway.

SDL supports using OpenGL under the hood, which basically leaves the SDL as an input/audio/windowing library.

[Fantasist]

SDL supports using OpenGL under the hood, which basically leaves the SDL as an input/audio/windowing library.

Oh, thanks for clearing that up >.<