 Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me. |
Forum Index : Microcontroller and PC projects : MM/CMM: crazy collisions
| Author | Message | ||||
Juri74 Senior Member  Joined: 06/02/2012 Location: ItalyPosts: 162 |
i'm going to be crazy with sprites collisions, tried and tried but actually without success, the command "COLLISION()" is missing something.. i think :D suppose this scenario: i've 20 sprites on screen (enemies) one sprite for player and one sprite for bullet fired from player.. sprites 1 to 20 are enemies sprite 21 is the player and sprite 22 is the bullet the player fire the bullet that collide with one enemy sprite.. how can i determine wich sprite has collided the sprite 22 (the bullet)? а very important thing to know is that enemies can collide with each other any clues please? COLLIDE(n,EDGE) is useless COLLIDE(n,SPRITE) is hard to use because it didn't return the sprite number that collided with sprite "n" but the EDGE it collided...... or maybe my english isn't good enough to fully understand appendix H ahahaha XD Juri |
||||
| cosmic frog Senior Member Joined: 09/02/2012 Location: United KingdomPosts: 284 |
The whole sprite collision thing is complicated and hard to use, I find it easier to use fonts. The sprite syntax wants to look something more like this - Sprite(n,i,x,y,c) n=sprite number i=sprite image x=x pos y=y pos c=collision returns the collided sprite number With this example you wouldn't have to draw lots of the same sprite, collision detection is built-in, and you wouldn't have to mess around turning sprites on and off just to change the sprite image. Amos basic on the Amiga used something like it for both Sprites and Bobs. I wonder if Goeoff could implement a Bob command. Dave. |
||||
| Juri74 Senior Member Joined: 06/02/2012 Location: ItalyPosts: 162 |
at least the command "collision(n,SPRITE)" should return the sprite number that collided with sprite n, it is useless to know that sprite n collided to somewhat at his edge, it's more useful to know that sprite n collided with sprite x... one way could be to check if sprite n has collided with a sprite, and immediately check if sprite x has collided too, but sprite x in that moment could have collided too, but with another sprite.. at least i could calculate an approximate collision with sprites x-y position using fonts is a good idea, i use fonts too however fonts can have only 1 color x char, sprites uses 8 colors, i tried it time ago with a special font with 4 chars with different colors overlapping, printed at same coords, but this way is too slow... sprites are damn faster... searching for workarounds.... ;) Edit: talking about sprites & bobs i think that bobs are useless or duplicated command.. taking for example amiga computer, Sprites was hardware generated images that were indipendent to the screen resolution/colours example a one bit screen (2 colours) could display 16 colours sprites.. bobs resolution/colours instead depend from the screen resolution.. a one bit screen (2 colors) can display ONLY 2 colours bobs... you programmed amos so you know this.. maximite doesn't have hardware sprites.. the fact is that they are called sprites but they are bobs, with fixed dimension. maybe in future sprites will have free dimensions or at least 1 byte step dimensions(8,16,24,32... pixels width/heigh) I appreciate the effort that Geoff has done to implement the sprite system, actually is limited but useable for simple tasks.. I hope that in the future it would be enhanced to at least give indipendent image from sprite "sprite(spr number,x,y,img number)" and sprite to sprite collision command "hit=Sprite Col(spr number)" where "hit" contain the sprite number collided by "spr number" this is intended as a constructive criticism, I can understand, the problems that may come out in the programming, commands that the end user can look very simple or "logic" can be very difficult to implement! all i can say now to Geoff is: do your best, as you have done until now! Juri |
||||
| cosmic frog Senior Member Joined: 09/02/2012 Location: United KingdomPosts: 284 |
You can also use small .bmp's (Bitmaps) and move them about with the blitter command but you'll still have the collision problem. |
||||
Nick Guru  Joined: 09/06/2011 Location: AustraliaPosts: 512 |
Some time ago, I sent a document to Geoff detailing some suggestions to add to the Sprite operations to improve these things that wouldn't break older software. I will follow it up with Geoff and see if he has plans to implement them. I feel that these additions would make things easier. The sprites are more powerful and offer greater flexibility than fonts. For starters, fonts can only be 2 colours and offer no collision. Nick |
||||
| cosmic frog Senior Member Joined: 09/02/2012 Location: United KingdomPosts: 284 |
Hi Nick, the collision detection definitely needs looking at, as it is it's like working blind. I suppose you could always use the old - IF XSPRITE1=XSPRITE2 AND YSPRITE1=YSPRITE2 THEN COLLIDE. Anyway I'm sure it will be sorted in future versions. Dave. |
||||
| Nick Guru Joined: 09/06/2011 Location: AustraliaPosts: 512 |
But comparing x,y sprite collisions that way means that a collision is only detected when the sprites line up exactly whereas the Sprite collision checks for any pixel of each sprite touching each other. It's more "pixel perfect". I don't recall having too much trouble with the collision detection in my game "Donut Dilemma". It seemed to work fine. |
||||
| Nick Guru Joined: 09/06/2011 Location: AustraliaPosts: 512 |
Here is my suggestion to Graham for improving the animation of Sprites... ------------------------------ Currently, if we wanted to animate a sprite, for example - a man walking, we need to create as many sprites required for each frame of the walking man. In our code, we then turn off the current "man sprite" and activate the next one. When we reach the last frame, we simply cycle back. I got thinking how this could be simplified and have come up with an idea that does this while still remaining compatible with the current method. Let's assume we create 4 sprites representing the 4 frames of the walking man. Let's label these as sprites 1 to 4. Let's now allocate sprite 5, which we haven't defined (blank) as the sprite that we will use in our program. Using a command such as... SPRITE COPY 1 to 5 ... this will transfer the contents of the 16x16 sprite matrix from sprite #1 to the 16x16 sprite matrix of sprite#5. You program only now has to manage 1 sprite value yet it can be animated using this command. ----------------------------------- |
||||
| Juri74 Senior Member Joined: 06/02/2012 Location: ItalyPosts: 162 |
Hey, that give me an idea, Geoff could add a pointer to the sprite data for using it with PEEK/POKE commands, keywords like RSPRITE,GSPRITE,BSPRITE then the sprite copy routine could be easy to do in basic, in this way could be possible to copy sprites to screen and get sprite data from screen too... |
||||
Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3194 |
I have to agree with pretty much everything that has been said in this thread. The problem as I see it is that there are many demands on sprites with different people trying to do different things and they all seem to need different and often conflicting features. I know nothing about writing games so I do not have a solid basis to determine what should be in or out. However, the current sprite system cannot be too bad as evidenced by Nick's excellent games. So, at this time and until I can see a clear way forward, I plan to hold off trying to make any further "improvements" to sprites. Having said that I can see how knowing what sprite you have collided with would be important, so I will have a look at that (it cannot be that hard). Geoff P.S. Juri, using BASIC to copy sprites to/from memory would be way to slow - that was why sprites were developed in the first place. Geoff Graham - http://geoffg.net |
||||
| Nick Guru Joined: 09/06/2011 Location: AustraliaPosts: 512 |
I'll attempt to clarify my previous explanation a bit more... If you have a sprite of a walking man, that uses 4 separate sprites of the man character in different poses, then, to give the effect of walking we need to turn on/off each of those 4 sprites in turn to achieve that effect. This is fine. But what if you needed to put the same man sprite more than once on the screen, let's say 4 men. We then have the problem of multi-using a sprite character. We can't use the same sprite twice. If one sprite is using sprite frame #1, then no other sprite can use sprite frame #1... MMBASIC will stop with an error. I got around this in my Donut Dilemma game by have each of the "Donut" sprites (up to 5 on screen at a time) be using a different sprite frame at each instance. They never shared the same sprite number and each sprites was always one frame ahead of the previous sprite. What my SPRITE COPY # to # suggestion does is to simply copy the contents of one sprite buffer to another. So, if I needed to display 4 of the same sprites on screen at the same time, I would assign 4 sprites but I would also have each frame required for the animation set aside in another set of sprites. Let's assume we want to display 4 sprites and that each sprite has 4 frames of animation. I would assign 4 sprites for the 4 displayed sprites and another 4 contain each of the animation frames. Now I can animate each of the 4 displayed sprites individually simply by copying the next desired animation sprite frame into the currently displayed sprite frame and I can have all 4 of my displayed sprites display the same animation frame if I wanted. I could have 10 displayed sprites but I still would only need 4 of the animated sprite frames... I just merely copy this to the desired displayed sprite. Eazy-peazy!! 
Nick |
||||
| Nick Guru Joined: 09/06/2011 Location: AustraliaPosts: 512 |
An addendum to my explanation (of the explanation)... You still need to do a SPRITE ON/OFF for each sprite to update the displayed sprite on-screen but the point is you are doing it to the one sprite and not needing to share sprite frames. I know this may all sound confusing. Game design is not "just a game", it has some complex concepts behind it. By adding/improving the commands in MMBASIC, it can go some way to simplifying them. Nick |
||||
| cosmic frog Senior Member Joined: 09/02/2012 Location: United KingdomPosts: 284 |
Hi Nick, Yes I think the Spritecopy is a good idea and will help with animation and having to make multiple sprites. What about collision detection? I would like to see detection of ANYTHING on screen. I know this may not be possible but just having a detection return a certain colour would be useful - eg. anything red could kill you or anything yellow would get you a powerup. This way you could use collision detection on BMP's and fonts. What do you think? Dave. |
||||
| Nick Guru Joined: 09/06/2011 Location: AustraliaPosts: 512 |
I can see it's use but normal sprites on sprite equipped systems don't even have this. This may be more than what Geoff would want to implement seeing that the Maximite's market is not predominantly games. Collision detection has always been about collisions between sprites. Nick |
||||
| Juri74 Senior Member Joined: 06/02/2012 Location: ItalyPosts: 162 |
I do agree with all, however i think the sprite system could be improved a little, for sure maximite wasn't think for doing games, however games could prove how powerful maximite is ;) problems with sprites system are that you have to "sprite off" and "sprite on" for animations etc, this cause that "flickering" effect on sprites, i can give some suggestions because i found a workaround: instead of turning off/on sprites turn all on and place unused frame out of the screen, update animation with sprite move command, in this way sprites flickering is about to 0. and when possible use the "solid colour" for background. at this time surely you will never make a "space invaders" using sprites! all enemies should have 2 sprites (for animations) repeated for the number of enemies on screen, every bullet of enemies are one sprite, it appear to be a simple task but how big will be the sprite data file? is better to use fonts here! sprite to background collision would be useful (even c64 has it) another option that could be useful is a sprite zone, an area of screen where sprites are displayed at last but not last, sprite to sprite collision with returning number of sprite that collided is almost essential.. it is clear from what Geoff wrote, that maximite was not born as "game machine", it's all in Geoff's hands to improve it in that direction or not. is the skill of the programmer, the ability to overcome the limitations of the machine, that makes the difference, certainly a help from Geoff could be very, very useful :D Juri |
||||
| shoebuckle Senior Member Joined: 21/01/2012 Location: AustraliaPosts: 189 |
Although I am not into programming games, I couldn't agree more. It is nice to have features to make it easy, but the challenge facing the programmer is to make it jump through hoops within the confines of the device's features. More kudos the the programmer who can. Hugh |
||||
 Print this page |
