A replacement for Danmakufu?

[Blargel]

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 joke.


... 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.

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. 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 >.<

[Nuclear Cheese]

http://en.wikipedia.org/wiki/Framebuffer_Object
FBO's aren't supported on older Intel GPU's though...

This shall be most useful. :3

Argh, 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.

A couple things regarding your TF2 example:
1) It sounds like you're always rotating about the same axis (up), which would greatly simplify the issue.

2) I'm not saying it's going to have problems.  I'm saying it's a pain in the ass to visualize multiple rotations about different axes being applied like that - especially when you're not very experienced with 3D graphics programming to begin with. 

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. 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 >.<

This "gimbal lock" deal certainly sounds like the main issue here.  I've never dealt with it before, though, so I'm open to ideas on how to get around it ...





Quick update today - tested and fleshed out the font code a bit more, and committed it to the code repository.

I also added some color constants.  They are all prefixed by col_, and each represent a 3-element array for a color.  The following colors are avaliable:

• red
• blue
• green
• yellow
• orange
• purple
• magenta
• white
• cyan
• black

This makes it a bit easier to specify a color -
DrawText("Some red text", 50, 50, col_red, 16, 10);
DrawText("Some blue text", 50, 70, col_blue, 16, 10);

Of course, you can use the array notation for it as well -
DrawText("Some other color text", 50, 90, [123, 45, 67], 16, 10);


Gradient and transparency are not in yet, but I've made a note to add them in at some point.

[Nuclear Cheese]

Another little update - I just added in a file selection menu.


It's rather simple at the moment, but it gets the job done.


Right now, it simply gives a list of files that have the "Musuu" header line, and allows you to select one or more to load, then start the game.  So, right now, to load up a "proper" game, you'll need to select both the enemy script and the player script (or one file that includes both).

Of course, in the long run we'll need to add some more header info so that we can distinguish between different script file types (player, enemy, game, ...), and then we can rework the menu to be a bit friendlier.  It's a pretty big start, though.



As part of this, I also added in code that, when you quit an in-progress game, returns to the menu and resets all of the internal structures, rather than just quitting (Theme, take note - your pause code should link into this ...).


(Figured I'd bump, since it's been a few days ...)

[Loki]

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. 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 -- an executable file with some scripts.
http://www.mediafire.com/?z05wyzwdmhn -- source code and libraries for VC++ 2008

[Nuclear Cheese]

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.

To clarify, the syntax of the files themselves will not be any different*.  All that will change between, say, a player script file and an enemy script file is one line at the top of the file that says whether it's a player/enemy/etc script.  To illustrate, a player script file may start out like this:

Code: [Select]

Musuu
Script[mdScript]
Type[Player]
... while an enemy script file may start out like this:

Code: [Select]

Musuu
Script[mdScript]
Type[Enemy]

This Type tag would allow the program to distinguish the different script types, and allow it to preset the user with a list of just the appropriate script types the user is looking for at the moment (for instance, the player would most likely select an enemy or game script to face first, then pick a player script to face it with).


Another header option I think we may want to include is Name, which will give the script a name for in the script file selection menu (as opposed to showing just the file name, which is all it can do at the moment).

As part of this, I also have the idea that we should, rather than expecting a fixed number of headers, instead just allowing as many header lines, and requiring a blank line to indicate the end of the header lines (it looks good syntactically, anyways).  This allows headers to appear in any order (except the first line needs to be Musuu), and it also allows headers to be optional.  Leave out the Name header, and it'll default to showing the filename in the menu.  Also, it could be set up so that, if you leave out the Script header, it'll assume you're using mdScript.



* Note that, using a different Script header will select a different scripting language.  The only defined languages at the moment are mdBase, which should never be used for anything serious, and mdScript, which is the "standard" scripting language for Musuu no Danmaku.
One idea is that, in the future, we'll be able to have plugins that define other script languages for Musuu no Danmaku to read in; perhaps someone will even step up to the challenge of writing a Danmakufu interpreter (I feel sorry for whoever pushes that one on themselves :V).

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 -- an executable file with some scripts.
http://www.mediafire.com/?z05wyzwdmhn -- source code and libraries for VC++ 2008

I'm not at my main computer right now, so I can't really check these out (plus, mediafire tends to hate me, so I'll probably have a bit of trouble downloading the files anyways >__>).

Looking up the named libraries ...

v8 - a Javascript library.  This project uses its own scripting engine, with its own script file formats, so (at least currently) I don't think there's any place for Javascript.  Blargel's danmaku engine project (which has its own thread somewhere around here, that hasn't been bumped in forever apparently) is using Javascript for scripting, but I think they're using a different Javascript engine.

sdl_ttf - SDL font library.  I think this only works when using SDL's graphics handling methods; Musuu no Danmaku uses OpenGL, and right now it interfaces FreeType to get font data.

openil - image library.  This might come in handy if we can interface with it.  A quick google search shows that it is supported by the Tao Framework, which makes it look promising.  If I can figure it out, there's a good chance it'll be more efficient than the current image loader code, which goes through System.Drawing.Bitmap.





I was just thinking about how we would handle scripting the equivalent of Danmakufu's Plural scripts, and here's the idea I came up with - a simple, scripted object which defines the lifebars and scripts to load.  Here's a sample of what I had in mind:

Code: (sample) [Select]

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"]]);
   }
}
The first command, SetLifeBars, defines the number of lifebars, the number of scripts in each lifebar, and the relative size of lifebar for each script.  The second command, SetScripts, defines the scripts for each component of each lifebar.  So, for example, the above script defines the following:

• 1st life bar (80 + 20 = 100 total "length")
  
  • ex_Chen_nonspell_1.txt - 80 "length" (80%)
  • ex_Chen_spell_1.txt - 20 "length" (20%)
• 2nd life bar (80 + 20 + 20 = 120 total "length")
  
  • ex_Chen_nonspell_2.txt - 80 "length" (66.7%)
  • ex_Chen_spell_2.txt - 20 "length" (16.7%)
  • ex_Chen_spell_3.txt - 20 "length" (16.7%)
• 3rd life bar (20 total "length")
  
  • ex_Chen_spell_4.txt - 20 "length" (100%)

For each lifebar, the bar will be divided based on each script's "share" of the total length.


The advantage to this script format is that it allows the scripter to easily change things based on certain variables.  For instance, you could use your global difficulty variable to determine whether or not to switch out ex_Chen_spell_4.txt for ex_Chen_spell_4_plus_ohmygodwhatisthis.txt if the player is playing on Lunatic, or even cut out ex_Chen_spell_3.txt entirely if they're playing on Easy.


At the same time, I do think a simple format may be useful as well.  We could also define another script "language" which more closely mimics Danmakufu's style of defining Plural scripts, such as with this sample:

Code: [Select]

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.txt
(Note that the Script header indicates mdPlural rather than the usual mdScript)

This syntax has the advantage of being simpler, while sacrificing some of the potential that the previous idea has.  Of course, both can be implemented side-by-side, but I'm wondering what you people think about them?


We should consider how these ideas would play in with the future idea that we'll be able to customize the lifebars ...


Also, we could have it allow the scripter to specify a color for each lifebar segment.



(PS - in case you guys forgot, I'm back on my usual too-busy-during-the-week schedule )

[Nimono]

Cheese: 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?

[Nuclear Cheese]

Cheese: 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.

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



Kind of surprised you consider the first syntax as "neater and friendlier", since I see the second one as much simpler and more accessible (at the cost of being more limited in functionality).  But that's just opinions, of course.

[Nimono]

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.

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.

[Nuclear Cheese]

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.

That's basically what I described above.  You could, for instance, have a short stage 1 boss:

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

[Nimono]

That's basically what I described above.  You could, for instance, have a short stage 1 boss:

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...

[Nuclear Cheese]

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...

Dynamic allocation works those types of miracles.

Code: (C++ example) [Select]

int number_list[];

// bunch of stuff

int number_count = get_amount_of_numbers;

number_list = new int[number_count];

// etc ...

Pretty much, as long as it can find the memory to store it in, you'll have no problem with the array length and such.





EDIT: some progress:

I updated the menus like I described above.  It now works similarly to Danmakufu, where you select an enemy script, then you select a player script.



I added two new headers to the file format: Name and Type.

Name is optional, and gives something other than the file name for the menu entry for the script.

Type can be Player, Game, Stage, Plural, or Enemy (probably will get a couple more types later on).  Right now, the only thing it's used for is distinguishing player scripts from non-player scripts, so as to separate them in the menus.


Also, headers are now optional, and there must be a blank line after them.  Default values:

• Script - mdScript
• Name - the script's file name
• Type - Enemy

[SONIC BHOCOLATE STRIKER]

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'.

[Nuclear Cheese]

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'.

I haven't updated the first post in forever and a half (laziness :V), so I ended up just editing it to put a note saying to check the latest posts for real updates.  Aren't we going to need to make a new thread soon, anyways, since we're approaching 500 posts?  Or do I have the number wrong?

As far as testing, feel free to download the latest test release (the link was posted a page or two back).  It's still pretty incomplete, but you can check out a lot of the basics.

I probably should put the test releases on the Google Code page; I'll try to remember to do that with the next one, at least.  I host them from my own website currently.



Speaking of the next testing release, I'm starting to feel like another one is warrented soon.  Major things have been added:

• Text drawing
• File selection menu
• Better error reporting (gets more info for in the log file)
• Finally fixed the 64-bit vs 32-bit issue we've been having

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?

Unfortunately, this weekend is pretty much shot, since I'm busy tomorrow, and I was out yesterday until I got home at 7:30 am, so I'm pretty much fried.  go me. :V


PS - Where has Theme run off to?

[Stuffman]

Aren't we going to need to make a new thread soon, anyways, since we're approaching 500 posts?

TSO upped it to 1000 posts after some forum upgrade, so we're good for now.

[SONIC BHOCOLATE STRIKER]

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

[PT8Sceptile]

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)

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.

• Other things I'm not thinking of at the moment?

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.

[Nuclear Cheese]

TSO upped it to 1000 posts after some forum upgrade, so we're good for now.

Dammit stop ruining my excuses to be lazy with the front post!

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

If you want to do something with documentation (my least favorite part of most projects), that would be cool.  Any particular points you'd want to look at?

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.

The 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".

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.

Yeah, the shot data thing will definitely be all we need to define the use of sub-images for bullets, and I do intend on adding support for using sub-images for the graphics of other objects, as well.  I can see if I have time to look at implementing support for this later this week, possibly for inclusion in the the next testing release (4).


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

We could define an mdScript function that defines bullet types, something such as:

DefineBullet("ChenShot01", "chenshot01.png", [0, 0, 15, 15], 3.5, 7, true, 0);

This would define the shot "ChenShot01", with the given image file; the array indicates the left, top, right, and bottom of the image subarea to use.  3.5 and 7 define the size and size2 of the hitbox, true indicates that it rotates with the shot's angle, and 0 means it does not spin.


Like with plural scripts, we could also define a custom scriptfile type to make loading these definitions simpler.  For example,

Code: (Sample) [Select]

Musuu
Script[ShotData]

ChenShot01
image chenshot01.png
subimage 0, 0, 15, 15
hitbox 3.5, 7
rotate true
spin 0
Of course, I'm open to suggestions.

Once bullets are defined, they can then be used just like current bullets - just use the name of the bullet instead of an image file name in the FireShot commands.



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).

[PT8Sceptile]

The 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".

Oh, right. Forgot all about replays.

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

• Delay color?
• Render type? (ADD, ALPHA etc...)
• Hitbox type? (rectangle, circle, ellipse, possibly even the circle+line segment one mentioned way back when laser hitboxes were talked about)
• Animation?

Just some possible parameters I'm throwing out there. Also, depending on the hitbox type, even more parameters may be needed (the foci for ellipse for instance: possibly you could even place the circle hitbox somewhere other than the center of the image, in case you're making something really weird, just as long as it defaults to the center.

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).

And I almost had forgotten this idea, too. It certainly seems promising.

[SONIC BHOCOLATE STRIKER]

@Nuclear Cheese: I know doc is most people's least favorite part, that's why I volunteered for it

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.

[Nuclear Cheese]

@Nuclear Cheese: I know doc is most people's least favorite part, that's why I volunteered for it

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.

I dunno about using Doxygen for things like mdScript ... that looks like it's meant more to map out actual code structure or functions for APIs.

But it would be cool to have you doing the docs and such.  How do you want to go about it?




A quick update tonight - Graphics subrects are now in.

Use the command SetObjImgRect to change an object's image subrect.  The syntax is as follows:

SebObjImgRect(id, x1, x2, y1, y2);

id is, of course, the object that you want to change's ID.

x1, x2, y1, and y2 are the coordinates of the texture image to use for the object's image.


Note: the graphics subrect gets reset whenever you change an object's image.



Thinking of putting together the next test release, but not right now because I'm tired and hungry.

[Montblanc]

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.

[Nuclear Cheese]

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.

Hi.  Glad to hear it's working for you.



I'm trying getting test release 4 together, but I just found this weird bug with the font code that I'm ironing out.  Might still get out today, depending on my patience and how much NMH2 pulls me in.



EDIT:
I fixed it.  Turns out I'm a fucking idiot. :vbang:

Test Release 4
Download is hosted on the project page here.

This should contain all necessary .dll's and such, although with the new inclusion of fonts I might have missed something again.

[Prime 2.0]

Test Release 4
Download is hosted on the project page here.

This should contain all necessary .dll's and such, although with the new inclusion of fonts I might have missed something again.

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.

[Nuclear Cheese]

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.

Godammit. >_<

But there are still no sample sounds! Lol.

Get me some sample sounds and I'll use them!

lol.

[Dizzy H. "Muffin" Muffin]

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 ...

[SupahVee1234]

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?

[Dizzy H. "Muffin" Muffin]

Why?

[Nuclear Cheese]

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 ...

When I'm back at my development computer, I need to remember to actually search back through the thread and find the link to that ...

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?

Point the first - I tried installing the XNA dev stuff on my computer.  It failed miserably.

Point the second - Correct me if I'm wrong, but I think XNA isn't available on non-MS operating systems.

Point the third - It is already in C# (although I'm guessing you already knew that).

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.


Don't take this as "fuk u ur wrong lol" or such.  I'm just pointing out my reasoning behind the decisions made in this project.

Why?

I'm kinda curious to this as well, to be honest.

[SupahVee1234]

Dunno, I think LUA is very solid and a perfect language for this project. Why create a new scripting language?

[Dizzy H. "Muffin" Muffin]

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.