Sprite priority question

[Vincent]

Wow!

I can't wait to have this honorific title. 
I am going to work on this double-time!

I have a demo that does work, but since it is not adding any dynamic sprites and, of course, not removing any dynamic sprites, the problem does not show up.  I will probably have to work with dynamic sprites eventually in my project, so I guess I will have to solve this problem eventually.

If you want to see what it does right now, I could post the demo.  Do you?

[Vincent]

Oh, sorry for the double post! 

I made a couple of changes to the sprite collection system.  Rather than having a sprite type detection (static or dynamic) based on the index of m_Sprites, I added a field and a property to the SpriteBase.  A field bool isStatic and the property bool IsStatic that Get and Set the field.  All sprites added at runtime are isStatic = false by default.  And when the initial SpriteCollection is constructed, all sprites contained within have their isStatic field set to true.  I guess it is not as optimal, because when the SpriteCollection is running it's Clean method, it iterates through all the list rather than from the staticSize index value.  And it checks each sprite to determine if it is isStatic before actually removing them.

To sum it up, I changed code in two files: SpriteCollection.cs and SpriteBase.cs.  The project compiles and everything seems fine.  There are no runtime errors from what I can see in my small project.

Now, bluemonkmn I really need your help (in fact, anyone capable of helping me is more than welcomed): I have no debugging tool for C#, and my project is not advanced or complicated enough to throughly test the modifications I've made.  I would really like it if someone could give it a look.  To ease things up, all the modifications I've made to the source code are within these markers:

Code: [Select]

      ///********************************************************************
      ///**************************added by Vincent**************************
      ///*******************************Begin********************************
      //staticSize = sprites.Length;
      //This is to make sure all initial sprites are considered static
      int i;
      for (i=0; i < InnerList.Count; i++)
      {
         ((SpriteBase)InnerList[i]).IsStatic = true;
      }
      ///********************************End*********************************
      ///**************************added by Vincent**************************
      ///********************************************************************As you can see, I commented the original code out (rather than deleting it) so it can still serve as a reference.  And by searching for my name through the code, you can easily find what I modified.

I would really like it if someone could give a look or tell me how to test it efficiently.  I am attaching the code files to this message, including my SpritePriorityFunctions.

If you like it bluemonkmn, I give it all to you.  Feel free to include it in your next SGDK2 release.  I'm happy to help.
If it does not work or if you're not interested, then discard it!  :laugh:

I hope to get news soon!

[bluemonkmn]

In SpritePriorityFunction, you are checking:
if (iSpriteToInsert < iSpriteRightUnder)
twice.  I think the second one should be
if (iSpriteToInsert > iSpriteRightUnder)

Also, I think you could change
for (i = iSpriteToInsert; i > iSpriteRightUnder; i--)
to
for (i = iSpriteToInsert; i > iSpriteRightUnder + 1; i--)
to avoid one unnecessary copy/move operation, but it doesn't matter much because the end is the same.

I don't think I would want to expose this function to everyone because, as you noted, it's somewhat less efficient, and also it allows the possibility that named (static) sprites could be completely removed from the layer (not just de-activated) and could leave someone very confused why activating a sprite doesn't do anything.  (That's probably why I made the collection read only.)  But for people like you who are clever enough to edit the code, you probably understand the dangers, so feel free to play with your project's version of the code as much as you like.  I didn't test the code, but other than the things I mentioned above, it looks reasonably sound.

Have you used it to actually affect priorities and see the effect yet?

[Vincent]

You are absolutely right bluemonkmn!  I made the two changes in my code.

Ok, then I'll keep this code for me!  (unless someones asks for it!)

Yes, I do have a demo in which sprite priorities are changing.  There is a sprite that move in front and behing another copy of the same sprite, and it's actually working perfectly from what I can see.  I'm going to post it with this message.  I zipped the ".exe" file.

The fighter on the left can be moved with the arrow keys (he's binded to the default player 1 keys), the fighter on the right is the second player.  With button 1, the fighter does a kick (but no collision detection or anything, the fighter cannot actually harm themselves) and with button 2 (you have to hold it) the fighters move up and down the mat.

So, if you press the upward arrow, the fighter jumps.  If you hold button 2 and press upward arrow, the fighter moves up the mat.
If you play around with the fighters, you will be able to see that they are painted in front and then behind each other without any problem.

I also added a detection so the fighters cannot actually pass through one another.  You have to circle around the other fighter to get to the other side of the mat.

Have fun!

[durnurd]

Impressive, I say.  This could end up being a very nice show that what SGDK2 is capable of is far beyond the basics included.

[Tanja]

i double-clicked at the exe and got an error message about missing files. can't post a screenshot, the forum doesn't let my. try it later.

[Vincent]

To Morgengrauen

Well I did not included the dll required to play the game (the zip file would have been too heavy).  If you place the exe within one of your project folders it should run.

I believe the required dll are:
microsoft.directx.direct3d.dll
microsoft.directx.direct3dx.dll
microsoft.directx.directinput.dll
microsoft.directx.dll
d3dx9_30.dll

Just put the exe in a folder with all of these dll, it should work.
But don't ask me what each individual dll does: i'm clueless on this!

Thanks durnurd!

What do you think bluemonkmn?

[bluemonkmn]

Now I see how to move in front and behind (I should have read this first before asking in my other post).  I think if you only post the SGDK2 file then people using SGDK2 will be able to compile the project on their own, and all the binary files will be copied to the right place, so it's best not to include the EXE when packaging the program for other SGDK2 users.

I think this demo qualifies you as clever ... but you will have to learn how to distribute your files

[Tanja]

the best would be when you would declare the buttons/actions with "logDebugLabel" directly in the game. at the first try, only after reading about the player controls, i had big difficulties to manage going down/up. anyway, great demo!

[bluemonkmn]

when

wenn = If
wann = When
(I think "if" is better here)

[Tanja]

one of these little traps all over the path... 

[Vincent]

Thanks a lot guys!  (woohoo! I'm clever! )

By the way Morgengrauen, I'm not sure I understand what you mean with "logDebugLabel" and controls?  Do you mean that I should explain how the controls of the game work by using the "LogDebugLabel"?  If it is the case, wouldn't it take too much space and hide much of the game?

Oh, and bluemonkmn, is there a guide or something that could explain to me how to distribute my files?  Or is it simply that I must remove the 5 dll and the exe file?

See ya!

[Tanja]

i don't know if the labels would take too much space of the display (you understood me right with the labels).
but i know you can manipulate color and size of the labels. but if you have described this already, you don't need it to do this way. just a suggestion.

edit: LOL, this is my "half evil" post... post count: 333

[bluemonkmn]

I added a new item to the SGDK2 project listing site home page this morning that explains a few tips about submitting projects for the listing.  But here is a brief summary:
1. If you want to distribute the source code for your game, just distribute the SGDK2 file (probably compressed).
2. If you want to distribute your compiled game, use the "Generate Project" command and then use "Delete Intermediate Output Files" and deliver only the contents of your project folder (not the SGDK2 file itself).

I prefer only the source code in the project listing, when that's acceptable to the author.

[durnurd]

Also of note: LogDebugLabel only works in debug mode.  It won't display anything when actually playing the game as a user.