A replacement for Danmakufu?

[Stuffman]

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.

[anonl]

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.

[Nuclear Cheese]

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.

Well, 800x600 isn't too much bigger than Danmakufu's screen (640x480), so you could use the same sprites you use now; they're just be a bit smaller on-screen.

Or, if you're worried about the ability to change the screen size - that's purely for the end user.  The program scales all graphics to match the screen resolution the user picks.

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 need to stop posting at 3am ... it's making me look like an idiot.

Yeah, that's how it'd be done.

[Dizzy H. "Muffin" Muffin]

I'd prefer some level of control over the resolution on the back-end, too, but ah well.

[Montblanc]

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

[Nimono]

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.

[Drake]

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.

[Nuclear Cheese]

I'd prefer some level of control over the resolution on the back-end, too, but ah well.

Could be added in later on; I don't think it'd be hard to add into the engine as it is shaping up.

I'd place it lower in the list of features to add, though.  No offense.

Wow. Color me impressed at how quickly this is progressing.

=/ It'd take me forever to get something like this going.

Well, what else am I going to do on weekends?  Video games?  Sleep?  I mean, come on, seriously? :V

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

I try.

Kudos, cheese. ...Or would you prefer Cheese? Kudos are kinda nasty-tasting. >_>

You will address me as "Lord Cheese the Magnificent, Supreme Commander of The Code and Final Arbitrator of All that is Awesome".  Anything else will simply not be sufficient.
(just kidding )

And I don't think I've ever had Kudos, so I can't give an opinion on their taste. <_<

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.

This is a good thing to address - what order do we want objects to draw by default?  My thoughts would be something like (highest = draw over everything else):

• Enemy Shot
• Player Hitbox
• Item
• Enemy/Boss
• Player
• Player Shot

This is just an off-the-top-of-my-mind list, and probably doesn't include everything.  My reasoning here, basically, is to prioritize the most important items first - dodging is the most important part of danmaku, right?  Feel free to discuss.





Just got done with a bit more coding, by the way.  Not much spectacular; I just added in support for selecting what 'layer' each object is on, which gives way to support what was just mentioned above.

Each object is given a layer value, which is an integer representing how high of a priority, visually, it is given.  Higher values mean higher priority.  Scripts will be able to change these values on a per-object basis.

Currently, there are no bounds to these values; we'll have to decide default layer values.  For example, using my list above:

• Enemy Shot - 60
• Player Hitbox - 50
• Item - 40
• Enemy/Boss - 30
• Player - 20
• Player Shot - 10

... would set the items to be visually prioritized in the same order as I listed, and allow nine layers in-between each "official" layer where scripters could throw things in-between.

I also started some optimization work on things, with a couple optimizations in the already-existing code, and planning for how to redo the current collision code to be more efficient (right now, it just blindly checks for collision between every object pair; I'm going to make it more intelligent).

[Naut]

Hitbox over enemy shots, it's just better that way. Everything else looks good.

[Drake]

Hitbox over enemy shots, it's just better that way. Everything else looks good.

[Helepolis]

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.

[Dizzy H. "Muffin" Muffin]

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

[Nimono]

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?

[Dizzy H. "Muffin" Muffin]

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

[Nuclear Cheese]

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?

Jeez, it's almost as if you guys are trying to tell me something. :V

The default order isn't even in the code yet.

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.

Not much to show today, mostly coded some optimizations to the engine.  Collision still isn't quite as optimal as I can get it, but it's much better now than it was (it only checks for collisions when it actually will do something).  Also optimized some parts of the drawing code.

Current performance - I added a circle of 360 Pyro-Reimus spreading out from the center, and it still holds a straight 60fps just fine currently.  Haven't gone into more stressful cases yet, but I think it looks good so far.

[Dizzy H. "Muffin" Muffin]

Yeah, I skim stuff over, sue me ... |3

[Be Pok U (1998 burst style)]

*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 ?

[Stuffman]

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?

[Helepolis]

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.

[anonl]

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:
"dof" (NL) = "dull" (EN)

I think a low-pass filter would do what you want...

[Nuclear Cheese]

*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 ?

For powerups, the current plan was discussed a page or two back.  Basically, a player script will have "power levels", which are discrete levels of shot power.
On the other side, the stage/game script will define the value of the power items and at what power thresholds we trigger what power levels in the player scripts.

For other items and the related scoring system, I don't recall any in-depth discussion about how to go about them, but we can probably follow a similar philosophy in that the stage/game script will define the values of items.

Of course, this is open for discussion.  (As if anything isn't :V)

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?

If we wanted to be masochisticthorough, we could have our level transition function take an array of items to show on the results screen.  Perhaps, something like this:

End_Level_Transition([["Point Items", num_points], ["Graze", num_graze], ["Bombs", num_bombs], ["Stage Bonus", bonus], ["Total Score", Get_Score()]]);

... just an idea.

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.

This should be possible with manipulation of sound buffers.  Something we'd have to look into, and I don't think it should be top priority, but I don't see why it wouldn't be doable.

Of course, for simplicity, we could keep the simple "just play the damn sound" function, too.

[8lue Wizard]

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.

[Chronojet ⚙ Dragon]

This should be possible with manipulation of sound buffers.  Something we'd have to look into, and I don't think it should be top priority, but I don't see why it wouldn't be doable.

Of course, for simplicity, we could keep the simple "just play the damn sound" function, too.
[/quote]

I dunno, PlaySEex(<parameters>)?

[Naut]

I motion to change that function from PlaySEex to PlaySex. All in favor?

[Nuclear Cheese]

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.

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.

I motion to change that function from PlaySEex to PlaySex. All in favor?

What am I to do with you silly people. :V

[Dizzy H. "Muffin" Muffin]

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.

[Be Pok U (1998 burst style)]

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 unsigned byte int (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.

[Chronojet ⚙ Dragon]

Supporting 2+ cutins on each side of a talk event.

(Lyrica's scenario in Touhou Kaeidzuka)

[8lue Wizard]

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.

v.v If you must. Though I'd still like to see the hard max a notch or two above the conventional max.

[Montblanc]

Supporting 2+ cutins on each side of a talk event.

(Lyrica's scenario in Touhou Kaeidzuka)

This. It's pretty necessary for one of my games. =o