The important parts of the Improvement thread.
+++++
Iv'e recently been working on functions and scripts to improve danamkufu but it hasnt been working like ive been wanting it, so il need help...Here's a few things on the agenda so far:
Better Laser Sources:
Danmakufu has a terrible way of making laser sources, Their too big on thin lasers and too small on big lasers (They turn CtC's beam graphic into a giant block). These sources also end up forming a giant blob when topped up on top of each other. What im thinking of is a script (Either enemy or shot, whichever does the job) that could:
-Be resized
-Choose color
-Have a delay and activated size to match the laser's
-Can -snap- onto a specific lasers for lasers that move
-Can flicker on smaller lasers
-Whatever would be convinient
Up-to-date Cutins
Dont you just envy the new cutin scripts on the newer touhou games? What im thinking for this one would be a drawing function in the boss that would activate at the start of regular spellcards, You would ignore the actual Cutin script. This drawing function would also be easely editable for those who want to expiriment with their own custom-cutin functions.
Templates for the default graphics and sounds
Alot of the graphics and sounds in danmakufu are pretty bland or just poorly drawn, and dont even get me started on the sound of ripping paper every time you kill an enemy. Luckely these can be changed from what CtC thought us, Im thinking of a few folders that could show you what the filenames of the Danmakufu graphics are and what to replace them with.
Cut-trough lasers
The hardest of my ideas so far, in the newer games when you bomb trough a laser it cuts in several pieces and every piece is properly resized, Im thinking of somehow making object lasers (or script if necesary) that would check for bombs, and resize into several different lasers based on which parts were touched...I think this one might actualy be imposible.
Anyways il wait to see what you guys have to suggest or even help me out on this, My msn is Samuel91119@hotmail.com
/////////////////////////////////////////////////////////////////////
#include won't work for drawing the cutins, I don't think.
Instead of calling a cutin, create a boolean upon loading. When a cutin is needed, change it to true. An 'if' statement inside the drawing loop activates. It should call a separate function that displays the graphic, moves it, resizes and all that junk based on what arguments the user calls.
Should be easy to do, in theory.
As for resizing lasers, only way to do that without ugliness is having a preloaded image with the laser graphics that you want at different widths. Lengths don't change a straight graphic much, so they should be fine as long as you don't have a stump laser. Yet again, the process would be the same as above, but they'd be objects instead. This means that you could still rotate and move it around easily. Very little resizing; the size argument indicates which image you use, and little discrepancies would be resized, and at certain widths the graphic would just change to a different one. If vertices could be used, they might help for a 3D effect as well.
With this, you could probably do the split-laser thing as well (should be easy enough to create a shitload of small copies of the original), but controlling every little laser would probably be hell.
Sounds that you can change by filename are
sePlayerShot01.wav
seGraze.wav
sePlayerCollision.wav (?)
sePlayerSpellCard.wav (?)
se1UP.wav
seScore.wav
seBomb_ReimuA.wav
seExplode01.wav
seBomb_ReimuB.wav
seUseSpellCard.wav (?)
seGetSpellCardBonus.wav (?)
seEnemyExplode01.wav
seSuperNaturalBorder1.wav
seSuperNaturalBorder2.wav
and
STG_Player01.png
STG_Player11.png
CutIn_PlayerChar01.png
CutIn_PlayerChar11.png
Select_Player01.png
Select_Player11.png
STG_Frame.png
/////////////////////////////////////////////////////////////////////
Has anyone checked to see how a laser graphic looks when you scale it down, rather than up? If it looks fine scaling down you could just use a high-definition shot graphic (like greater than 100 pixels) and stretch it however you want, and it wouldn't look nearly as bad as a tiny bullet blown up to Master Spark size.
/////////////////////////////////////////////////////////////////////
You'd think so. Most things are actually still possible, there just isn't enough direct code to simplistically get what you want accomplished. Requires an intense amount of dicking around. But I do agree, I'm not seeing how split lasers could be done. Active collision detection of a laser, then create two lasers on either side of the collision point... Or more? Sounds iffy to me. Can you even call upon non-circular collision detection? How does collision detetction of lasers even work (dozens of small circles, or just an elongated circle/oval)?
What Koishi did was create the laser source (the delay cloud thing) and the laser seperate of eachother, so instead of that really shitty spread thing you see when you make a wide laser, it looks something like this:
http://i641.photobucket.com/albums/uu134/Nautth/CtC-Stylebiglasers.png/////////////////////////////////////////////////////////////////////
http://mp3splt.sourceforge.net/mp3splt_page/home.phpLoadMusic(track);
PlayMusic(track);
let min = 0;
let sec = 0;
let cen = 0;
//current time, starts at 0'0"0
let loopmin = 3;
let loopsec = 42;
let loopcen = 58;
//time to loop at
@MainLoop{
cen++; //every frame, cen will increase
if (frame % 60 == 0){sec++;} //every 60 frames, sec will increase
if (frame == 3600){min++; frame = 0;} //every 3600 frames (or 60 seconds), min will increase
if (cen == loopcen && sec == loopsec && min == loopmin){ //if you're at the loop time
LoadMusic(looptrack);
PlayMusic(looptrack); //play the split track
loopmin = 1;
loopsec = 23;
loopcen = 54;
min = 0;
sec = 0;
cen = 0;
//reset the current time and change the time to loop at
}
}
/////////////////////////////////////////////////////////////////////
A good idea, Drake. One suggestion, though: It may be better to use the GetTime() function instead of counting frames. If the game starts experiencing slowdown, your counter will start lagging behind, resulting in a late restart of the loop (it could happen the other way, too, if the game starts playing too fast for some reason).
This function gives you the time, in milliseconds, that the script has been running. All you need to do is keep track of when you started the current loop, and check for when it should be restarted using this simple formula:
time_to_restart_at = time_loop_started + (minutes * 60000) + (seconds * 1000) + milliseconds
The just do a simple check to see if you should restart the loop:
if (GetTime() > time_to_restart_at) <restart the loop>;
This still won't be perfect, since it only gets called once per frame and has the possibility of not lining up perfectly with the music, but if you set it up right it should be good.
I've been making extensive use of this type of stuff in a new, secret project which I'll never finish cause I'm a lazy dumbass
I've been a bit too busy to work on effectively. Hopefully I'll find motivation to finish it up soon!
I should mention, though - I highly recommend against using GetTime() for anything related to the actual gameplay normally, since that will very likely break replays (since the timing could very well be different each time it is run).