I dunno, you mentioned that scoring would be handled by MnD, and I want to know what it would put for "difficulty level" or whatever.
The game will keep track of the player's score (as in, keep the value), but I don't remember saying the program would handle the specifics of how things were scored - there's way too much room for variety there.
My current understanding was that scripts would be setting score values on things, as well as difficulty levels. Menu scripts will allow the selection of difficulty levels, with the selection most likely being stored in a global variable that would be read by the individual game entities which would then set their scoring appropriately.
Feel free to suggest other idea, though.
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.
Morning? What the hell is that?
(fun fact: I didn't get out of bed until almost 6pm today. Too bad I need to adjust back to 7am for work days >__>).EDIT: For fonts, Mona looked best, so it has my vote.
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.
Theme -
Looking at your changes for the
add enhancements, it looks good for the most part, but there's one part that I think will be an issue.
When you append/whatever to an array, it looks like you're using the
List<Value> pointer that is stored for the value itself. This is a problem since it would be re-modifying the original stored value, as well (since Lists are classes and, thus, kept as pointers). You should make a copy of the list before adding/removing elements, so that the original is not modified. In all honesty, I probably missed it in a couple points myself with the initial implementation, now that I think about it.
For your
mdScript enhancement issue - it probably does make sense to separate out
neg from
not. However, if we do that, then there is no reason to keep the case for numbers on
not. 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. While it's fine to fix typos or other small things, putting too much extra content in an issue leads to administrative issues down the line - there's more 'bulk' on the one issue, and the changes made don't line up with the original description, which can make it harder to find when things were done. 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.
Speaking of which, I've added an 'enhancement' template for issues.
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 (this applies for anyone else who wants to work actively on the source):
- Make sure to test your changes before you commit them to the source.
Run the program and make sure none of your new functionality/fix screws up. Try to hit all the different cases for the new code. Also, where applicable, test related, unmodified functionality to ensure it hasn't been corrupted.
It's practically impossible to test every possible case, but we need to at least ensure we don't break the main code line with a commit.
When in doubt, upload a patch or commit to a branch, and ask others to test it as well.
- Also, if you want to make an interim/incomplete commit for some reason, make sure to commit to a branch. Generally, you probably won't have a reason for this, but just in case the situation comes up ...
- Comment your code
It is important to comment what the code does at a large scale, and how it works. Don't comment on obvious things, like "This gets the sum of A and B" - that just clutters up the code. The important part is that someone else should be able to come in with minimal knowledge of how the project works, and at least be able to have some understanding of how the code works without spending hours tracing around.
This also applies to the XML-style comments - at the very least, put a summary comment for each function, describing what it does. - Try to keep your local copy of the source up-to-date.
If your copy is behind, you might have problems that crop up with your changes when combined with other parts of the code that have been updated separately. - Avoid "hackjob" implementations
Not that I'm entirely innocent of this myself, but it may be worth the effort to spend 10 minutes or so looking to see if there's a better way to do what you're trying to do. - While it's not a big deal now, since there's just me (and soon Theme), in the future there could very well be many people working in the code at once. To avoid conflicts and duplicate effort, it would be a good idea to note in an issue when you start working on it, so that someone else doesn't start working on it as well.
- Please don't start really huge changes (such as "I'm gonna completely redefine mdScript") without approval. Large changes like that can break lots of stuff, and others may not like the direction being taken.
Small changes (such as "Fixing crash when ___" or "Adding new function to convert foo to bar") are okay to work without approval, but still keep in mind what else could be affected by the change.
Of course, everyone makes mistakes, so I'm not expecting people to be perfect in regard to these items (not like I am to begin with :V). But generally following these guidelines will hopefully keep the mainline source clean and working.
Some new stuff in the program:
- Optimized the function to get the next power of 2 (for texture dimensions) - Theme
- Abstracted collision detection, so that we can more easily add new collision types later on.
