mono collisions

[Zack]

I searched "collision" in the forum and found nothing relevant, so I don't think this has been discussed before.

The collision sprites in Mono are square, not circular.  An octagon, or a square with squares cut out of its corners, would be much better.  I know that this makes the game heavier, but I hope an economical enough solution can be found, because it's pretty obvious when a slow-moving big circle collides with you on a diagonal that the collision detection is defective in this way.

Also, a small pet peeve: the font used in DUOtris is practically un-readable.

Thanks for making games!

(btw, I think using CMY instead of RGB in the "black" mode of mono would be really appropriate.  You can't paint on black with red, red is dark.  You have to paint on it with glowing CMY, or else ... you get the idea, I'm just putting my intuition down on the screen)

Best of luck.

[TheKhakinator]

The CMY thing was discussed at length in another topic somewhere

It's not too hard to use circles instead of squares as the collision thing. Circles can actually be cheaper processing wise then squares, let alone octagons...

EDIT: The topic was here: http://www.binaryzoo.com/forum/index.php?topic=247.0

[las6]

EDIT: Thanks, "TheKhakinator"... I completely forgot all about that thread. It's probably a bit more clear than this.

btw, I think using CMY instead of RGB in the "black" mode of mono would be really appropriate.  You can't paint on black with red, red is dark.  You have to paint on it with glowing CMY, or else ... you get the idea, I'm just putting my intuition down on the screen

hey, it is a game. And not even a realistic one at that. But different modes were something we thought about. I myself always tend to favour HSL when dealing with colors, but try implementing that in the game. ( Actually I think it *could* work, but would produce wildly different results. )

also, CMYK (remember, there's a K in there too) would also bring other problems.. Like if we wanted a bright Cyan color, we can't just use 100% Cyan and the rest at 0%. Full Cyan is C: 85%, M:0%, Y:34%, K:0%. And as you probably know, the enemies are controlled by the color of the background. This would mean constant conversion of the colours which just leads to rounding errors and other headache we really don't need. See games, and computer applications in general, like to work in a very RGB environment. So using anything other than RGB means you have to do software conversions. It's just a lot simpler to use RGB and be done with it.

The collision sprites in Mono are square, not circular. An octagon, or a square with squares cut out of its corners, would be much better.

Heh, let me know when you find out a way to make octagonal images. And I mean really the images themselves, not the content in them. You see, those are not "collision sprites"..they are just sprites.

because it's pretty obvious when a slow-moving big circle collides with you on a diagonal that the collision detection is defective in this way.

I know what you mean, but have you found this to be the case with mono? If you think it is, I suggest you play the game again.


Oh and welcome to the forum!

[TheKhakinator]

Yeah, I never had the problem with mono of the whole "hit by a square circle" variety. Always acted like circles when I played...

[fog]

Hi Zack and welcome.

The collision sprites in Mono are square, not circular.  An octagon, or a square with squares cut out of its corners, would be much better.  I know that this makes the game heavier, but I hope an economical enough solution can be found, because it's pretty obvious when a slow-moving big circle collides with you on a diagonal that the collision detection is defective in this way.

As las6 says, the collisions in mono are all done using circles and not squares so they are correct.

The only time I can imagine this could look wrong is if your PC is struggling.  In which case not all frames are drawn and it may appear collisions are slightly out.....although I can assure you this is not the case.

I honestly can't remember all the options in mono (doh!) but I suggest you reduce the FX setting and see if that helps.

Also, a small pet peeve: the font used in DUOtris is practically un-readable.

Can't say anyone else has mentioned that but I appreciate it's not as easy to read as it might have been.  I blame the artist

(btw, I think using CMY instead of RGB in the "black" mode of mono would be really appropriate.  You can't paint on black with red, red is dark.  You have to paint on it with glowing CMY, or else ... you get the idea, I'm just putting my intuition down on the screen)

Yeah that's always an option and one we will be using at some stage no doubt.

Basically though for non technical types CMY is a bit of a mystery.  As a lot of gamers really have no knowledge or interest in such things, RGB is at least something most will have heard of and appreciate to some extent how it works.


Thanks for the feedback.

[Zack]

I'll work up a video of some collisions.  I took another look and I'm sure I'm getting square collision sprites.
edit: I can't seem to use Fraps to capture video of mono.  I'll try some other programs.

Thanks all for the warm welcome.

offtopic: a triviality

CMYK (remember, there's a K in there too)

CMYK is for printing.  K is black ("key") and is used in printing because black ink is cheap, and often you can reduce the amounts of CMY ink that you need by putting down some black.   This wikipedia article has more information.  You know more about this than I do (cyan isn't just 100% cyan? huh!).  You know all this already.  My thinking is that since this application doesn't involve printing, we can leave the K out, as CMY coordinates alone are enough to define colors equivalent to RGB color coordinates.

[fog]

I'll work up a video of some collisions.  I took another look and I'm sure I'm getting square collision sprites.

I'd be interested to see that.

edit: I can't seem to use Fraps to capture video of mono.  I'll try some other programs.

Strange, I'm sure las6 used fraps on echoes (our current game) so I'd have thought it would work on mono.

[Zack]

link to video.  It's in a 1 MB zip file, but unfortunately you've got to unzip it into a 120 MB avi to view it.  (I am a noob with VirtualDub, and I can't get the compression codecs to work on this file.)

I used Bulent's Screen Recorder, and it taxed my processor to the point that mono didn't run too well.  You can still see that collisions are quite different at diagonal angles (first part of the video) than at cardinal angles (second part of the video).

[fog]

Hmm.  Difficult to comment when the video looks like the screenie below and everything is skewed. 

[Zack]

Hmm. I'll try posting just the avi captured by Bulent's.

Ok, here it is.

edit: the first 40 seconds are spent launching Mono (it takes a while because the screen recorder is heavy).

[fog]

Thanks Zack, I'll check that out tonight.

[fog]

Hmm.  Well even at the low frame rate of that video it's obvious something isn't right.

Not quite sure what could be causing it though as the collisions, as mentioned previously, are definately based on circles.  It's fairly simple code too so it's not like some fancy function or external library could be screwing things up.

I am however using a slightly different method in new game "echoes" so I'd be interested to know if that looks any better.....when I get a new version uploaded. 

[Zack]

I'll try reinstalling.

[fog]

I'll try reinstalling.

Nah I doubt very much that will help.

Like I said, I'll upload a recent version of echoes with a slightly different collision system and see how that works (the echoes system uses some pre-calculated collisions so will also be faster....if it works )

[Zack]

I'd forgotten that the install process was "unzip to desired folder."  Yeah, it won't help much to do that again.