enemy_boss_object_type "Stupid_Boss"
{
// typical counter variable
count = 60;
// holds the image file name for easier reference
graphic = "teh_boss.png"
Initialize
{
// Initialize necessary stuff
SetLife(100);
MoveTo(GetCenterX(), 100);
SetCollisionSize(24);
LoadGraphic(graphic);
}
Tick
{
count = count - 1;
if (count <= 0)
{
count = 30;
// Fire a blue shot at the player every 1/2 second
FireShot(GetX(), GetY(), GetAngleToPlayer(), 2.0, Shot_Type_1, Blue);
}
}
Draw
{
// Draw the boss
DrawGraphic(graphic, GetX(), GetY());
}
Finalize
{
// Create some point items for the player at the end
i = 0;
while (i < 10)
{
CreateItem(Point_Item, GetX() + rand(-50, 50), GetY() + rand(-20, 20));
i = i + 1;
}
}
}enemy_shot_object_type "Silly_Shot"
{
// Typical counter variable
count = 60;
// set to true once the bullet has stopped, so we won't keep stopping and restarting
let already_stopped = false;
Tick
{
count = count - 1;
if (count <= 0)
{
if (!already_stopped)
{
spd = GetSpeed();
if (spd > 0.1)
{
// We're still decelerating
SetSpeed(spd - 0.1);
}
else
{
// We've stopped.
SetSpeed(0);
already_stopped = true;
}
}
else if (GetSpeed() == 0)
{
// We've stopped, and haven't restarted yet. Turn towards the player.
ang_diff = GetAngleToPlayer() - GetAngle();
if (abs(ang_diff) < 0.1)
{
SetAngle(GetAngleToPlayer());
SetSpeed(2.5);
}
else if (ang_diff < 0)
{
SetAngle(GetAngle() + 0.1);
}
else
{
SetAngle(GetAngle() - 0.1);
}
}
}
}
}game "t3h hardest danmakuu evar lulz"
{
// allow selection of difficulty for the main game
Main_Game_Difficulty_Select(true);
// define images for the difficulty selections
Main_Game_Difficulty_Images("grade_school.png", "normal.png", "hard.png", "wtf.png");
// enable the extra game
Extra_Game(true);
// allow selection of difficulty for the extra game
Extra_Game_Difficulty_Select(true);
// define difficulties for the extra game, in increasing order
Extra_Game_Difficulty_List(["Extra", "Phantasm", "lulz", "OMEGA"]);
// define images for the difficulty selections in the extra game
Extra_Game_Difficulty_Images("extra.png", "yukari.png", "⑨.png", "Ω.png");
// enable the music room
Music_Room(true);
// list of music for the music room
music_files_list = ["01.ogg", "02.ogg", "03.ogg", "04.ogg", "etc.ogg"];
music_names_list = ["Menu - Stuff Go Boom", "Stage 1 - Your Face", "Stage 2 - WTF Is This Shit?!",
"Final Stage - ZOMGWTFBBQ", "Extra Stage - lulz", "Credits - You'll Never Hear This"];
Music_Room_Info(music_files_list, music_names_list);
// disable spellcard practice. Only n00bs use it anyways :V (Cheese: wait what?)
Spellcard_Practice(false);
// define the stages for the main game
main_game_scripts = ["stage1_script.txt", "stage2_script.txt", "stage3_script.txt"];
Main_Game_Scripts(main_game_scripts);
// define the stages for the extra game
Extra_Game_Scripts(["lulz.txt"]);
// use EoSD-style power-up mechanics
Power_Style(EOSD_Type);
// define the in-between stages results screen image
Mid_Game_Results_Screen("point_totals.png");
// define the main game post-game script
Main_Game_Ending("its_ovar.png");
// define menu background image
Menu_Background("lulz_title.png");
// define menu option images
Menu_Item_Images("new_game.png", "extra_game.png", "", // blank string for spellcard practice, since its disabled
"music.png", "highscores.png", "stage practice", "replay.png", "quit.png");
}If you go through with this I will*placeholder*make some music for your epic.
I think a big thing the engine needs is the capability to make a full game without having to hack in your own title screen and stage end screens through some obtuse method. Some sort of default title screen function where you can specify the path to the title screen image, paths to scripts you can run, maybe fonts for the text. Nothing too complicated, just enough to select player/difficulty inside the script, select the extra stage, maybe a music room. In-script replays would obviously be on the complicated side so no need to get into that just yet.
I can even see how Stuffman's suggestions can be brought into play. Like Danmakufu had different script types for enemies and bullet definitions and whatnot, you could define different script types for not only those, but outside-playing-field properties (and tasks such as the enemy marker), title screen/menus, etc. As such you wouldn't have to jumble the different code inside the same script.
By the way, if you manage to go through with this and you've got a Paypal account I will gladly make good on my offer of 20 bucks.
Maybe.
Making it easier to actually concatenate scripts into a game would probably be a crowning achievement, IMO, since Danmakufu requires so much indirect finagling to actually accomplish this. I'm not sure if anyone else would want this, though...
Not having to use Applocale to load it alone is a big improvement. Makes distribution much easier.
And if this actually went through, I think a title theme for Countless Barrages would be in order. =D
Another thing Danmakufu is missing. Graphic layer settings for objects.
and karfloozy hasn't been to cpmc recently (http://www.shrinemaiden.org/forum/index.php?topic=1950.msg82271#msg82271)lol, I haven't been to COMPUTER recently, let alone MotK... =\
Should this ever see a usable beta version, expect monies.
Also seriously? Separate files for every type of bullet in the game? I think you should make it so you can have multiple scripts inside one .txt, and import them into a spell script via some sort of #include, because there is no way in heck you can expect people to have 200 .txts lying around just for the bullets the bosses will be firing.Yeah, like the way you can have an enemy script within a boss script, to be used as a familiar. In fact, every type of "GetBlahFromFile" function ought to have a "GetBlahFromScript" counterpart, because if I want to use an enemy/bullet/whatever only once, why have it in a separate file?
Regarding the bullets using colours to create the type of colour bullet you want is a good idea, but it will require too much colorcalculating + scripting while looking at the bullet in a sheet and simply using it's ID is easier. What I would like to see is being able to load more than 255 IDs for a bullet.
I'm also not sure why you would want to do that RGB thing with bullets, it would be overly complex when you could just change the graphics.
Also perhaps even the possibility to load ShotData inside tasks ( multiple shotdata ). Like in the same script:
Task Barrage1{ loadshotdata(CtC style); CreateShot bla bla bla (make danmaku hell) }
Task Barrage2{ loadshotdata(User styles); CreateShot bla bla (fire fire!) }
Or is this already possible ( afaik , not )
-Issues with adding new shot data. There really shouldn't be an ID limit, and you should be able to use multiple files within a shot data file. In addition, you should be able to change the alpha of additive bullets, because the fire bullets from TH9.5+ look really terrible IMO. Perhaps a way to name the bullets beyond their ID, so I don't have to make a separate file with RED12 = 123, and such?
Personally, now that I've figured out how they work, I like the way tasks are set up. Maybe you could include them with a different name, just for computability reasons.
I'm really curious as to how you plan to handle tasks/micro-threads, since this is primarily how I code using Danmakufu nowadays. I'm a big fan of the "do this, wait x frames, do something else, repeat, etc" method, as opposed to the conditional statements and augmenting values method most people use.
Microthreading/tasking is seriously the best step I took on field of danmakufu. It makes me build complex scripts much much easier and it was hell of a help during my afro boss and also being hell of a help with my Kisume boss ( which is almost finished )
- Tasking for sure.
I will echo other people's opinions of tasks though. I think the way Danmakufu handles them is fine, and a much easier way to use Danmakufu on a whole than the traditional method. Be careful when adding them into your replacement, as it's tough to improve them without really just adding lazy functions for people (inbuilt Wait, etc).
A few other issues I have:
-Inability to change a lot of the default graphics and effects. It would be especially great if a full game script could have a few simple functions to completely overhaul the default graphics temporarily.
-Random incompatibility with MP3 files. Many times I have to change my desired BGM just because danmakufu refuses to play it for no visible reason.
I would be glad to help make some menu graphics, default bullets, and such.
Beyond that concern, everything else I had issues with has been mentioned. I'm really looking forward to seeing this program completed, so please keep us posted on your progress and let us know if you have any issues or requests. I'd like to help in any way possible, though my skillset may not be as diverse as Drake's musical or puremrz'sbulleticalgraphical talents.
And any concept of an improvement to Danmakufu would OBVIOUSLY generate a positive response, Nuclear Cheese. XD I think we're all a little tired of "these numbers are too big, I'm going to stop working nao" or "bullet graphics? You mean fun white squares? I think you want fun white squares. Here's some fun white squares." (I refer to danmakufu's stupid alpha rendering... hm)
Oh yes, proper music looping would be great.
- Agreeing on Drake's two points: Music looping + ShotDirectionType handling.
If you make a function that can pick the music's startingpoint, endpoint and loop-beginpoint, you have my approval. :V
I'm used to working with midis in my early days of game-making, and the program I worked with (Zelda Classic) had such functions, so I'm kinda spoiled.
Also just because I've had trouble with it in the past, a way to change the base angle of everything in the playable area such as SetShotDirectionType, but more controllable, would be fantastic. Of course this is relatively minor, just putting it out there.
Should this ever see a usable beta version, expect monies.
Should this ever see a usable beta version, expect monies.
Totally supporting this project 100% (Not sure about being able to chip in money though...)
Will it be very hard to remake/modify danmakufu to let it become what you have in mind? At the moment danmakufu's English speaking audience seems rather small. But if you can manage to make it better usable, it'll probably get more crowded in here. I hope.
Hell if you finish and douzo it to 2ch you'll be famous and stuff lol, never mind getting more english speakers.
Ah, thought of a new idea:
You should be able to change the size of the game field. The current is 448x480 (vertical style, touhou-like), you should be able to edit it at the start of a script to say, 556x400 (horizontal style, gradius-like shooter). I'd also like if the whole program was ran in a larger window -- instead of 640x480, it could be 800x600, which I think is still compatible with most computers and allows more room to work with.
Actually, Danmakufu's screen is too big, believe it or not. Touhou has always (Windows) been 384x448.
Either way the concept's practicality holds true.
I've been thinking, adding new cutins like Kaiedzuka(?), Fuujinroku, and Subtarranean Animism( Undefined Fantastic Object uses the same as SA).. 0.0 Though I'm not much of a expert coder.
Also if there is one thing that I demand be changed, it's the handling of transparency. Do NOT make (0, 0, 0) the transparent color like the Danmakufu developers did. It's stupid, and causes problems.
EDIT: Also seriously? Separate files for every type of bullet in the game? I think you should make it so you can have multiple scripts inside one .txt, and import them into a spell script via some sort of #include, because there is no way in heck you can expect people to have 200 .txts lying around just for the bullets the bosses will be firing.
Yeah, like the way you can have an enemy script within a boss script, to be used as a familiar. In fact, every type of "GetBlahFromFile" function ought to have a "GetBlahFromScript" counterpart, because if I want to use an enemy/bullet/whatever only once, why have it in a separate file?
... "fun white squares"? I've ... actually never heard of that problem. Mind describing it a bit, so I can be sure to not make the same mistake?Instead of rendering the bullet, shit happens and you get a mass of squares chucked at you. Think on Drake's black squares of death mods.
You just can't drop the "Maybe", can you? :VI will beat that.
let CUT_KOUMA = 0;
let CUT_YOUMU = 1;
let CUT_EIYA = 2;
let CUT_KAEI = 3;
let CUT_FUZIN = 4;
let CUT_TIREI = 5;
task SPELLCARD(let spell_type, let cutin_img, let l, let t, let r, let b, let arg_angle) {
let wait_time = 40;
cutin;
task cutin {
let cut = cutin_img;
// LoadGraphic(cut);
let obj = Obj_Create(OBJ_EFFECT);
ObjEffect_SetTexture(obj, cut);
ObjEffect_SetPrimitiveType(obj, PRIMITIVE_TRIANGLEFAN);
ObjEffect_CreateVertex(obj, 4);
ObjEffect_SetLayer(obj, 5);
let wh = [l ,t, r, b];
let xy = [-(wh[2] - wh[0]) / 2, (wh[2] - wh[0]) / 2, (wh[2] - wh[0]) / 2, -(wh[2] - wh[0]) / 2, -(wh[3] - wh[1]) / 2, -(wh[3] - wh[1]) / 2, (wh[3] - wh[1]) / 2, (wh[3] - wh[1]) / 2];
let uv = [wh[0], wh[2], wh[2], wh[0], wh[1], wh[1], wh[3], wh[3]];
ascent (i in 0..4) {
ObjEffect_SetVertexXY(obj, i, xy[i], xy[i + 4]);
ObjEffect_SetVertexUV(obj, i, uv[i], uv[i + 4]);
}
if (spell_type == CUT_KOUMA) {
let start_x = GetClipMaxX + (absolute(r - l) / 2);
let end_x = GetClipMaxX - (absolute(r - l) / 2) - 15;
let move_x = (end_x - start_x) / wait_time;
Obj_SetPosition(obj, start_x, GetCenterY);
ObjEffect_SetScale(obj, 1.3, 1.3);
let al = 255 / wait_time;
ascent (i in 0..wait_time) {;
ascent(j in 0..4) {
ObjEffect_SetVertexColor(obj, j, i * al, 255, 255, 255);
}
Obj_SetPosition(obj, start_x + move_x * i, GetCenterY);
wait(1);
}
wait(wait_time * 1.5);
ascent (i in 0..wait_time) {;
ascent(j in 0..4) {
ObjEffect_SetVertexColor(obj, j, 255 - (i * al), 255, 255, 255);
}
ObjEffect_SetScale(obj, 1.3 + i * (2 / wait_time), 1.3 + i * (2 / wait_time));
wait(1);
}
}
if (spell_type == CUT_YOUMU) {
let x = absolute(r - l) / 2;
let start_y = GetCenterY - 125;
let end_y = GetCenterY + 125;
let move_y = (end_y - start_y) / (wait_time * 3);
let get_y;
Obj_SetPosition(obj, GetClipMaxX - 5 - x, start_y);
ObjEffect_SetScale(obj, 1.3, 1.3);
let al = 255 / wait_time;
ascent (i in 0..wait_time * 1.5) {;
ascent(j in 0..4) {
ObjEffect_SetVertexColor(obj, j, i * al, 255, 255, 255);
}
Obj_SetPosition(obj, GetClipMaxX - 5 - x, start_y + move_y * (i * 0.75));
wait(1);
}
get_y = Obj_GetY(obj);
ascent(i in 0..wait_time * 1.5) {
Obj_SetPosition(obj, GetClipMaxX - 5 - x, get_y + move_y * (i * 0.75));
wait(1);
}
get_y = Obj_GetY(obj);
ascent (i in 0..wait_time * 1.5) {;
ascent(j in 0..4) {
ObjEffect_SetVertexColor(obj, j, 255 - (i * al), 255, 255, 255);
}
Obj_SetPosition(obj, GetClipMaxX - 5 - x, get_y + move_y * (i * 0.75));
wait(1);
}
}
if (spell_type == CUT_EIYA) {
let start_y = GetCenterY - 50;
let end_y = GetCenterY + 50;
let move_y = (end_y - start_y) / (wait_time * 3);
let get_y;
Obj_SetPosition(obj, GetCenterX, start_y);
ObjEffect_SetScale(obj, 1.3, 1.3);
let al = 255 / (wait_time * 1.5);
ascent (i in 0..wait_time * 1.5) {;
ascent(j in 0..4) {
ObjEffect_SetVertexColor(obj, j, i * al, 255, 255, 255);
}
Obj_SetPosition(obj, GetCenterX, start_y + move_y * i);
wait(1);
}
get_y = Obj_GetY(obj);
ascent(i in 0..wait_time * 1.5) {
Obj_SetPosition(obj, GetCenterX, get_y + move_y * i);
wait(1);
}
get_y = Obj_GetY(obj);
ascent (i in 0..wait_time * 1.5) {;
ascent(j in 0..4) {
ObjEffect_SetVertexColor(obj, j, 255 - (i * al), 255, 255, 255);
}
Obj_SetPosition(obj, GetCenterX, get_y + move_y * i);
wait(1);
}
}
if (spell_type == CUT_KAEI) {
let x = absolute((r - l) / 2);
let y = absolute((b - t) / 2);
xy = [-x, x, x, -x, -y, -y, y, y];
uv = [wh[0], wh[2], wh[2], wh[0], wh[1], wh[1], wh[3], wh[3]];
ascent (i in 0..4) {
ObjEffect_SetVertexXY(obj, i, xy[i], xy[i + 4]);
ObjEffect_SetVertexUV(obj, i, uv[i], uv[i + 4]);
}
Obj_SetPosition(obj, GetCenterX, GetClipMinY + 50 + y);
ObjEffect_SetScale(obj, 1.3, 0);
let change_scale = 1.3 / (wait_time * 0.22);
ascent(i in 0..wait_time * 0.25) {
ObjEffect_SetScale(obj, 1.3, 0 + change_scale * i);
wait(1);
}
loop (wait_time * 2.5) {
wait(1);
}
descent(i in 0..wait_time * 0.25) {
ObjEffect_SetScale(obj, 1.3, 0 + change_scale * i);
wait(1);
}
}
if (spell_type == CUT_FUZIN) {
let start_y = GetCenterY + 150;
let end_y = GetCenterY - 50;
let move_y = (end_y - start_y) / (wait_time * 3);
let get_y;
Obj_SetPosition(obj, GetCenterX + 50, start_y);
ObjEffect_SetScale(obj, 1.3, 1.3);
let al = 255 / wait_time;
ascent (i in 0..wait_time) {;
ascent(j in 0..4) {
ObjEffect_SetVertexColor(obj, j, i * al, 255, 255, 255);
}
if (i < wait_time / 2) {
Obj_SetPosition(obj, GetCenterX + 50, Obj_GetY(obj) + move_y * 0.5);
} else {
Obj_SetPosition(obj, GetCenterX + 50, Obj_GetY(obj) + move_y * 1.5);
}
wait(1);
}
get_y = Obj_GetY(obj);
ascent(i in 0..wait_time) {
Obj_SetPosition(obj, GetCenterX + 50, get_y + move_y * (i * 1.5));
wait(1);
}
get_y = Obj_GetY(obj);
ascent (i in 0..wait_time) {;
ascent(j in 0..4) {
ObjEffect_SetVertexColor(obj, j, 255 - (i * al), 255, 255, 255);
}
if (i < wait_time / 4) {
Obj_SetPosition(obj, GetCenterX + 50, Obj_GetY(obj) + move_y * 1.5);
} else {
Obj_SetPosition(obj, GetCenterX + 50, Obj_GetY(obj) + move_y * 0.5);
}
wait(1);
}
}
if (spell_type == CUT_TIREI) {
let set_x = GetClipMaxX + ((r - l) / 2);
let set_y = GetClipMinY - ((b - t) / 2);
let set_radius = (absolute(GetCenterX - set_x) ^ 2 + absolute(GetCenterY - set_y) ^ 2) ^ 0.5;
let start_x = GetCenterX + set_radius * cos(arg_angle);
let start_y = GetCenterY + set_radius * sin(arg_angle);
Obj_SetPosition(obj, start_x, start_y);
ObjEffect_SetScale(obj, 1.3, 1.3);
Obj_SetAngle(obj, atan2(GetCenterY - start_y, GetCenterX - start_x));
Obj_SetSpeed(obj, ((absolute(GetCenterX - start_x) ^ 2 + absolute(GetCenterY - start_y) ^ 2) ^ 0.5) / wait_time);
let al = 255 / (wait_time * 0.95);
ascent (i in 0..wait_time * 0.95) {;
ascent(j in 0..4) {
ObjEffect_SetVertexColor(obj, j, i * al, 255, 255, 255);
}
wait(1);
}
ascent(i in 0..wait_time * 1.5) {
Obj_SetSpeed(obj, 0.5);
wait(1);
}
ascent(i in 0..wait_time) {
Obj_SetSpeed(obj, 0 + i * 0.5);
ascent(j in 0..4) {
ObjEffect_SetVertexColor(obj, j, 355 - (i * al), 255, 255, 255);
}
wait(1);
}
}
Obj_Delete(obj);
}
}
I have a suggestion on something you might want to code in...maybe. Just...player homing. I'd honestly like an easier way than just factoring everything in and putting in a huge script. Like, I'd rather just have something like IsHoming(true); in the script, with, say, HomingType(REIMU_AMULET); or something to define how it'd home in. (Such that you could have different types of homing, such as true homing that follows until it hits, like Reimu's amulets, homing within a certain range, such as Sakuya's, except still true homing, etc. Maybe allow people to then code in their own homing styles, too?) At least have a homing function that picks the target itself without us having to make a lot of code to do so, and also stop the homing when there's nothing to hit, especially when a boss is dying. Just a thought, though I'm sure a few people might say that they'd rather script the homing themselves, but it'd be nice to NOT have to go through all of that.Or at the very least keep the enemy enumeration easy.
Consider using an existing scripting language -- creating your own is a crapload of work. Calling the C# functions from any other .NET language shouldn't be too hard.
I have a suggestion on something you might want to code in...maybe. Just...player homing. I'd honestly like an easier way than just factoring everything in and putting in a huge script. Like, I'd rather just have something like IsHoming(true); in the script, with, say, HomingType(REIMU_AMULET); or something to define how it'd home in. (Such that you could have different types of homing, such as true homing that follows until it hits, like Reimu's amulets, homing within a certain range, such as Sakuya's, except still true homing, etc. Maybe allow people to then code in their own homing styles, too?) At least have a homing function that picks the target itself without us having to make a lot of code to do so, and also stop the homing when there's nothing to hit, especially when a boss is dying. Just a thought, though I'm sure a few people might say that they'd rather script the homing themselves, but it'd be nice to NOT have to go through all of that.
I agree with the enemy enumeration thing. Once you actually get a good homing code down, there's not really that much use for it aside from one or two things. It took me nine million years to actually GET a good homing code down, but I did it, and it works perfectly. =D
Consider using an existing scripting language -- creating your own is a crapload of work. Calling the C# functions from any other .NET language shouldn't be too hard.
Alternatively, you can omit the scripting language altogether. Just make Shot/Enemy/Player classes and turn Initialize/Tick/Finalize blocks into methods.
Well, a lot of the work can be taken out if you just use a lexer (http://en.wikipedia.org/wiki/Lexical_analysis) to write the language (that's what I plan on doing with my javascript danmakufu interpreter (http://www.shrinemaiden.org/forum/index.php?topic=1628.0)).
On the subject of looping music (a subject I hold dear to my heart):
The way ZUN seems to do it is, he stores the BGMs as individual WAV files along with two numbers representing memory addresses in the WAV files. The first represents the memory address of the start of the loop, and the second represents the address of the end of the loop. So in PCB, for instance, the title screen BGM's loop begins at 0x00129300 (1217280 bytes into the WAV file), and ends at 0x00e9e420 (15328288 bytes in). I'm not entirely sure how useful this information will be; I'm also not sure how ZUN handles pausing the music when you pause the game (nor why this concept seems to have escaped Tasofro, but that's neither here no there), but just chipping in my two cents since I can't actually afford $20.
One thing to look into: being able to pause a BGM, play a different BGM, and then stopping the second BGM and resuming the first one where it left off. I suspect not bothering with this, now that the "continue" screen has its own BGM, is a good chunk of why ZUN has made continuing = "start over entire stage."
On the subject of menus:
I think the best way of handling menus (and also probably the most complicated) would be creating a secondary scripting language for how the title-menu should behave. That way, you aren't limited to making Touhou-style games; for instance, you could also make a Suguri-style game ("story mode": you select stages individually and unlock them as you beat them; "arcade mode": you play all the stages continuously; and you can also unlock and select weapons before playing, a mode where you select a boss to fight and then you only fight them, and so forth), or your own entirely different thing.
I think the best way to handle that would involve a sort of "menu screen" class with its own backgrounds, positioning of each item (absolutely or relatively) and/or a list, whether a menu-item is locked or unlocked, the appearance of the menu item if locked (i.e. the image is at 50% alpha for Extra on the title screen, "-------" instead of the name on the music room, etc), and a smattering of things that the menu-items actually do. This could also handle the pause-menu as well.
... okay, this is getting closer to 50 cents, but two more questions: 1. will it stay "scripted," or will you be able to "compile" the scripts to make it harder for someone to hax into your stuff and say, "Hey! There's a wacky unlockable-thing/ending sequence/whatever in this script!" (or just steal it, whatever)? 2. Will this project be open-source?
Either way, I think it would be nice if there was some sort of plugin structure that would allow for several different scripting languages. Bonus points if it's cross-platform. Just my two cents.
1) My plan is to have support for regular script files to be readable directly into the program. If there is demand for a compiled format (so you can keep the ending hidden/stop Suikama from stealing shit*), I can add it in.You'll never stop me! :V
arcane - do you know of a good lexer for .NET languages, or perhaps even a full parser generator? I can write a lexer/parser mself, but why reinvent the wheel?
arcane - do you know of a good lexer for .NET languages, or perhaps even a full parser generator? I can write a lexer/parser mself, but why reinvent the wheel?
Yeah, there's a bunch for .NET: http://en.wikipedia.org/wiki/List_of_parser_generators
I can't give you any specific one over the other, due to the fact that I don't know much about .NET.
It would be great if this was open source, that way I could transcribe your parser into my engine; I can't do that very easily with danmakufu, it would probably cut the time I'd need to spend on it in half.
Well, then, I demand that you make it open-source and include a "compiled" format! ;)
Seriously, though: open-sourcing it would make it a lot easier for people to find and fix bugs, make their own versions, add in "compiled" support if you never make it, pick up the project if you suddenly suffer a fatal heart attack or just lose interest, etc ... ;3
1) My plan is to have support for regular script files to be readable directly into the program. If there is demand for a compiled format (so you can keep the ending hidden/stop Suikama from stealing shit*), I can add it in.You'll never stop me! :V
Fair enough. If "getting started on it" is part of the source of the problem with open-source, I can certainly sympathize. ;)Well, then, I demand that you make it open-source and include a "compiled" format! ;)
Seriously, though: open-sourcing it would make it a lot easier for people to find and fix bugs, make their own versions, add in "compiled" support if you never make it, pick up the project if you suddenly suffer a fatal heart attack or just lose interest, etc ... ;3
Jeez, you people and your demands :V
I'll think about the open source thing - probably can set it up once the codebase gets to a decent, stable point. Never set up such a thing before, though, so when that point comes around, I'll be looking for advice/support on setting it up.
And I'll add a compiled format to the list of features, although please keep in mind that I think it'll be a low-priority feature for the time being.
Jeez, you people and your demands :V
I'll think about the open source thing - probably can set it up once the codebase gets to a decent, stable point. Never set up such a thing before, though, so when that point comes around, I'll be looking for advice/support on setting it up.
I'd definitely like to see power items/power system put in there somewhere ...
... & for the player/character scripts to be easier to put together(?)...suggestions on how to go about this, I got nothing...
I had the idea of making some sort of rules.ini file like with the game red alert 2 (if you know how to mod it)
the point here would be that you can modify many things outside of the actual game, such as:
title screen music, define if there is an extra stage and whats required to unlock it, the stage script list, a song title list, and such things.
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.
I'd be willing to help you out there, I know a lot about open source. PM me if you want.
... perhaps, we could even take it a step further, and format these files some way so that the player could select their preferred language, and have it use that when possible. What do you people think?Even better!
Fourth Item: Implementation:EW .NET! >_< Er, uh... I mean, thanks for thinking about us Linux users. Might actually give this a try if you work on it. =] Lemme know if you need a Linux tester.
As I mentioned previously, this would be implemented using SDL.NET and OpenGL in C#. The main advantage of this is that it should be entirely cross-platform portable (without even recompiling!) using Mono.
Fourth Item: Implementation:EW .NET! >_< Er, uh... I mean, thanks for thinking about us Linux users. Might actually give this a try if you work on it. =] Lemme know if you need a Linux tester.
As I mentioned previously, this would be implemented using SDL.NET and OpenGL in C#. The main advantage of this is that it should be entirely cross-platform portable (without even recompiling!) using Mono.
I'm ditching danmakufu the instant you finish this.
Also, it'd be nice if you could compile the scripts into an exe.
EW .NET! >_< Er, uh... I mean, thanks for thinking about us Linux users. Might actually give this a try if you work on it. =] Lemme know if you need a Linux tester.
Awesome ideaand something I never got around to doing, Nuclear Cheese.
How are you going about programming this, anyway? I have a lot of experience in SDL.NET, but I understand it's not the most efficient way to do things - unfortunately, I don't know how to use OpenGL in C#. Someone in #c76 mentioned they always just initialize the window with SDL.NET and then do everything else in openGL.
Along those lines, any websites you can point me towards regarding doing just that?
Just had another thought about localization: instead of just one text file, have a .ZIP file or whatever which would also contain any images with text on them.
And as I was typing that it occurred to me that you wouldn't just need to use that for languages: if you put in levels and menus, you could have things like mods and expansion packs ... the possibilities are endless.
And, finally, an update: CODING HAS STARTEDYEAAAAHH ಥ_____ಥ!!!
Very unlikely I'll have a testing release tonight, but I'd say so far the progress is pretty good.
Very unlikely I'll have a testing release tonight, but I'd say so far the progress is pretty good.
Jesus dude, I wasn't expecting a working beta for weeks ...
Musuu
Script[ScriptType]
// 'a' is a global variable
global a;
// Define an enemy boss object type
Boss "A Boss"
{
// Define the initialization script
Initialize
{
a = 1.0 + 1.5;
}
// Define the tick (per-frame) script
Tick
{
a = a + 0.1;
}
}... at this rate I'm actually going to have to script something in Danmakufu before it becomes obsolete!
Don't forget the input handling. :p
Anyway, I'll look up some information on the Tao framework's openGL stuff, I guess, and play around with it a little. Hopefully I'll be in a position to help you out a little if you put the source code online... or something. 8D
EDIT -- Well, I taught myself openGL for a school group project(physics simulator, whoo) but that was using glut -- though it used enough openGL for the code to be recognizable to me. What I'm confused about, and what I can't find, is an example of using SDL.NET to create the window and then using openGL the rest of the way... The examples on Nehe have an insane amount of DLL and function imports all over the place >_<
Honestly, .NET is one of the things that Microsoft did right, if you ask me. And I'm usually on the frontlines of the MS-bashing. :VYep yep. I guess I'll prefetch Mono, so I can install it when you have some code ready.
As far as testing is concerned - when this gets to the point where I think some widespread testing* can occur, I'll put up a quick download for people to try. Feel free to give it a go and post your results/etc then.
* In other words, when it doesn't look like total shit.
Perhaps this will help: http://cs-sdl.sourceforge.net/index.php/NeHe_1_OpenGL_Tutorial (http://cs-sdl.sourceforge.net/index.php/NeHe_1_OpenGL_Tutorial)
I don't know if this has been suggested before but: a way to auto-run a script. It could be useful for people who make whole games. I admit full games are pretty rare so this probably isn't really an important addition, but some people would probably like it.Methinks this would go hand-in-hand with "compiling" scripts. Maybe a "create a custom EXE with the icon of your choice which automatically runs the specified script" too ...
I don't know if this has been suggested before but: a way to auto-run a script. It could be useful for people who make whole games. I admit full games are pretty rare so this probably isn't really an important addition, but some people would probably like it.
Methinks this would go hand-in-hand with "compiling" scripts. Maybe a "create a custom EXE with the icon of your choice which automatically runs the specified script" too ...
Also, English documentation :D (Not a request. I'm only happy that I'll understand)
And English error messages :D (yeah... I guess it would be kind of normal to get error messages we can actually understand instead of having to use the wiki to finally not find what the error was, totally rebuild your code from scratch, not fixing the error and causing a Faildows crashing error or that kind of tihs...)
First of all, Nuclear Cheese, let me say I have been a fan of your Danmakufu scripts for a while now.
Now, with that out of the way, I would like to hereby declare that I joined this site solely out of interest in this project. I know a few people who go here, but this is my first time posting.
Anyhow, I'll be sure to submit my own suggestions (although frankly, it seems like you've really covered the bases already), as well as offer any (limited) support that I am able to.
And like Stuffman, I shall happily pay you several dollars if you go through with the project / if it will help expedite development of the project.
Maybe.
For some reason, I feel like designing the default "STG_Frame" for this replacement.
I'm working on the center picture, just so you know.
Ohz
So, what's the actual name of this project going to be? "A Replacement For Danmakufu" feels, I 'unno, kind of awkward as far as this goes ...
Fifth Item: Program's Name:
I'm thinking 無数の弾幕 ("Musuu no Danmaku" - "Countless Barrages") ... any objections/recommendations?
Ohright!
Hmm. I dunno, something about that title just doesn't resonate with me, or something. I think it has to do with the fact that it's Japanese, with no intrinsic English component, and since this is going to be targetted primarily at English-speakers ... yeah. (At least you could have someone who knows Japanese check your grammar, I guess ...)
Lol, just trying to show my support, Cheese. xD Although it's a relief to hear that you don't need finances, heheh.
And yeah, Time Devotion is always a bit of a troublesome issue. That's part of the reason why I'm interested in this - I'm working on my own game, and I started progression of it on Danmakufu. But frankly, that program is anything but User Friendly.
Thankfully, my Computer Crashed, and development has been on hold, which meant that I didn't get too far in before finding out about this - after reading everything on the first post, and taking a gander at your example scripting, I've decided I'd much rather redevelop the game using your program, once it's completed, rather than continue with Danmakufu, as it would be much less time-consuming from the looks of things.
Of course, that's all assuming you can indeed find the time for this project.
Regarding the name, I think I could come up with a few other suggestions - I have a thing for naming things. So I'll be sure and get back to you on that, as I gotta run at the moment for class.
Toodles~
Um, screw me in the spleen, then ... |3Ohright!
Hmm. I dunno, something about that title just doesn't resonate with me, or something. I think it has to do with the fact that it's Japanese, with no intrinsic English component, and since this is going to be targetted primarily at English-speakers ... yeah. (At least you could have someone who knows Japanese check your grammar, I guess ...)
Four semesters of Japanese classes, I would hope I'd be able to piece together a two-word phrase without screwing up the grammar :V
Now, I have several games in-planning. One of them, which I have yet to begin production on, features a Team feature similar to that of Imperishable Night.This is already very possible in Danmakufu. (http://onthenet9999.googlepages.com/ReimuYukari.zip) I'm not sure if we need specific functions for it in Countless Barrages. It's just a matter of If statements to check which character is currently being used.
If ((Shot button not depressed) && (playerX = minClipX) && (check for tap left)) {
freeze controls
manipulate player X to acheive teleportation
unfreeze controls
}
LetsDoSomeFuckingDanmaku.exeYES.
LetsDoSomeFuckingDanmaku.exeThis is the right idea
LetsDoSomeFuckingDanmaku.exe
Um, screw me in the spleen, then ... |3
????????? ~ Maiden's Bullet Storm
Hm. ... Endless Danmaku, maybe?
Well, it's good to know that. Again, I never really looked into those aspects before, so I was unsure.
Also, I thought of a (somewhat lame) name suggestion.
????????? ~ Maiden's Bullet Storm
The Japanese part translates to "Violent Stormy Rain of the East". And the English can be acronymed to MBS, which my mind, in its occasional immaturity, took as a double-meaning for "My Bull****".
Cuz, y'know, some user-generated scripts can be total BS.
Ehhh for a name I would prefer something more straightforward, like Custom Danmaku Engine. Calling it something like "Countless Barrages" or with Japanese in the title or whatever makes it sound like it's supposed to be its own game, when it's just an engine for running them.
In honour of another favorite tool of mine, what about Danmaku World Editor?
Danmaku Maker? marishrug.jpg
LetsDoSomeFuckingDanmaku.exe
Also, a thought occurred to me today to ask about this:
Now, I have several games in-planning. One of them, which I have yet to begin production on, features a Team feature similar to that of Imperishable Night.
I never bothered to look up weather or not that it is even possible to do that on Danmakufu, so I was wondering - would your program offer support for focus/unfocus Team Formations? If you have not thought of this, would it be a possibility to include it?
Also, while not a necessity, it would be really neet if there was a way to include special abilities a la Subterranean Animism. However, due to the extreme level of open-ended-ness in the vaguely descriptive "Special Abilities", I doubt that this would be quite so possible.
This is already very possible in Danmakufu. (http://onthenet9999.googlepages.com/ReimuYukari.zip) I'm not sure if we need specific functions for it in Countless Barrages. It's just a matter of If statements to check which character is currently being used.
(to switch my player, you have to use C though)
^ Both of those points you mention would be a matter of implementing player scripts with the features in question. I hear Danmakufu had problems with its player scripts, but since I never tried working with it, I don't know exactly what could be improved. "Team" implementation would be a simple matter of swapping out sprites, and I'd be greatly surprised if it took any considerable effort, regardless of how well the scripting works. As for special abilities, you could implement, say, Yukari's teleportation thing rather simply:
t3h codes
And the same for the other direction. It's all a matter of how creative you get with the scripting.
jmp jumps to another part of the current event script.Oh god YES.
jmp jumps to another part of the current event script.Oh god YES.
Anyways, I have a name suggestion that may be kid friendly and touhou-life.
How about something as basic as "Danmaku Infinite"?
Inspired by how MUGEN(Which means infinite, for those that don't know) is a literal game of infinite content, Danmaku Infinite is a shmup of infinite stages and bosses!
Alternatively, you can call it Touhou Infinite. But people not interested in spell cards wont touch spell cards, there for making "Touhou" redundant.
I think the name is basic enough to remember, but cool enough to not be boring either.
I don't have muchany experience with coding player scripts in Danmakufu, so (I might have asked this already ... my brain is slightly fried at the moment) it would be helpful if people point out any particular issues they've had in Danmakufu.
QuoteI don't have muchany experience with coding player scripts in Danmakufu, so (I might have asked this already ... my brain is slightly fried at the moment) it would be helpful if people point out any particular issues they've had in Danmakufu.
Easier bomb coding dear lord that was my least favourite part. Also, optional to disable/not disable regular shots during bomb. (Alternatively, potential custom bomb system, should we opt for MoF/SA setup)
Also, homing code aides.
Also, optional to disable/not disable regular shots during bomb. (Alternatively, potential custom bomb system, should we opt for MoF/SA setup)ForbidShot(true/false); The bomb coding in Danmakufu is a bit difficult, especially with bombs technically being separate scripts, with you having to redeclare all the variables for your image paths and such. However, it's also very flexible once you understand how it works.
I do agree with you on post-IN stuff being available. 1-up and bomb pieces, and maybe even a power system. The player would have something like EnablePower(6/10/11/12)Methinks you should go the "complexity" route of allowing the users to script that kind of thing themselves, so that e.g. we don't have to rework the EnablePower function and whatnot every time a new Touhou game is released. Much better to do a generic "item" superclass, and make the code flexible enough to do whatever you want when you collect a given instantiation.
Suggestion: rather than hardcoding things like power, bosses' health-meters, dying, etc., you include a bunch of "default scripts" which handle things like that, so that if someone doesn't want to use it or wants to use something different (i.e. an Imperishable Night-style game where one type of item is a powerup and another is a point-item for the human-character, and it's the other way around for the youkai-character; PCB-style "this boss has X number of health-meters" versus MoF-style versus EoSD-style; a health-meter for the player instead of a number of lives), they don't have to use scripts to fight an uphill battle against the hardcode.
MUGEN is indeed horrible NC. Bad reputation :V though still funny to play now and then.
I think I kinda like "Infinite Danmaku" itself. It could grow on me. ``
Just keep it as Musuu no Danmaku and be on with it lol.
Easier bomb coding dear lord that was my least favourite part. Also, optional to disable/not disable regular shots during bomb. (Alternatively, potential custom bomb system, should we opt for MoF/SA setup)
Also, homing code aides.
Unfortunately, if we want any sort of flexibility with bombs, it has to be complex. It seems that more flexibility = more complexity, and vice versa.
I do agree with you on post-IN stuff being available. 1-up and bomb pieces, and maybe even a power system. The player would have something like EnablePower(6/10/11/12);. 6 (EoSD) would make it a value from 0 to 128, 10 (MoF) would make it 0.00 to 5.00 and attach the bomb system to it, 11 (SA) would be the same but only go up to 4.00, and 12 (UFO) would go from 1.00 to 4.00 and make the bombs separate again. The CreateItem function would ignore spawning power items if the player didn't have power enabled, and bomb items if MoF or SA settings.
Methinks you should go the "complexity" route of allowing the users to script that kind of thing themselves, so that e.g. we don't have to rework the EnablePower function and whatnot every time a new Touhou game is released. Much better to do a generic "item" superclass, and make the code flexible enough to do whatever you want when you collect a given instantiation.
*digs through back pages* On the subject of power/bombs, this needs to be rementioned:
The existing systems are great as a base, but it really should be flexible enough to handle just about anything you could think up. I say default scripts for 6/10/12 style, but paramaterize them so you can go from 10-style to 11-style as simply as "setMaxPower(400);", tweak power thresholds for 6-style and whatnot. And then if you wanna do something wacky, you can do a custom script and everyone's happy.
May I suggest more capabilities for dialogue? Maybe a way to implement cut scenes as well?
As it is, working with text is really annoying in danmakufu since it is so limited and shows so little at once.
People like me who're story whores really have trouble writing for danmakufu because we have to chop up dialogue so much. So something to help with storytelling is HIGHLY appreciated. Even if it is a selfish request of mine.
Also, easier 3d. Danmakufu's 3d fails.
Perhaps even an Hp system to. A good thing to remember is we should aim to make this tool universal for danmaku and not just touhou. Touhou will probably be the biggest use, but options to disable is preferred.
Brain wave: What if we have the player scripts define some arbitrary number of power levels (I'm thinking 0-7, for 8 levels total; I can't imagine anybody realistically needing more than that) and have the enemy/stage script track power however it wants to, and tells the player which power level to execute?
Bonus: not all 8 power levels need be defined by player scripts. You could define, say 0/1/3/5/7, and if a script goes looking for 4, it defaults to the next one down that is defined, 3. (0, of course, would have to be required)
EDIT: Elaborating on this a bit...
Internally, power is just an integer, so all we need is a section of stage scripts to define the thresholds for each power level, and optionally a custom display method (If we leave bombs, score, and whatever else to stage scripts, too, we could lump this all into some kind of "resource management" section). Player scripts can also include their own version of this in case the stage script doesn't really care and omits this part. If neither of them has a power definition, it can default to "always max (7) power" like DMF does now.
Power_Meter_Max(128); // max power = 128
Power_Meter_Display(Integer); // display power as an integer
Small_Power_Item_Value(1); // small power item gives 1 unit
Large_Power_Item_Value(8); // large power item gives 8 units
Bomb_Cost(0, 1); // Bomb uses 0 power and 1 bomb
Miss_Cost(24); // power lost of miss
Power_Threshold(1, 8); // Set power thresholds
// ...
Power_Threshold(8, 128);
Start_Power(0); // start at zeroPower_Meter_Max(5); // max power = 5
Power_Meter_Display(Decimal); // display as a decimal number
Small_Power_Item_Value(0.05); // small power item gives 0.05
Large_Power_Item_Value(1); // large power item gives 1.00
Bomb_Cost(1, 0); // bomb costs 1.0 power and 0 bombs
Miss_Cost(2);
Power_Threshold(2, 1.0); // Set power thresholds
Power_Threshold(4, 2.0);
Power_Threshold(6, 3.0);
Power_Threshold(8, 4.0);
Start_Power(0); // start at zeroAnd why would the former require you make a program update to add new systems? :o
That's what Onthenet was suggesting, but it's not intrinsic to "the level/pattern script handles it."And why would the former require you make a program update to add new systems? :o
I think I slightly misinterpreted it, thinking of it as the script selecting one of multiple pre-defined types. :-\
I think that bombs are best served with, "When player uses a bomb, run player's bomb-script" and let the bomb script do anything any other script can.
I'll clarify what I found complex about bomb scripts: You have to use effect objects to create any visible effects during the bombs. Offering a much simpler method that can use normal draw routines or standard bullet graphics drawing would be wonderful. Yeah, keeping complexity is nice, but... srsly.
I haven't used Danmakufu at all. Care to elaborate, since you'd apparently rather taunt me for my ignorance than try to correct it? ;PI think that bombs are best served with, "When player uses a bomb, run player's bomb-script" and let the bomb script do anything any other script can.
Always nice to see people who haven't used Danmakufu's Player Scripting functions... My my.
Once you know how to use effect objects you'll they are infinately better than the shitty "draw from the center" style DrawGraphic functions, despite the steep learning curve.
Personally, I don't think there's any real "easy" way to do 3D. The simplest way would be to just give the scripter the ability to throw down triangles directly to the renderer, but even that's not particularly easy to use.
Any wants in this area?
I think that anything which doesn't directly affect what the player is able to do (HP, maximum bomb capacity, etc) should be handled by the "level" script. While it's true that you won't be able to do things like giving different players different HP or whatever, I'd say this is a relatively small price to pay for being able to use any player script.
As for 3D ... hmm. Feel free to count this as one cent instead of two, since I have almost no experience working directly with the nitty-gritty details of how 3D stuff actually works (nor have I used Danmakufu's before), but ... I'm thinking, using polygons (rectangles?) in 3D space. Give each polygon width, height, texture, (tint, maybe?), X Y Z coordinates of the center, pitch/yaw/roll rotation, and ... that should handle a lot of things. Script camera-control, "fog" (i.e. the way things fade into a blank color in the distance), background image/color ...
Also, I realized a problem with my Brilliant Plan for 3D: it would be extremely difficult to make, say, an octagonal pillar, because rotating a rectangle 45 degrees, to fit with anything else you'd need use the Pythagorean theorem to give it a helpful width. So, instead, how about, um, a "triangle" function where you specify the X,Y,Z coordinates of each corner (and the texture and all details about that), and a "rectangle/rhombus" function that where you specify the X,Y,Z coordinates of three of the coordinates, and extrapolate the fourth from that. Really, I think that no matter what we do, unless Nuclear Cheese is prepared to code an entire 3D GUI, there is no easy way of doing 3D.
I think that bombs are best served with, "When player uses a bomb, run player's bomb-script" and let the bomb script do anything any other script can.
I'll clarify what I found complex about bomb scripts: You have to use effect objects to create any visible effects during the bombs. Offering a much simpler method that can use normal draw routines or standard bullet graphics drawing would be wonderful. Yeah, keeping complexity is nice, but... srsly.
Also, I remember testing on Danmakufu and finding that although you could shoot as normal, damage added from the shots was auto-reduced... but I may have come upon an error there.
I think that bombs are best served with, "When player uses a bomb, run player's bomb-script" and let the bomb script do anything any other script can.
Always nice to see people who haven't used Danmakufu's Player Scripting functions... My my.
I'll clarify what I found complex about bomb scripts: You have to use effect objects to create any visible effects during the bombs. Offering a much simpler method that can use normal draw routines or standard bullet graphics drawing would be wonderful. Yeah, keeping complexity is nice, but... srsly.
Once you know how to use effect objects you'll they are infinately better than the shitty "draw from the center" style DrawGraphic functions, despite the steep learning curve.
Yeah, but you don't have the choice. And that's where the problem lies - what commands you could use were limited by script 'type' in Danmakufu.
Aaaand NC mentioned the coordinate system... Why do we have 0 pointing up? Why are we screwing up the degree system even further? Do you know how often I have to change my work on math exams because I keep using clockwise rotation...? Just keep it like it should be, I have no problem using 270 as down. It's how everybody is taught. Also, (0,0) -> bottom left. Why was this ever changed...
In addition to that, before you try to handle the program's player scripting functions, you might want to go through Stuffman's Player Script tutorial and see how it's done for yourself. There's not real easy way to explain how batshit player scripting is other than actually seeing for yourself.
Personally, I don't think there's any real "easy" way to do 3D. The simplest way would be to just give the scripter the ability to throw down triangles directly to the renderer, but even that's not particularly easy to use.
Any wants in this area?
That distorted area around the bosses of SA/UFO would be nice, if you could do that.
This sounds simply amazing. Have you already started?
If so, then what language are you using to program it?
As he's adding a type of script for menus and such, that would be introduced there. You would just call a task at a certain point that cycles through images. Not that hard to pull off. (The intro for the two games use only images, not text, as well. They're cut into the image and text portion, though.) As you said, music would be just as easy as during a boss.Thank you very much for explaining it properly for a newby like myself ;D
That distorted area around the bosses of SA/UFO would be nice, if you could do that.
Haven't played those two games yet (save for the SA demo once some time ago). We'd need to figure out what, exactly, the effect is doing. If we're lucky, it's simple enough that we won't need shaders and such.
pos: v3, vertex position
normal: v3, vertex normal
radius: float
amplitude: float, should be negative to mimic TH11/12
pos += amplitude * normal * (1 + cos(min(PI, PI * dist(vertex, boss) / range)))
I haven't used Danmakufu at all. Care to elaborate, since you'd apparently rather taunt me for my ignorance than try to correct it? ;PI think that bombs are best served with, "When player uses a bomb, run player's bomb-script" and let the bomb script do anything any other script can.
Always nice to see people who haven't used Danmakufu's Player Scripting functions... My my.
And, Naut - play nice ;)
Aaaand NC mentioned the coordinate system... Why do we have 0 pointing up? Why are we screwing up the degree system even further? Do you know how often I have to change my work on math exams because I keep using clockwise rotation...? Just keep it like it should be, I have no problem using 270 as down. It's how everybody is taught. Also, (0,0) -> bottom left. Why was this ever changed...
In addition to that, before you try to handle the program's player scripting functions, you might want to go through Stuffman's Player Script tutorial and see how it's done for yourself. There's not real easy way to explain how batshit player scripting is other than actually seeing for yourself.
A few points, my friend -
- Computer graphics pretty much always have (0,0) in the upper left. It's how the screen buffer is addressed. Location 0 is the upper left, incrementing are you increase X. When you hit the end of the row, the next location is the leftmost pixel one row down.
- With the Y inverted from how it usually is in math class, rotation is going to be inverted too.
- I set up as zero because, to me, it makes more sense to have a vertical angle as zero (thinking like 0 = forward). I can change this if people want.
Not trying to be condecending or anything here; I'm just explaining my reasoning.
Y should NOT be inverted. As it then contradicts the system which every programming language uses, which is the inverse to that used in math.
We are using a programming language here, so...
There's no need to accommodate every single preference when it comes to scripting syntax. Consistency is better because it won't lead to confusion down the line.
Up as 0 is fine as it feels right to me, and right as 0 is also fine because I'm used to it in Danmakufu. Just pick one or the other.
Y should definitely go from top to bottom though, I can't think of any programming language that doesn't do it that way.
If there aren't any major objections, I'd like to stick with angle 0 = up, since that makes the most sense to me.
Can you also fix the replay function?I don't think "fix" is exactly the right word, given that he's creating his own entirely new program, he isn't directly basing anything much on Danmakufu besides the basic purpose of the program.
I suggest implementing that history thing ZUN uses in spell cards. With Danmakufu, there's no such thing, except through the use of common data functions... :'(I suspect the reason Danmakufu doesn't have it is that it would be a logistical nightmare. Where would you store it? How would it handle two identical scripts with different filenames (i.e. for the spellcard Hax Sign "Burn Everything", "haxsign.txt" versus "hax sign burn everything.txt")? How would it handle different versions of the same script which noticeably alter the gameplay? What about two different versions where all that's changed is one line that only changes the background color?
Can you also fix the replay function? in danmakufu, when you speed up using the space bar while watching the replay, it won't show the exact replay anymore... usually it'll desync or something... example... there was once where I only wanted to see the latter part of a replay I saved, I sped up the replay using the space bar, but when it was speeding the player died... when I watched it without speeding, it went on normally without the player dying...
One last uninformed suggestion by yours truly:
Could players be more flexible so that you would be able to switch them after a script/game has been activated? Say you want it to switch to a specific player when you reach a boss.
As it stands, in danmakufu you would have to add the code to the player you select when you load a script. Things get a little messy from there...
To sum it up: Being able to switch shot types.
I suggest implementing that history thing ZUN uses in spell cards. With Danmakufu, there's no such thing, except through the use of common data functions... :'(I suspect the reason Danmakufu doesn't have it is that it would be a logistical nightmare. Where would you store it? How would it handle two identical scripts with different filenames (i.e. for the spellcard Hax Sign "Burn Everything", "haxsign.txt" versus "hax sign burn everything.txt")? How would it handle different versions of the same script which noticeably alter the gameplay? What about two different versions where all that's changed is one line that only changes the background color?
And if that wasn't enough, ZUN has a separate history-counter for every character and shot-type. The issue is therefore multiplied by what player script you're using.
It wouldn't really be a problem of balance. It's a problem of danmakufu being so dependent on the character you've selected.One last uninformed suggestion by yours truly:
Could players be more flexible so that you would be able to switch them after a script/game has been activated? Say you want it to switch to a specific player when you reach a boss.
As it stands, in danmakufu you would have to add the code to the player you select when you load a script. Things get a little messy from there...
To sum it up: Being able to switch shot types.
This could be an interesting secondary feature, although it could easily break player balance by letting you keep switching to the 'optimal' shot type for the occasion.
This could be an interesting secondary feature, although it could easily break player balance by letting you keep switching to the 'optimal' shot type for the occasion.
<Quoted stuff>
It wouldn't really be a problem of balance. It's a problem of danmakufu being so dependent on the character you've selected.
From what I could understand so far, it seems like the problem is that danmakufu is so dependent on the character you chose if, for lets say you unlocked the extra stage in your game.
By switching characters, I mean support to do so after a game/script has been activated. To perhaps even choose the characters ingame from the story mode menu rather than prior.
This could require completely recoding how the program treats players though, but it would allow much more possibilities.
Again, sorry if I said anything incorrect and sorry for my lack of "advanced" knowledge >_<
Couple of suggestions, sorry if it's a bit late as I just noticed this thread as I was perusing around the board. I know this has been attempted in the past (RIP OpenDMF) so godspeed to you for working on a new replacement.
1) I wouldn't use C# for this mostly because although Mono is great, I wouldn't rely on it for graphical programs. WinForms and other GUI things work DRASTICALLY different on Mono than on Windows .net to the point that you might as well use a third party toolkit, negating the whole point of using .net in the first place. Also SDL is pretty crappy on all platforms, only really useful for having a single target to hook a window to for OpenGL (which after reading is all you're using it for anyways). I would honestly look into using an existing crossplatform 2D/3D engine like Irrlicht or CrystalSpaces (definitely recommend CrystalSpaces) and just focus on coding the actual danmaku and hitbox framework.
I know you already got some code down but honestly maintainability in the long run will be MUCH easier if you stick to a preestablished engine and just code in C the object logic/patterning and hitboxing. Especially for crossplatform compatibility and just future compatibility even in Windows (look how many issues DMF has :|)
2) Yes use an existing scripting engine/language rather than invent your own parser/lexer. Lua was designed specifically for this, and it's stupid easy to embed it or something like Python or Ruby. It's infinitely easier to just use an existing language and have people learn to use it rather than invent and maintain your own parser and lexer. Maintainability comes back into play here, as you won't have to worry about making code binds for every little thing. You just have to code key functions you want to expose to the scripts, and let the language handle the flow and logic.
Plus with older DMF scripts you can just build a conversion tool and then just hand-fix any oddities rather than trying to match DMF's syntax and usage word for word.
Basically what I'm trying to say is, it's great you're doing it, but you really don't have to reinvent the wheel. Using already built stuff like the game engine and script language will let you focus more on what actually matters, coding the danmaku framework and script bindings, and will be much easier to maintain and complete and make crossplatform.
Good luck, and if you'd like some help I'd definitely be willing to throw a few programming hours into it, although I don't really have much time right now to devote to it. I'd be willing to setup Mercurial repository and bugtracker for the project so people can collectively work on the source and contribute as necessary rather than forcing the load just onto you.
It wouldn't really be a problem of balance.
Also, and this isn't any kind of important issue, but was there any specific font style you had in mind for any in-game text? I know a few Touhou games had their own custom-style font sets, and was just wondering if you had any ideas on that thus far.
try to add a different colision type for lasers.... using circles (if i read right) would be bad i think
Lishy isn't really properly communicating why he wants the change-players function, he talked to me about it earlier.
He doesn't mean having the Player Select screen come up in the middle of scripts, he means being able to change the active player script in the middle of the game.
For instance, it might be a part of your game that you play a different character on a certain stage, or maybe your character unlocks their hidden powers and is different for the last couple stages or something like that. The trouble is that there's no way to change to a different player file mid-script in Danmakufu. You have to work around it by putting all that stuff in the same player file and making it work with common data, which is kind of clumsy.
Circle <-> line-segment+radius is probably easier to implement than circle <-> rotated ellipse.try to add a different colision type for lasers.... using circles (if i read right) would be bad i thinkCertainly makes sense. Would most likely do something like an ellipse ...
I was playing MoF earlier and was reminded by doing so to ask about something. xDLevelTransition();
For Stage Progression, are you planning on making it like Danmakufu/EoSD/PCB/IN, where after completing a stage, the screen shrinks and your score page pops up before moving on?
Or are you going to do it like MoF/SA/UFO, where your score briefly pops up and then automatically shifts into the next stage without any transition screen?
Circle <-> line-segment+radius is probably easier to implement than circle <-> rotated ellipse.try to add a different colision type for lasers.... using circles (if i read right) would be bad i thinkCertainly makes sense. Would most likely do something like an ellipse ...
(http://i33.tinypic.com/16m7yfr.png)
I was playing MoF earlier and was reminded by doing so to ask about something. xD
For Stage Progression, are you planning on making it like Danmakufu/EoSD/PCB/IN, where after completing a stage, the screen shrinks and your score page pops up before moving on?
Or are you going to do it like MoF/SA/UFO, where your score briefly pops up and then automatically shifts into the next stage without any transition screen?
LevelTransition();
How about YOUMU or FUJIN?
Although, come to think of it, what about the case of two colliding lasers? I'm sure it's doable, but I don't know the algorithm off the top of my head.Reduces to the problem of finding the minimum distance between two line segments.
I'm always ambivalent about higher resolutions because it means I need to make bigger sprites :V
But whatever, 800x600 is a resolution for true bros, so I'm cool with the current setup.
Although, come to think of it, what about the case of two colliding lasers? I'm sure it's doable, but I don't know the algorithm off the top of my head.Reduces to the problem of finding the minimum distance between two line segments.
Oh hey, sorry if this sounds dumb or anything, but are you going to make shots have some selectability on what they go behind or in front of no matter what? My line of thinking is player shots. Currently, in Danmakufu, they ALWAYS go IN FRONT of the player. This is annoying, because it is EXTREMELY distracting to the hitbox for me. I do my best to avoid allowing player shots to cross into the player's graphics if they're not spawned from the player's location itself, because otherwise, the shots cloud up my vision of my location, and it becomes much harder for me to avoid bullets because it feels like my hitbox is somewhere other than the location it's truly at... So basically, I just want to know if you plan on putting in a simple way to allow player shots to go below the player graphics. That's all.
Another thing Danmakufu is missing. Graphic layer settings for objects.It was like the third thing suggested.
I'd prefer some level of control over the resolution on the back-end, too, but ah well.
Wow. Color me impressed at how quickly this is progressing.
=/ It'd take me forever to get something like this going.
Anyhow, I very much like how it's coming along, and it seems like despite your limited amount of time, you're really staying on top of it. =P
Kudos, cheese. ...Or would you prefer Cheese? Kudos are kinda nasty-tasting. >_>
Oh hey, sorry if this sounds dumb or anything, but are you going to make shots have some selectability on what they go behind or in front of no matter what? My line of thinking is player shots. Currently, in Danmakufu, they ALWAYS go IN FRONT of the player. This is annoying, because it is EXTREMELY distracting to the hitbox for me. I do my best to avoid allowing player shots to cross into the player's graphics if they're not spawned from the player's location itself, because otherwise, the shots cloud up my vision of my location, and it becomes much harder for me to avoid bullets because it feels like my hitbox is somewhere other than the location it's truly at... So basically, I just want to know if you plan on putting in a simple way to allow player shots to go below the player graphics. That's all.QuoteAnother thing Danmakufu is missing. Graphic layer settings for objects.It was like the third thing suggested.
Hitbox over enemy shots, it's just better that way. Everything else looks good.
Hitbox over enemy shots, it's just better that way. Everything else looks good.
Hitbox over enemy shots, it's just better that way. Everything else looks good.
Confirming and agreeing above two gentlemen. All the latter touhou games have hitbox over enemy shots. The only ones I remember having shots over player hitbox is PoFV and older.
Yeah, I still fondly remember a moment in PCB -- I forget whether it was on Youmu or the Prismrivers -- when three different bullets completely obscured my hitbox, and none of them hit me. (This was before my haxcheatin' days ...)
I think Enemy/Boss should be the LOWEST object order, on the basis that even the player and player shots go above them in MoF. (I can't check against SA and UFO, as my current laptop won't run them fast enough to truly be able to play them...) However, I'm sure you'll allow a function to manually override a default layer order for a specific object, am I right?
I'm sure someone somewhere will want better reasons for doing things that way than "because ZUN did it" (read: "I wanna do it my way!"), how about have that as the default, and then making object-order customizable in the script. Possibly changing mid-script, too, with getters and setters and "bring forward" and "send backward" ...
Scripts will be able to change these values on a per-object basis.
So the script should be able to mutate the : pitch, volume and "noise" ( don't know exact sound but the volume remains the same but it sounds like the sound is being dimmed / distorted. In dutch we call it 'dof' )In this context:
*after skimming*
what about items/power ups handling ?
For the sake of making scoring systems will stuff like UFO's system be handled else where or directly within the stage ?
Something that came to mind about that LevelTransition() function, how do we want to handle putting score text on that? Should we bother trying to allow itemizing stuff like in earlier Windows Touhous (level bonus, graze bonus, difficulty modifier, etc) or should we just have a singular argument for Stage Bonus that we calculate everything into?
The latter is probably the most feasible, I'm just curious how in-depth we plan to go with this.
There's also the issue of figuring out how to change how point items calculate their value...perhaps it would be a good idea to just have an "item" object type?
Here is another suggestion came to my mind after having a discussion with CaSercan on IRC about the sounds in Touhou (as they are not the same ingame as they are as wavfiles).
So the script should be able to mutate the : pitch, volume and "noise" ( don't know exact sound but the volume remains the same but it sounds like the sound is being dimmed / distorted. In dutch we call it 'dof' )
An idea about the code would be: PlaySE(soundsfx.wav,<volume>,<pitch>,<"noise">); Same could be applied for music I guess.
I know I said earlier that I couldn't imagine anybody wanting more than 8 power levels, but I suddenly have the desire to make a player script with an utterly broken level 10 power definition.
"Hey Blue, what's the script say about her power level?"
Me: IT'S OVER 9!
"WHAT, 9!"
>.>
<.<
Aaaaand, this is why I shouldn't post when I'm tired. >.< Still, not having a harcoded power limit is probably a good idea.
I motion to change that function from PlaySEex to PlaySex. All in favor?
| When the stage-script asks for: | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
| ... the player-script returns: | 1 | 1 | 2 | 2 | 3 | 3 | 4 | 4 |
Here's a thought: instead of a mandatory specific number of levels, have the player-script specify a "max power" and (maybe/optionally) a "minimum power" like how UFO has 1.00 as its minimum, and when the stage-script calls for a power-level change, round it to the nearest available fraction-of-the-max-level in the player-script. So, let's say, if a stage-script was expecting 0-7, and the player-script had 1-4, then:
When the stage-script asks for: 0 1 2 3 4 5 6 7 ... the player-script returns: 1 1 2 2 3 3 4 4
Also, maybe some sort of multiplier for how much point-items are worth, like how in SA, Marisa-Alice gains a level for every 12 point-items, but everyone else gains a level every 20 point-items.
Whatever the limit, I think it's best to have a fixed range of values for power levels, so that all player scripts will have the right range to use.
Supporting 2+ cutins on each side of a talk event.
(Lyrica's scenario in Touhou Kaeidzuka)
Here's a thought: instead of a mandatory specific number of levels, have the player-script specify a "max power" and (maybe/optionally) a "minimum power" like how UFO has 1.00 as its minimum, and when the stage-script calls for a power-level change, round it to the nearest available fraction-of-the-max-level in the player-script. So, let's say, if a stage-script was expecting 0-7, and the player-script had 1-4, then:
When the stage-script asks for: 0 1 2 3 4 5 6 7 ... the player-script returns: 1 1 2 2 3 3 4 4
Also, maybe some sort of multiplier for how much point-items are worth, like how in SA, Marisa-Alice gains a level for every 12 point-items, but everyone else gains a level every 20 point-items.
In a way you don't really need a min power; Its probably better to just keep power as a variable unsignedbyteint (considering UFO). I think its easier to just to set a game var "number of power items to max" and player script to assign "X number of levels" so all the game needs to do is "game p items to max" divided by "X levels per player" to find how many items it takes to level up. The whole thing with 1.00 starting power, or decimals for that matter is pure aesthetics, it can be probably be handled in the game ui ? taking "x powerups to level up" divided by say ... 20. and you'll have MoF style output. divided by 100 + 1.00 and you got UFO.
Its still problematic should someone want to create a non straight forward power up system though; like if you use different item power up items that does different things. The assumption on that I guess is if someone is going to use a very unique power up system for their game, its going to be restricted to their own custom player scripts anyway. Leaving default power up handling like so, for the one shot stage creations.
Supporting 2+ cutins on each side of a talk event.
(Lyrica's scenario in Touhou Kaeidzuka)
v.v If you must. Though I'd still like to see the hard max a notch or two above the conventional max.
Musuu
Script[mdBase]
/ A thing
Object_Type Effect A thing
/ initialize script
Script initialize
/ Initialize the global a
add #a, 1.0, 1.5
/ Set our size
obj_get_id !tmp
obj_set_size !tmp, 100, 150
/ tick script
Script tick
/ change the value of the global a
sub #a, #a, 0.1
/ collide1
Script collide Effect
/ change the value of the global a
add #a, #a, 100000
/ collide2
Script collide2 A thing
/ change the value of the global a
add #a, #a, 100
/ Player type
Object_Type Player A player
Script initialize
obj_get_id !tmp
obj_set_size !tmp, 5.0, 7.0
obj_set_image !tmp, "test1.png"
/ Pyro-Reimu :V
Object_Type Enemy Pyro Reimu
/ initialize script
Script initialize
obj_get_id !tmp
obj_set_size !tmp, 5, 8
obj_set_image !tmp, "reimu1.png"Never seen a language where you have to specify the scoping in your references. Variable shadowing is generally a good thing.
- Boolean literal: true or false
- Numeric literal: just the number - 5.0, 65536
- String literal: string in doublequotes - "A string"
- Local variable reference: !variable_name
- Object variable reference: @variable_name
- Global variable reference: #variable_name
!a = true
!b = !!a
Or will there be no '!' operator?My idea was actually more of a sort of hybrid: you'd define how many levels the player can handle in the player script, and the stage-script would define how many levels we're supporting in this game. If the stage-script has more levels, it doesn't level the player up until it's reached a level that does correspond with a player's level; it the player-script has more levels, it skips levels. The advantage is that, in this respect at least, all player-scripts will be compatible with all stage-scripts. The disadvantage is that the increase would be somewhat uneven if the player's number of levels and the stage's number of levels don't factor well with each other.
Regardless, I still say this should be part of a "default script which comes with the game" rather than making any of it hardcoded, since "hardcoded" by definition means "someone would have to do all sorts of unnecessarily-complex juggling with the scripts if they didn't want to do it the hardcoded way."
Never seen a language where you have to specify the scoping in your references. Variable shadowing is generally a good thing.
This is not what script file code will look like
Musuu
Script[mdScript]
// Declare "difficulty" as a global variable - accessible everywhere
global difficulty;
Object_Type Enemy "Pyro-Reimu"
{
// Declare "counter" as an object variable - accessible from all scripts on this object
define counter;
tick
{
// "temp" is a local variable - will be only accessible in this tick script
let temp;
}
}Also:Code: [Select]!a = trueOr will there be no '!' operator?
!b = !!a
As I mentioned before, mdBase is basically a direct translation of the internal structures used to hold code internally for the Execution Engine. By the time the script reaches this point, all variable scoping has already been determined, so that the Engine can quickly know where to look for the value.
script --[compiles_to]--> mdBase --[lex,parse]--> interpreter
var a;
var b;
if (blah) {
var a; //Is this decl allowed?
b = a; //How would you compile this line to mdBase?
}
In a way, this is pretty much what I was saying, albeit with a couple different details. The way I suggested above also leaves all player scripts usable with all stage scripts - stage scripts controls how where player's power level is within a scale, and the player scripts then uses that value to determine how strong of an attack to fire.Hmm. If I'm interpreting this right, this actually works better than the way I had it in some ways.
As far as hardcoding things is concerned - if you don't want to use the hard-coded power system, just don't enable it and don't use the default, provided-by-the-program power items. I do think, though, this system would be flexible enough to handle many variations on the Touhou-style power systems, at least; also, if there is demand other power system templates could be coded/scripted as well.Well, one of the things I had a problem with was hardcoding the number of power levels, which would restrict things.
[/pirate]
Just about the effects that surround the boss, it's obvious what the spell circle does, first of all.
(http://img198.imageshack.us/img198/2162/eff01.png)
The ones surrounding the boss are in here. Slightly different in each game, but the middle one kind of blurbs around the middle of the character and the top four bits start off big, then shrink towards the center, creating some sort of weird effect. A red version of the left thing starts flat and grows upwards. All this together makes the aura thing.
Upon analysis of the distorting space, it comes down as an asymmetrical pattern. I'm fairly sure it's a near-perfect circle. The "Border of Spell" circle that surrounds it is just the same graphic but rotating. It's not affected by the distortion. In fact, the only thing affected is the background. Although considering I don't know how the effect works, I don't know if he has a graphic associated with it.
Also, upon more analysis Hele's cut-in script still needs some work :V
Also, the collision detection sounds great.
[pirate]
The ones surrounding the boss are in [image]. Slightly different in each game, but the middle graphic kind of blurbs around the middle of the character and the top four bits start off big and outside the character, then shrink towards the center. The left thing starts flat and grows upwards. All this together makes the aura thing.Sorry, this was the only part that you needed to pay attention to. I wasn't sure on anything about the distortion.
So:Code: [Select]script --[compiles_to]--> mdBase --[lex,parse]--> interpreter
That still leaves the question of shadowingCode: [Select]var a;
var b;
if (blah) {
var a; //Is this decl allowed?
b = a; //How would you compile this line to mdBase?
}
Well, one of the things I had a problem with was hardcoding the number of power levels, which would restrict things.
And by "not wanting to use it" I meant "not wanting to use a Touhou-style power system." Granted, with only a few minor adaptations you can make it into ... well, just about any other power system. I mean, you couldn't really do a Suguri-style energy-system with it, but ...
Well, the way Suguri's "power" system works is more like a fighting game: as you attack enemies, a gauge fills up, and you can use it to do super-moves, but your actual attack-power doesn't change or increase. This also replaces bombing.
If (PlayerName == "Reimu") {
<load Satori boss graphic>
} Else {
<load Reimu boss graphic>
}orIf (PlayerShoelaceIsUntied) { blahblahblah } Or whatever. (Also, this way, we could have a tag like "PlayerHasSuperPower" that identifies power definitions above whatever we decide as a max. :V No ulterior motives here! >.>;; )
AddTag("Reimu")
AddTag("Homing")
AddTag("Human")
AddTag("Solo")
AddTag("Superpower")And then menu scripts can filter the player lists based on tags that are/aren't included, stages can have different things happen depending on what properties the player has, and generally there's a lot more room for creativity.
>.< Blargh. Yet more proof that I shouldn't be allowed to post at 4 AM. Lemme try this again:... now that would be badass.
I think player scripts should be allowed to define a slew of tags that stage and menu scripts can tweak on. For example, a player script might have a section that looks something like this:Code: [Select]AddTag("Reimu")And then menu scripts can filter the player lists based on tags that are/aren't included, stages can have different things happen depending on what properties the player has, and generally there's a lot more room for creativity.
AddTag("Homing")
AddTag("Human")
AddTag("Solo")
AddTag("Superpower")
I'm trying to think of a system for handling power levels that's going to allow us to standardize our player scripts and have them function correctly despite having different numbers of power levels.
Perhaps power levels should be tracked by percent? i.e. the stage script defines the maximum amount of power you can have, and the player script bases its current power level on how much of a percentage of that maximum they have. Like for instance the player script will say,
if(PowerRatio()>=0.5 && PowerRatio()<0.75){PowerLevel=2;}
where PowerRatio represents the percentage (0.5 being 50%).
Like, say a given stage script has a maximum of 400 power.
PCB-style Reimu has 8 power levels past 0, broken up into 12.5% increments.
SA-style Reimu has 4 power levels past 0, broken into 25% increments.
That way when they're at 200 power, PCB-Reimu will have her level 4 shot and SA-Reimu will have her level 2 shot, which are supposedly equal in effectiveness despite different numbers of levels.
Hey, any chance we may see support for menu scripts?
So far in danmakufu, I know there are different typrs. But none specifically for menus (Is there?)
So I figure, why not a menu type for scripts that will allow us to select character, difficulty, etc.?
In other words, to tweak variables and to load up stage scripts, as well as allowing activation of other scripts once a requirement has been met (Such as extra/phantasm stages)
If I didn't put this in the right words, could a moderator please help? Because custom menus in danmakufu is currently hard as heck to make, and this could really take away from the stress if support is pre-built
>.< Blargh. Yet more proof that I shouldn't be allowed to post at 4 AM. Lemme try this again:
I think player scripts should be allowed to define a slew of tags that stage and menu scripts can tweak on. For example, a player script might have a section that looks something like this:
Code: [Select]
AddTag("Reimu")
AddTag("Homing")
AddTag("Human")
AddTag("Solo")
AddTag("Superpower")
And then menu scripts can filter the player lists based on tags that are/aren't included, stages can have different things happen depending on what properties the player has, and generally there's a lot more room for creativity.
Hmmmmmm...Could you be a bit clearer about what you mean? :o
Life piece enabling/disabling, like in Chireiden/Seirensen (enabling) or in Koumakyou/Youyoumu/Eiyashou (disabling)
Am I missing something? This sounds pretty much like the idea we've been throwing around, except you're using a percentage rather than a set of numbers.
Could you be a bit clearer about what you mean? :oUm, you know about those purple stars that the enemy characters drop (and even that one fairy in SA stage 4)?
Could you be a bit clearer about what you mean? :o
I think he means the life parts that the SA bosses drop whenever you finish a non-spell or spell card without dying or the ones that the red UFO drops in UFO...Yeah, what Kyle said. Also, I don't think it appears in MoF.
Ah, I see, yeah.Hmmmm... thanks for reminding me, I just finished an experiment with common data, and this thing that works ALMOST like the life pieces.
Honestly, something that would make me super, super, happy... would be that this version be compatible with Mac OS X, and Linux.
Fourth Item: Implementation:
As I mentioned previously, this would be implemented using SDL.NET and OpenGL in C#. The main advantage of this is that it should be entirely cross-platform portable (without even recompiling!) using Mono.
>.< Blargh. Yet more proof that I shouldn't be allowed to post at 4 AM. Lemme try this again:This person is thinking. I like it.
I think player scripts should be allowed to define a slew of tags that stage and menu scripts can tweak on. For example, a player script might have a section that looks something like this:Code: [Select]AddTag("Reimu")And then menu scripts can filter the player lists based on tags that are/aren't included, stages can have different things happen depending on what properties the player has, and generally there's a lot more room for creativity.
AddTag("Homing")
AddTag("Human")
AddTag("Solo")
AddTag("Superpower")
What about system requirements? Do you think this will use more or less power when compared to Danmakufu?
Btw, I like how this project is so serious. We really need a better engine to work with...
PS: I don't know how to code anything, but I'm never looking forward to use danmakufu if I have anything else to spend time on.
So is this going to have multicore support ? :V
What about system requirements? Do you think this will use more or less power when compared to Danmakufu?
This is being built from the ground up to replace danmakufu isn't it? I'd assume its suppose to be faster...
So is this going to have multicore support ? :V
Danmakufu runs on multiple cores, so I hope to God on high that this will as well.
I noticed the plan is to use a single "numbers" data type for all numbers; I can see the simplicity in that, but feels kinda memory expensive if you were to like use doubles for all numbers.
I've got another possibly nooby question.
As far as I know, Danmakufu couldn't make games with a Phantasmagoria (versus type) set-up.
Seeing as how this seems to be based on the standard setup of a standard Touhou game, I doubt it will be the case here either, but just ofr the sake of asking, will it be possible to set-up a game to follow a Versus shooter set-up?
Also, going back to the Suguri thing that was mentioned previously - implementing the "Power up for Super Move" thing would be as simple as setting the script so that the Player gains a Bomb after collecting a certain number of items (of your choosing).
The Power Graphic can be represented with a little bar on the screen, and your actual player-shot will never change power. Since Suguri gains Power by destroying enemies, you can just set all enemies to drop a specific item, which you can then set to auto-collect upon appearance, which will then boost your "Power", which will then modify the graphic you set on the screen.
...did that make sense?
Adding support for TSS/PoDD/PoFV-style versus mode is certainly possible.
Given how different that type of game is though, it might be wiser to make a separate executable based of the same engine that would do this type of game.
Collision I'm worried about it being messed up if a bullet happens to be flying stupidly high speeds,it might worsen the desync problem. Timing is everything. Are there speed limits for bullets? :V
Rendering generally shouldn't be an issue, but if splitting the collision detection into a different thread is feasible for you, go for that. I think it might be actually slower(check me on this), especially if you're using non-rectangular shapes for collision masks.
A possibility is just to have a separate thread running that will check if anything on the screen is colliding(important things - player with enemy bullet, enemy with player bullet) and updating some kind of data structure with that information, so all the main thread has to do is go through and deal with them appropriately(using a mutex, waiting for the lock). I don't think you should put that in another thread because of desyncing problemsand I only have two cores.
But then again, I'm not too experienced with threads. ><; Just thought I'd throw that out there.
I see what y
Collision I'm worried about it being messed up if a bullet happens to be flying stupidly high speeds,it might worsen the desync problem. Timing is everything. Are there speed limits for bullets? :V
Mutlithreading scripts looks a bit nasty to me though; Depending on the person writing the script, bloated scripts might just out right crash the engine for instance, unless, you can really make the scripting idiot proof somehow... :V
I say split rendering. Higher level scripts usually take tons of data just in rendering and effects, it's likely that splitting it between cores would improve performance more than script splicing and splitting the collision functions.
Musuu
Script[mdBase]
/ Effect object - Starter
/ Should be spawned once when the game starts
/ Creates all necessary objects, then deletes itself
Object_Type Effect Starter
Script initialize
obj_create !id, "ThePlayer", 213, 400
obj_create !id, "TheEnemy", 213, 100
obj_get_id !id
obj_destroy !id
/ Player ThePlayer
/ object for the player
Object_Type Player ThePlayer
Script initialize
obj_get_id !tmp
obj_set_angle !tmp, 0
obj_set_speed !tmp, 0
obj_set_image !tmp, "test1.png"
obj_img_rotate !tmp, false
obj_set_pmove !tmp, 5.4, 3.2
obj_set_size !tmp, 2.2, 5
obj_set_layer !tmp, 20
/ Right now, we need to have the collision scripts here,
/ since we can't get the object ID of the other object
/ collided with yet. This will, of course, change later.
Script collide Boss
obj_get_id !tmp
obj_destroy !tmp
Script collide Enemy_Shot
obj_get_id !tmp
obj_destroy !tmp
/ Boss TheEnemy
/ boss object
Object_Type Boss TheEnemy
Script initialize
obj_get_id !tmp
obj_img_rotate !tmp, false
obj_set_size !tmp, 16, 20
obj_set_image !tmp, "reimu1.png"
obj_set_layer !tmp, 30
add @count, 60, 0
Script tick
sub @count, @count, 1
less !tmp, 0, @count
jmp !tmp, 12
add @count, @count, 20
div !inc, 1.5707963267948966192313216916398, 20
add !ang, 3.9269908169872415480783042290994, 0
/ loop to create a spread of shots
obj_create !id, "AShot", 213, 100
obj_set_angle !id, !ang
obj_set_speed !id, 2.5
sub !ang, !ang, !inc
less !res, 2.3, !ang
jmp !res, 6
/ Enemy_Shot AShot
/ basic shot type. Won't be needed in the long run, since
/ a default type will be supplied by the program.
Object_Type Enemy_Shot AShot
Script initialize
obj_get_id !tmp
obj_set_image !tmp, "shot1.png"
obj_set_size !tmp, 5.5, 7.5
obj_set_layer !tmp, 40
Looks awwwwwright
Oh, how does it determine drawing priority for bullets? The shot overlap looks really odd.
This looks brilliant. The script syntax you made is strangely similar that of an MMOG programming language I code in frequently, so I feel like I already know how to script it.
Looking forward to its completion, I'll definitely be using it once its released. ;D
I know, I know, I saw the examples.
Frankly, while an easier collision detection mechanism would be better, I'd much prefer a freer graphical system, especially regarding the sidebar. Danmakufu requires too many workarounds to get at that.
You are aware that you're not actually supposed to plug a monitor in to the back of a microwave, aren't you?But it's cool
Frankly, while an easier collision detection mechanism would be better, I'd much prefer a freer graphical system, especially regarding the sidebar. Danmakufu requires too many workarounds to get at that.
Anything new to report, NC?
A custom GUI system would be awesome, with changeable fonts and all because the font Danmakufu uses isn't SUPERFLASHY.
Nice to know this is more affordable. Danmakufu lags even without any script being run here.
You are aware that you're not actually supposed to plug a monitor in to the back of a microwave, aren't you?
But it's cool
:cool:
Nuclear Cheese,
Can you put on the same hat as Remilia, same outfit and some wings ...
Aside the ass licking:
Forgive me for following this thread at a bad pace ( I should be ashamed for being one of the danmakufu scripters who pushes their work till the limits ).
I will try to catch up from page 6 (where I was last left) and see if I got anything useful to add. ( Imo you should also have some kind of blog/webpage where you can write progress easier and faster ) but I guess a forum is more personal and nice.
Hmm. I don't mean to push you back a few steps, but wouldn't it be better to have a general "item" class and determine what each type of item does by scripts? Or am I taking the name too literally?
I really need to get into ANTLR more and figure out how exactly to get it to do what I want it to, so that we can get a real scripting language in here already. That would really kick ass.
... unless someone else wants to take up that end of things? Any volunteers? If we could at least get a grammar in place for the script language (mdScript?), it'd make things easier.DoublyTriply so if it outputs mdBase, since that would trivialize the part of then getting it into the engine itself.
global stuff;
enemy "A thing"
{
define my_stuff;
initialize
{
my_stuff = 5 + Get_ID();
Set_Stuff(my_stuff, 1);
}
tick
{
my_stuff = my_stuff * 2 + 1;
New_Stuff(my_stuff, 2+1/3, More_Stuff(my_stuff + 1));
}
collide "Super Shot"
{
Obj_Destroy(Get_Collided_ID());
}
collide_2 "A thing"
{
my_stuff = my_stuff + 1;
}
}
enemy_shot "Super Shot"
{
define lol;
tick
{
Obj_Set_Angle(Get_My_ID(), Get_Angle_To_Player());
}
}Object_Type enemy A thing
Script initialize
callret "Get_ID", !0
add !1, 5, !0
set @my_stuff, !1
call "Set_Stuff", @my_stuff, 1
Script tick
mul !0, @my_stuff, 2
add !1, !0, 1
set @my_stuff, !1
div !0, 1, 3
add !1, 2, !0
add !2, @my_stuff, 1
callret "More_Stuff", !3, !2
call "New_Stuff", @my_stuff, !1, !3
Script collide Super Shot
callret "Get_Collided_ID", !0
call "Obj_Destroy", !0
Script collide_2 A thing
add !0, @my_stuff, 1
set @my_stuff, !0
Object_Type enemy_shot Super Shot
Script tick
callret "Get_My_ID", !0
callret "Get_Angle_To_Player", !1
call "Obj_Set_Angle", !0, !1Loop_Start:
/ some loop stuff
/ .
/ .
/ .
/ If !continue_looping is true, we'll jump back to the label above.
jmp !continue_looping, "Loop_Start"Yes, while-loop is good. Also for-loop. And for-each would be splendid, too, I spose ...
// Starter object
// Temporary object used to spawn the boss and the player
// Will be unnecessary once the program can figure out what to spawn on its own.
Effect "Starter"
{
initialize
{
Create_Object("ThePlayer", 213, 400);
Create_Object("TheEnemy", 213, 100);
my_id = Get_My_ID();
Destroy_Object(my_id);
}
}
// ThePlayer
// Player object
Player "ThePlayer"
{
initialize
{
Set_Image("test1.png", false, 20);
Set_Player_Movement(5.4, 3.2);
Set_Size (3.2, 16);
}
}
// TheEnemy
// Enemy boss that makes some fucking danmaku.
Boss "TheEnemy"
{
define count;
initialize
{
Set_Image("reimu1.png", false, 30);
Set_Size(24, 30);
count = 60;
}
tick
{
count = count - 1;
// When count reaches zero, we fire a spread of bullets, and spawn a point item.
if (count <= 0)
{
// Adjust the "20" here to change the frequency of firing spreads.
count = count + 20;
// Adjust the "20" here to change the density of spreads.
increment = 1.5707963267948966192313216916398 / 20;
angle = 3.9269908169872415480783042290994;
while (angle > 2.3)
{
Fire_Shot_01(213, 100, angle, 2.5, "shot1.png");
angle = angle - increment;
};
Create_Object("Point_Item", 213, 100);
};
}
}Musuu
Script[mdBase]
Object_Type Effect Starter
Script initialize
call "Create_Object", "ThePlayer", 213, 400
call "Create_Object", "TheEnemy", 213, 100
callret "Get_My_ID", !0
set !my_id, !0
call "Destroy_Object", !my_id
Object_Type Player ThePlayer
Script initialize
call "Set_Image", "test1.png", false, 20
call "Set_Player_Movement", 5.4, 3.2
call "Set_Size", 3.2, 16
Object_Type Boss TheEnemy
Script initialize
call "Set_Image", "reimu1.png", false, 30
call "Set_Size", 24, 30
set @count, 60
Script tick
sub !0, @count, 1
set @count, !0
less !0, @count, 0
equ !1, @count, 0
add !2, !0, !1
not !3, !2
jmp !3, "Label0"
add !0, @count, 20
set @count, !0
div !0, 1.5707963267948966192313216916398, 20
set !increment, !0
set !angle, 3.9269908169872415480783042290994
Label1:
less !0, 2.3, !angle
not !1, !0
jmp !1, "Label2"
call "Fire_Shot_01", 213, 100, !angle, 2.5, "shot1.png"
sub !0, !angle, !increment
set !angle, !0
jmp true, "Label1"
Label2:
call "Create_Object", "Point_Item", 213, 100
Label0:I'm assuming you want an easy way to iterate over an array? That could be useful, once I actually put support for arrays in.Just so!
I have something I would LOVE for you to add!Yes.
The ability to convert a pile of scripts into a .exe for everyone to play regardless of having danmakufu.
Oh and those floaty things around the boss are annoying IMO
Oh and those floaty things around the boss are annoying IMOMaybe give enemies an "effects surrounding sprite" part of their script, and the default-scripts for the boss would have an "effects surrounding boss" which you could turn off, maybe ...
Just so!
Also, I have a bad feeling about trying to make focus hardcoded, since not all games would necessarily use Focus. (Or they might do it differently -- just look at StB. And in Suguri, instead of "focus", it has dashing, which makes you invincible to bullets (but not collisions or missiles).) Not saying you shouldn't do something like that (we've already had this discussion with Power), but just throwing out comments. Can you tell I'm prejudiced in favor of making it more flexible as opposed to true-to-Touhou?
I have something I would LOVE for you to add!
The ability to convert a pile of scripts into a .exe for everyone to play regardless of having danmakufu.
- Set_Image - parameters: image, rotate, layer
rotate is a boolean that determines if the image will rotate with the object's angle or not.
layer is the graphic layer to draw the image on.
object
rotate
Is that object rotation I'm hearing? How splendid! Now I won't have to make and delete objects in a loop while auto-setting a new Z parameter for a rotation angle. I also had to manually set the new X and Y positions for movement, and a direction angle, and speed, just to get the object to move from one point to another at an angle I want while rotating. Because SetSpeed doesn't work if the object will be deleted a frame after it's fired.
Keep doing whatever you're doing. I love the sound of this.
Now I won't have to make and delete objects in a loop
Umm ... right now, this rotation is the same as the object's facing angle, which is the direction it will move when its speed is greater than zero. Just like in Danmakufu.
I'm pretty sure there's a way to make rotating shots in Danmakufu, though, and it'll get added into Musuu no Danmaku as well at some point.
... and please tell me you aren't really deleting and recreating objects every frame. That's rediculous! :vbang:
#TouhouDanmakufu[Stage]
#Title[Object loop]
#Text[rotation&movement]
#Player[FREE]
#ScriptVersion[2]
script_stage_main{
let imagefile = GetCurrentScriptDirectory ~ "leaf.png";
let resurrectionframe=0;
@Initialize{
LoadGraphic(imagefile);
blowingup;
}
@MainLoop{
yield;
}
@DrawLoop{
}
@BackGround{
}
@Finalize{
// clear the loaded image file from memory
}
task blowingup{ yield;
fireshot(80,60);
}
task fireshot(shots,time){ yield;
let total=0; let angleused=0; let angle=0;
loop(time){
total+=(shots/time);
while(total>=1){firstobjecteffect(angleused); angleused+=500/70; total--;}
yield;
}
}
task firstobjecteffect(angle){
///first and second row, rotation, movement, speed, and angle
///third for, scaling
///fourth row, colors and alpha value
let rotatez=0; let X=rand(-1,1); let Y=rand(-1,1); let AddX=0; let AddY=0;
let speed=rand(1,5); let Z=rand(0,360); let rotate=0; let rotation=rand(-2,2);
let addtoscale=0; let AddWhatToScale=-0.04; let Spawnscale=rand(2.5,5);
let red=rand(100,255); let blue=rand(100,255); let green=rand(100,255); let alpha=255;
loop{ let totalscale=Spawnscale+addtoscale; if(totalscale<0){totalscale=0;}
let objid = Obj_Create(OBJ_EFFECT);
Obj_SetPosition(objid,GetCenterX+X,GetCenterY+Y);
ObjEffect_SetRenderState(objid,ADD);
ObjEffect_SetTexture(objid, imagefile);
ObjEffect_SetAngle(objid,0,0,Z+rotate);
ObjEffect_SetScale(objid,totalscale,totalscale);
ObjEffect_SetPrimitiveType(objid, PRIMITIVE_TRIANGLESTRIP);
ObjEffect_CreateVertex(objid, 4);
ObjEffect_SetVertexXY(objid, 0, -17, 17);
ObjEffect_SetVertexUV(objid, 0, 0, 34);
ObjEffect_SetVertexColor(objid, 0, alpha, red, blue, green);
ObjEffect_SetVertexXY(objid, 1, -17, -17);
ObjEffect_SetVertexUV(objid, 1, 0, 0);
ObjEffect_SetVertexColor(objid, 1, alpha, red, blue, green);
ObjEffect_SetVertexXY(objid, 2, 17, 17);
ObjEffect_SetVertexUV(objid, 2, 32, 34);
ObjEffect_SetVertexColor(objid, 2, alpha, red, blue, green);
ObjEffect_SetVertexXY(objid, 3, 17, -17);
ObjEffect_SetVertexUV(objid, 3, 32, 0);
ObjEffect_SetVertexColor(objid, 3, alpha, red, blue, green);
yield; Obj_Delete(objid);
X+=cos(angle)*speed; Y+=sin(angle)*speed;
rotate+=rotation;
addtoscale+=AddWhatToScale;
if(totalscale<Spawnscale/3.5){alpha+=-17;}
}
}
}
While converting things into a standalone .exe would be a real bitch (and that's if it's "easy"), there is a plan to have a "compiled" script format, whereby you could just distribute the one big file with everything in it, along side the Musuu no Danmaku executable (possibly with other files that it needs and can't be packed easily).Well at least where you don't have to go through a menu screen like danmakufu, doesn't need AppLocale, and actually looks like a touhou game when you run it(Low priority IMO)
Take out all underscores in all functions, they are completely unnecessary. In addition to that, I'm still pretty sure it's completely unnecessary to add opening and closing bracks to functions that have no parameters (GetCenterX();, Main();, etc. versus GetCenterX;, Main;, etc.).
Enemy_Shot "Lol I'm a Bullet"
{
define GetSpeed;
initialize
{
GetSpeed = 5.0;
SetSpeed(3.0);
}
tick
{
temp = GetSpeed; // now what?
}
}How do you plan to handle micro-threads? Helepolis is teaching all the new recruits to program everything in tasks, so something similar would be preferred, if possible. Especially given the reason people have to learn using Helepolis' videos instead of the tutorials. I know you hate tasks, but I feel this will at least get rid of a lot of bitching in the near future.
// ... other stuff ...
Enemy_Shot "LolShot"
{
define count;
initialize
{
count = 0;
// Call the original shot init script, since
// it's overridden here.
EnemyShotInit();
}
tick
{
count = count + 1;
if (count = 60)
{
count = count - 120;
SetAngle(GetAngleToPlayer());
}
}
}Well at least where you don't have to go through a menu screen like danmakufu, doesn't need AppLocale, and actually looks like a touhou game when you run it(Low priority IMO)
The underscores are the way I usually type identifiers; if people would prefer underscoreless function names that can be arranged with ease.
As far as pulling the parentheses (brackets are {} ;) ) off of argumentless function calls, I don't like that, honestly - it makes the syntax ambiguous. There's nothing stopping you from defining a variable named GetSpeed (well, aside from good programming practice, but you don't design something like this assuming the user will never do something stupid ...), so if you write code such as:Code: [Select]...
By requiring the parentheses, we guarantee a lack of syntactic ambiguity in the script - that is, the parser can immediately be sure how something should be interpreted.
Besides, C/C++/C#/Java(if I remember correctly) all have it like this. :V
Well, correct me if I'm wrong, but isn't the usual way of using tasks is to create a separate task to control, say, an object bullet as it moves about the screen?
...
Correct me if I'm mistaken, but isn't this much like the typical use of tasks to handle object bullets?
Also - aren't tasks a more advanced topic to begin with? Shouldn't the new recruits be taught simple stuff first, like "how I shot bullet?" and such ???
Since it apparently wasn't addressed, object-object collision is absolutely ESSENTIAL. Some of the most creative danmaku of ever used object-object collision.Not addressed? It's already been implemented.
The underscore is completely unnecessary to type considering you're capitolizing the next word in the function anyway. Just seems like a needless use of two hands when typing, as well as affecting overall typing speed. I hate typing underscores, it's the slowest thing on the keyboard. Oh God.
Most programming languages do not allow you to name variables the same as built-in functions.
Danmakufu doesn't require you to do that, isn't it C-based (dipping in to territory I do not understand)?
That is a way to use tasks, yes. It is nowhere near the only way and is now not even the usual way to use tasks. I was referring to the ambigiuty between jumping between tasks using yield; (you once said something like "not knowing which task is run before another," or something similar, forgive me if I incorrectly paraphrase considering we actually know which tasks are prioritized before others), as well as them running alongside the @MainLoop as their own thread. Are you going to follow the same idea or what?
Take a gander. (http://www.youtube.com/watch?v=OYpwkQWGFbk)
Since it apparently wasn't addressed, object-object collision is absolutely ESSENTIAL. Some of the most creative danmaku of ever used object-object collision. Also, I don't mean to nag, but don't forget about common data files.
I'll stop bugging you now. =\ You're the strongest, NC.
Not addressed? It's already been implemented.
Random question time!
Can individual scripts be made into standalone .exe files? Saves the trouble of "you must download this, then this, then put this in lib, then uncomment line 9, then..."
Oh, and I had this crazy idea that would be for way, way, waaaay~ down the line -Please don't. It really isn't needed and will be nothing but trouble.
An integrated content distribution system that would allow people to upload and download scripts from the program itself to a server. Add in things like rantings, sorting by author/genre/etc, automated checking for updates, etc., and it could become some crazy-awesome setup.
Of course, this would be at the bottom of the feature list. :V
Well, I can take them [underscores] out - it's just a naming issue. Does anyone else here have an opinion?[/size]Underscore naming has been out of fashion since the mid-nineties.
Most programming languages do not allow you to name variables the same as built-in functions.Actually, most languages -do- allow you to name variables the same as functions. The only exception I can think of right now is some functional languages.
By the nature of multitasking, you generally aren't ever given a specific order that tasks/threads are run.Depends on your thread scheduler. It's certainly possible to activate each task once a frame in the same order.
The biggest obstacle there is saving off the call stack (which right now is done intrinsically by using recursive calls to Script.Run()*) and other necessary information so that it can be resumed later, while still allowing other scripts as well as other instances of the same script to run without interferenceImplement tasks scheduling as iterating over a list of generators (http://en.wikipedia.org/wiki/Generator_%28computer_science%29) and implementing the script yield using C# yield?
Not addressed? It's already been implemented.
Please don't. It really isn't needed and will be nothing but trouble.
Y'know, I think the EXE thing is starting to get popular enough that you should at least consider it.
If nothing else, just an "EXE which has its own specified icon and automatically loads a given compiled script/set of scripts, possibly with no other functionality for selecting other scripts" ...
Underscore naming has been out of fashion since the mid-nineties.
Depends on your thread scheduler. It's certainly possible to activate each task once a frame in the same order.
Implement tasks scheduling as iterating over a list of generators (http://en.wikipedia.org/wiki/Generator_%28computer_science%29) and implementing the script yield using C# yield?
Musuu
Script[mdScript]
Enemy "ImaBoss"
{
// A task to control movement
task movement_task
{
while (true)
{
yield 31;
MoveToSomeOtherRandomPosition();
}
}
// A task to control shots
task shot_task
{
while (true)
{
yield 23;
FireSomeFuckingDanmaku();
}
}
initialize
{
// Run the two tasks
movement_task();
shot_task();
// Other initialization stuff
SetLife(100);
SetScore(9);
}
}One last thing: will we ever see a song looping function or two? =\
Failing that, I have a backup plan which will require a small bit of work on the scripter's side - split the song into two files: one for the intro (before the loop) and one for the loop. What will then happen is the intro file will be played once, and when that finishes the loop file will start playing and loop repeatedly. Syntax would be something like this:
PlayMusic("omgbestsongevar_intro.ogg", "omgbestsongevar_loop.ogg");
I think you'd do well to deal with infinite-loops by having it somehow check for them in a check-for-problems stage that it does before actually executing the script.
THAT WORKS.
Just need to confirm something, if we use:
PlayMusic("song",A,B);
will it start from 0:00, then play to B, then go back to A?
i want a music function that will make echo effects and reverse the clip and have it normalize the decibel peaks and add change the instruments in the song
Cause adjusting volume is totally on tier with that rightYou could just, you know, use audacity :V
You could just, you know, use audacity :VThat was my point
While on the subject of lol fun musics:
PlayMusic(music.wav, loop point A, loop point B, time taken to fade in [if 0 then no fade in will occur]);
FadeMusic(music.wav, number of frames to take to fade out music);
As you can see, if there is someway to control the volume of music over time then I think a fade in and out option should be implimented. This is particularly useful when transitioning between songs -- instead of the song ending abruptly and the new one starting immediately, you can have one fade out and the other fade in. This would be even better if you could play more than one song at a time. I seperated the functions because you may need to fade out depending on user inputs. Is something like this possible?
The idea was so that you could fade in a second song when you make the transition from stage to boss, which will not always happen at the same time due to fps lagging and any points where you need to rely on input from the player. Adjusting volume in a song is pretty hurr, I just wanted to know if we could make the song transitions a little smoother by adjusting it in any given script.
i want a music function that will make echo effects and reverse the clip and have it normalize the decibel peaks and add change the instruments in the song
No support for MP3....
HERE'S THE KNIFE CHEESE. PLUNGE IT INTO MY HEART.
Over-Drama aside, I'm loving your updates. xD I've missed quite a bit, so it's lovely catching up on it all and seeing how quickly it continues to progress.
That EXE option is very appealing, so I'll toss my opinion in on the consideration side - if you can manage it, it'd be awesome.
I have no real preference one way or another with how you choose to implement the scripting (underscores or nor, brackets, whatever and whatnot). As long as it's functional and I can work it, I don't care what it looks like.
xD Of course, I'm not being overly picky for the primary reason that CHEESE IS DOING US A GRAND FAVOR BY BUILDING THIS PROGRAM SO WE WILL ACCEPT WHAT HE GIVES US AND WE WILL LIKE IT.
Not an attempt to kiss up, I'm serious. =/ Seems like some people are being far too picky considering you don't HAVE to do this for us at all.
How about a way to set parents ? you know ? movement relative to another bullet ? EASILY ?
But what am I saying... nothing can be easy in danmaku. except some ⑨ stuff.
Basic fadeout/fadein I can do, pretty much 100% certain of it.
Cross-fading from one song to another might not be as simple, unfortunately. I think SDL's music functionality explicitly stops one music when you start another. I might be able to just use the sound effect channels for it instead, but I think that'd be a bit of a kludge.
...
...
...
... no.
Seriously, though, MP3 is a proprietary format, which means the SDL devs would need to fork out a licensing fee to have code in there to use it. Lame, but that's how shit rolls.
One question here is - if two different objects try to adopt the same child object, what happens? Either the first one wins, and we disallow reassignments until the child object is disowned or orphaned (parent object is despawned), or the second one wins, and we allow objects to steal other objects' children.
My recommendation here would be to, when something tries to adopt another object, check for a circular reference, and disallow it if it would cause such a problem.
Finally, if a child object is orphaned (parent object is depawned), do we just reset it to parentless, or do we set it to the original parent's parent, if any?
* Exception - Like I mentioned previously, I have a tournament tomorrow, so this weekend will probably be light on updates.
One question here is - if two different objects try to adopt the same child object, what happens? Either the first one wins, and we disallow reassignments until the child object is disowned or orphaned (parent object is despawned), or the second one wins, and we allow objects to steal other objects' children.
First one wins, so says my coin flip.
How would PODD stages even work?
How would one be able to code all the random fairies and the enemy AI?
No, I'd much prefer the latter as it would allow more freedom in how objects are controlled. If we want to make sure we're not grabbing children that have parents, there can be a function that checks that.
If we want to make sure we're not grabbing children that have parents, there can be a function that checks that.STRANGER DANGER!
PoDDanmakufu should be a seperate project.I agree with this post. Having it in the same program could complicate things.
He was just making fun of my request because he didn't actually think about how it could be applied. Such faith nowadays, it's hurtful :(
o u
Two questions
1. How far are you into creating this, if you are creating it?
2.
PoFV AND PoDD TYPE STAGES
(At least easier to make.)
Musuu
Script[mdScript]
include("ThePlayer.txt");
include("TheEnemy.txt");
Musuu
Script[mdScript]
// ThePlayer
// Player object
Player "ThePlayer"
{
initialize
{
Set_Image("test1.png", false, 20);
Set_Player_Movement(5.4, 3.2);
Set_Size (3.2, 16);
}
}
Musuu
Script[mdScript]
// TheEnemy
// Enemy boss that makes some fucking danmaku.
Boss "TheEnemy"
{
define count;
initialize
{
Set_Image("reimu1.png", false, 30);
Set_Size(24, 30);
count = 60;
}
tick
{
count = count - 1;
// When count reaches zero, we fire a spread of bullets, and spawn a point item.
if (count <= 0)
{
// Adjust the "20" here to change the frequency of firing spreads.
count = count + 20;
// Adjust the "20" here to change the density of spreads.
increment = 1.5707963267948966192313216916398 / 20;
angle = 3.9269908169872415480783042290994;
while (angle > 2.3)
{
Fire_Shot_01(213, 100, angle, 2.5, "shot1.png");
angle = angle - increment;
};
Create_Object("Point_Item", 213, 100);
};
}
}Also, are you going to release a tutorial, or at least a help file defining functions?
The Danmakufu wiki might end up being a good place for actual documentation ... perhaps we could start thinking about using that?
Also, I forgot in my last list - trig functions
Don't worry about ancillary trig functions, just sin and cos is needed for now (it's really all you ever need, so yeah).
But what about arctangent? :-Seems there's atan in Danmakufu...
But what about arctangent? :-Cos / Sin
Cos / Sin
Every trig function comes from sin and cos somehow so yeah
Needs atai() |3atai(9)
But what about arctangent? :-Don't forget atan2
Needs atai() |3
Cos / Sin
Don't forget atan2
FUCK YOU C++
Anyway, what about MOD/XM files, Cheese? They're pretty fucking awesome. You can save the trouble of defining loop points and doing it in the song itself. It's pretty much the shit.
Also, FYI - pulled straight from the SDL.NET wiki (http://cs-sdl.sourceforge.net/index.php/Audio), audio formats that are supported:
- WAVE files (.wav)
- VOC files (.voc, I believe)
- MIDI files (.mid, .midi)
- MikMod (.mod, .s3m, .it, .xm)
- Ogg Vorbis (.ogg)
umm ... no. That's tan.
Also, quick brainstorm while I was at work. I thought it would be quite empowering to allow the scripters to override the default, built-in scripts if they so desire.
Take, for example, the idea of coding an Ikaruga-type game. With this functionality in place, all you would need to do is override the default bullet collision functions (so that they check player/bullet color, etc), and then every bullet you fire (even ones of the default bullet type) will behave accordingly*!
What do you guys think? It sounds useful to me.
It's actually cotangent. Tangent is sin/cos. Arctan is it's reverse though, yes.Does this mean there will be pi? :p
Still on the topic of trig, make it so we can use radians. Far more useful, even if confusing to some.
It's actually cotangent. Tangent is sin/cos. Arctan is it's reverse though, yes.
Still on the topic of trig, make it so we can use radians. Far more useful, even if confusing to some.
Does this mean there will be pi? :p
I was under the impression this was already possible, though it was likely my imagination. So uh, yes! That would be awesome.
I have an uttermost important request:
Support for more keys
Seriously... The only extra key we have in danmakufu is C.
Support for a few more keys to activate abilities and such would be nice.
Is it bad that I read that as "atoi()" the first timeA TOY. (a truck.)
Would be really easy to add support for. Just need to add more bits to the input enumeration and define some controls to trigger them. Would probably take all of a minute to add to the code. :D
Main question is - how many buttons are we talking about? When I was developing SphereTide gunner, there were a couple people who commented that four buttons (slow, shot, and two bomb-related buttons) was pushing on too much. Now, that's certainly part opinion, but what I'm getting at is that it might be asking a bit much of the player to expect them to keep track of eight different buttons in addition to movement.
All of them. We're not expecting people to remember every button. Let player script have all the buttons needing definition. Have types like SHOT and BOMB, let the user define them at the beginning like KeyState(Shift, SLOWMOVE); or KeyState(Z, SHOT);, this way if the player wants to map out a completely different control interface, it is possible. Perhaps you can default everything to Touhou style, but let the controls be easily overwritten.
I may or may not be the first to make a full game out of this. (right now it's "Should I use danmakufu or wait for this")
Still on the topic of trig, make it so we can use radians. Far more useful, even if confusing to some.
Right now the engine uses radians in its entirety, actually.
Here's a thought: Being able to use your freaking keyboard to type in the name for the high score and replay, instead of selecting letters with the arrow keys. And maybe have a key to toggle between arrow keys/keyboard mode too, for good measure.
On topic of mathematical stuff, you do have exponentiation and roots (at least the square one) in? Since the Pythagorean theorem does have it's uses...
Here's a thought: Being able to use your freaking keyboard to type in the name for the high score and replay, instead of selecting letters with the arrow keys. And maybe have a key to toggle between arrow keys/keyboard mode too, for good measure.
Actually, while I'm at it, why not extend the number of characters you can use when typing in the name of a replay or high score entry beyond what it is in danmakufu and the official touhou games?
YESSSSSSSSSSSSSS!
Seriously, this is one thing I don't like in DMF. Accursed 360/6.28 factors when doing crazy angular velocity calculations like circular homing. This will make my life so much easier!
On topic of mathematical stuff, you do have exponentiation and roots (at least the square one) in? Since the Pythagorean theorem does have it's uses...
(does it even have a scoreboard yet).
What the heck is a radian?
ascent(i in 0..num)
{
CreateShot01(GetX, GetY, 2, rad(2*pi/num)*i, RED01, 10);
}So how would you make a shot circle with radians if a circle can't be broken into an even number of them? 360 can be neatly divided so many ways!Which is why some programs use [0,511] since that divides even better.
As I am not a trigonometry major and probably younger than a lot of you, I haven't the foggiest idea what all this crazy arcsine junk is, and RADIANS... well lets not even go there.
Point is, I hope you give the option to use radians. Some of the less in-the-know people would much prefer to use degrees.
Um, we will be able to use either radians or degrees based on preferance, right? I'm having difficulty wrapping my head around why we have radians, let alone how they'd be more useful than degrees.
I think radians are good for lazy people if you like working with even divisions of 360 and don't want to do some quick mental math. i.e. "Hm, I don't know what 360/46 is, so I'll just make my angle increments equal to pi/23".
I'd like the option, but I like sticking with degrees. What would it default to, NC?
Let it default to degrees, and have a simple function switch it to radians for the rest of the script. In the rare event that someone wants to use both degrees and radians for something, it would also be nice to have a conversion function, like "let InRadians = Radian(x);" and "let InDegrees = Degree(x);".
Fffff
So how would you make a shot circle with radians if a circle can't be broken into an even number of them? 360 can be neatly divided so many ways!
Coming from someone who knows nothing: 2pi rad is 360 degrees, so 2pi/10 rad or pi/5 rad is 36 degrees, for example.
Thus, in Danmakufu:Code: [Select]ascent(i in 0..num)
{
CreateShot01(GetX, GetY, 2, rad(2*pi/num)*i, RED01, 10);
}
If we assume rad(x) makes the program read x as radians, or something.
I bet I'm totally wrong, since I really don't see the advantage over using radians when you can just divide in 360 instead of 2pi. Maybe I'm missing the point because I know nothing about the subject? Also, it doesn't NEED to be broken into an 'even number of them'. You can still divide a ring into 31 bullets in Danmakufu, despite 31 not being a factor of 360.
On a related thought - does anyone see any usefulness in having a function that returns whether radians or degrees is currently selected?Nah, I don't think so, because it would be a bitch to work with both at the same time, and you pick one at the start like you said.
It's always better to have extra useless functions than to be missing one that could potentially be useful later on. I say to add it just for the one oddball case way down the road that might require it.
This. Everything that you can set you should be able to get, as a rule. You never know.Seconded. And in this case it's just a boolean.
I do think it would be good to have the option for using either for the trig functions/angle/etc.Having switches like that can become a bit confusing (think about Object.GetAngle!).
As far as a default, it seems most people want degrees as the default, it seems that most people want degrees. The plan is to have a command to switch it, which will be remembered for each object (so set it once in initialize and you're good to go).
angle_t a = degrees(270);
a += radians(PI);
print(a.degrees()); //prints 90 (not 450)
How would the values be stored, though? I have this vision of "dodgeThis.getDegrees()" where the "dodgeThis" angle was set as radians, and getting a result like 44.99999999875 or whatever instead of 45.A difference of 0.00000000125 shouldn't be noticeable.
(Furthermore, if we want to be compatible with Everything Else, it should be easy for a script to get at everything someone else's script did ...)
Maybe you can promote angle to a type:Code: [Select]angle_t a = degrees(270);
a += radians(PI);
print(a.degrees()); //prints 90 (not 450)
Musuu
Script[mdScript]
// TheEnemy
// Enemy boss that makes some fucking danmaku.
Boss "TheEnemy"
{
define count;
define move;
initialize
{
SetImage("reimu1.png", false, 30);
SetSize(24, 30);
count = 60;
move = 0.5;
UseRadians(true);
}
tick
{
SetX(GetX() + move);
if (GetX() > 350)
{
move = -0.5;
}
if (GetX() < 76)
{
move = 0.5;
}
count = count - 1;
// When count reaches zero, we fire a spread of bullets, and spawn a point item.
if (count <= 0)
{
// Adjust the "30" here to change the frequency of firing spreads.
count = count + 30;
bullets = 11;
increment = 1.5707963267948966192313216916398 / (bullets - 1);
angle = 3.1415926535897932384626;
player_id = GetPlayerID();
if (player_id > -1)
{
ydiff = ObjGetY(player_id) - GetY();
xdiff = ObjGetX(player_id) - GetX();
if (xdiff == 0 && ydiff == 0)
{
// Just in case ...
ydiff = 1;
}
angle = arctan2(ydiff, xdiff);
}
angle = angle - (increment * ((bullets - 1) / 2));
while (bullets > 0)
{
FireShot01(GetX(), GetY(), angle, 2.5, "shot1.png");
angle = angle + increment;
bullets = bullets - 1;
};
CreateObject("EvilShot", GetX(), GetY());
CreateObject("PointItem", GetX(), GetY());
};
}
}
Enemy_Shot "EvilShot"
{
define count;
define next_count;
initialize
{
SetSize(5.5, 7.5);
SetAngle(180);
SetSpeed(1.5);
count = 60;
next_count = 90;
// Call the internal bullet init function to ensure standard stuff is setup
enemy_shot_init();
SetImage("shot2.png", true, 55);
}
tick
{
count = count - 1;
if (count <= 0)
{
count = next_count;
next_count = next_count + 30;
player_id = GetPlayerID();
if (player_id > -1)
{
ydiff = ObjGetY(player_id) - GetY();
xdiff = ObjGetX(player_id) - GetX();
if (ydiff == 0 && xdiff == 0)
{
ydiff = 1;
}
SetAngle(arctan2(ydiff, xdiff));
}
}
}
}
- A sample script, along with images (yes, I know the "point item" image looks too much like another shot. I'm not an artist. :V)
Anyways, it's pretty great already.
I don't really seem to fit with not being able to have the triangle respawn. You know what I'm saying?
For me it just says it has encountered a problem and needs to close :/Not yet, remember that Nuclear Cheese needs more time to put that in.
Edit: Nevermind I saw I didn't unpack a file.
Works awesome.
Is there a function similair to SetShotDataA?
Works awesome.
Is there a function similair to SetShotDataA?
Not yet, remember that Nuclear Cheese needs more time to put that in.
Okay, so main things I see big need of in next update in order of importance:
Respawning (VERY high priority)
Shots (High Priority)
Bombs (low priority)
Live Stock (low priority)
Bomb Stock (low priority)
Point system (low priority)
Graze System (low priority)
Then some things that I would like to see in the long run:
Icon :V
Built-In Graphics
An ability to switch on/off the menu that danmakufu has (It's good for playing others' script, but it would be annoying to go through that process just to get to your script and having to quit and reenter just to see your player edits and this is one of the most annoying things about danmakufu for me :V)
Musuu no Danmaku version 0.1.3591.29235
Starting logging file ...
2009 <march> 01 10:18:02.704 - Initializing engine ...
2009 <march> 01 10:18:02.782 - Error during initialization: <The type initializer of> SdlDotNet.Graphics.Video <caused an exception>.
Stack trace:
<at> SdlDotNet.Graphics.Video.SetVideoMode(Int32 width, Int32 height, Boolean resizable, Boolean openGL, Boolean fullScreen, Boolean hardwareSurface)
<at> Musuu_no_Danmaku.Graphics.Initialize()
<at> Musuu_no_Danmaku.Program.Main(String[] args)
The program will close now.Musuu no Danmaku version 0.1.3591.29235
Starting logging file ...
2009 marras 01 17:46:08.703 - Initializing engine ...
2009 marras 01 17:46:09.546 - Loading script objects ...
2009 marras 01 17:46:09.562 - Creating new Game object ...
2009 marras 01 17:46:09.593 - Error during initialization: Input string was not in a correct format.
Stack trace:
at System.Number.StringToNumber(String str, NumberStyles options, NumberBuffer& number, NumberFormatInfo info, Boolean parseDecimal)
at System.Number.ParseDouble(String value, NumberStyles options, NumberFormatInfo numfmt)
at System.Double.Parse(String s, NumberStyles style, NumberFormatInfo info)
at Musuu_no_Danmaku.mdBaseReader.Parse_Instruction_Line(String line)
at Musuu_no_Danmaku.Game..ctor()
at Musuu_no_Danmaku.Program.Main(String[] args)
The program will close now.It's apparently erroring for me, even though I ran both the SDL.NET runtime and the Tao framework runtime installers. Platform is Windows Vista Home Premium. The scripts being run are the default ones. Here's the log file (my computer is in Finnish, but I have translated the Finnish parts in English. Whenever there's a <.....> surrounding some text, that indicates a translated part):Code: [Select]Musuu no Danmaku version 0.1.3591.29235
Starting logging file ...
2009 <march> 01 10:18:02.704 - Initializing engine ...
2009 <march> 01 10:18:02.782 - Error during initialization: <The type initializer of> SdlDotNet.Graphics.Video <caused an exception>.
Stack trace:
<at> SdlDotNet.Graphics.Video.SetVideoMode(Int32 width, Int32 height, Boolean resizable, Boolean openGL, Boolean fullScreen, Boolean hardwareSurface)
<at> Musuu_no_Danmaku.Graphics.Initialize()
<at> Musuu_no_Danmaku.Program.Main(String[] args)
The program will close now.
If there's a known fix for this, or if it's a result of some idiotic mistake I made, please let me know. And if not, then have some merry bugfixing...
EDIT:
I'm now on my second computer (I have to alternate between two computers on a weekly basis for various reasons) and tried running it. This computer has Windows XP Home Edition, and I've installed the SDL.NET runtime (version 6.1.0, same as on the other computer) on it (haven't installed the Tao Framework, but since it didn't help on the other comp and it seemingly hasn't been necessary for others, I don't think it'd help). The program gets further this time, but still manages to error and stop working. (It actually initializes the window this time! Oh well, like we needed any more proof that XP > Vista.)
Default scripts, log (full english this time, no need to translate):Code: [Select]Musuu no Danmaku version 0.1.3591.29235
Starting logging file ...
2009 marras 01 17:46:08.703 - Initializing engine ...
2009 marras 01 17:46:09.546 - Loading script objects ...
2009 marras 01 17:46:09.562 - Creating new Game object ...
2009 marras 01 17:46:09.593 - Error during initialization: Input string was not in a correct format.
Stack trace:
at System.Number.StringToNumber(String str, NumberStyles options, NumberBuffer& number, NumberFormatInfo info, Boolean parseDecimal)
at System.Number.ParseDouble(String value, NumberStyles options, NumberFormatInfo numfmt)
at System.Double.Parse(String s, NumberStyles style, NumberFormatInfo info)
at Musuu_no_Danmaku.mdBaseReader.Parse_Instruction_Line(String line)
at Musuu_no_Danmaku.Game..ctor()
at Musuu_no_Danmaku.Program.Main(String[] args)
The program will close now.
Either I'm doing something horribly wrong or the program is really in need of some bugfixing.
hmm ... I only saw this error when testing on my laptop before I installed SDL.NET runtimes. I was originally going to just include the SDL.NET .dll's, but that didn't seem to work, so I instead point to the installer.
Just to make sure, you did unpack all of the files from the .zip into a folder on your hard drive, right?
I don't know too much about Vista, but you may want to try fiddling with the compatibility mode settings (at least XP compatibility mode). I also remember hearing about some games needing admin privileges to run; this game shouldn't need them, but it may be worth a shot if you want to try it.
Finally, it may be something with the OpenGL drivers installed on your machine. Unfortunately, I can't provide any real advice here at the moment; I don't think I've used anything but the stock OpenGL on my system.
This is something that's going wrong in SDL.NET's initialization of the window and OpenGL; unfortunately not code I wrote myself, so I can't offer any immediate code fixes if that is where the problem is.
Also - march? Is your computer date set eight months back? o_O
This one bothers me more. This looks to be where it's initializing the built-in function code - I wrote them as mdBase lines and feed them through the parser to generate the internal structures.
I notice "marras" for the month - what language/region is this system set for? After a quick bit of research, depending on the region, the function "StringToNumber" will be expecting either a "." or a "," as a decimal point (pi = 3.14159 vs pi = 3,14159). Is your region one that uses the comma? That would explain the error if it is.
Before running, you must have the SDL.NET runtime installed. Go to the
website - http://cs-sdl.sourceforge.net/index.php/Main_Page - and select
"Download SDL.NET", and select the newest version for your system.
Right, so I used the sdldotnet-6.1.0-runtime-setup.exe, and now your program doesn't give the "encountered a problem" message... it just doesn't do anything, at all. I'm pretty sure the program just closes down as soon as it opens. I'm running 64-bit windows XP here, is there anything you can tell me about what I could be doing to get this working?
Musuu no Danmaku version 0.1.3591.29235
Starting logging file ...
2009 Nov 02 14:13:19.312 - Initializing engine ...
2009 Nov 02 14:13:20.250 - Error during initialization: The type initializer for 'SdlDotNet.Graphics.Video' threw an exception.
Stack trace:
at SdlDotNet.Graphics.Video.SetVideoMode(Int32 width, Int32 height, Boolean resizable, Boolean openGL, Boolean fullScreen, Boolean hardwareSurface)
at Musuu_no_Danmaku.Graphics.Initialize()
at Musuu_no_Danmaku.Program.Main(String[] args)
The program will close now.
Apparently I suck at translating and translated "Marraskuu" into "March" subconsciously while it's actually "November", and "Maaliskuu" is "March". Oh well, mistakes do happen...
My region (Finland) uses the comma, so that might be the problem. Unfortunately, though, I have absolutely no idea how that setting should be changed, so can't really verify it is the problem.
EDIT:
Additional research reveals that according to the documentation source I found (http://msdn.microsoft.com/en-us/library/system.double.parse%28VS.71%29.aspx , I unfortunately have no previous knowledge on C# so I have to go by documentation) the parameter NumberFormatInfo in System.Double.Parse contains the data for the decimal annotation. Thus, you should probably try creating a CultureInfo for the culture the program is coded in, retrieving the NumberFormatInfo and using that as the parameter for the function instead of the current computer's culture. I have no idea will it work, though, since as stated, I have no prior experience about C# and am just referencing whatever documentation I'm finding. Good luck in fixing the problem, though.
So there's something wrong the the SDL.net installation? Bleh.
OpenGL
The x64-based versions of Windows Server 2003 and of Windows XP Professional x64 Edition do not include an OpenGL graphics driver. Contact the manufacturer of the device for a driver that is compatible with the x64-based versions of Windows Server 2003 and of Windows XP Professional x64 Edition.
PT8 - this might be similar to the issue you're having on your Vista machine ... is it by any chance also a 64-bit machine?
Good luck!
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.)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'(I used the default scripts.)
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 '}'
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)
EDIT: I notified that the FPS sometimes goes over 60 (usually 62-63).
Nuclear Cheese, do you need someone to draw some sample sprites for you, much like the ExRumia of danmakufu? I could probably sprite some enemies and bosses for you, if you want.
Yeah, it would be good to have a set of default (i.e. "not ripped from ZUN") graphics and sounds ...
I could provide some sounds, if you don't mind them sounding, um, a bit less like the original games ... See also http://www.freesound.org/ for that kind of thing ...
Hmm ... those are messages from ANTLR. Is the default danmaku working correctly? It should fire spreads of round blue bullets aimed at you, and fire individual red arrow bullets which re-aim at you every once in a while.
I wonder if this is something that's happening on my end, even, and I'm not seeing it since it doesn't run from a console on Windows (even if you start it in a console, the console immediately returns and you don't get stdout or anything, from what I've seen). I know that ANTLR tries to compensate for 'trivial' syntax errors, like "hey dumbass you need a semicolon here", so that's probably what it's doing with these messages.
... actually, I wonder if I accidentally duplicated the semicolon marker on some lines in the grammar ... I should look at that when I can.
Musuu no Danmaku version 0.1.3591.29235
Starting logging file ...
2009 Nov 05 15:48:16.825 - Initializing engine ...
2009 Nov 05 15:48:17.040 - Loading script objects ...
2009 Nov 05 15:48:17.043 - Creating new Game object ...
2009 Nov 05 15:48:17.083 - Loading script file: baka.txt
2009 Nov 05 15:48:17.092 - Loading script file: ThePlayer.txt
2009 Nov 05 15:48:17.101 - Loaded Object_Type - ThePlayer of type Player
2009 Nov 05 15:48:17.101 - Loading script file: TheCirno.txt
2009 Nov 05 15:48:17.112 - Loaded Object_Type - TheEnemy of type Boss
2009 Nov 05 15:48:17.115 - Loaded Object_Type - EvilShot of type Enemy_Shot
2009 Nov 05 15:48:17.115 - Spawning an object of type ThePlayer as the player.
2009 Nov 05 15:48:17.123 - Spawning an object of type TheEnemy as the enemy.
2009 Nov 05 15:48:17.123 - Starting main loop ...
2009 Nov 05 15:48:17.132 - An error occurred: Incorrect # of args for command set
Stack Trace:
at Musuu_no_Danmaku.Script.Run (Musuu_no_Danmaku.Object o, Musuu_no_Danmaku.Game current_game, System.Collections.Generic.Dictionary`2 locals) [0x00000]
at Musuu_no_Danmaku.Script.Run (Musuu_no_Danmaku.Object o, Musuu_no_Danmaku.Game current_game) [0x00000]
at Musuu_no_Danmaku.Object.Tick (Musuu_no_Danmaku.Game current_game) [0x00000]
at Musuu_no_Danmaku.Game.Tick () [0x00000]
at Musuu_no_Danmaku.Program.Events_Tick (System.Object sender, SdlDotNet.Core.TickEventArgs e) [0x00000]
2009 Nov 05 15:48:17.132 - Closing the program ...
What characters are sprites needed of? ???Presumably, generic Reimu and Marisa ...
What characters are sprites needed of? ???
Presumably, generic Reimu and Marisa ...
If you're still open to suggestions...
Replaceable Everything. Font, lifebar texture, graze SFX, every little thing for the complete Custom Game experience.
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.
Reminds me, make it so that you can set between PC-98 style dialogue and Windows.
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?
Snapshotted Mima VS Sara (I'm not too familiar with PC-98 characters).
Oh yeah -- after fooling around with SimSynth (http://www.threechords.com/hammerhead/simsynth.shtml) a bit, I have managed to produce an SFX (http://www.mediafire.com/?myrzo2nkzdm) which is almost, but not quite, enturely unlike the Touhou death SFX.Ehh that's more of a 'peewwww' than 'spoooon'
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.
Ehh that's more of a 'peewwww' than 'spoooon'Yeah, hence the "almost, but not quite, entirely unlike" ...
Yeah, hence the "almost, but not quite, entirely unlike" ...How... vague :V
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.
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) (http://www.youtube.com/watch?v=-9CKXoW_Ygk#t=160)
Lotus Land Story (Touhou 4) (http://www.youtube.com/watch?v=pmz_NnQQSIg#t=56)
Mystic Square (Touhou 5) (http://www.youtube.com/watch?v=poeP7pxRkAA#t=150)
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 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.
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.
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.
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.
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.
Also, may I add, that everyone asking for a PoFV engine should be ashamed.
STB engine is where it's at.
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'(I used the default scripts.)
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 '}'
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).
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.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.
Store dialog (and other?) text in a separate file, to facilitate making translations
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.
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?
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 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.
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.
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.
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.
*some research later* http://support.microsoft.com/kb/896456 (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.
Fixed archive uploaded ... same link as above.
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.
Prime 2.0
- XP 64-bit
- Error in SetVideoMode in Graphics.Initialize
- Test release 2 does not create log files (just to be sure - did you properly unpack the new archive and make sure your shortcut points to the right place?)
Another thing I just thought of - we may need to install libsdl (the main SDL library) as well. See here (http://www.libsdl.org/download-1.2.php).
Another thing I just thought of - we may need to install libsdl (the main SDL library) as well. See here (http://www.libsdl.org/download-1.2.php).
Hate to be a pain and keep asking people to try these things, but I've only got two computers to try things on myself, and they're both WinXP 32-bit (and already have some dev crap installed).
Also, Furu - does testing release 2 work in your XP VM?Yes, it works now. After some more testing with SDL and Tao framework I found out what might be needed to run Musuu. Please test the following for your OS if it's not working.
Windows XPWell, I already have .NET framework 3.0, and those DLL files are already in the folder. I tried running the installer for the Tao framework, didn't fix anything.
- I needed to install .NET framework 2.0 to be able to run it (I got a message about it)
- Copy SdlDotNet.dll, Tao.OpenGl.dll and Tao.Sdl.dll to your Musuu folder (Get SDL here (http://sourceforge.net/projects/cs-sdl/files/) and Tao framework here (http://sourceforge.net/projects/taoframework/files/). Download the latest .zip files (or the installers if you want to try that instead but I haven't tested it). They are in the bin folder of the archives.)
Yes, it works now. After some more testing with SDL and Tao framework I found out what might be needed to run Musuu. Please test the following for your OS if it's not working.
Ubuntu 9.10 & 9.04
- Install mono-runtime and libmono2.0-cil through Synaptic (9.04 users may need to install mono-jit)
- Copy SdlDotNet.dll, Tao.OpenGl.dll and Tao.Sdl.dll plus their config files SdlDotNet.dll.config, Tao.OpenGl.dll.config and Tao.Sdl.dll.config to your Musuu folder (Get SDL here (http://sourceforge.net/projects/cs-sdl/files/) and Tao framework here (http://sourceforge.net/projects/taoframework/files/). Download the latest .tar.gz files. They are in the bin folder of the archives.)
$ mono -V
Mono JIT compiler version 2.0.1 (tarball)
Copyright (C) 2002-2008 Novell, Inc and Contributors. www.mono-project.com
TLS: __thread
GC: Included Boehm (with typed GC)
SIGSEGV: altstack
Notifications: epoll
Architecture: amd64
Disabled: none
Tried this again with the newer Musuu release, but no dice. I'm using an older version of ubuntu (9.04, not 9.10), so that may be the problem. Here's my version of mono:Code: [Select]$ mono -V
Mono JIT compiler version 2.0.1 (tarball)
Copyright (C) 2002-2008 Novell, Inc and Contributors. www.mono-project.com
TLS: __thread
GC: Included Boehm (with typed GC)
SIGSEGV: altstack
Notifications: epoll
Architecture: amd64
Disabled: none
/ Comment
/ Comment
/ Set screen dimensions
screen_width 800
screen_height 600
/ Determine fullscreen/window
full_screen false
/ Enable/Disable hardware surfaces
hardware_surfaces true
/ Bits per pixel (16 or 32)
bits_per_pixel 32I know people want me to get the actual code posted up so people can... still up for discussion.criticize my sucky organization skillshelp out ... the first question is, of course, where do we keep it? I'm not too familiar with these things, so suggestions are welcome.
Second question is when does it get posted? I could post it this coming weekend if you guys really want, but be warned that the code is a freaking mess (by my standards, anyways).
Third, call me a jerk or whatnot, but I do want to retain some "control" over the codebase until it gets more complete. Feel free to argue with me on this one; I might change my mind.
Fourth, Blargel and Blargel's brother - no stealing code! (j/k)
Musuu no Danmaku version 0.1.3599.41460
Starting logging file ...
2009 nov 13 15:29:15.906 - Initializing engine ...
2009 nov 13 15:29:16.421 - Error during initialization: The type initializer for 'SdlDotNet.Graphics.Surface' threw an exception.
Stack trace:
at SdlDotNet.Graphics.Surface..ctor(IntPtr handle, Boolean isVideoMode)
at SdlDotNet.Graphics.Video.SetVideoMode(Int32 width, Int32 height, Int32 bitsPerPixel, Boolean resizable, Boolean openGL, Boolean fullScreen, Boolean hardwareSurface, Boolean frame)
at SdlDotNet.Graphics.Video.SetVideoMode(Int32 width, Int32 height, Boolean resizable, Boolean openGL, Boolean fullScreen, Boolean hardwareSurface)
at Musuu_no_Danmaku.Graphics.Initialize()
at Musuu_no_Danmaku.Program.Main(String[] args)
The program will close now.
Remember that one of my XP machines didn't run Musuu? Guess I missed the log the first time but anyway here it is:
After a little searching I found out that sdl_image might be missing. I downloaded it (http://www.libsdl.org/projects/SDL_image/) and moved all dll files to my Musuu folder. After that, Musuu was up and running ;D
.
.
.
miss
{
// run death animation task
death_anim();
}
task death_anim()
{
while (!death_animation_complete)
{
// disable player motion/shooting
...
// check for deathbomb, revert miss if it comes
...
// anime the player character going boom
...
if (death_animation_complete)
{
// reset player's location & stock
}
// resume processing on the next frame
wait(1);
}
}
.
.
..
.
.
message ChangeAngle(new_angle)
{
SetAngle(new_angle);
}
.
.
..
.
.
shotid->ChangeAngle(angle_to_player);
.
.
.Actually one of the machines I tested it on run 9.04 64-bit so that's not the case. I have also tested running it with Compiz running and that worked without a problem. I was also running the same version of Mono.
After studying the config files I found out that you probably need to have these packages installed:
- libsdl-image1.2
- libsdl-gfx1.2-4
- libglu1-mesa
These will probably be needed later on when fonts and sound are enabled:
- libsdl1.2debian-all
- libsdl-mixer1.2
- libsdl-ttf2.0-0
- libsmpeg0
btw, found this today, maybe you'd find this useful: http://arstechnica.com/microsoft/news/2009/11/test-and-package-net-apps-for-linux-with-visual-studio-add-in.ars?utm_source=rss&utm_medium=rss&utm_campaign=rss
After doing this, everything worked.
Musuu
Script[mdScript]
// TheEnemy
// Enemy boss that makes some fucking danmaku.
Boss "TheEnemy"
{
define count;
define move;
define parameters;
define num_bullets;
define num_bullets_index;
initialize
{
// image, fire_delay, movement_speed, life, evil shot life threshold
parameters = ["reimu1.png", 30, 0.5, 150, 90];
num_bullets = [7, 11, 5, 9, 4, 11, 8];
num_bullets_index = 0;
SetImage(parameters[0], false, 30);
SetSize(18, 24);
count = 60;
move = parameters[2];
UseRadians(true);
SetLife(parameters[3]);
}
tick
{
if (GetLife() <= 0)
{
// Onoes I dead x__x
DestroyObject(GetMyID());
}
SetX(GetX() + move);
if (GetX() > 350)
{
move = 0 - parameters[2];
};
if (GetX() < 76)
{
move = parameters[2];
};
count = count - 1;
// When count reaches zero, we fire a spread of bullets, and spawn a point item.
if (count <= 0)
{
count = count + parameters[1];
bullets = num_bullets[num_bullets_index];
num_bullets_index = num_bullets_index + 1;
if (num_bullets_index >= length(num_bullets))
{
num_bullets_index = 0;
}
increment = (pi / 2) / (bullets - 1);
angle = 3.1415926535897932384626;
player_id = GetPlayerID();
if (player_id > -1)
{
ydiff = ObjGetY(player_id) - GetY();
xdiff = ObjGetX(player_id) - GetX();
if (xdiff == 0 && ydiff == 0)
{
// Just in case ...
ydiff = 1;
};
angle = arctan2(ydiff, xdiff);
};
angle = angle - (increment * ((bullets - 1) / 2));
while (bullets > 0)
{
FireShot01(GetX(), GetY(), angle, 2.5, "shot1.png");
angle = angle + increment;
bullets = bullets - 1;
};
if (GetLife() < parameters[4])
{
CreateObject("EvilShot", GetX(), GetY());
};
CreateObject("PointItem", GetX(), GetY());
};
}
}
Enemy_Shot "EvilShot"
{
define count;
define next_count;
initialize
{
SetSize(5.5, 7.5);
SetAngle(180);
SetSpeed(1.5);
count = 60;
next_count = 90;
// Call the internal bullet init function to ensure standard stuff is setup
enemy_shot_init();
SetImage("shot2.png", true, 55);
}
tick
{
count = count - 1;
if (count <= 0)
{
count = next_count;
next_count = next_count + 30;
player_id = GetPlayerID();
if (player_id > -1)
{
ydiff = ObjGetY(player_id) - GetY();
xdiff = ObjGetX(player_id) - GetX();
if (ydiff == 0 && xdiff == 0)
{
ydiff = 1;
};
SetAngle(arctan2(ydiff, xdiff));
};
};
}
}...
bullet_array = EnumerateObjects("Enemy_Shot");
i = 0;
while (i < length(bullet_array))
{
DestroyObject(bullet_array[i]);
}
...
Some more news from my Vista Home premium which still has been unable to run the program:
-I've added the .dlls for SDL, SdlDotNet, SDL_gfx and SDL_image to Musuu's folder, but it still doesn't work. Also I've had both the SDLDotNet runtime and Tao Framework installed for some time.
However, more importantly:
-I downloaded a C# IDE (namely SharpDevelop) and used it to compile the OpenGL tutorial code (http://cs-sdl.sourceforge.net/index.php/NeHe_1_OpenGL_Tutorial:Code) in SDLDotNet's site (the lower one with C# code, most definitely not the upper one that's in Visual Basic .NET). I changed all SetVideoMode methods to have the same parameters as in Cheese's initial config file (save for window size, since I doubt that's going to cause the error): HardwareSurfaces is true, bpp is 32 and pressing the key defined in the code (originally F1, but I changed it to left ctrl for no reason at all ::) ) toggles between fullscreen and windowed. I can now say with near absolute certainty that the example code works and creates the resizable window it's supposed to. This concludes the proof that the computer can run both SdlDotNet and OpenGl with no major problems.
If I'm interpreting this correctly, this isolates the error to the following problems:
- Something differing in the references, although this is improbable, since I only added references for the SdlDotNet project and Tao.OpenGl, and I have both of them installed and important .dlls copied to the Musuu directory.
- Something differing in the compilation, which I cannot comment on due to my lack of experience with C# compilers (and lack of experience with C# coding in general, as this was the first C# app I've ever compiled).
- Some absolutely weird situational bug with SDL or OpenGL.
I will be moving to my XP machine that failed running Musuu due to the '.' vs ',' -problems last time soon, and thus cannot access this computer for yet another week, so I can't provide much more input on this during the next week. I'm really hoping this problem gets found and fixed soon, though.
EDIT:
Version 2 works fine on XP.
:awesome:
I managed to code player respawning to my player script, but it has a tiny problem: over 50% of the time I respawn into a bullet and, since I have no starting invincibility, I die. Great, just great.
Some other stuff I really miss from DMF and hope to be implemented as defaults in the future:
- The % operator (I tried it but it errored for me, so I assume it's not implemented).
- Defining images by drawing rects (making every bullet a seperate file is frustrating).
- CreateShotA, obviously.
- Visible hitbox. Dodging without one is frustrating.
- Some syntax stuff like ++.
- Effect objects and drawing functions.
Also, another tiny suggestion: Add an additional parameter to the CreateShot functions that allows the player to specify, whether the bullet rotates according to it's angle or not (like you can do with object icons now). ZUN apparently uses this for round bullets to preserve the full graphical quality when rotation is not required, as evidently proven by Drake's BlackSquare mods. It would for example make the round bullets with thin outlines look a lot better without having to make them all objects.
However, overall, this is already excellent work. Major props for you, Cheese, and keep up the good work!
There's no invulnerability function yet, but you could simulate it by setting the player object's size1 (first argument to SetSize) to zero, which will preclude it from collision with enemy bullets, for the duration of invulnerability.
Really? What was the script you used? I thought I had it working; I'll have to look back at it.
Something similar can be done down the line. In the meantime, you can get a similar effect by scripting a new enemy_shot object type.
Huh. I didn't know ZUN did that.
Wait, it's supposed to work? Let me try again...
...D'OH. if(count%5 == 0) errors, BUT if(count % 5 == 0) works! Therefore this goes along with those a-b failing and a - b working problems...
// TheEnemy
// Enemy boss that makes some fucking danmaku.
Boss "TheEnemy"
{
define count;
define move;
initialize
{
if(count%5 == 0)
{
count = stuff%50;
};
}
tick
{
if(count%5 == 0)
{
count = stuff%50;
};
}
Object_Type Boss TheEnemy
Script initialize
mod !0, @count, 5
equ !1, !0, 0
not !2, !1
jmp !2, "Label0"
mod !0, !stuff, 50
set @count, !0
Label0:
Script tick
mod !0, @count, 5
equ !1, !0, 0
not !2, !1
jmp !2, "Label1"
mod !0, !stuff, 50
set @count, !0
Label1:This would be so much more convenient if shot objects accepted parameters other than X and Y (hint hint...)
Notice that the circular bullet squares aren't rotated at all, even though they all obviously can't be going into the same direction.
Round bullets ( with ring, without ring and the smaller ones ) quality make me rage in Danmakufu when inserting ZUN original shotsheets. Serious rage.
if (GetLife() <= 0)
{
// Onoes I dead x__x
DestroyObject(GetMyID());
objects = GetObjectList("Enemy_Shot");
i = 0;
while (i < length(objects))
{
DestroyObject(objects[i]);
i = i + 1;
};
};
As seen above, both with and without spaces by the %, the same mdBase is generated. Could you please provide some more details on the error you saw and, if possible, the full script you were using?
You're saying you want to pass in additional arguments to an object you're creating, right (in this case, a shot)? The messages idea I had a few posts back could cover this, and/or I could add a simple functionality to pass an additional arg when creating an object (give it an array if you need multiple parameters).
Finally, there's the idea I had above of accessing object parameters directly.
Object listing.
Maybe this is a lot to ask, but there's no possibility of a converter from Danmakufu to this.. Right?
Object listening is like OOP right? To modify the object's behaviour once it is spawned. Like
fire object bullet --> modify it's behaviour freely whenever you by objectbullet.changespeed(3) or something?
pid = GetPlayerID();
angle_to_player = arctan2(pid->y - GetY(), pid->x - GetX());shot_array = GetObjectList("Enemy_Shot");
let i = 0;
while (i < length(shot_array))
{
obj_id = shot_array[i];
obj_id->angle = obj_id->angle + 180;
i++;
}I know people want me to get the actual code posted up so people cancriticize my sucky organization skillshelp out ... the first question is, of course, where do we keep it? I'm not too familiar with these things, so suggestions are welcome.
Second question is when does it get posted? I could post it this coming weekend if you guys really want, but be warned that the code is a freaking mess (by my standards, anyways).
Third, call me a jerk or whatnot, but I do want to retain some "control" over the codebase until it gets more complete. Feel free to argue with me on this one; I might change my mind.
Hmm. Ten days late and my first post, but
Let me introduce you to revision control systems (one of these is called Subversion (http://en.wikipedia.org/wiki/Subversion_(software)), and I'll be speaking based on experience with SVN, but I think Mercurial (http://en.wikipedia.org/wiki/Mercurial_(software)) is gaining popularity). Revision control manages a repository of files. Every change someone makes gets a unique revision identifier (e.g., initial set is revision 0 and the next change is revision 1). Each revision has metadata such as timestamp, author (if you choose to grant access to a few other people), and comments.
Doing this has several advantages; revisions can be compared, restored, and even merged. You can step back and check which revision introduced a bug, and with a diff you can see exactly what lines were changed. Or perhaps you can have two people work independently on the same program but doing different tasks; when they're done, they can easily merge their changes. Additionally, you can create a simple changelog just by glancing through the comments in the revision log.
Sites such as Google Code (http://code.google.com/projecthosting/) and SourceForge (http://sourceforge.net/) can provide a repository for you while allowing public users read-only access to it. If you choose not to go the version control route, I believe both of these services offer file uploads as well, so distributing the source .zip is a viable alternative.
Anyway, collaborative editing is extremely powerful. Things get done better and faster due to the combined input of several minds; improvements can be made thanks to the individual knowledge and experience each coder has, so if you do share the code with us soon, I hope to contribute some patches and help you out with the project.
... once I learn C#, that is.
That's easy. Just picture the bastard child of C++ and Java, and you're already 90% of the way there. :V
(serious: it's a piece of cake to pick up if you know either)
What the hell am I still doing up? It's 0530am! Stupid insomnia. At least I took the day off of work.
Notice the outlines of the rotated red bullets. While both have some incosistencies due to rotation, Musuu's bullets have a much more broken outline than DMF's.
I suggests using the . (as in id.x) instead of -> because that's used in some object-oriented languages I use so I'm pretty used to it and it's faster to type.
Also, I think it's better to use something like id.GetAngle() instead of id.angle to get the angle and use id.variable to access a local variable instead.
And about using arrays and this, using a Get command with an object list might not work that well but at least Set might work.
:image:
The bullets are not blended yet, so they have a solid outline as opposed to a semi-transparent or "blended" outline (which makes the bullet look smoother). I assume this has yet to be added to Musuu.
True, right now there isn't any special blending or anything with the graphics. Not sure what particular effects Danmakufu uses, but it looks like at the very least some antialiasing is going on there.
... is that a background image? Also it looks like you gave :awesome: a nose. :V
I was more asking for opinions on which site would be best for this project. SourceForge and Google Code were two ones I was looking at, but I'm not familiar with the particular features of each, so I was wondering what people thought.
I definitely agree that getting this under version control is a good idea, and I have some experience with SVN so that would probably be my first choice.
Just picture the bastard child of C++ and Java, and you're already 90% of the way there. :V
(serious: it's a piece of cake to pick up if you know either)
What the hell am I still doing up? It's 0530am! Stupid insomnia. At least I took the day off of work.
Oh, and are there any random variable functions implemented yet (such as rand(min,max) or rand_int(min,max)). If not, take this as a some sort of a reminder...
True, right now there isn't any special blending or anything with the graphics. Not sure what particular effects Danmakufu uses, but it looks like at the very least some antialiasing is going on there.
glBindTexture(GL.GL_TEXTURE_2D, texId);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR);
Yes, it's a spell bg for my currently-in-planning game I'm going to make with Musuu I implemented for the sake of testing and having a background. And it's not a nose, it's a (quickly drawn excuse of a) hitbox.
Oh, and are there any random variable functions implemented yet (such as rand(min,max) or rand_int(min,max)). If not, take this as a some sort of a reminder...
I haven't tried SourceForge yet because it requires your project to be approved before it can be added, but Google Code is pretty easy to set up and it includes a downloads page, Wiki, issue tracking, and public source viewing, any of which can be hidden if you want.
And then there are Atom feeds for several kinds of project stuff. They do require you to select a code license, but BSD, LGPL, and MIT are selectable, so that shouldn't be a problem.
Couldn't hurt to give it a shot?it's Google, after all. Looks like Google and SourceForge are the only popular hosts with unlimited space and a code browser, so...
Oh, then hooray!
Now get that code upso I can destroy it.
(Also, midnight coding is <3.)
I assume the Mersenne Twister would be implemented, Nuclear Cheese?
It's just linear filtering:Code: [Select]glBindTexture(GL.GL_TEXTURE_2D, texId);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR);
Cool with the BG. In the long run there should be functions that'll make setting up background and such easier ... I'm assuming for now you're using an Effect object with an unusually large image?
So people, what's up? (http://code.google.com/p/musuu-no-danmaku/)
Source is viewable from here. Have fun being horrified at my shitty organization and plethora of "#warning TODO"s. ;)
Random thought: how do you think pattern-functions will handle zeroes as an input-value (i.e. if you feed it a variable for the number-of-bullets which evaluates to zero)? I'm imagining something like, a setup for multiple difficulty-levels which uses multipliers for various things so that you only have to make one script per difficulty-level, and you want one particular bit to not appear on Easy, so you set it up with modifiers so that the "number of bullets" is zero when the numbers are that of Easy ...)
Actually, compared to what I was expecting it's actually quite readable. The only real problem (aside from not having the necessary skills to read and interpret .g files such as mdScript_to_mdBase.g) I have interpreting it is that I have no idea where you have defined the MDScript functions.
1. How can I make some buttons not work while using a script (specificly Esc, Ctrl, Alt, F4, Del, Windows)
This sounds rather exploitable?mainly the blocking of Alt+F4 and Ctrl+Alt+Del. Hooking the Windows button makes sense, and I suppose Escape as well, but I don't think preventing the user from killing the program is a good idea. If you feel the need to block those, you might just be griefing the player.
Up to Nuclear Cheese, though.
Well, finally got it to compile and run after tons of trial and error. I think there was something in the latest TheEnemy.txt that would error out with the updated parser.
EDIT: Hooray, got a patch for you. I'll upload it in about half an hour on the issue you started since I think it solves the negation problem.
- When creating the mdBase command for the negation, you forgot to get a new variable name for the result. The way you had it, "stuff = -count" would end up storing -count back to count.
- More of an optimization than anything else, but the mdBase command not will negate numbers. It should be a bit faster than mul, since it does direct negation rather than a multiplication.
- The original issue was that "count-1" broke, since the parser was getting confused and thinking we meant "-1" as a number. With your addition of general negation, though, I could pull the negative sign off of the definition for the number literal. We end up having an extra operation for negative constants, but it should all work correctly now.
Good job on this, though.
Hmm ... I should probably post up some reference material for mdBase on the wiki over there, so that in the future developers will be able to understand what the hell all that nonsense is.
Also, I'm gonna go post some new issues/enhancements in the list, mainly coming from my own local "todo" list.
Ah, I see. Thanks for the input; I think I'm starting to get at least the script-parsing part of it so far. I've only done high-level programming so mdBase is pretty new to me.
Well, I've got a weekend to kill and it's not worth coding for TF2 when you can't play it so it looks like I'm stuck here.
Can't wait to make your code worse with my own.
Oh yeah -- how's the scoreing system going to be handled, as far as difficulty-level goes? I'm thinking of if the scripter wanted to make custom difficulty-levels, multidimensional difficulty, etc. I suggest simply storing the difficulty as a string in the score-file, so that you could, um, do whatever you wanted, really. (In the "multidimensional difficulty" example, you could store it as "Speed:"+speedVariable+" Density:"+densityVariable ... or, um, however you're concatenating strings)
Theme ... you appear to have lots of free time.
... while I was busy eating dead birds with family, ...
started work on two enhancement issues
I made a couple slight changes to your input configuration code. Mainly, I changed its behavior on an unknown key string, such that it should not reassign the input and instead write a warning to the logfile.
Theme, fyi - the "branches" thing ...
When you're making code changes that are going to be reviewed, it expects you to branch the source (so you're not editing the mainline while working on the change). Once the change is completed and reviewed, the changes made on the branch are merged back into the mainline.
I'm not sure how to branch files in SVN, but I'm sure it's not too hard. You'll need write access to the repository, though (which I should probably just give you, since you seem to be doing quite well with this. Pardon my stupid, overly 'protective' personality ... :V).
svn copy trunk branches/theme97I dunno, you mentioned that scoring would be handled by MnD, and I want to know what it would put for "difficulty level" or whatever.
Why yes, yes I do. The bird-eating festivities only during dinner time for us, so that gives me way too much time in the morning.
EDIT: For fonts, Mona looked best, so it has my vote.
(http://i48.tinypic.com/28h26vq.png)
Speaking of that, what library are we going to use to render text? I don't think Tao includes font rendering and I'm a bit confused on what we're currently limited to.
EDIT 2: Oh, SDL_ttf?
EDIT 3: Or ... is it possible already? Well, now I'm thoroughly confused, so I guess fonts are your job too.
My current plan is to use the Tao Framework's mapping of FreeType. I still need to actually look into its workings and figure out how to use it, but from a quick glace it does look promising
It looks like you're treating Numbers as Booleans (much like bools in C/C++ are actually ints), but that's not how things are in Musuu no Danmaku, and in C#.
Also, please be careful not to go too far out of the original scope of your issues. [...] If you see another thing that needs to be done, as long as it isn't critical to what you're working, it's usually best to write a new issue for it. Also, in the first post of an item, please give a description of what will be done in the item.
btw - that note you made about ANTLR errors being off by 2 lines, that's because right now the program reads the header lines from the file, and then passes the remainder of the file to ANTLR.
And, Theme, I am thinking of giving you dev rights on the project. If I do, though, I will ask that you follow the following guidelines:
- Smooth texturing (PT8 - should make what you pointed out look better)
function = new Script.Instruction[7];
function[0] = mdBaseReader.Parse_Instruction_Line("obj_create !id, \"BasicEnemyShot\", !arg1, !arg2");
function[1] = mdBaseReader.Parse_Instruction_Line("obj_set_angle !id, !arg3");
function[2] = mdBaseReader.Parse_Instruction_Line("obj_set_speed !id, !arg4");
function[3] = mdBaseReader.Parse_Instruction_Line("obj_set_size !id, 5.5, 7.5");
function[4] = mdBaseReader.Parse_Instruction_Line("obj_set_image !id, !arg5");
function[5] = mdBaseReader.Parse_Instruction_Line("ret !id");
function[6] = mdBaseReader.Parse_Instruction_Line("obj_img_rotate !id, false");
function_list.Add("FireShot01S", new Script(function));Well, I was thinking it would be helpful to store more than just "a number" for the score. I mean, okay, if the script did allow multiple difficulty levels, how would the score get stored? Would it store them in separate score-lists somehow, would it display the difficulty and player-character, or what?
But FreeType doesn't render; it's only provides an interface.
First of all, was the play field size stealth changed while I was away, since I had to scale up my background images? Or does this have something to do with the non-power-of-two textures update?
Secondly:
- Could you please rename arctan2 as just atan2, or at least add that in as an alternative form for the same function (like in DMF you can use either truncate or trunc). Not having to write two more letters every time you need the angle between two objects should be enough reason.
Secondly:- Also, I did some testing with the non-rotating-image bullets. Specifically, I added the following function CreateShot01S (S is supposed to stand for stationary, as opposed to rotating, but I'm sure there are better names out there) that's exactly the same as CreateShot01, except the bullets don't rotate. Function code is the following (altough I guess figuring it out would have been a trivial matter, since most of it is direct copypasta from CreateShot01):Code: [Select]function = new Script.Instruction[7];
function[0] = mdBaseReader.Parse_Instruction_Line("obj_create !id, \"BasicEnemyShot\", !arg1, !arg2");
function[1] = mdBaseReader.Parse_Instruction_Line("obj_set_angle !id, !arg3");
function[2] = mdBaseReader.Parse_Instruction_Line("obj_set_speed !id, !arg4");
function[3] = mdBaseReader.Parse_Instruction_Line("obj_set_size !id, 5.5, 7.5");
function[4] = mdBaseReader.Parse_Instruction_Line("obj_set_image !id, !arg5");
function[5] = mdBaseReader.Parse_Instruction_Line("ret !id");
function[6] = mdBaseReader.Parse_Instruction_Line("obj_img_rotate !id, false");
function_list.Add("FireShot01S", new Script(function));
I did some testing and was extremely pleased with the results, and therefore suggest the implementation of this or some alternate form of the same functionality.
EDIT: Actually, concerning the non-rotating image bullets, are you going to implement something similar to how ShotData files work in DMF later on in the project? If yes, then that would probably be the ideal place to define, does a bullet's image rotate along with the angle, since they will probably contain other similar data for shots such as automatic rotation over time, delay color and render type. Also, ShotData files would also be an excellent place for defining bullet hitbox shape and size (things Danmakufu's ShotData files don't support). However, consider the function I posted above as a temporary fix, since I don't see something like ShotData files or any other bulletsheet definition method being implemented anytime soon.
bullet "name"
{
image "image.png";
size 5, 8;
shape circle; // collision shape (right now, only circle exists)
rotate_with_angle false; // don't rotate bullet with angle
spin_speed 5; // auto-rotate image 5 degrees per frame (no code for this exists yet)
}I thought of something that I think might be useful:The trails should only be the size of the hitbox, because often it looks like bullets cover everything but the hitboxes don't (Eirin's card)
A safespot tester.
What it would do is force bullets to leave behind non-damaging trails. This would eat at the background, and when the spell card is over...
"I can see the background, there are too many safespots".
That is essentially the point
I thought of something that I think might be useful:
A safespot tester.
What it would do is force bullets to leave behind non-damaging trails. This would eat at the background, and when the spell card is over...
"I can see the background, there are too many safespots".
That is essentially the point
Dunno where Theme is; haven't heard from him all week (probably back to being busy. stupid real-life commitments).
Once the font stuff is done I think I can get started on quite a few things (esp. the pause screen). I've also considered adding TATE but I'll wait for the semester to finish before seeing if I'll go through with that.
Tonight I'm going to look through mdScript stuff and commit the for() loop, *= and /= operators, and compound assignments on object parameters once I've got those tested. That's probably the last you'll see of me for the next couple of weeks.
Edit: Also, I had to get some SDL-related .dll files before I could get MsD to run without erroring out (at least SDL_image.dll and SDL_mixer.dll). Might want to figure out a way to make sure users get these in your next release because it was rather difficult to figure out that these were needed. (Or perhaps my SDL download didn't like me.)
Only major concern with throwing in TATE mode is that you need to make sure it doesn't break stuff.
Only detail I'd note is that, in C's for, you can leave the first (and third, if I remember correctly) field blank
Couple random ideas I had:
- text-parsing functions, like substring(string, position of first character, length), explode(string-to-be-turned-into-array,delimiter) ... My motive for this was an idea whereby a script-maker could set things up so that you could give each player their own "script" file for e.g. pre-boss dialogue, so you wouldn't have to rewrite the code every time you had to wanted to add a new character/you could add non-default dialogues (say, for instance, if you wanted to do the equivalent of playing Sakuya in UFO). But you'd need string-parsing functions to do that ...
- giving the script read-access to the preferences, so you could e.g. tweak your script's graphics according to the resolution or something, or set up a custom framerate-counter. (Or pull a Psycho Mantis. "YOU'RE PLAYING THE GAME FULLSCREEN AT 1024x768 WITH SOUND DISABLED!")
I now included all of the SDL and Tao .dlls that it is using (as far as I could tell, anyways), so that'll lessen the need for searching those out.
2009 Dec 19 16:06:10.125 - Error during initialization: The type initializer for 'SdlDotNet.Graphics.Surface' threw an exception.
Stack trace:
at SdlDotNet.Graphics.Surface..ctor(IntPtr handle, Boolean isVideoMode)
at SdlDotNet.Graphics.Video.SetVideoMode(Int32 width, Int32 height, Int32 bitsPerPixel, Boolean resizable, Boolean openGL, Boolean fullScreen, Boolean hardwareSurface, Boolean frame)
at SdlDotNet.Graphics.Video.SetVideoMode(Int32 width, Int32 height, Int32 bitsPerPixel, Boolean resizable, Boolean openGL, Boolean fullScreen, Boolean hardwareSurface)
at Musuu_no_Danmaku.Graphics.Initialize()
at Musuu_no_Danmaku.Program.Main(String[] args)Musuu no Danmaku version 0.1.3640.32756
Starting logging file ...
2009 Dec 19 21:26:40.209 - Reading config file ...
2009 Dec 19 21:26:40.224 - Finished reading config file.
2009 Dec 19 21:26:40.224 - Initializing engine ...
2009 Dec 19 21:26:40.240 - Initializing graphics: 800x600 windowed, hardware surfaces enabled
2009 Dec 19 21:26:40.256 - Error during initialization: The type initializer for 'SdlDotNet.Graphics.Video' threw an exception.
Stack trace:
at SdlDotNet.Graphics.Video.SetVideoMode(Int32 width, Int32 height, Int32 bitsPerPixel, Boolean resizable, Boolean openGL, Boolean fullScreen, Boolean hardwareSurface)
at Musuu_no_Danmaku.Graphics.Initialize()
at Musuu_no_Danmaku.Program.Main(String[] args)
The program will close now.
static bool isInitialized = Initialize();
...
/// <summary>
/// Initializes Video subsystem.
/// </summary>
public static bool Initialize()
{
if ((Sdl.SDL_WasInit(Sdl.SDL_INIT_VIDEO))
== (int)SdlFlag.FalseValue)
{
if (Sdl.SDL_Init(Sdl.SDL_INIT_VIDEO) != (int)SdlFlag.Success)
{
throw SdlException.Generate();
}
return false;
}
else
{
return true;
}
}int SDL_Init(Uint32 flags) {
#if !SDL_THREADS_DISABLED && SDL_THREAD_PTH
if (!pth_init()) return -1;
#endif
SDL_ClearError();
#if defined(__WIN32__)
if (SDL_HelperWindowCreate() < 0) return -1;
#endif
if (SDL_InitSubSystem(flags) < 0) return (-1);
if (!(flags & SDL_INIT_NOPARACHUTE)) SDL_InstallParachute();
return (0);
}Code: [Select]2009 Dec 19 16:06:10.125 - Error during initialization: The type initializer for 'SdlDotNet.Graphics.Surface' threw an exception.
Stack trace:
at SdlDotNet.Graphics.Surface..ctor(IntPtr handle, Boolean isVideoMode)
at SdlDotNet.Graphics.Video.SetVideoMode(Int32 width, Int32 height, Int32 bitsPerPixel, Boolean resizable, Boolean openGL, Boolean fullScreen, Boolean hardwareSurface, Boolean frame)
at SdlDotNet.Graphics.Video.SetVideoMode(Int32 width, Int32 height, Int32 bitsPerPixel, Boolean resizable, Boolean openGL, Boolean fullScreen, Boolean hardwareSurface)
at Musuu_no_Danmaku.Graphics.Initialize()
at Musuu_no_Danmaku.Program.Main(String[] args)
Adding libpng12-0.dll solves this, and then it asks for zlib1.dll. After adding those two, it runs fine for me.
Finals are over so I can start getting things done again.
Code: [Select]Musuu no Danmaku version 0.1.3640.32756
Starting logging file ...
2009 Dec 19 21:26:40.209 - Reading config file ...
2009 Dec 19 21:26:40.224 - Finished reading config file.
2009 Dec 19 21:26:40.224 - Initializing engine ...
2009 Dec 19 21:26:40.240 - Initializing graphics: 800x600 windowed, hardware surfaces enabled
2009 Dec 19 21:26:40.256 - Error during initialization: The type initializer for 'SdlDotNet.Graphics.Video' threw an exception.
Stack trace:
at SdlDotNet.Graphics.Video.SetVideoMode(Int32 width, Int32 height, Int32 bitsPerPixel, Boolean resizable, Boolean openGL, Boolean fullScreen, Boolean hardwareSurface)
at Musuu_no_Danmaku.Graphics.Initialize()
at Musuu_no_Danmaku.Program.Main(String[] args)
The program will close now.
I can't say I'm surprised. I even added those two DLLs Theme97 mentioned, didn't make a difference. Anyone else here with 64-bit XP having the same problem? I'm pretty sick of this not working. -_-
Hmm.
SdlDotNet.Graphics.Video (https://cs-sdl.svn.sourceforge.net/svnroot/cs-sdl/trunk/SdlDotNet/src/Graphics/Video.cs) containsCode: [Select]static bool isInitialized = Initialize();
...
/// <summary>
/// Initializes Video subsystem.
/// </summary>
public static bool Initialize()
{
if ((Sdl.SDL_WasInit(Sdl.SDL_INIT_VIDEO))
== (int)SdlFlag.FalseValue)
{
if (Sdl.SDL_Init(Sdl.SDL_INIT_VIDEO) != (int)SdlFlag.Success)
{
throw SdlException.Generate();
}
return false;
}
else
{
return true;
}
}
The two Init functions in the Tao framework (http://taoframework.svn.sourceforge.net/viewvc/taoframework/trunk/src/Tao.Sdl/Sdl.cs?view=markup) are just interfaces to SDL.dll (http://www.libsdl.org/cgi/viewvc.cgi/trunk/SDL/src/SDL.c?view=markup), which has:Code: [Select]int SDL_Init(Uint32 flags) {
#if !SDL_THREADS_DISABLED && SDL_THREAD_PTH
if (!pth_init()) return -1;
#endif
SDL_ClearError();
#if defined(__WIN32__)
if (SDL_HelperWindowCreate() < 0) return -1;
#endif
if (SDL_InitSubSystem(flags) < 0) return (-1);
if (!(flags & SDL_INIT_NOPARACHUTE)) SDL_InstallParachute();
return (0);
}
SDL_InitSubSystem calls SDL_VideoInit here (http://www.libsdl.org/cgi/viewvc.cgi/trunk/SDL/src/video/SDL_video.c?view=markup), which then does a whole mess of stuff that leads me to believe that I have no idea what is going on.
I'm on 32-bit XP, though, so that might be why it's working for me.
Hi Theme, you're posting while I'm posting. :V
Musuu no Danmaku version 0.1.3640.42532
Starting logging file ...
2009 Dec 20 00:16:26.021 - Reading config file ...
2009 Dec 20 00:16:26.021 - Finished reading config file.
2009 Dec 20 00:16:26.021 - Initializing engine ...
2009 Dec 20 00:16:26.037 - Initializing graphics: 800x600 windowed, hardware surfaces enabled
2009 Dec 20 00:16:26.052 - Error during initialization: The type initializer for 'SdlDotNet.Graphics.Video' threw an exception.
Stack trace:
at SdlDotNet.Graphics.Video.SetVideoMode(Int32 width, Int32 height, Int32 bitsPerPixel, Boolean resizable, Boolean openGL, Boolean fullScreen, Boolean hardwareSurface)
at Musuu_no_Danmaku.Graphics.Initialize()
at Musuu_no_Danmaku.Program.Main(String[] args)
The program will close now.
2009 Dec 20 00:16:26.084 - Inner exception: An attempt was made to load a program with an incorrect format. (Exception from HRESULT: 0x8007000B)
Stack trace:
at Tao.Sdl.Sdl.SDL_WasInit(Int32 flags)
at SdlDotNet.Graphics.Video.Initialize()
at SdlDotNet.Graphics.Video..cctor()
The program will close now.
Tried that test EXE out, error log coughed this stuff up:Code: [Select]Musuu no Danmaku version 0.1.3640.42532
Starting logging file ...
2009 Dec 20 00:16:26.021 - Reading config file ...
2009 Dec 20 00:16:26.021 - Finished reading config file.
2009 Dec 20 00:16:26.021 - Initializing engine ...
2009 Dec 20 00:16:26.037 - Initializing graphics: 800x600 windowed, hardware surfaces enabled
2009 Dec 20 00:16:26.052 - Error during initialization: The type initializer for 'SdlDotNet.Graphics.Video' threw an exception.
Stack trace:
at SdlDotNet.Graphics.Video.SetVideoMode(Int32 width, Int32 height, Int32 bitsPerPixel, Boolean resizable, Boolean openGL, Boolean fullScreen, Boolean hardwareSurface)
at Musuu_no_Danmaku.Graphics.Initialize()
at Musuu_no_Danmaku.Program.Main(String[] args)
The program will close now.
2009 Dec 20 00:16:26.084 - Inner exception: An attempt was made to load a program with an incorrect format. (Exception from HRESULT: 0x8007000B)
Stack trace:
at Tao.Sdl.Sdl.SDL_WasInit(Int32 flags)
at SdlDotNet.Graphics.Video.Initialize()
at SdlDotNet.Graphics.Video..cctor()
The program will close now.
:V
It worked!
It was also absolutely nothing like I expected it to be. Test release 3 was supposed to have sound, right?
Anyways, this just occurred to me, but is the Musuu no Danmaku name set in stone? It occurred to me recently that you could maybe name it Bullet Forge, to coincide with that danmaku scripting website that Blargle was making. Well, that and it just sounds a lot cooler. I guess you'd have to ask him first. I feel awkward for even bringing this up. ._.
The x86 version worked fine on my Windows Vista that couldn't run the last 2 releases, so I can assume you found the correct cause for the problem. Excellent work!
Just reporting in to say I finally got around to trying the demo, and everything is working very smoothly.
I have three suggestions for this - would it be possible to allow a gradient for the color, like DMF?
Also, there seems to be lacking an opacity option, which might be problematic in some cases.
Third, to cut down on render time, perhaps there could be an option to pre-load the text and convert it into a graphic? This shouldn't be a priority of course, but it would be nice to have.
I dunno if this was asked and/or addressed yet, but will there be 3D? Perhaps I'm getting ahead of the project a little.
This is a possibility - if your script knows in advance it needs "MY AWESOME SCRIPT" in 60-point bright-red lettering every frame, it could buffer that into a texture and render it more like a normal image.
Actually this reminds me of a feature in some other engines, where you could create a new image (like, image=CreateImage(64,64); and it would give you a transparent image 64x64) and have the ability to draw on that instead of the screen (DrawGraphicOnImage or something); then you could draw that image to the screen after you've modified it. You could also copy an area of the screen and put that in an image.
Actually this reminds me of a feature in some other engines, where you could create a new image (like, image=CreateImage(64,64); and it would give you a transparent image 64x64) and have the ability to draw on that instead of the screen (DrawGraphicOnImage or something); then you could draw that image to the screen after you've modified it. You could also copy an area of the screen and put that in an image.
But then again, this is more memory intensive. It's a tradeoff.
Though, with RAM sizes these days... ^^;
Yeah, a "copy this section of the screen to an image" function would be fun too, just so you could add PoFV-like screen transitions. (Hey, you can't have a shooter game without at least one pointlessly cool transition effect...)
Dunno if this has been mentioned already 'cause I'm not gonna read 16 pages of stuff, but Danmakufu has really messed up 3D rotation when you try to rotate on multiple axes at once. I believe this is due to the use of matrix transformations. A better way to handle rotation would be to use quaternions instead. I dunno how either work, but just throwing it out there :P
This could certainly be possible, at least once I figure out where OpenGL's render-to-texture functionality is kept.http://en.wikipedia.org/wiki/Framebuffer_Object (http://en.wikipedia.org/wiki/Framebuffer_Object)
Danmakufu's rotation is based on three individual rotations, one about each of the primary axes, applied in sequence.
OpenGL has a function to specify a rotation of t degrees about vector (x, y, z). Might be a good starting point, but we might have to "stack" rotations in order to get all possible results, and this gets confusing pretty quickly.
1) "I dunno how X works, but I suggest using X." :V
Sorry, I just find this boiled-down version of your statement amusing.
2) Danmakufu's rotation is based on three individual rotations, one about each of the primary axes, applied in sequence. The only thing I found really strange about it was the order in which they seemed to be applied.
3) Everything in 3D graphics boils down to matrix math. Even if you give it a quarternion for a rotation, internally it converts it to the appropriate matrix.
4) Quarternions are no joke mathematically - no (http://www.genesis3d.com/~kdtop/Quaternions-UsingToRepresentRotation.htm) joke (http://en.wikipedia.org/wiki/Quaternions_and_spatial_rotation).
... with all that said, I do agree that we need a better 3D rotation function than Danmakufu provides.
OpenGL has a function to specify a rotation of t degrees about vector (x, y, z). Might be a good starting point, but we might have to "stack" rotations in order to get all possible results, and this gets confusing pretty quickly.
http://en.wikipedia.org/wiki/Framebuffer_Object (http://en.wikipedia.org/wiki/Framebuffer_Object)
FBO's aren't supported on older Intel GPU's though...
Argh, gimbal lock (http://en.wikipedia.org/wiki/Gimbal_lock) sucks but Euler angles are the easiest to understand.
Huh, really? I made a plugin for Team Fortress 2 a while back where rockets would gradually turn to home in on a player. It worked by creating a vector from the rocket's position to the player and then getting the up vector. Each frame, it would rotate the rocket's velocity vector around that up vector, and the plugin never had problems with that.
Okay, well the problem with the way Danmakufu handles multiple axis rotation is that it seems to run into an issue similar to gimbal locking (http://en.wikipedia.org/wiki/Gimbal_lock). I ran into this problem while trying to make a function that draws a texture that is always facing the camera. It worked properly until you rotated the camera to a specific angle. When I tried to test rotation in specific ways to see if it was a problem with my math, it seemed to go crazy and didn't look right. A bit of research indicated that using quaternions to handle rotation circumvented the problem somehow, but again, I don't exactly know how.
As for quaternions being no joke, my brother turned out to be using OpenGL as well and apparently there's a bunch of open source math libraries that include quaternions.
EDIT: Ahahaha, we both posted about gimbal lock at the same time >.<
Sorry for my writing mistakes, English is not my native language.
I think it is better to do without creating a different syntax for various types of files.
Musuu
Script[mdScript]
Type[Player]Musuu
Script[mdScript]
Type[Enemy]Over the last couple of days, I created a prototype, based on the V8 javascript engine. This is an example of danmaku-engine, in which almost all operations are stored in the interpreted files. This is what I would like to see in your program.
In addition, you may be interested in using the v8, sdl_ttf and openil libraries.
http://www.mediafire.com/?2mzzjljjrkn (http://www.mediafire.com/?2mzzjljjrkn) -- an executable file with some scripts.
http://www.mediafire.com/?z05wyzwdmhn (http://www.mediafire.com/?z05wyzwdmhn) -- source code and libraries for VC++ 2008
Musuu
Script[mdScript]
Type[Plural]
Name[EX Chen]
Plural "exChen"
{
initialize
{
// set up the lifebars. This array of arrays is explained below
SetLifeBars([[80, 20], [80, 20, 20], [20]]);
// set up the scripts. Also explained below
SetScripts([["ex_Chen_nonspell_1.txt",
"ex_Chen_spell_1.txt"],
["ex_Chen_nonspell_2.txt",
"ex_Chen_spell_2.txt",
"ex_Chen_spell_3.txt"],
["ex_Chen_spell_4.txt"]]);
}
}Musuu
Script[mdPlural]
Type[Plural]
Name[EX Chen]
// First life bar
// The number at the beginning is each script's contribution to the lifebar length
80 ex_Chen_nonspell_1.txt
20 ex_Chen_spell_1.txt
// Next life bar
next
80 ex_Chen_nonspell_2.txt
20 ex_Chen_spell_2.txt
20 ex_Chen_spell_3.txt
// Next life bar
next
20 ex_Chen_spell_4.txtCheese: I actually like the first Plural script idea you had, as it looks neater and friendlier, in my opinion. Can you get it to have a dynamic length, though?
If by "dynamic length" you mean "set up the boss with different amounts of scripts of lifebars based on certain conditions", then the first one can already do that.Curse my wording. I meant "pass any amount of arrays into it and it will know exactly how long it needs to be internally". I don't have any real experience in coding, so I have no idea what I'm talking about.
If you mean "change the number of scripts or lifebars midway through the boss sequence", that can be done as well. Probably would end up just adding in a tick function for the Plural script, and if at some point it determines we should change the line-up, call the SetLifeBars and SetScripts commands again with the new info.
Player might find it strange that all of a sudden the boss they're facing has two more lifebars, but whatever. :V
Curse my wording. I meant "pass any amount of arrays into it and it will know exactly how long it needs to be internally". I don't have any real experience in coding, so I have no idea what I'm talking about.
SetLifeBars([[80, 20], [20]]);
SetScripts([["nonspell1.txt", "spell1.txt"], ["spell2.txt"]]);SetLifeBars([[80, 20], [80, 20, 20], [80, 20, 20, 30, 20, 20, 20, 20, 20], [5], [9001], [1, 2, 3], [7, 9]]);
SetScripts([["nonspell1.txt", "spell1.txt"], ["nonspell2.txt", "lol", "wtf"], // etc you get the point :VThat's basically what I described above. You could, for instance, have a short stage 1 boss:I meant internally, in the game's coding, not on the end result. :p Like I said, I don't know much about coding at all, but I didn't know it was possible to make something like that in the coding and have its required length to work dynamically change to fit the amount passed into the function...Code: [Select]SetLifeBars([[80, 20], [20]]);
SetScripts([["nonspell1.txt", "spell1.txt"], ["spell2.txt"]]);
You could also have a really long boss:Code: [Select]SetLifeBars([[80, 20], [80, 20, 20], [80, 20, 20, 30, 20, 20, 20, 20, 20], [5], [9001], [1, 2, 3], [7, 9]]);
SetScripts([["nonspell1.txt", "spell1.txt"], ["nonspell2.txt", "lol", "wtf"], // etc you get the point :V
I meant internally, in the game's coding, not on the end result. :p Like I said, I don't know much about coding at all, but I didn't know it was possible to make something like that in the coding and have its required length to work dynamically change to fit the amount passed into the function...
int number_list[];
// bunch of stuff
int number_count = get_amount_of_numbers;
number_list = new int[number_count];
// etc ...Wow. This project looks awesome.
I know C# (I took a class entitled "Graphics Programming" at school; it should've been called "game Programming" and the text book was definitely "XNA Game Studio 3.0 Unleashed").
Hey, I can't wait to try the finished product. When you finish it (or if you need a tester) email me or something (I can't guarantee my presence at the forums all of the time) and I'll be glad to help out.
Also, you should:
a) put the download links to the latest builds on the front page
b) upload those builds to your Google Code page
Just sayin'.
Aren't we going to need to make a new thread soon, anyways, since we're approaching 500 posts?
There's a couple more things I'm thinking about, and I'm wondering what ones people would want to see implemented before the next test release ...
- New script commands
- test if an object exists by ID
- random numbers
- Support for multiple directories (right now it only uses the directory the program is in)
- Other things I'm not thinking of at the moment?
shot = FireShot01(parameter, stuff, here, etc...);
SetRect(shot, 0, 0, 16, 16);TSO upped it to 1000 posts after some forum upgrade, so we're good for now.
I'm looking forward to any new releases you make. I'll be watching the google code page while I'm at school. I'd love to help you if I can (especially with something like writing the documentation; I'm OCD enough to make it all-encompassing)
EDIT: home != school
Random numbers shouln't be much of a burden (just a mdbase command linking to System.Random and a corresponding mdscript command linking to the mdbase one) so adding them in shouldn't be much of a problem. All the features are practically necessary to add at some point of time, but aren't in such a hurry.
Graphic rects I guess. Having to use seperate image files for all the bullets is STILL a pain. Some sort of SetRect() -function for objects would do well for starters. Maybe implement it so that you give the object ID to it alongside with the rect, or just make two versions with one asking object ID and one defaulting at currect object, since my look at the source code tells me that CreateShot01(S) returns the ID of the shot object (how come no-one told me this before?!? It's incredibly useful!), so you could just write:Code: [Select]shot = FireShot01(parameter, stuff, here, etc...);
SetRect(shot, 0, 0, 16, 16);
Of course, whenever shot data is implemented (I assume that might take a while), this might become obsolete, so consider whether it is worth it, but at least add such a function for the current object at some point of time.
Musuu
Script[ShotData]
ChenShot01
image chenshot01.png
subimage 0, 0, 15, 15
hitbox 3.5, 7
rotate true
spin 0The trick with random numbers is making sure that they work with replays. I know how to do that, but it makes it a bit more than just "Call System.Random lol". ;)
Speaking of the shot data, I don't think it'll be that hard to do, honestly. The main thing we need is to agree on what information is needed, and a way to present it to the program. Here's the list of items I think we need for a shot type, just pulling the idea from the top of my head:
- Graphic & graphic subrect
- Hitbox sizes
- If the shot rotates with the angle it is moving at
- Rate at which the shot graphic spins
I still also want to, later on, try that thing I mentioned before, where you can color-key a bullet image and then give it a color at runtime. It would make things simpler, since the scripter wouldn't need to define "MyShot01Blue", "MyShot01Azure", "MyShot01LightBlue", etc, instead just defining "MyShot01" and giving it the color each time, as needed.
It'd also allow the use of literally any color in the RGB spectrum (without making utterly ridiculous amounts of bullet definitions).
@Nuclear Cheese: I know doc is most people's least favorite part, that's why I volunteered for it :P
I pretty much want to make it so that, with each release, every (user-accessible) function is documented cleanly, either (preferably) in a website, maybe auto-generated by Doxygen (which I need to learn to use anyway), and in the source code they are all commented properly for those who want to look and see the insides.
My main reason for wanting to do it (aside from gaining an intricate knowledge of how your game works, learning some new programming techniques, scripting, etc) is that every project I've ever used had some part of the doc that was confusing, not finished, ignored, or just lazily done, making my job harder. I want to see this thing produce some awesome games, and to do that, people are gonna need to know how to use it.
After a sizable absence (pfffft, Like you missed me :V), I have returned and played the latest Test Release.
^^ Great work. Playing a lot smoother than the last one I tried, and I even managed to put together a random, mini little pattern to dodge through. I felt all pro.
Test Release 4
Download is hosted on the project page here (http://code.google.com/p/musuu-no-danmaku/downloads/detail?name=Musuu%20no%20Danmaku%20-%20Test%20Release%204%20%282010%20Jan%2031%29.zip&can=2&q==).
This should contain all necessary .dll's and such, although with the new inclusion of fonts I might have missed something again.
Musuu no Danmaku version 0.1.3683.32116
Starting logging file ...
2010 Feb 01 02:55:25.718 - Reading config file ...
2010 Feb 01 02:55:25.765 - Finished reading config file.
2010 Feb 01 02:55:25.765 - Initializing engine ...
2010 Feb 01 02:55:25.781 - Initializing graphics: 800x600 windowed, hardware surfaces enabled
2010 Feb 01 02:55:27.875 - Initializing font ...
2010 Feb 01 02:55:27.890 - Error during initialization: Unable to load DLL 'freetype6.dll': The specified module could not be found. (Exception from HRESULT: 0x8007007E)
Stack trace:
at Tao.FreeType.FT.FT_Init_FreeType(IntPtr& alibrary)
at Musuu_no_Danmaku.Font.Init_Font()
at Musuu_no_Danmaku.Graphics.Initialize()
at Musuu_no_Danmaku.Program.Main(String[] args)
The program will close now.
Code: [Select]Musuu no Danmaku version 0.1.3683.32116
Starting logging file ...
2010 Feb 01 02:55:25.718 - Reading config file ...
2010 Feb 01 02:55:25.765 - Finished reading config file.
2010 Feb 01 02:55:25.765 - Initializing engine ...
2010 Feb 01 02:55:25.781 - Initializing graphics: 800x600 windowed, hardware surfaces enabled
2010 Feb 01 02:55:27.875 - Initializing font ...
2010 Feb 01 02:55:27.890 - Error during initialization: Unable to load DLL 'freetype6.dll': The specified module could not be found. (Exception from HRESULT: 0x8007007E)
Stack trace:
at Tao.FreeType.FT.FT_Init_FreeType(IntPtr& alibrary)
at Musuu_no_Danmaku.Font.Init_Font()
at Musuu_no_Danmaku.Graphics.Initialize()
at Musuu_no_Danmaku.Program.Main(String[] args)
The program will close now.
Yes, you definitely missed something. *googles*
Yeah, slapping freetype6.dll in there fixed it.
But there are still no sample sounds! Lol.
I submit my laser-thingy-noise as the death-SFX, since I dunno how else to make a Jimmy Hart version of ZUN's ... maybe I'll throw together something similar for a Spell Card noise and a "powerup" SFX ...
Sorry if I ignore all the work done by the developers so far, but wouldn't the project be better started from scratch with C#, XNA and LuaInterface?
Why?
Dunno, I think LUA is very solid and a perfect language for this project. Why create a new scripting language?
Point the fourth - Call me insane, but I found it easier to script up my own scripting language rather than using Lua (at least partly a lack of familiarity with Lua, but such is things).
Point the fifth - While it's not supported currently, if there's significant demand I believe we could add support for Lua scripts (even running alongside other scripts!) sometime in the future.
Point the sixth - Setting up a custom scripting language, in my view at least, makes it easier to custom-tailor the functionality of it to the specific purpose of the program. Also, it makes it easier to add in features that aren't yet supported, since it's all our code.
I tried running it, all i get is a blue screen, even after i installed SDL.NET.
I don?t get it... why isn?t it working?
Musuu no Danmaku version 0.1.3683.32116
Starting logging file ...
2010 Feb 05 19:08:17.548 - Reading config file ...
2010 Feb 05 19:08:17.618 - Finished reading config file.
2010 Feb 05 19:08:17.618 - Initializing engine ...
2010 Feb 05 19:08:17.669 - Initializing graphics: 800x600 windowed, hardware surfaces enabled
2010 Feb 05 19:08:20.804 - Initializing font ...
2010 Feb 05 19:08:20.838 - Error during initialization: Die DLL "freetype6.dll": Das angegebene Modul wurde nicht gefunden. (Ausnahme von HRESULT: 0x8007007E) kann nicht geladen werden.
Stack trace:
bei Tao.FreeType.FT.FT_Init_FreeType(IntPtr& alibrary)
bei Musuu_no_Danmaku.Font.Init_Font()
bei Musuu_no_Danmaku.Graphics.Initialize()
bei Musuu_no_Danmaku.Program.Main(String[] args)
The program will close now.Code: [Select]Musuu no Danmaku version 0.1.3683.32116
Starting logging file ...
2010 Feb 05 19:08:17.548 - Reading config file ...
2010 Feb 05 19:08:17.618 - Finished reading config file.
2010 Feb 05 19:08:17.618 - Initializing engine ...
2010 Feb 05 19:08:17.669 - Initializing graphics: 800x600 windowed, hardware surfaces enabled
2010 Feb 05 19:08:20.804 - Initializing font ...
2010 Feb 05 19:08:20.838 - Error during initialization: Die DLL "freetype6.dll": Das angegebene Modul wurde nicht gefunden. (Ausnahme von HRESULT: 0x8007007E) kann nicht geladen werden.
Stack trace:
bei Tao.FreeType.FT.FT_Init_FreeType(IntPtr& alibrary)
bei Musuu_no_Danmaku.Font.Init_Font()
bei Musuu_no_Danmaku.Graphics.Initialize()
bei Musuu_no_Danmaku.Program.Main(String[] args)
The program will close now.
did you forget to update your zip?
because it seems that a certian DLL is still missing.
One more question though - the way you described it, were you indicating that the program doesn't close on its own when it is erroring? If so, that's something that needs to be fixed.
EDIT?: also... i noticed (while playing around and making a script on my own) that, depeding on how much there is on the screen it slows down and that INCLUDES the text function (especially the amount of letters used in them). hopefully it is just my computer...
Oh yeah -- after fooling around with SimSynth (http://www.threechords.com/hammerhead/simsynth.shtml) a bit, I have managed to produce an SFX (http://www.mediafire.com/?myrzo2nkzdm) which is almost, but not quite, enturely unlike the Touhou death SFX.Found it!
here's a sort-of spellcard sound (http://www.mediafire.com/?gmntmyh2zty) and a mediocre charge-up sound (http://www.mediafire.com/?lkgyjnujvy0).
It just shows a blue screen and then closes on it?s own. It would be helpful to get a "DLL-Missing" box, kinda like the Touhou games have.
EDIT: got the .dll now.
It would be kinda helpful if there was an .html file whice has all the functions explained...
because i don?t know whice of these things does what, and i don?t feel like searching for them on the 17 pages of this topic (18th page not counted as there aren?t any informative posts here, yet)
EDIT?: oh btw... i just made the first (to my knowledge) customed character in the history of Musuu no Danamku.
Download here! (http://www.mediafire.com/?3qwyymnnlmy)
Zip includes: player script(of course), shot(:V) and sprite(whice looks messed up inside the program for some wierd reason).
EDIT?: also... i noticed (while playing around and making a script on my own) that, depeding on how much there is on the screen it slows down and that INCLUDES the text function (especially the amount of letters used in them). hopefully it is just my computer...
Yes. The program starts to slow down at certain object amounts, which due to the code not being optimized enough are somewhat low (for bullet hell standards). For me it's about 1000 objects onscreen on my newer computer and about 500 on an older one. A major part of this is most probably the still-unoptimized collision checking, since the slowdown stops whenever the player character dies, even if I don't set the code to clear the bullets upon death, but also starts up again when the player character respawns. Danmakufu has similar limits, but only much higher (about 4000 small bullets on my newer computer). I haven't tried text drawing functions yet but I do know they cause higher amounts of slowdown than ordinary images, since the same happens with Danmakufu, too.
This however does prove that the collision checking code (and possibly even other parts of the program like graphics rendering) are in need of optimization. I assume this will be done once the initial features are added in and the developers can start planning on releasing a stable release.
Also, concerning these "initial features", could it be useful to piece together a to-do list on whatever should be finished before the initial "stable" release, or possibly even the releases afterwards. There's been a lot of suggestions flying around in this topic but one has yet to gather them together in a single list. It could help people get an idea on what still has to be done, and having one for the initial release could help developers to decide on when to stop adding features and start fleshing out the program (more user-friendly error handling, code optimization and stuff like that). Then, after the program has a stable user-friendly release, all the useful extra features that aren't necessary for the first release could be added in.
Found it!
And here's a sort-of spellcard sound (http://www.mediafire.com/?gmntmyh2zty) and a mediocre charge-up sound (http://www.mediafire.com/?lkgyjnujvy0).
I'm kinda intrigued as to why SCARD and CHARGEUP are in WAV format, while Spooon is in OGG ...Um ... because I forgot I'd converted spoon into OGG before. |3
At least there's Test release 4.1 (http://code.google.com/p/musuu-no-danmaku/downloads/detail?name=Musuu%20no%20Danmaku%20-%20Test%20Release%204.1%20%282010%20Feb%2006%29.zip&can=2&q=#makechanges).
Just added in the missing .dll file.
I tried this, but I'm still getting a window to pop up with a blue background, then it closes (on linux). Maybe I need freetype6.dll.config? I can't seem to find it anywhere though. I did copy the other .config files for the tao framework though.
PS - a couple comments on your script (not being mean, just some hints and possible improvements):I accidentaly added Hitbox.png in there, sorry.
- Not sure if it's intended or not, but you make no reference to Hitbox.png
- You're not correctly reassigning the player sprite to danielu2.png, so that image is never shown either. You need to call SetImage again with the new image name; simply reassigning the variable player won't work.
Also, you might want to take the image assignment outside of the if statement, so that the image will reassign even if the player isn't firing.
tick
{
count = count-1;
SetImage(player, true, 20);
if (count <= 0 && GetKeyState(key_shot))
{and it crashes, as soon as i call the playerscript.//set variable to unfocused sprite here
player = "danielu.png"
if (GetKeyState(key_focus))
{
//set variable to focused sprite here
player = "danielu2.png"
}
SetImage(player, true, 20);I accidentaly added Hitbox.png in there, sorry.
I tried to make the second sprite appear in many different ways, this was one of the only things that worked and didn?t crash the program.
I put it here:Code: [Select]tickand it crashes, as soon as i call the playerscript.
{
count = count-1;
SetImage(player, true, 20);
if (count <= 0 && GetKeyState(key_shot))
{
EDIT: After some playing around with the script, i got it to work but i don?t know how...Code: [Select]//set variable to unfocused sprite here
player = "danielu.png"
if (GetKeyState(key_focus))
{
//set variable to focused sprite here
player = "danielu2.png"
}
SetImage(player, true, 20);
will update the scriptfile now and re-upload it.
EDIT2: Download the first MusuuNoDanmaku Character that has an visable hitbox if focused. (http://www.mediafire.com/?ykymjhlnzmy)
Oh, in case we're uploading our player characters:
PT8's awesomeface character you may have seen already in this thread. (http://www.mediafire.com/?ndondenntnm)
Features respawning (it has infinite lives as of now, I planned on implementing a life counter but I'm currently too lazy for that), visible hitbox (both when focused and unfocused), initial invincibility upon respawning and options. The sprite and the options aren't made by me, but the shots and the hitbox are. Also comes with a custom death SFX I made that may be reused as you see fit.
[...] PT8Sceptile beat you to the "MnD player with a visible hitbox when focused" thing [...]
Anyway, I'm interested in how your scripting engine works... Will you release the source code, or at least the scripting language part of the source code?
The source code has been released for a while in the Google Code repository (http://code.google.com/p/musuu-no-danmaku/source/browse/#svn/trunk). Also, the program apparently uses a tool called ANTLR to translate the scripting language into a simpler language it can read, so researching that might also have some advantages in understanding the grammar file of the program (or more like may be necessary to understand it, since I can understand the rest of the code with no prior C# experience but can't figure out how the grammar file works at all since I haven't studied how ANTLR works).
EDIT: I made some spellcards out of boredom. (http://www.mediafire.com/?nwmmgzjqnmu)
What's the logfile say?
I don't think the .config files are necessary, to be honest, but if everything else fails it might be worth a try.
Musuu no Danmaku version 0.1.3683.32116
Starting logging file ...
2010 Feb 07 23:12:25.936 - Reading config file ...
2010 Feb 07 23:12:25.965 - Finished reading config file.
2010 Feb 07 23:12:25.966 - Initializing engine ...
2010 Feb 07 23:12:26.082 - Initializing graphics: 800x600 windowed, hardware surfaces enabled
2010 Feb 07 23:12:27.409 - Initializing font ...
2010 Feb 07 23:12:27.443 - Error during initialization: freetype6.dll
Stack trace:
at (wrapper managed-to-native) Tao.FreeType.FT:FT_Init_FreeType (intptr&)
at Musuu_no_Danmaku.Font.Init_Font () [0x00000]
at Musuu_no_Danmaku.Graphics.Initialize () [0x00000]
at Musuu_no_Danmaku.Program.Main (System.String[] args) [0x00000]
The program will close now.Code: [Select]Musuu no Danmaku version 0.1.3683.32116
Starting logging file ...
2010 Feb 07 23:12:25.936 - Reading config file ...
2010 Feb 07 23:12:25.965 - Finished reading config file.
2010 Feb 07 23:12:25.966 - Initializing engine ...
2010 Feb 07 23:12:26.082 - Initializing graphics: 800x600 windowed, hardware surfaces enabled
2010 Feb 07 23:12:27.409 - Initializing font ...
2010 Feb 07 23:12:27.443 - Error during initialization: freetype6.dll
Stack trace:
at (wrapper managed-to-native) Tao.FreeType.FT:FT_Init_FreeType (intptr&)
at Musuu_no_Danmaku.Font.Init_Font () [0x00000]
at Musuu_no_Danmaku.Graphics.Initialize () [0x00000]
at Musuu_no_Danmaku.Program.Main (System.String[] args) [0x00000]
The program will close now.
As I suspected, it has to do with freetype6.dll...
So, I tried to create a danmaku in Musuu no Danmaku.
And it worked. It crashed if I tried to play music, but, oh well.
Here (http://www.mediafire.com/?z1n4azjznhm) it is. I don't know what it is, but it's there.
(P.S. The music crash didn't bring up anything in the log. I don't know whats up with that.)
Some things that I really hope you add:
- Some way to get the ids of all objects of a given type (e.g. not just all Effects, but all Effects named "Option")
- Some way to get the id of the boss
- Some way to set the hit box of default bullets
All that being said, Musuu no Danmaku is awesome. Keep up the good work!
PlaySfx("PlayerDeath.ogg");And it did cause the whole program to quit. This code is inside of the Awesomeface player character, and the download for that includes "PlayerDeath.ogg".Musuu no Danmaku version 0.1.3683.32116
Starting logging file ...
2010 Feb 10 23:09:04.875 - Reading config file ...
2010 Feb 10 23:09:04.937 - Finished reading config file.
2010 Feb 10 23:09:04.937 - Initializing engine ...
2010 Feb 10 23:09:04.984 - Initializing graphics: 800x600 windowed, hardware surfaces enabled
2010 Feb 10 23:09:10.234 - Initializing font ...
2010 Feb 10 23:09:11.125 - Graphics init completed.
2010 Feb 10 23:09:11.125 - Loading script objects ...
2010 Feb 10 23:09:11.359 - Creating new Game object ...
2010 Feb 10 23:09:13.640 - Error building file list: The process cannot access the file 'C:\Documents and Settings\Bille\Desktop\Musuu no Danmaku\Musuu no Danmaku log file starting 2010 Feb 10 2309.txt' because it is being used by another process.
Stack trace:
at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
at System.IO.FileStream.Init(String path, FileMode mode, FileAccess access, Int32 rights, Boolean useRights, FileShare share, Int32 bufferSize, FileOptions options, SECURITY_ATTRIBUTES secAttrs, String msgPath, Boolean bFromProxy)
at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize, FileOptions options)
at System.IO.StreamReader..ctor(String path, Encoding encoding, Boolean detectEncodingFromByteOrderMarks, Int32 bufferSize)
at System.IO.StreamReader..ctor(String path)
at Musuu_no_Danmaku.Menu.Fill_In_File_List(Boolean select_players)
2010 Feb 10 23:09:13.750 - Starting main loop ...
2010 Feb 10 23:09:17.406 - Loading script file: TheEnemy.txt
2010 Feb 10 23:09:17.625 - Loaded Object_Type - TheEnemy of type Boss
2010 Feb 10 23:09:17.640 - Loaded Object_Type - EvilShot of type Enemy_Shot
2010 Feb 10 23:09:17.656 - Error building file list: The process cannot access the file 'C:\Documents and Settings\Bille\Desktop\Musuu no Danmaku\Musuu no Danmaku log file starting 2010 Feb 10 2309.txt' because it is being used by another process.
Stack trace:
at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
at System.IO.FileStream.Init(String path, FileMode mode, FileAccess access, Int32 rights, Boolean useRights, FileShare share, Int32 bufferSize, FileOptions options, SECURITY_ATTRIBUTES secAttrs, String msgPath, Boolean bFromProxy)
at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize, FileOptions options)
at System.IO.StreamReader..ctor(String path, Encoding encoding, Boolean detectEncodingFromByteOrderMarks, Int32 bufferSize)
at System.IO.StreamReader..ctor(String path)
at Musuu_no_Danmaku.Menu.Fill_In_File_List(Boolean select_players)
2010 Feb 10 23:09:18.390 - Loading script file: Awsumface.txt
2010 Feb 10 23:09:18.390 - Loaded Object_Type - ThePlayer of type Player
2010 Feb 10 23:09:18.390 - Loaded Object_Type - Respawner of type Effect
2010 Feb 10 23:09:18.390 - Loaded Object_Type - Hitbox of type Effect
2010 Feb 10 23:09:18.406 - Loaded Object_Type - LeftOption of type Effect
2010 Feb 10 23:09:18.406 - Loaded Object_Type - RightOption of type Effect
2010 Feb 10 23:09:18.437 - Spawning an object of type TheEnemy as the enemy.
2010 Feb 10 23:09:18.656 - Spawning an object of type ThePlayer as the player.
The particular command that caused the crash wasCode: [Select]PlaySfx("PlayerDeath.ogg");And it did cause the whole program to quit. This code is inside of the Awesomeface player character, and the download for that includes "PlayerDeath.ogg".
The error doesn't appear in the log. However, I do have a whole bunch of weird stuff in the logs, so I'll just show you the log after the crash. Here you go:
<t3h log>
(Oh wait! P.S.! Is there are rand() function or something. Because I need a rand() function. My above script uses the players x location as some sort of hobo's rand(), but a real rand() would super awesome.)
(P.S. II! I've created a Notepad++ syntax for mdScript, and I can post that too.)
The particular command that caused the crash wasCode: [Select]PlaySfx("PlayerDeath.ogg");And it did cause the whole program to quit. This code is inside of the Awesomeface player character, and the download for that includes "PlayerDeath.ogg".
Odd ... I haven't tested using OGG for sound effects, but I'm guessing PT8Sceptile had it working if it was included. I'll try to take a look at this once I get back to my desktop.
Oh, and arcanesign - gave a bit of thought to your weird DLL issue ... are you using the DLL from test release 4.1, or did you download the DLL from somewhere? That might have something to do with it, if you did grab a different one.
if (player_id > -1)
{
xdiff = player_id->x - id->x;
ydiff = player_id->x - id->y;
if (xdiff == 0 && ydiff == 0) ydiff = 1;
angle - atan2(ydiff, xdiff)l
}gets tiring after a while.Well, here's (http://www.mediafire.com/?zlml2ldjzuy) my second danmaku. Unlike the last one, this one isn't terrible.
Something I noticed: A GetAngleToPlayer() or a GetAngleToObj() function would be really nice. having to type:Code: [Select]if (player_id > -1)gets tiring after a while.
{
xdiff = player_id->x - id->x;
ydiff = player_id->x - id->y;
if (xdiff == 0 && ydiff == 0) ydiff = 1;
angle - atan2(ydiff, xdiff)l
}
I'll keep making stuff. Have a nice day/night.
Well, here's (http://www.mediafire.com/?zlml2ldjzuy) my second danmaku. Unlike the last one, this one isn't terrible.
Do you have the "Shot" directory?
[...] if you don't want me using your bullets, just tell me.
I used the one in the 4.1 release, downloaded the whole thing from the google code page.
Also, as for the To-Do -list for the initial release I suggested, here's something to start with (since no-one else is apparently creating one):
- Bullet definition files
Of course. ;)
- Additional functions for:
- Random numbers
- Improved audio control (loop points, pausing/resuming, possibly fadein/fadeout)
- Possibly some improved bullet shooting functions like CreateShotA to avoid having to script overtly simple patterns with objects
Of course. Need to plan this out a bit, but I'm planning on adding a miss script, for player scripts to take action to animate their "ONOES I DEAD" and such, with a default for when there isn't one specified by the player script.
- Default support for:
- Lives/respawning
- Points/Graze (partially implemented with -dt, but needs to be shown on the interface and lack handling functions like GetGraze() and SetPoints())
- Bombs (altough I could see these being already scripted with some cleverness in player scripts, these probably need a default implementation, too)
- Power system
- Plural files, stage files, possibly game files?
- Dialogue events
- Lasers
- Effect objects with vertices, possibly 3D drawing (altough I'm not sure if 3D drawing needs to be in the initial release, but that's your call).
- User-defined functions/subroutines (tasks can probably be simulated well enough with dummy objects).
- Inter-object messaging
- Replays
- Various bugfixing
- Code optimization to make the program run faster
- Better error handling
All I would add to that would be:
- Custom collisions
- Documentation
- More bullet graphics
More comments on Musuu no Danmaku itself:
- Needs a sqrt() function
- Or some other way to find the distance between objects
- Custom Player Shots
Well, I finished my player early, so here (http://www.mediafire.com/?ytttvymrrda) it is. It's nothing special, but it has a working hit box, startup invincibility, and it re-spawns after 2 seconds. The hit box, invincibility, and re-spawner are inspired by PT8Sceptile's awesomeface player, but are, for the most part, coded differently.
The Mima sprite sheet came form Johnny Walker's Mima (Mystic Square) touhou danmakufu player script. If using that was bad, well, I'm sorry! I won't do it again!
Well, here's (http://www.mediafire.com/?zlml2ldjzuy) my second danmaku. Unlike the last one, this one isn't terrible.
Something I noticed: A GetAngleToPlayer() or a GetAngleToObj() function would be really nice. having to type:Code: [Select]if (player_id > -1)gets tiring after a while.
{
xdiff = player_id->x - id->x;
ydiff = player_id->x - id->y;
if (xdiff == 0 && ydiff == 0) ydiff = 1;
angle - atan2(ydiff, xdiff)l
}
I'll keep making stuff. Have a nice day/night.
Do you have the "Shot" directory? I thought it came with the Musuu download, but it doesn't seem to have. I think it was in one of the other test danmaku. I don't remember which one, though. If you can't find it, I'll put up a download link to it.
I actually made them to be used forDanmakufuMusuu No Danmaku scripts.
But i wasn?t expecting anyone to already use them this early... i might try to also make different colored versions of Shot2.png but i used it once and it wasn?t turning (all bullets pointed to the bottom while flying in any direction), preaty much just a bunch of "V"s on the screen.
That's pretty much all I can think of in the moment that Musuu needs to obsolete Danmakufu. If I've forgotten something, just add it to the list, and if you consider something on the list too irrelevant/tricky to implement for the first release, feel free to exclude it. This is just something to help people get a better idea on the amount of work left.
...Also, considering that this has been worked on for about half a year pretty much only during weekends, I'm really surprised on how short that list is.
Okay, by "Custom Collisions" I just meant letting us script what happens when one object hits another.
I can't remember what I wanted it for though. Hmm... It probably wasn't important.
// stuff
{
// stuff
collide "SomeObject"
{
// do stuff here
}
collide_2 "SomeOtherObject"
{
// do stuff here
}
// stuff
}Can be done. Do we want something specifically mirroring CreateShotA, or something similar, but with some differences?
Of course. Need to plan this out a bit, but I'm planning on adding a miss script, for player scripts to take action to animate their "ONOES I DEAD" and such, with a default for when there isn't one specified by the player script.
Yeah, a default implementation is definitely needed. Will most likely add a bomb script for this.
Certainly planned. We need to nail down the formatting for how these'll work ... there were some ideas thrown around earlier, I remember.
Planned, although these are probably gonna take back-seat to the more gameplay-related items.
These are gonna be a bit tricky to implement, but I'm sure they'll get in there.
I'd say this is lower-priority, but certainly planned at some point.
Functions are definitely planned. I do plan on adding tasks later on, but they will work a bit differently than Danmakufu's tasks.
Already possible via global variables. I do, however, have plans for an actual implementation of this type of thing specifically. Probably low priority, though.
define GlobalVar
Object "SomeObject" {
initialize {
//Do stuff to GlobalVar.
GlobalVar = 5;
}
}
Object "SomeOtherObject" {
tick {
//Do some other stuff to GlobalVar
GlobalVar++;
}
}
More bullet graphics
Of course. Will probably come with or shortly after the bullet definition files. The ones in the test releases are just quick samples. I suck at making graphics anyways.
There's also my idea that would allow the use of one graphic to create bullet graphics of any color, most likely using shaders.
Or some other way to find the distance between objects
Could be calculated by a script once we have exponents in, but we can also add in a helper function for this.
You can already script custom player shots by using the Player_Shot base type, much like using Enemy_Shot for a custom enemy shot.
I can add a helper function for this. Only question is - what should be used when there is no player object to get an angle to? Should we return any specific default value?
Danmakufu's CreateShotA -system works decently. However, Musuu might be able to get away with less thanks to being able to modify the properties of ordinary non-object shots in the main script just by saving the ID returned by the CreateShot-function in a variable.
They're pretty much "effect-objectlike bullets" with render-type ADD instead of ALPHA and vertices laid out so that the bullet image is "stretched" in Danmakufu. The same will probably work in Musuu, with possibly an option for a "repeat this graphic" -type laser, too. They just need their own rendering function (or a generic rendering function for effect objects that they use, too), and the collision types. Collision is annoying, though. It has to be an ellipse or a line segment with radius (http://www.shrinemaiden.org/forum/index.php?topic=2129.msg99168#msg99168), like was already suggested before. In both cases collision-checking is a bit trickier than simple circular collision checking.
Well, adding Danmakufu-like tasks would be redundant since dummy objects can do pretty much everything they can, and the object-based programming Musuu's scripting language uses makes them somewhat obsolete.
...wait? You can define global variables in Musuu? Somehow like this?
t3h codez
If that's possible, scripting with this just became about a million times more effective.
Also, I have a suggestion regarding the messaging system. Could we define a "dummy property" for each object that could be accessed with the property operator like ObjectID->arg , but doesn't have any direct effects on the behavior of the object like ObjectID->x, ObjectID->y, ObjectID->speed or ObjectID->angle have. This could serve as a simple "messaging system" between objects since you can pass arrays as the variable. This would be especially useful once Musuu can add and remove items in an array like array = array ~ [1] and array = erase(array, 3) in Danmakufu (if that hasn't been implemented yet), since then you could just have an object's dummy property be an array of arrays where you add arrays as "messages" and remove them in the object being messaged to after handling them properly (for example, if you want to inform an object you have made to start firing, you could in the boss object just code: Obj->arg = Obj->arg ~ [["FireStuff"], [true]]; The recipient object sees that the arg-array has an item. Checks arg[0][0], sees that it concerns "Firing stuff", checks arg[0][1], sees it's true, sets a local variable true to instruct it's tick-script to fire stuff, does the same for other "messages" in arg like arg[1][0], arg[2][0] etc... as long as arg has any messages and then cleans arg so that it's an empty array again).
With image subrects in one could probably already use the existing shotsheets like the CtC one and such.
By the way, something about custom player shots that's interesting me: How does one define how much damage they do to the boss aside from using the parameter in the default player shot dreation function? Does that have some function of it's own that can set it or do we just have to custom-code the collide functions to damage the enemy?
I'm suggesting downwards as the default value.
Also, concerning the To-do -list, I guess I forgot a simple item that should be added to it: Drawing functions. While effect objects can do most of the things they can, I'd guess adding them could be a major timesaver when scripting backgrounds. Just something to consider.
The collision checking is probably the roughest part of implementing lasers ... we need a good model of the laser shape and routines to collision-check it with the same as well as other shapes. But, of course, we'll get there.You can take a look at the TouhouDS source code (specifically src/arm9/collision.cpp). It has functions for circle<->circle, line<->circle and line<->line collision checking. The rest of the code is also pretty well optimized.
You could perhaps use my shotsheet when it's done. It was originally made just for my DMF project, but I'd love to see it used elsewhere. It would need to wait until your implementation of actual sheets is supported, though (and PNG alpha channel, if that's not already done).
You can take a look at the TouhouDS source code (specifically src/arm9/collision.cpp). It has functions for circle<->circle, line<->circle and line<->line collision checking. The rest of the code is also pretty well optimized.
Almost. You use the global keyword to define them instead of define. I did it like this to make the syntax less ambiguous.
Another important note is that a global variable will only be recognized by scripts in a file that define it as a global. With your example, for instance, if another code references a variable named GlobalVar without declaring it as global, it'll still be a local-scoped variable, even though it is a global defined elsewhere. This is necessary so that we don't pollute one script's variables by defining globals in another.
My plan was to allow a script to define functions that could be called by other script objects, with a syntax something like:
some_other_object_id->message_function(arg);
These would allow you to define object behaviors that can be called upon externally.
Sound like a good idea?
SetLife(#)
Since shots have no need for a life counter, I use the life value for the amount of damage a player shot will do to the enemy.
It should already support alpha transparency. As far as support for sheets, it's sort-of there ... to use it right now, you'll need to define a custom enemy shot type so you can set the graphic properties. Of course, this will change by the time we have bullet definition files.
SetObjImgRect(FireShot01S(GetX(), GetY(), angle + tcount/2/90*pi + pi, 2, "sheet.png"), 16*8, 16*8 + 16, 0, 16);Quick update - just added random numbers. Two functions:
rand() - simply returns a number in the range of [0.0, 1.0)
rand_int(low, up) - returns an integer in the range of [low, up)
Important to note that current implementation, at least, the upper bound on rand_int is a value it won't hit (this is how the underlying command, System.Random.Next(int, int) is implemented). If there's demand, I can add in code to adjust for this behavior.
- Some more mathematical functions like the power function.
- Improved audio control (loop points, pausing/resuming, possibly fadein/fadeout)
*PT8 suddenly remembers all the positive side-effects of having a good documentation.
Wait what?Code: [Select]SetObjImgRect(FireShot01S(GetX(), GetY(), angle + tcount/2/90*pi + pi, 2, "sheet.png"), 16*8, 16*8 + 16, 0, 16);
All that is needed to get a specific bullet image out of a shotsheet is one line of code like this (it does, however, get a bit repetitive having to type all of this in so I'm eagerly waiting for the bullet definition files).
Can I make a suggestion? Don't use "life" for "this is how much damage it does" -- what if you want a shot to keep going after it hits something, and you want to specify "number of times the shot can hit something before dying"?
you should also make different scoring systems available like normal bombing, MoF style power, and UFOs.
For documentation, you may want to skim through these articles, I found them helpful:
http://jacobian.org/writing/great-documentation/
Didn't feel like reading the whole thread, but are the shotsheets like in Danmakufu, or it's just a colour and you change Hue via code?
If you could put out another test release with the random number functions or something, I would really appreciate it. I've been trying to think of cool danmaku to create, but they all work best with random numbers.
Musuu
Script[mdBullet]
Type[Shot]
shot Shot1
image shot1.png
size1 5.5
size2 7.5
rotate false
shot Shot2
image shot2.png
size1 5.5
size2 7.5
rotate true
rect_x1 0
rect_x2 -1
rect_y1 0
rect_y2 -1
Musuu
Name[Sample Enemy]
Type[Enemy]
// include the shot definitions
include("shots.txt");
// TheEnemy
// Enemy boss that makes some fucking danmaku.
Boss "TheEnemy"
{
// etc ...
Something I noticed when moving stuff to the new version. Musuu no Danmaku can't look into subdirectories. It would make organization much easier if it could. I don't think we should have enforced subdirectories, like in Danmakufu, where players have to be in /player and scripts in /script, but some subdirectory crawling would be nice.
EDIT: What's the optimal ratio of hitbox size to graze hitbox size?
Test Release 5.
Excellent, I've waited this for a long time. At last I can use shots with hitbox size bigger than the default one.
However, you made a tiny mistake. The program errored on me until I changed all the decimal part indicators in the shot definition file from '.' to ','. I assume you do know how to fix this, though, since this has caused you trouble before, too.
I think it'd be a good idea to give line-numbers at minimum when a script fatalerrors. I got "The given key was not found in the dictionary" when I tried to run Phi2Dao's boss-script, which is neither helpful nor informative. :<
Hmm. Maybe some system for "separate hitbox for items and bullets" maybe ... NO I DIDN'T SET THE HITBOX TO ZEROOOOO
I'm planning on writing a bullet definition file for the shot sheet that PT8Sceptile posted earlier (if they don't write one first), and when I do I'll upgrade my old enemies and repost them.
SetSize(size1, size2);
size1 is the collision size. If it's 0, you can't be hit.
size2 is the graze size. If it's 0, you can't graze or collect items.
So, for an invincible player that can still graze and collect items, you want SetSize(0, something); And not SetSize(0, 0);
Right, I did SetSize(0, 32); and I couldn't collect items for some reason.
else if (line.ToLower().StartsWith("size1 "))
{
// define the shot's size1
if (current_name != null)
{
current.size1 = double.Parse(line.Substring(5).Trim());
}
}
else if (line.ToLower().StartsWith("size2 "))
{
// define the shot's size2
if (current_name != null)
{
current.size1 = double.Parse(line.Substring(5).Trim());
}
}
Right, I did SetSize(0, 32); and I couldn't collect items for some reason.
Facepalm. Thankfully fixing that is pretty much trivial now that we know where the problem lies.
collide2 = new Script.Instruction[1];
collide2[0] = mdBaseReader.Parse_Instruction_Line("call \"point_item_collect\", !collided_with_id");
point_item.Attach_Script(collide2, "collide Player");
point_item.Attach_Script(collide2, "collide2 Player");
I would've expected Collide1 for item collection, leaving Collide2 for the magnetism effect...
no? o.o
I would've expected Collide1 for item collection, leaving Collide2 for the magnetism effect...
no? o.o
Yes, found it. Now, for whatever collision type point items use:
While the variable name does indeed cause confusion, I believe this to be collide instead of collide2, since if it were collide2, the last line should be:
Therefore, calling SetSize(0, something) does prevent a player from collecting point items.
This seems like the better idea. Actually, the way this probably should be coded is to leave the point item collect to collide and implement player invincibility through some other means than reducing the collide1 size to zero (most probably through overriding the default "player collided with enemy shot/enemy/boss" collide functions with custom ones on custom players, or perhaps implementing default ones that have inbuilt invincibility support and add a SetPlayerInvincibility function similar to Danmakufu).
You should use collide2 for the magnetism effect, but the actual item hitbox for collecting should be in the coding for the item, not the player. Things like how fast the item moves when it's "magnetized" should also be in the item code.
Just had a thought: a separate "framework" script-type, included by different stage/enemy scripts, and it would handle stuff like lives, score, UI, etc., and then stuff like lives/respawning would be handled in that instead of hardcoded.
Oh yeah, by the way, I forget if there was any plans for the level-script specifying the playing-field size ...
I just put together Test release 5.1 (http://code.google.com/p/musuu-no-danmaku/downloads/detail?name=Musuu%20no%20Danmaku%20-%20Test%20release%205.1%20%282010%2003%2004%29.zip&can=2&q=) - this should fix the two issues that were brought up in 5.
else if (line.ToLower().StartsWith("size2 "))
{
// define the shot's size2
if (current_name != null)
{
current.size1 = double.Parse(line.Substring(5).Trim(), number_format_info);
}
}
Good news: Decimal annotation and point items work as supposed. Good work.
Bad news:
is still looming there in the source code. Just a friendly reminder on the fact that there were actually three problems instead of two.
This is exactly why I feel like grazing etc. should be in scripts instead of hardcoded. |3
Bullets should disappear when they hit the player by default. Preferably in a method tied to the sprite used. :V
Bumping, with what's probably a stupid question, but I've never used this or Danmakufu before and I don't know if I should learn danmakufu or wait for this or use this as is please don't hurt me :ohdear:
Will we be able to do complex, DoDonPachi-style backgrounds, with structures to blow up and ground-based enemies to hide behind them and under bridges and stuff? Or dink around with UI elements, like what bombs or the boss health bar look like?
What I meant by that was that the default animation played by the dissipating bullet would be determined by the sprite used for said bullet. Different bullets dissapear in different ways, you see. :E
Also, if you want to notice it, just go through Kaguya's endgame gauntlet. The one with those quickly moving lines of bullets will make the dissipation rather obvious, if you get hit by said line of bullets.
Fired the example up to test, ran rather slow on my machine [at 800x600, sped up a bit at 640x480, problem went away at 320x240, but that's really small... but I'm so glad my laptop still supports fullscreen with such a low resolution...], and when the life display had a really small decimal part to it [like 50.00000000003], everything went even slower.
I'm on a laptop with a 2.1GHz Dual Core Pentium, 3GB RAM, and one of the Intel GMA things for my video accelerator.
Bumping, with what's probably a stupid question, but I've never used this or Danmakufu before and I don't know if I should learn danmakufu or wait for this or use this as is please don't hurt me :ohdear:
Will we be able to do complex, DoDonPachi-style backgrounds, with structures to blow up and ground-based enemies to hide behind them and under bridges and stuff? Or dink around with UI elements, like what bombs or the boss health bar look like?
Also, concerning the UI, Musuu seems to be headed in a direction where everything is customizable, so yes. Removing the lifebar might be tricky at the moment but otherwise customizing lives/bombs/etc... should be completely possible even as of now. Just add some effect objects on a drawing layer above the border image (which, by the way, can also be changed by changing the border image in the folder). Just remember that using text images is oftentimes faster that drawing text, since both Musuu and DMF have somewhat slow text-drawing functions. You can also achieve similar results in DMF with a bit of effect objects and stuff, but customizing the default functionality is a bit trickier in DMF.
Also, has there been any progress since last update? It's been quite a while and the topic had even fallen down to the second page during that time. I'm not hurrying you up or anything but I'm just curious about how things are proceeding.
A brainstorming-thought: allowing scripters to make a "game" file, which would consist of all the script/graphics/sound/music/EVERY files you want, in one (say) uncompressed zip file, to distribute games more easily.
Also, I kinda forget, but there was a "start music file from arbitrary point" function planned, wasn't there?
Another crazy idea I had recently was whether it might be somehow possible to do Braid-style time-reversal, here or in Danmakufu. I'm really just tossing out ideas as they come to me.
Then I shall concern myself no further with the Braid idea. (I'd imagine that it has something to do with "everything is fugging deterministic" and built an engine specifically for time-reversal shennanigans.)
include("sheet.txt") in your Musuu script.I'm trying to make my own Danmakufu-clone with C#, SFML and LuaInterface, but I can't figure out how to implement a "yield / wait" function in my scripts.I used LUA in TouhouDS -- you can implement yield using lua threads and coroutine.yield()
It took me long enough, but I finally made a shot script for the shot sheet posted earlier. Here (http://www.mediafire.com/?4jmy1nqhbmm) it is. The .rar contains the shot sheet, the shot script, and the ruby program that I used to create the shot script.
To use this, just unpack it in your Musuu folder, and putCode: [Select]include("sheet.txt")in your Musuu script.
NOTES: There is something weird with how Musuu selects rectangles. Sometimes colors bleed into each other. I think the problem isn't on my end though.
PS: I actually have ideas for Danmaku, so I might actually post something sometime soon!
Hey Nuclear, I'm trying to make my own Danmakufu-clone with C#, SFML and LuaInterface, but I can't figure out how to implement a "yield / wait" function in my scripts. Do you run the script in a separate thread? How do you handle the wait function? :blush:
Oh, crazy idea I just had while typing this - in addition to the option of saving the error report like described above, perhaps I could also add the option of saving the complete game state to a file. This would mainly include a listing of all objects currently in the game (position, image, type, object variables, ...) as well as global variables and, once they're implemented, similar information for tasks.
*Concerning lasers, they need 3 things to match DMF:s
- Elliptical/line segment with radius/some other laserlike collision type.
- Stretching effect similar to verticed effect objects.
- ADD rendering.
Number two somehow suggests that verticed effect objects should be higher than low priority, even if 3D certainly is such. Another assistive feature is that they are something that OpenGL practically does for us, the only things required are creating a list of vertices and a variable to save the vertice data interpretion type (for example, TRIANGLEFAN, TRIANGLESTRIP, or the one MnD is currently using in it's draw function: QUADS). Then just add a new draw function or modify the existing one to use vertice data instead of rectangle bounds, and scripting functions to modify these variables.
Collision is however tricky: It's quite easy to approximate elliptical collision, but getting exact results is most certainly not easy. This raises the question of how accurate should MnD:s collisions be (since more accuracy means less efficience). This is especially problematic with small elliptical bullets because there are often hundreds of objects on the screen and if most of them were elliptical, using accurate collision checking methods without a lot of pruning first may result in a noticeable performance drop.
Uh, are you looking for another programmer? I don't really like working alone on a big project.
So, can I give you a hand? :ohdear:
Error in TheEnemy.tick ...
Error in PlaySfx ...
Attempted to load unknown file: C:\Documents and Settings\NuclearCheese\My Documents\Visual Studio 2005\Projects\Musuu no Danmaku\Musuu no Danmaku\bin\Debug\Shot9001.wavError in TheEnemy.tick ...
Error in PlaySfx ...
Attempted to load unknown file: C:\Documents and Settings\NuclearCheese\My Documents\Visual Studio 2005\Projects\Musuu no Danmaku\Musuu no Danmaku\bin\Debug\Shot9001.wav
Object types loaded:
BasicEnemyShot
BasicPlayerShot
PointItem
TheEnemy
EvilShot
AnotherPlayer
Globals:
- point_value [Number_Literal] = 10000
Objects:
0 - TheEnemy
Location: (243, 100)
Angle: 0
Speed: 0
Life: 146.7 / 150
Image: C:\Documents and Settings\NuclearCheese\My Documents\Visual Studio 2005\Projects\Musuu no Danmaku\Musuu no Danmaku\bin\Debug\reimu1.png
Local variables:
- parameters [Array] containing 5 entries
- entry 1 [String_Literal] = reimu1.png
- entry 2 [Number_Literal] = 60
- entry 3 [Number_Literal] = 0.5
- entry 4 [Number_Literal] = 150
- entry 5 [Number_Literal] = 75
- num_bullets [Array] containing 4 entries
- entry 1 [Number_Literal] = 3
- entry 2 [Number_Literal] = 7
- entry 3 [Number_Literal] = 5
- entry 4 [Number_Literal] = 7
- num_bullets_index [Number_Literal] = 1
- count [Number_Literal] = 60
- move [Number_Literal] = 0.5
1 - AnotherPlayer
Location: (241, 379)
Angle: 0
Speed: 0
Life: 0 / 0
Image: C:\Documents and Settings\NuclearCheese\My Documents\Visual Studio 2005\Projects\Musuu no Danmaku\Musuu no Danmaku\bin\Debug\test1.png
Local variables:
- count [Number_Literal] = -7
5 - BasicPlayerShot
Location: (241, 152)
Angle: 0
Speed: 8
Life: 1.1 / 1.1
Image: C:\Documents and Settings\NuclearCheese\My Documents\Visual Studio 2005\Projects\Musuu no Danmaku\Musuu no Danmaku\bin\Debug\player_shot1.png
Local variables:
6 - BasicPlayerShot
Location: (241, 192)
Angle: 0
Speed: 8
Life: 1.1 / 1.1
Image: C:\Documents and Settings\NuclearCheese\My Documents\Visual Studio 2005\Projects\Musuu no Danmaku\Musuu no Danmaku\bin\Debug\player_shot1.png
Local variables:
7 - BasicPlayerShot
Location: (241, 211)
Angle: 0
Speed: 8
Life: 1.1 / 1.1
Image: C:\Documents and Settings\NuclearCheese\My Documents\Visual Studio 2005\Projects\Musuu no Danmaku\Musuu no Danmaku\bin\Debug\player_shot1.png
Local variables:
8 - BasicPlayerShot
Location: (241, 251)
Angle: 0
Speed: 8
Life: 1.1 / 1.1
Image: C:\Documents and Settings\NuclearCheese\My Documents\Visual Studio 2005\Projects\Musuu no Danmaku\Musuu no Danmaku\bin\Debug\player_shot1.png
Local variables:
9 - BasicEnemyShot
Location: (243, 100)
Angle: 2.36336282618944
Speed: 2.5
Life: 0 / 0
Image: C:\Documents and Settings\NuclearCheese\My Documents\Visual Studio 2005\Projects\Musuu no Danmaku\Musuu no Danmaku\bin\Debug\shot\shot1.png
Local variables:
- this_bullet_grazed [Boolean_Literal] = False
10 - BasicEnemyShot
Location: (243, 100)
Angle: 3.14876098958689
Speed: 2.5
Life: 0 / 0
Image: C:\Documents and Settings\NuclearCheese\My Documents\Visual Studio 2005\Projects\Musuu no Danmaku\Musuu no Danmaku\bin\Debug\shot\shot1.png
Local variables:
- this_bullet_grazed [Boolean_Literal] = False
11 - BasicEnemyShot
Location: (243, 100)
Angle: 3.93415915298433
Speed: 2.5
Life: 0 / 0
Image: C:\Documents and Settings\NuclearCheese\My Documents\Visual Studio 2005\Projects\Musuu no Danmaku\Musuu no Danmaku\bin\Debug\shot\shot1.png
Local variables:
- this_bullet_grazed [Boolean_Literal] = False
Could you release a new version with all of this new stuff? Or tell me how I could compile it myself?
Could you release a new version with all of this new stuff? Or tell me how I could compile it myself?
For compiling it yourself (this is at least what I've done and succeeded in doing, but I'm no expert on C# stuff, so someone else might know an easier way or better programs for the job):
1. Get the necessary programs: A SVN client (I used TortoiseSVN), a C# Compiler/IDE (in my case SharpDevelop) and a tool for converting the ANTLR file into C# (again in my case, ANTLRworks). Install whichever ones need installing
2. Create a folder where you'll store the code and use the SVN client to checkout a copy of the code into the folder.
3. Use whichever ANTLR tool you have to convert the mdScript_to_mdBase.g -file into the C# lexer/parser files (they should have a similar file extension as the other code files).
4. Open up the IDE and then either:
4a. Use one of the preconfigured project files. The repository seems to have some for Visual studio and they may work, but seeing as I used SharpDevelop, I can't really give you advice on them.
...or if that doesn't work:
4b. Create a new project for Musuu. Add all the files you checked out with SVN into your project files. Then, add all the .dll -files distributed with Musuu, including the SDL.NET -dll you probably have installed on your computer to get Musuu working, into your project references.
5. Compile. It should show some warning/ToDO - messages, but if there are no errors that prevent compiling, you've probably succeeded.
6. Take the compiled file and put it into the Musuu folder (don't delete the old one incase the new one doesn't work for some reason). Run the file.
Afterwards when updating, you only need to do a SVN-update to your files, reconvert the .g -file, add any new files into your list (if you're not using an existing project file), add any new .dlls (again, if you're not using the existing project files) and compile.
I've succeeded in this, so it certainly should work in compiling the files, but I can't guarantee that I can remember every single step I've taken (at least I haven't had to edit the files at all, though). Again, if anyone knows an easier way or better programs to use, go ahead and correct me.
One thing to note, though, is that I read that SharpDevelop can read Visual Studio project files - not sure if it requires anything special myself, since I mainly use Visual C# Express.
To note, the main project file was made in Visual C# Express 2005; there is also a project file from 2008 in the repository as well.
I dream of a drag and drop system. Kinda like RPG maker.
Sticks and stones can break my bones, but words may hurt your brain :derp:
" eh wonder how that will work "
I know I'm being a complete ⑨ for:
1. Not searching this thread for a Downloadz link hard enough
2. not understanding how the heck am I supposed to "Edit the /Library/Frameworks/Mono.framework/Versions/Current/etc/mono/config file to include the entries from the SdlDotNet.dll.config and Tao.Sdl.dll.config files." what the shit do i add?!? *internal raging from unability of running danmaku*
Sorry for not reacting to what you just posted, but I've got a general question:
Are you creating a new scripting language from the bottom up, or are you using parts of an existing language ?
If you're making a new one (I think it's the case), what were your reasons not to use an existing one?
If something is broken in our scripting language, we can simply fix it, whereas if something is broken in someone else's script language, we'd need to rely on them to fix it (might not be entirely true, given the amount of open-source projects out there today). This also applies to new features to be added into the scripting language.
Call me crazy if you must, but I actually found it easier to set up my own scripting language than to use someone else's.
Might it be possible to have two different power meters - one for your own shot, and one for options? Maybe by - and keep in mind I have never tried anything remotely like this before so I do not know if I am using the right words - defining Power1 and Power2 as opposed to just Power in the stage and player scripts, and then setting it up so that if the player script receives a Power boost instead of a Power1/2 boost, it applies to both, and if the stage script tries to give a Power1 or Power2 item to a shottype that lacks those, it'll instead dispense a Power item?
And today's dumb question:
Might it be possible to have two different power meters - one for your own shot, and one for options? Maybe by - and keep in mind I have never tried anything remotely like this before so I do not know if I am using the right words - defining Power1 and Power2 as opposed to just Power in the stage and player scripts, and then setting it up so that if the player script receives a Power boost instead of a Power1/2 boost, it applies to both, and if the stage script tries to give a Power1 or Power2 item to a shottype that lacks those, it'll instead dispense a Power item?
Musuu
Script[mdScript]
Type[Enemy]
Plural "PluralEnemy"
{
initialize
{
SetPlural(["TheEnemy", "AnotherEnemy");
NextPlural();
}
}
include("TheEnemy.txt");
include("AnotherEnemy.txt");Er ... could you clarify what you meant by "plural script"? I can't remember if you explained it before and I'm slightly too brain-fogged to work it out on my own from the context ...
I am not sure if this is the right place to address this, but in the first post of this thread, under item number six, it was mentioned that bullets would be colored using only the red and green channel in a file. however, in mountain of faith and subterranean animism there are a few bullets using black parts.
my suggestion (and forgive me if it has already been made, or is simply ⑨ish) is to use
the red channel for opacity (or alpha),
the green channel for brightness (255: completely white/color, 0: completely black),
and the blue channel for the parts that need to be colored (assuming the pixel is set to 255 green, 0 blue would mean white, 255 blue would mean completely in the chosen color).
I hope this doesn't sound too stupid.
Musuu
Script[mdScript]
Name[Message Testing]
Type[Enemy]
Boss "TheEnemy"
{
initialize
{
SetLife(9001);
id = CreateObject("OtherObject", 50, 50);
id->"send id"(GetMyID());
}
tick
{
if (GetLife() < 1000)
{
SetLLife(2000);
}
}
message "hurt" (amount)
{
SetLife(GetLife() - amount);
}
message "get stuff"
{
return "stuff";
}
}
Effect "OtherObject"
{
define id;
initialize
{
id = -1;
}
message "send id" (new_id)
{
id = new_id;
}
tick
{
if (id > -1)
{
id->"hurt"(50);
}
}
}actually I'm not sure I should learn at all since I'm not even sure what I can use and how I could even contact Zun to ask permission to do so...
aren't the official guidelines made by you guys also? This all started because of an angry ZUN fan-boy yelling at someone to stop using ZUN's work didn't it? and you treat it like it was ZUN himself who said it. I'm not sure about this though, so correct me if I'm wrong.I'm pretty sure the guidelines were laid out by ZUN
I saw the thread where someone posted that, btw.
Is there a twitter I can follow for this?Here's ZUN's twitter if you want (http://twitter.com/korindo)
So I haven't really been following this as closely as I should, but I really do want to script in your language. The problem is, I'm not really interested in devoting hours and hours to reading through this whole thread and trying to teach myself the language, while still keeping up with updates. So, for the next thing to be done, I'd love to see an extremely basic tutorial on scripting within Musuu. Since the majority of us that are following your engine know danmakufu, you can assume we know really extreme basic stuff and whatnot, so you can just provide us with syntax. Right now I just have no idea how to get things started, and some terms look very foreign (I know they're explained in the thread, but hunting through so much information is... :ohdear:). So uh, I'd love it if you could write a few paragraphs explaining what all these new terms are and how things operate. I know I'm not the only person who looks at this project and gets discouraged because of the massive wall of jumbled information everywhere, so I think it'd be really benificial to you to have more play testers and whatnot.
Ditto Naut. What we really need right now is some starting documentation.
yeah. thing is, I'm not sure whether I should learn this or danmakufu. considering danmakufu is in japanese and has little support outside this forum.
Is there a twitter I can follow for this?
Here's ZUN's twitter if you want (http://twitter.com/korindo)
Hi, keeper of the Brofists. You're posting while I'm posting. :]:wikipedia:
Musuu
Script[mdScript]
Effect "Testing Tasks"
{
task "task one"
{
i = 0;
while (i < 60)
{
i++;
delay(i);
}
}
task "task two"
{
i = 60;
while (i > 0)
{
i--;
delay(i);
}
}
initialize
{
Start("task one");
Start("task two");
}
}In other news - has anyone taken a look at the documentation I put up? It'd be nice to get some feedback ... I'm not sure if what I wrote up matches people's expectations and such.
could you provide a sample of what a simple pattern might look like? so far, it looks less imposing than when I glanced at a random danmakufu script.
Musuu
Name[Sample Enemy]
Type[Enemy]
// include the shot definitions
include("shots.txt");
// TheEnemy
// Enemy boss that makes some danmaku.
Boss "TheEnemy"
{
define count;
initialize
{
// Set the image to reimu1.png
// Also set it to always be aligned (don't rotate), and at layer 30
SetImage("reimu1.png", false, 30);
// set the collision sizes
SetSize(18, 24);
// Set the amount of life for the boss
SetLife(150);
// our timer variable
count = 60;
}
tick
{
// decrement our counter
count--;
if (count <= 0)
{
// reset the counter
count = 60;
// Fire a spread of bullets
angle = 140;
while (angle <= 220)
{
FireShot01(GetX(), GetY(), angle, 2.5, "Shot1");
angle += 20;
}
}
}
}
Hello
I skimmed through fast through the topic and i have a question:
IS this a new danmaku engine or you're upgrading danmakufu?
and is there some where a future list?
Checklist update:
Bullet definition files- Additional functions for:
Random numbers- Some more mathematical functions like the power function.
- The drawing functions.
- Improved audio control (loop points, pausing/resuming, possibly fadein/fadeout)
- Improved bullet shooting functions like CreateShotA to avoid having to script overtly simple patterns with objects
- Default support for:
Lives/respawningPoints/GrazeBombs- Power system
- Plural files, stage files, possibly game files? (plural files partly implemented)
- Lasers*
- User-defined functions/subroutines/tasks.
Message functions for objects.- Various bugfixing
- Code optimization to make the program run faster
Better error handling(mostly done)- *Low priority* Dialogue events.
- *Low priority* Effect objects with vertices*, 3D drawing.
- *Low priority* Replays.
Everything looks pretty good to me. The script deconstruction styled tutorials work pretty well as a primer and the function descriptions are easy enough to grasp, at least for this novice Danmakufu scripter. The only one I really had trouble understanding was the description for SetPlural. Then again, there's nothing else in there about Plurals that I could find (bar NextPlural and LastPlural descriptions, naturally), so it could just be an issue of context.
Now for the main reason why I finally decided to post in this thread after lurking it for so long... I haven't actually tried scripting anything yet, but a question did come to me after stumbling on something in the latest test release. Do you intend to have the script browsing reined in to just the folder Musuu is in and its child folders or are you keeping it as is? As it stands right now, you can back up and away from the Musuu folder and look literally anywhere on your hard drive for compatible scripts if you know the way.
Out of curiosity, would it be too much to ask for the ability to code multiplayer? I'm thinking about multiple things (player versus player danmaku, phantasmagoria clones, tyrian style player turrets), but I'd imagine that, with some ingenuity, it'd be possible to do all of the above by simply allowing more than one player character for certain scripts. And being able to switch player bullets hitting other players.
For the sake of GetPlayeretc (outside of the player scripts, anyway), perhaps an extra argument for which player to check?
Also, if this is for generalized danmaku shoot 'em ups, a way to replace the default life system would be nice.
Then again, considering the recent news, a English-based danmaku engine that will be consistent (hopefully), is always nice. :V
oh yeah, would bosses with multiple damagable parts be able to be done?
The overall plan is to make this as generalized as possible, so having a different life system could definitely be doable. To get thought rolling on this, any particular ideas that you'd be looking to implement?For a few examples, a health system like in PoFV where you have a few hits, but you get pushed back and get blink invincibility when hit. Another example would be a plain standard system where you have a certain amount of hits before dying; like, say, in pretty much every game. :V
For a few examples, a health system like in PoFV where you have a few hits, but you get pushed back and get blink invincibility when hit. Another example would be a plain standard system where you have a certain amount of hits before dying; like, say, in pretty much every game. :V
A way to do shields and "armor" would be nice; basically, a second health bar that probally regenerates and prevent damage to the player's real health until depleted, like in Tyrian. As for armor, it's like that but it doesn't complete prevents damage, just reduces it; think of something like in an FPS.
Of course, the latter two could easily be coded by the coder him/herself with a player version of SetDamageRate and tinkering with variables, so yeah. :V
I still say that if I were doing it, for maximum flexibility, rather than putting just about anything in the hardcode (bullet-types, how items work, death, hitboxes/graze, "continue," even field-size and UI-setup), I'd put specific game-details in default/example scripts which you'd, like, "include" in the user-made scripts, so that if someone wanted to make a setup like Suguri (which is almost entirely different from Touhou), the game engine wouldn't get bogged down with hardcoded defaults which would just be ignored by the script. Kinda like how RPG Maker XP/VX do it ...
Musuu
Script[mdScript]
Type[Stage]
Name[A Stage]
Stage "Test Stage"
{
initialize
{
// do stuff
}
tick
{
// do stuff
}
}Musuu
Script[mdScript]
/ A sample plural script
/ Comments start with a '/'
/ Type and name of this plural object
Plural "Enemy Boss"
/ The various phases of this enemy
/ "file" "type"
"Enemy1.txt" "Phase1"
"Enemy2.txt" "Phase2"
"Enemy2.txt" "Phase3"Checklist update:
Bullet definition files- Additional functions for:
Random numbers- Some more mathematical functions like the power function.
- The drawing functions.
- Improved audio control (loop points, pausing/resuming, possibly fadein/fadeout)
- Improved bullet shooting functions like CreateShotA to avoid having to script overtly simple patterns with objects
- Default support for:
Lives/respawningPoints/GrazeBombs- Power system
Plural files, stage files, possibly game files?Lasers- User-defined functions/subroutines/tasks.
Message functions for objects.- Various bugfixing
- Code optimization to make the program run faster
Better error handling(mostly done)- *Low priority* Dialogue events.
- *Low priority* Effect objects with vertices, 3D drawing.
- *Low priority* Replays.
Glad to see this is still in progress :D
Random musing: How exactly does one make curvy lasers?
// Set PCB-style power system
SetPowerDisplay(power_display_fraction);
SetPowerThreshold(1, 8);
SetPowerThreshold(2, 16);
SetPowerThreshold(3, 32);
SetPowerThreshold(4, 48);
SetPowerThreshold(5, 64);
SetPowerThreshold(6, 80);
SetPowerThreshold(7, 96);
SetPowerThreshold(8, 128);
SetPowerMax(128);
SetPowerMaxDisplay("MAX POWER!");global power_value_2;
// ...
{
// ...
{
// Set MOF/SA-style power system
SetPowerDisplay(power_display_decimal_fraction);
SetPowerThreshold(2, 20);
SetPowerThreshold(4, 40);
SetPowerThreshold(6, 60);
SetPowerThreshold(8, 80);
power_value_2 = 20;
SetPowerMax(100);
SetPowerLostOnMiss(20);
}
}This is still alive? Best holiday present ever!
If you would be kind enough to release another test version, I'll make something for you :)
| Old Algorithm | New Algorithm | |
| Circles | 35-41 | 56-62 |
| Lasers | 26-29 | 52-57 |
Checklist update:
Bullet definition files- Additional functions for:
Random numbers- Some more mathematical functions like the power function.
- The drawing functions.
- Improved audio control (loop points, pausing/resuming, possibly fadein/fadeout)
- Improved bullet shooting functions like CreateShotA to avoid having to script overtly simple patterns with objects
Default support for:
Lives/respawningPoints/GrazeBombsPower systemPlural files, stage files, possibly game files?Lasers- User-defined functions/subroutines/tasks.
Message functions for objects.- Various bugfixing
- Code optimization to make the program run faster (major progress)
Better error handling(mostly done)- *Low priority* Dialogue events.
- *Low priority* Effect objects with vertices, 3D drawing.
- *Low priority* Replays.
Oh, so you're actually going through with this? If you get a perfectly stable version out I will love you forever.
This is starting to look really good. How long until we have function documentation? That's the only thing really stopping me from playing around with it at this point.
Uh.. If I were to make some folders to organize everything (so that all the resources arent in one folder, would that still work?
One last little thing here, if I wanted to use an animated picture for a sprite, I can do so? Or do they absolutely have to be static?
(I'm guessing I can, but looking for confirmation)