Blizz-ABS Bug and Suggestion Compilation

Started by winkio, April 21, 2010, 03:40:33 am

Previous topic - Next topic

Blizzard

There's a reason I didn't make perfect pixel collision detection. *points to CPU heavy algorithms for collision detection*
Check out Daygames and our games:

King of Booze 2      King of Booze: Never Ever
Drinking Game for Android      Never have I ever for Android
Drinking Game for iOS      Never have I ever for iOS


Quote from: winkioI do not speak to bricks, either as individuals or in wall form.

Quote from: Barney StinsonWhen I get sad, I stop being sad and be awesome instead. True story.

Subsonic_Noise

Well, that guy made a demo using that script and it didn't lag. I know, it will perhaps on slower PCs, but hey, maybe it's worth an addon? I don't think Endzeit will work too well on slow PCs anyways...

Blizzard

Did he in the demo test the collision of 10 objects at once? I don't think he did.
Check out Daygames and our games:

King of Booze 2      King of Booze: Never Ever
Drinking Game for Android      Never have I ever for Android
Drinking Game for iOS      Never have I ever for iOS


Quote from: winkioI do not speak to bricks, either as individuals or in wall form.

Quote from: Barney StinsonWhen I get sad, I stop being sad and be awesome instead. True story.

Subsonic_Noise

I don't know if he did and now stop ruining my dream. >:U

winkio

pixel perfect collision is not needed unless you have pixel perfect movement.  If everything is aligned to a grid, then that grid will be the smallest unit of event/enemy size for collisions.  For example, if you have PIXEL_MOVEMENT_RATE of 1 (meaning you used 16x16 squares), then you could define an enemy size that was 5x3 squares (80x48 px).

Subsonic_Noise

Quote from: winkio on April 23, 2010, 09:30:53 am
pixel perfect collision is not needed unless you have pixel perfect movement.  If everything is aligned to a grid, then that grid will be the smallest unit of event/enemy size for collisions.  For example, if you have PIXEL_MOVEMENT_RATE of 1 (meaning you used 16x16 squares), then you could define an enemy size that was 5x3 squares (80x48 px).

I agree with this. I was just adding that in case you're thinking about adding pixel movement. But what abou enemies that aren't rectangular?

winkio

April 23, 2010, 09:50:29 am #26 Last Edit: April 23, 2010, 09:51:31 am by winkio
QuoteBut what about enemies that aren't rectangular?


no.  Don't want to have to deal with rotation of wonky hitboxes.  And you are using a rectangular graphic for your enemies, so your enemies should be able to be represented by a rectangle.

Blizzard

If you want non-rectangular enemies, don't use RMXP. It's that simple. :P
Check out Daygames and our games:

King of Booze 2      King of Booze: Never Ever
Drinking Game for Android      Never have I ever for Android
Drinking Game for iOS      Never have I ever for iOS


Quote from: winkioI do not speak to bricks, either as individuals or in wall form.

Quote from: Barney StinsonWhen I get sad, I stop being sad and be awesome instead. True story.

Subsonic_Noise

Quote from: Blizzard on April 23, 2010, 09:55:22 am
If you want non-rectangular enemies, don't use RMXP. It's that simple. :P

I concidered using other engines, but it always failed at the fact that I can't do shit with them.
Why not add something like a "collision map" but parted into, for example, 16x16 blocks?
Couldn't that work?

winkio

Quote from: winkio on April 23, 2010, 09:50:29 am
QuoteBut what about enemies that aren't rectangular?


no.  Don't want to have to deal with rotation of wonky hitboxes.  And you are using a rectangular graphic for your enemies, so your enemies should be able to be represented by a rectangle.


Lets say you have a collision map that looks like this:
x x x
   x x x
   x x x
x x x

What happens when the enemy turns 90 degrees?  It's going to cause more glitches and handling than it's worth.  If you really do need that shape, then there will be the multi-event enemy plugin/option, which will be able to split it up into 3 rectangles:

x x x would be one

   x x x
   x x x  would be one

x x x would be one

Subsonic_Noise

oh lol I totally didn't notice your answer. I guess it's okay then.

G_G

Another suggestion. Have it so each item has its own DROP_AMMO variable. That way some ammo does drop and you can pick it back up and others aren't able to be picked back up.
Example:
Arrows can be picked up after being fired.
Bullets can't be picked up after being fired.

winkio

seems reasonable.  Also, I added a remake of the ammo system, because it's kinda awkward as it now stands.

legacyblade

D: what's the remake. I spent hours making a CMS that allowed for the equipping of AMO

winkio

It's not quite a remake, really just giving the option for each weapon to have a default ammo.

legacyblade

Oh, that'll make it so I can eliminate a big chunk of code :D

WhiteRose

Quote from: winkio on April 23, 2010, 11:32:02 pm
seems reasonable.  Also, I added a remake of the ammo system, because it's kinda awkward as it now stands.

Will ammo still need to be hotkeyed to be used? I know that several people have had issues with the current setup.

winkio

April 24, 2010, 01:44:18 pm #37 Last Edit: April 30, 2010, 06:57:04 pm by winkio
Yeah, the point is you will have the choice for each weapon whether you have to equip ammo or not.

EDIT: Another idea: Blizz-ABS HUD Maker, a GUI that allows you to arrange displays and their content, and then generates the code.

Subsonic_Noise

Seriously a really good idea. Will it allow moving the bars independently and resizing them?

winkio

yeah, I thought so too.  It's pretty much the only way I could think of to get people to stop using the default HUD. 

And yes, you can play around with the bars, and even use custom bar images.