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.
Okay, at least it's working as it's currently intended to.
Popping up a message box is trickier than you probably think, since it's pretty API-specific (for instance, there is a Windows-specific
MessageBox function), and one of the main goals of this project is to keep it able to run on multiple platforms (with minimal, if any special-case code).
Also, this is a generic error-catch, so it's not just there for a missing DLL, but any possible error during initialization. This could include missing font file, missing necessary graphics, etc.
Any suggestions on a better way to indicate a statup error?
Pre-Post EDIT:MediaFire cooperated enough for me to download this. Looks like the graphical weirdness is due to the smoothing that is applied to graphics in the game. Perhaps we need to add an option to disable said smoothing on certain graphics?
It might be fixable in the image file, though. I pulled your image up in GIMP, and noticed that all of the pixels in the transparent areas are white. This makes the smoothing function fade the edges to white. You can recolor this invisible area to better fit the borders of your image, and that makes it look a bit better (in my view, at least).
PS - a couple comments on your script (not being mean, just some hints and possible improvements):
- 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.
Pretty good for a first try with crap documentation, though.
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)
SonicBHOC is going to start putting together some documentation for this project. I've been in contact with him via email.
In the meantime, unfortunately there isn't any decent documentation yet. This is still a pretty new, work-in-progress project, so we haven't got everything fleshed out yet. Sorry for the inconvenience.
EDIT?: oh btw... i just made the first (to my knowledge) customed character in the history of Musuu no Danamku.
Download here!
Zip includes: player script(of course), shot(:V) and sprite(whice looks messed up inside the program for some wierd reason).
I would have downloaded and checked this out, but MediaFire hates me.
Could you describe/show what you mean by the sprite looking messed up in the program? It might be a bug in the graphics code.
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.
Correct, there is still some decent amounts of optimization to do in the collision detection code. Specifically, in the code that decides what particular pairs of objects need to be collision-checked.
With the sheer number of objects on screen, it would be CPU suicide to collision-check every possible pair of objects, especially when so many potential collisions don't even yield anything important (two enemy bullets collided? WHOOP-DE-FREAKIN'-DOO ...). The code instead has code to build a list of what object pairs would actually have some meaning if they collide, and then uses that list to run collision detection.
The main issue right now is that the program dynamically rebuilds the list each frame, which is certainly not very efficient (but less prone to stupid errors in the code). So, yeah, I'm gonna have to go back and optimize it at some point.
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.
This is probably a good idea. Admittedly, I tend to be a bit disorganized with my projects. :V
Found it!
And here's a sort-of spellcard sound and a mediocre charge-up sound.
More MediaFire links. Dammit.
Pre-Post EDIT:MediaFire is actually cooperating with me? Wow.
These effects remind me of stuff from the Atari era of video game consoles (not a bad thing!). We can use these, at least as samples to throw in the test releases.
I'm kinda intrigued as to why SCARD and CHARGEUP are in WAV format, while Spooon is in OGG ...
Unfortunately, this weekend is pretty much shot for progress, since I'm busy. Next weekend is looking iffy as well.
I really hate having to bum out on working on this, but unfortunately sometimes this "real life" thing just gets in the way.
* >__>
(* See also - almost every weekday of the past five-or-so months <__<)At least there's
Test release 4.1.
Just added in the missing .dll file.
