A replacement for Danmakufu?

[Ragnikarth]

If you're still open to suggestions...

Replaceable Everything. Font, lifebar texture, graze SFX, every little thing for the complete Custom Game experience.

[Prime 2.0]

Adjustable playfield size would be neat. You know, so you could make a PC-98-ish stage or something.

Also, customizeable keys. I don't mean making the script allow you to use more keys than C for custom stuff, I mean allowing the user to change what key does what... so I could make S focus, D fire, and F bomb if it were my inclination... or any custom trigger that a scripter would set up, for that matter.

This is important because of anti-ghosting on keyboards. I have used keyboards that do not let you use the arrow keys with shift and z before, and the keyboard I use right now doesn't let me focus, fire, and hold C while moving around. This is not something that anyone should ever have to put up with, and you have the opportunity to make a workaround in this new program. So please, add some customizable keys.

[Nuclear Cheese]

What characters are sprites needed of? 

Presumably, generic Reimu and Marisa ...

For playables, yes.  We'll probably want to script up some default player scripts like the normal Reimu/Marisa A/B styles.

We probably should also pick a character or two for some sample scripts, much like Danmakufu does with ExRumia.

If you're still open to suggestions...

Replaceable Everything. Font, lifebar texture, graze SFX, every little thing for the complete Custom Game experience.

The general idea was to have about as much customizability as possible (within reasonable bounds, at least).

Adjustable playfield size would be neat. You know, so you could make a PC-98-ish stage or something.

This has been discussed previously, and while it isn't a priority feature, it would not be difficult to add in at some point.

Also, customizeable keys. I don't mean making the script allow you to use more keys than C for custom stuff, I mean allowing the user to change what key does what... so I could make S focus, D fire, and F bomb if it were my inclination... or any custom trigger that a scripter would set up, for that matter.

This is important because of anti-ghosting on keyboards. I have used keyboards that do not let you use the arrow keys with shift and z before, and the keyboard I use right now doesn't let me focus, fire, and hold C while moving around. This is not something that anyone should ever have to put up with, and you have the opportunity to make a workaround in this new program. So please, add some customizable keys.

I might not have made it clear previously, but my plan from the get-go was to have the controls be fully customizable, including on the keyboard.  While the controls are currently fixed, the framework is already in the code for customizing the controls.  I just need to actually add said configuration ability.

[Lishy1]

I would happily draw an ExWriggle and ExUtsuho if you'd like  :V

[Chronojet ⚙ Dragon]

Reminds me, make it so that you can set between PC-98 style dialogue and Windows.

[Dizzy H. "Muffin" Muffin]

Make it EX-Cirno. :3

[Nuclear Cheese]

Reminds me, make it so that you can set between PC-98 style dialogue and Windows.

If you can provide examples of PC-98 style dialogue boxes, I'm sure they can be accomodated.  I haven't played the PC-98 games much/at all, so I'm not sure of the visual difference at the moment ...



Some progress tonight:

• mdScript
  
  • Added the Player_Shot base type
  • I figured out why count = count-1; explodes, but count = count - 1; doesn't.  ANTLR is getting confused, and is trying to parse the former by setting "-1" as a negative one, instead of a subtraction.
    I'm not yet sure how I'll fix this ... we'll see.
• The actual program
  
  • Fixed the "." vs "," thing.  "." won. :V
  • Fixed an issue with loading non-power-of-2 textures, which I just randomly stumbled upon while working on other things.
  • Added a default Player_Shot object type - BasicPlayerShot
  • Added some new commands:
    
    • SetLife(life)
    • GetLife()
    • FirePlayerShot01(x, y, angle, speed, image, damage)

I modified the test/sample scripts so that the boss has 100 life, and dissapears when it hits zero (right now the boss checks this manually; automatic code/script for this will be added later, of course).
The player was modified to automatically shoot a five-way spread of shots every 10 frames, each shot doing 0.8 damage.  Once scripts can read input, this will be triggered off of input rather than just being stuck on auto-fire.


I also grabbed Always お⑨'s point item graphic - since you posted it here I'm guessing it's okay, but do you mind me including it in the releases?

[Naut]

Ahh, angle before speed paramters, oh this will haunt me. Also, no penetration on the player bullet type (how many times the bullet can score a hit on the enemy before deleting itself)? Or can we expect more than one player shot function, unlike Danmakufu?

[Nuclear Cheese]

Ahh, angle before speed paramters, oh this will haunt me.

Just like everything else, this is adjustable if people want.  Opinions?

Also, no penetration on the player bullet type (how many times the bullet can score a hit on the enemy before deleting itself)? Or can we expect more than one player shot function, unlike Danmakufu?

Failing any implementation of a hard-coded parameter of such, you could always create a custom Player_Shot object type which has this behavior.

Such a thing should be perfectly possible right now even, but you'll need to use mdBase since there's no mdScript function for "damage the enemy" yet.

[Dizzy H. "Muffin" Muffin]

Oh yeah -- after fooling around with SimSynth a bit, I have managed to produce an SFX which is almost, but not quite, enturely unlike the Touhou death SFX.

[Chronojet ⚙ Dragon]

Snapshotted Mima VS Sara (I'm not too familiar with PC-98 characters).

[Prime 2.0]

Snapshotted Mima VS Sara (I'm not too familiar with PC-98 characters).

This screenshot doesn't show that each text box can hold up to 3 separate lines(in Mystic Square, at least)... In addition, the dialogue will sometimes appear letter by letter(usually the first messages appear in this fashion, though the original "both characters say something at the same time before the fight starts" line was also presented this way).

The text boxes varied by game in the PC-98 series, so here are videos of each:

Story of Eastern Wonderland (Touhou 2)
Lotus Land Story (Touhou 4)
Mystic Square (Touhou 5)

There is even some variation among the windows games, most notably in the appearance of the text box, and how the portraits are handled. While I think it would be a good idea to have some presets(SoEW, LLS/MS, EoSD/PCB, IN, MoF/SA/UFO), I think it would be best to allow for the customization of how the dialogue happens, so you could create an entirely new cutscene appearance...and to be able to switch to an image of the textbox instead of the textbox itself for any given line, sorta like what was done in SA Phantasm.


Speaking of dialogue, one thing I noticed with Danmakufu is that there are no dialogue cut-ins for the regular characters, and that in order to have a player cut-in for the dialogue, you have to have ones included in the script.

I think that's stupid. I figure that each character should be able to have a standard set of portraits... for the standard emotes, and a small set of SoEW box portraits. In a given script that has dialogue, the script would first check which character you are using(by looking for a character ID within that character's script file, so you could have a custom Marisa that uses Marisa's dialogue, or a script that has dialogue for an entirely different character), and then would grab the appropriate portrait for each line of dialogue from that character.

And of course, you could insert portraits the old way, too.


I'd like to put forward that, like in Danmakufu, you should be able to replace all of the default sounds and graphics if it is your inclination to do so. Though, for the default players, I think there should be some more frames of animation there to replace, lol.


One last thing for now: I want a way to organize my scripts beyond the single-plural-stage designation. I currently have a separate scripts folder for the stuff from the Halloween contest because that stuff would horribly clutter all my other scripts. I currently switch between them by renaming the folders, but if there was an in-game way to switch between them, that would be sweet.

[Suikama]

Oh yeah -- after fooling around with SimSynth a bit, I have managed to produce an SFX which is almost, but not quite, enturely unlike the Touhou death SFX.

Ehh that's more of a 'peewwww' than 'spoooon'

[Furu]

I found another bug that if you run if (1==1 && 0==1 && 2==2) the statement will return true and if you run if (0==1 || 1==1 || 0==2) the statement will return false. The same applies to if (1==1 && 0==1 && 0==2 && 2==2) and so on. A workaround at this moment is to write if (a==1 && (b==1 && c==1)) instead.

Oh, and did you implement the infinite loop protection? Cause it didn't work when I tested it.

After making a script I found that one thing I really miss is arguments for object shots. Other than that Musuu is really good even if it's far from complete. Keep up the good work.

One last thing for now: I want a way to organize my scripts beyond the single-plural-stage designation. I currently have a separate scripts folder for the stuff from the Halloween contest because that stuff would horribly clutter all my other scripts. I currently switch between them by renaming the folders, but if there was an in-game way to switch between them, that would be sweet.

That is one of the things I don't like with Danmakufu, having to many scripts so you can barely find anything. I suggest to only have two menu options for running scripts, Games and Develop. Games would only contain complete projects from others with only one option in the menu instead of one for each difficulty and spellcard. Game-scripts would then be used for showing name, picture and comments in the menu as well as other things. Develop would be used to test scripts. Debug options like invincibility would only be available here. This plus a way to sort your scripts would be awesome.


Another thing is that I think it's best to have character selection within the games' own menu, preferred being able to make your own or at least have your own background.

[Dizzy H. "Muffin" Muffin]

Ehh that's more of a 'peewwww' than 'spoooon'

Yeah, hence the "almost, but not quite, entirely unlike" ...

[Suikama]

Yeah, hence the "almost, but not quite, entirely unlike" ...

How... vague :V

[8lue Wizard]

Speaking of dialogue, one thing I noticed with Danmakufu is that there are no dialogue cut-ins for the regular characters, and that in order to have a player cut-in for the dialogue, you have to have ones included in the script.

I think that's stupid. I figure that each character should be able to have a standard set of portraits... for the standard emotes, and a small set of SoEW box portraits. In a given script that has dialogue, the script would first check which character you are using(by looking for a character ID within that character's script file, so you could have a custom Marisa that uses Marisa's dialogue, or a script that has dialogue for an entirely different character), and then would grab the appropriate portrait for each line of dialogue from that character.

I approve of this idea. There should definitely be some sort of communal area and naming conventions for dialog portraits. We could even have some default function(s) for "Get me X portrait of Y character", where if X port doesn't exist, it goes to the default port for that character, and if Y char has no ports, it goes to a generic silhouette portrait.

However, I don't think we should spend any great effort creating or maintaining a comprehensive library for distribution with the main package. If certain individuals would like to do so as a separate package, as with the Expanded Shot Data add-ons for DMF, that's their business, but I feel that it would be outside the scope of this project.

[Nuclear Cheese]

This screenshot doesn't show that each text box can hold up to 3 separate lines(in Mystic Square, at least)... In addition, the dialogue will sometimes appear letter by letter(usually the first messages appear in this fashion, though the original "both characters say something at the same time before the fight starts" line was also presented this way).

The text boxes varied by game in the PC-98 series, so here are videos of each:

Story of Eastern Wonderland (Touhou 2)
Lotus Land Story (Touhou 4)
Mystic Square (Touhou 5)

There is even some variation among the windows games, most notably in the appearance of the text box, and how the portraits are handled. While I think it would be a good idea to have some presets(SoEW, LLS/MS, EoSD/PCB, IN, MoF/SA/UFO), I think it would be best to allow for the customization of how the dialogue happens, so you could create an entirely new cutscene appearance...and to be able to switch to an image of the textbox instead of the textbox itself for any given line, sorta like what was done in SA Phantasm.

Oh fun.  Sounds like we have some work to do.

Speaking of dialogue, one thing I noticed with Danmakufu is that there are no dialogue cut-ins for the regular characters, and that in order to have a player cut-in for the dialogue, you have to have ones included in the script.

I think that's stupid. I figure that each character should be able to have a standard set of portraits... for the standard emotes, and a small set of SoEW box portraits. In a given script that has dialogue, the script would first check which character you are using(by looking for a character ID within that character's script file, so you could have a custom Marisa that uses Marisa's dialogue, or a script that has dialogue for an entirely different character), and then would grab the appropriate portrait for each line of dialogue from that character.

And of course, you could insert portraits the old way, too.

I approve of this idea. There should definitely be some sort of communal area and naming conventions for dialog portraits. We could even have some default function(s) for "Get me X portrait of Y character", where if X port doesn't exist, it goes to the default port for that character, and if Y char has no ports, it goes to a generic silhouette portrait.

However, I don't think we should spend any great effort creating or maintaining a comprehensive library for distribution with the main package. If certain individuals would like to do so as a separate package, as with the Expanded Shot Data add-ons for DMF, that's their business, but I feel that it would be outside the scope of this project.

Having default cut-ins for the provided characters is definitely a good idea.  I like Blue Wolf's idea of having a function that can get said cut-in graphics automatically, although we should still allow a function to set it to whatever specific graphic you want.

I'd like to put forward that, like in Danmakufu, you should be able to replace all of the default sounds and graphics if it is your inclination to do so. Though, for the default players, I think there should be some more frames of animation there to replace, lol.

I agree about things being replacable like you describe.

As far as the "frames of animation" comment ... is that something with Danmakufu's default players?

One last thing for now: I want a way to organize my scripts beyond the single-plural-stage designation. I currently have a separate scripts folder for the stuff from the Halloween contest because that stuff would horribly clutter all my other scripts. I currently switch between them by renaming the folders, but if there was an in-game way to switch between them, that would be sweet.

That is one of the things I don't like with Danmakufu, having to many scripts so you can barely find anything. I suggest to only have two menu options for running scripts, Games and Develop. Games would only contain complete projects from others with only one option in the menu instead of one for each difficulty and spellcard. Game-scripts would then be used for showing name, picture and comments in the menu as well as other things. Develop would be used to test scripts. Debug options like invincibility would only be available here. This plus a way to sort your scripts would be awesome.

... are you guys using the "Directory" option in Danmakufu's menu?  This lets you browse the scripts folder by directory, and I've found it quite easy to deal with organizing scripts using this otpion.  You just need to set up your organization once, and then browse it as you see fit.  For instance, you could organize things like this:

• script
  
  • wip
    
    • omg secret project
    • ntsd next version
  • completed
    
    • pyro reimu
    • ntsd current version
  • other people - single scripts
    
    • Suikama (stolen scripts)
      
      • ntsb
    • Naut
      
      • GFS
  • other people - full games
    
    • PoSR

... and when you select "Directory", you get a simple list of wip, completed, other people - single scripts, and other people - full games.  Select one and you get the next level of stuff.  Really simple, if you ask me.

I was going to use this as the default browsing method for Musuu, but if anyone has any better suggestions I'm open to ideas.

I found another bug that if you run if (1==1 && 0==1 && 2==2) the statement will return true and if you run if (0==1 || 1==1 || 0==2) the statement will return false. The same applies to if (1==1 && 0==1 && 0==2 && 2==2) and so on. A workaround at this moment is to write if (a==1 && (b==1 && c==1)) instead.

Lovely. :V

I'll have to look into this as well.

EDIT: Could you please post the script you used to observe this?  I just did a quick test, and it looks like it's translating to the correct mdBase commands, at least ...

EDIT2: fixed.

Oh, and did you implement the infinite loop protection? Cause it didn't work when I tested it.

How did you test it?

Keep in mind it may take a while to come into effect - right now it take 100,000,000 mdBase commands for it to take effect (keep in mind that, depending on complexity, each mdScript command will be broken down into anywhere from 1 to several mdBase commands).
Also keep in mind that this is for each individual script.  You'll still break things by spawning an object in initialize, which in turn does the same, etc., because it'll keep running initialize scripts.

In summary, it's in place, but it isn't complete yet.

After making a script I found that one thing I really miss is arguments for object shots. Other than that Musuu is really good even if it's far from complete. Keep up the good work.

I'll make a note to add the option to pass an argument when creating a new object - that should cover this issue.

Another thing is that I think it's best to have character selection within the games' own menu, preferred being able to make your own or at least have your own background.

I think we were considering allowing this with game scripts.

[MCXD]

Also, may I add, that everyone asking for a PoFV engine should be ashamed.

STB engine is where it's at.

[Nuclear Cheese]

Also, may I add, that everyone asking for a PoFV engine should be ashamed.

STB engine is where it's at.

That would certainly be less of a deviation from the normal engine than PoFV-style, at least :V




Have some progress:

• mdScript
  
  • Fixed the issue Furu found with his equality stuff.
    Turns out the grammar wasn't properly handling consecutive same-level operations correctly (also was a problem with, for example, "1 + 2 - 3")
• The program
  
  • Input checking - use the new function GetKeyState
  • Constants
    
    • pi
    • key state values - key_left, key_right, key_up, key_down, key_shot, key_bomb, key_focus, key_skip
  • Added in a default enemy lifebar display (just a simple rectangle at the top of the screen)
  • Added POC code to the default item tick script.  POC is currently fixed at Y=100 (will be updated later to allow dynamic POC position)

Player script now only fires when the shot key is pressed.  Also, firing while focused now fires a tighter spread.

[arcanesign]

Yes! After a lot of tinkering I finally got Musuu to run in my 64-bit Linux machine. If somebody want to try it in Linux too, here is how I did it:

* Installed Mono runtime.
* Downloaded SDL 6.1.0 tar.gz and extracted everything in bin into Musuu's folder.
* Downloaded Tao framework 2.1.0 tar.gz and extracted Tao.Sdl.dll, Tao.Sdl.dll.config, Tao.OpenGL.dll and Tao.OpenGL.dll.config from the bin folder into Musuu's folder.

I got a few error in the command-line but they seem to have no effect on the application.

Code: [Select]

line 26:6 missing SEMICOLON at 'if'
line 31:6 missing SEMICOLON at 'count'
line 54:12 missing SEMICOLON at 'angle'
line 57:9 missing SEMICOLON at 'angle'
line 105:12 missing SEMICOLON at 'SetAngle'
line 107:6 missing SEMICOLON at '}'
line 108:3 missing SEMICOLON at '}'(I used the default scripts.)

Also I tried to run Musuu in my Virtual machine with Windows XP (this is where I run Danmakufu) but got the same error as PT8's second computer but that might be because my region also uses the comma as decimal point. (My Linux install is set to English)

(I have been following your project from start, just been to shy to join the forum.)

EDIT: I notified that the FPS sometimes goes over 60 (usually 62-63).

Using these instructions on 64-bit Ubuntu 9.04, it crashed. It showed a black window, then died after that.

Log:

Code: [Select]

Musuu no Danmaku version 0.1.3591.29235
Starting logging file ...
2009 Nov 07 22:22:21.566 - Initializing engine ...
2009 Nov 07 22:22:21.742 - Error during initialization: An exception was thrown by the type initializer for SdlDotNet.Graphics.Surface
Stack trace:
  at SdlDotNet.Graphics.Video.SetVideoMode (Int32 width, Int32 height, Int32 bitsPerPixel, Boolean resizable, Boolean openGL, Boolean fullScreen, Boolean hardwareSurface, Boolean frame) [0x00000]
  at SdlDotNet.Graphics.Video.SetVideoMode (Int32 width, Int32 height, Boolean resizable, Boolean openGL, Boolean fullScreen, Boolean hardwareSurface) [0x00000]
  at Musuu_no_Danmaku.Graphics.Initialize () [0x00000]
  at Musuu_no_Danmaku.Program.Main (System.String[] args) [0x00000]

The program will close now.
Maybe it's due to the fact that I'm running Compiz?

[Dizzy H. "Muffin" Muffin]

I had a crazy idea while I was riding my bike: functions for reading text-files. One of my many Brazillion ideas involves storing the dialogue in a separate text file to e.g. facilitate translation, if anyone wanted to do that.

[Chronojet ⚙ Dragon]

I had a crazy idea while I was riding my bike: functions for reading text-files. One of my many Brazillion ideas involves storing the dialogue in a separate text file to e.g. facilitate translation, if anyone wanted to do that.

We already got that down.

Store dialog (and other?) text in a separate file, to facilitate making translations

[Dizzy H. "Muffin" Muffin]

O rite. |3

Oh, right, I'd also brought that up because I was thinking of text-parsing functions (i.e. for putting "tags" on a given line of dialogue for whatever reason), then realized that most of that could be handled ingame.

[Furu]

How did you test it?

Keep in mind it may take a while to come into effect - right now it take 100,000,000 mdBase commands for it to take effect (keep in mind that, depending on complexity, each mdScript command will be broken down into anywhere from 1 to several mdBase commands).
Also keep in mind that this is for each individual script.  You'll still break things by spawning an object in initialize, which in turn does the same, etc., because it'll keep running initialize scripts.

In summary, it's in place, but it isn't complete yet.

That might explain it, I tested it with a while-loop that fired och shot each loop. Recently I did a new test with a while-loop that only was setting a variable. It took about 30 seconds before it quit, and my computer is not very old. Might consider reducing the number to something like 10,000,000? I highly doubt anyone needs more mdBase commands than that in a single frame.

Using these instructions on 64-bit Ubuntu 9.04, it crashed. It showed a black window, then died after that.

Log:

Code: [Select]

Musuu no Danmaku version 0.1.3591.29235
Starting logging file ...
2009 Nov 07 22:22:21.566 - Initializing engine ...
2009 Nov 07 22:22:21.742 - Error during initialization: An exception was thrown by the type initializer for SdlDotNet.Graphics.Surface
Stack trace:
  at SdlDotNet.Graphics.Video.SetVideoMode (Int32 width, Int32 height, Int32 bitsPerPixel, Boolean resizable, Boolean openGL, Boolean fullScreen, Boolean hardwareSurface, Boolean frame) [0x00000]
  at SdlDotNet.Graphics.Video.SetVideoMode (Int32 width, Int32 height, Boolean resizable, Boolean openGL, Boolean fullScreen, Boolean hardwareSurface) [0x00000]
  at Musuu_no_Danmaku.Graphics.Initialize () [0x00000]
  at Musuu_no_Danmaku.Program.Main (System.String[] args) [0x00000]

The program will close now.
Maybe it's due to the fact that I'm running Compiz?

I'm running 64-bit Ubuntu 9.10. When I was using Compiz I could run 3D games at the same time so I don't think that's the case. But I'm not running it nowdays so I can't be sure. Try to turn off Compiz temporary and see if it works.

[Nuclear Cheese]

Using these instructions on 64-bit Ubuntu 9.04, it crashed. It showed a black window, then died after that.

Log:

Code: [Select]

Musuu no Danmaku version 0.1.3591.29235
Starting logging file ...
2009 Nov 07 22:22:21.566 - Initializing engine ...
2009 Nov 07 22:22:21.742 - Error during initialization: An exception was thrown by the type initializer for SdlDotNet.Graphics.Surface
Stack trace:
  at SdlDotNet.Graphics.Video.SetVideoMode (Int32 width, Int32 height, Int32 bitsPerPixel, Boolean resizable, Boolean openGL, Boolean fullScreen, Boolean hardwareSurface, Boolean frame) [0x00000]
  at SdlDotNet.Graphics.Video.SetVideoMode (Int32 width, Int32 height, Boolean resizable, Boolean openGL, Boolean fullScreen, Boolean hardwareSurface) [0x00000]
  at Musuu_no_Danmaku.Graphics.Initialize () [0x00000]
  at Musuu_no_Danmaku.Program.Main (System.String[] args) [0x00000]

The program will close now.
Maybe it's due to the fact that I'm running Compiz?

It's crapping out during the graphics initialization, as the log indicates.  Not too familiar with the specifics of setting up this stuff on 'nix systems, so I'm not sure what it could be.

Perhaps Furu can help - he/she seems more in tune with this end of things.

I had a crazy idea while I was riding my bike: functions for reading text-files. One of my many Brazillion ideas involves storing the dialogue in a separate text file to e.g. facilitate translation, if anyone wanted to do that.

Muffin, I'd let this go, but, seriously:

Random idea: put things like dialogue etc. in a specific separate file, for the purposes of making it easier to translate the game into other languages.

: V

That might explain it, I tested it with a while-loop that fired och shot each loop. Recently I did a new test with a while-loop that only was setting a variable. It took about 30 seconds before it quit, and my computer is not very old. Might consider reducing the number to something like 10,000,000? I highly doubt anyone needs more mdBase commands than that in a single frame.

... as far as the final limit, it certainly can be adjusted.  It's mainly a tradeoff between how complex things can get in the script vs how long it takes for the program to drop the hammer on rouge scripts.

Also, I just remembered that the counter doesn't transfer for function calls (yet), so if you're calling lots of functions it'll actually take a lot more commands to bomb out currently.

[Azure Lazuline]

Maybe you could make it adjustable? Default to 10,000,000 like you planned, but add a command to raise it (or disable checking completely) for the chance that you might need a script to actually do that much.

[Nuclear Cheese]

Maybe you could make it adjustable? Default to 10,000,000 like you planned, but add a command to raise it (or disable checking completely) for the chance that you might need a script to actually do that much.

I thought about that.  Ultimately, it could be useful, but at the same time it could just be a hassle.

If it's script controlled, it would leave it open to jerks who want to annoy you (probably a minor issue, but m'eh).  If it's user-controlled, it might end up confusing some users.

Also, keep in mind that 10,000,000 even takes a couple seconds to chew through on most computers ... I dunno what the hell you'd be doing that takes that long to begin with.

But m'eh.  It's open to discussion, as usual.



No real big changes tonight (just a quick optimization or two), but ...

Testing Release 2

Includes all of the changes I said I've implemented since the last week's release, including (most importantly) the issue between "," and "." regional differences, and the ability to read inputs.

Also, last time I was an idiot and forgot to include license information for the libraries used.  They're included this time; hope I didn't screw anything up with that, 'cause I kinda rushed to piece that together moments ago. :V

[Prime 2.0]

*some research later* http://support.microsoft.com/kb/896456 aha!

This could be causing your trouble.  I would recommend looking for updated drivers for your graphics cards - of course, make sure you get 64bit drivers.
As for where to get those - that, of course, depends on your graphics card.

Good luck!

I updated my drivers, no luck. Also, test release 2 gives the "encountered a problem" message when I open it, and refuses to give a log.

[Nuclear Cheese]

I updated my drivers, no luck. Also, test release 2 gives the "encountered a problem" message when I open it, and refuses to give a log.

Dammit.  Forgot to reenable error catching.  I usually disable it so exceptions get thrown to the IDE.

Fixed archive uploaded ... same link as above.