Author Topic: Suggestion for Plans and Sprites  (Read 13677 times)

durnurd

  • Lead Lemming
  • Expert
  • Fanatic
  • *****
  • Posts: 1234
  • Games completed so far: 0
    • MSN Messenger - durnurd@hotmail.com
    • View Profile
    • Find My Ed
Re: Suggestion for Plans and Sprites
« Reply #15 on: 2010-04-17, 06:32:50 PM »
I noticed a few more things:

There's still nothing stopping me from putting illegal characters in a plan's name on the map editor.
  • If I specify a SpriteBase variable in a subclass of PlanBase, I can use the dropdown combo box to edit its value in the map editor (although it sometimes takes a few clicks to get it to refresh and show it), but I can't access that sprite in the plan editor.
  • If I specify a subclass of SpriteBase as a variable in a subclass of PlanBase, I cannot use the dropdown combo box to edit its value in the map editor.  I can still type in values as text.
    Trying to run the game when an instance of it is already running crashes SGDK2
  • If a sprite is riding a platform, and the platform becomes deactivated, the app crashes in debug mode, because the rider tries to update the platform manually before doing its own reactToPlatform, which then calls the assert(IsActive).
  • Similar to the SpriteBase thing, if I specify a LayerBase as a variable of a SpriteBase, I cannot use the dropdown combo box to edit its value in the map editor.  In fact, I cannot even see the property in the list in the map editor (I've tried setting using the [Description("")] tag to no avail).  I can still set its value in the rules editor using, in my case:
Code: [Select]
m_ParentLayer.m_Builder_2.LockLayer = ((Map01_Map)m_ParentLayer.ParentMap).Locked_Tiles
  • When using CheckNextCoordinate in FollowPath, the check for reaching the target point uses < TargetDistance, meaning having a TargetDistance of 0 will never move on to the second point in the path.  If the TargetDistance is 1 instead, an L-shaped path will cause the sprite to have a slight grade while going from the second to the third point, because it will never have reached the exact middle point of the L.
« Last Edit: 2010-04-18, 08:36:25 AM by durnurd »
Edward Dassmesser

bluemonkmn

  • SGDK Author
  • Administrator
  • Fanatic
  • *****
  • Posts: 2752
    • ICQ Messenger - 2678251
    • MSN Messenger - BlueMonkMN@gmail.com
    • View Profile
    • http://sgdk2.sf.net/
    • Email
Re: Suggestion for Plans and Sprites
« Reply #16 on: 2010-04-19, 06:46:48 AM »
Thanks.  Just like at my job, I'm glad to have someone else with the time to test my work more thoroughly so I can just focus on fixing the things that people care about, rather than spending all my time testing, and then not knowing if anybody even cares about what I tested :).

Looks like I've set expectations pretty high with some of my helpfulness in the map editor.  You want a drop-down list of all the sprites of a particular derived SpriteBase type to be available when editing a plan's property values in the map editor when a plan has a variable of that derived SpriteBase type?  That's pretty fancy, isn't it? :)  (Although, I guess it shouldn't be much different than what I've already done.)

Question about your experience with CheckNextCoordinate: do you think "<= 0" would fix the problem?  You say that using "1" didn't work, which implies that your sprite had some landing points between 0 and 1 pixels from its destination, which suggests to me that it's unlikely your sprite would end up exactly at 0 pixels from its destination within a reasonable amount of time.  Or do you have it running at a constant 0.5 pixels per frame or something like that?


durnurd

  • Lead Lemming
  • Expert
  • Fanatic
  • *****
  • Posts: 1234
  • Games completed so far: 0
    • MSN Messenger - durnurd@hotmail.com
    • View Profile
    • Find My Ed
Re: Suggestion for Plans and Sprites
« Reply #17 on: 2010-04-19, 07:59:46 AM »
The sprite is always running at 1 px per frame at orthogonal angles.  The reason I care so much is because as soon as it reaches the last point in its path, it deactivates itself, and whenever it's directly overlapping a tile, it changes that tile, so if it deactivates itself before it reaches the end, it won't change the last tile unless I extend the path 1 px extra.

I got around that issue, I think, by limiting the velocity to 1 px per frame before moving, then resetting velocity to 0 for the next call to FollowPath.  Then, on the very last point, I put a weight of 1 so that it will wait there 1 frame before starting to move back towards its original point (which is how it determines if it should deactivate itself).  There's probably something else I did as well, but I don't remember it.
« Last Edit: 2010-04-19, 09:40:13 AM by durnurd »
Edward Dassmesser

bluemonkmn

  • SGDK Author
  • Administrator
  • Fanatic
  • *****
  • Posts: 2752
    • ICQ Messenger - 2678251
    • MSN Messenger - BlueMonkMN@gmail.com
    • View Profile
    • http://sgdk2.sf.net/
    • Email
Re: Suggestion for Plans and Sprites
« Reply #18 on: 2010-04-25, 11:05:38 AM »
Some more points:  One reason I wanted to make subclasses was so I could override functions like reactToSolid in the subclass.  There are plenty of ways to handle this, but it seems like the cleanest would be to have a subclass in between SpriteBase and the specific classes that use the overridden reactToSolid method.  The problem is that reactToSolid is not marked virtual and is in an abstract class, which means it can't be overridden properly.  I can use 'new' instead of 'override', but I'm not sure what the difference is, and if it would be a problem.

I don't understand why you would want to override ReactToSolid instead of just implementing your own ReactToSolid.  Should many other functions be overridable too?

durnurd

  • Lead Lemming
  • Expert
  • Fanatic
  • *****
  • Posts: 1234
  • Games completed so far: 0
    • MSN Messenger - durnurd@hotmail.com
    • View Profile
    • Find My Ed
Re: Suggestion for Plans and Sprites
« Reply #19 on: 2010-04-25, 10:40:12 PM »
Well, I don't really know the difference between creating a New ReactToSolid method vs an overridden ReactToSolid method.  I know what overriding the function does, so that's what I assumed would be the best option.
Edward Dassmesser

bluemonkmn

  • SGDK Author
  • Administrator
  • Fanatic
  • *****
  • Posts: 2752
    • ICQ Messenger - 2678251
    • MSN Messenger - BlueMonkMN@gmail.com
    • View Profile
    • http://sgdk2.sf.net/
    • Email
Re: Suggestion for Plans and Sprites
« Reply #20 on: 2010-04-26, 06:25:22 AM »
I wouldn't name it "ReactToSolid" because that would be confusing if you're implementing a new function.  But the real reason you'd need to override a function instead of implement a new one is if you need polymorphism.  So the question is, do you need to be able to call ReactToSolid on the base type and have it execute the actual derived ReactToSolid code depending on the actual sprite type?

durnurd

  • Lead Lemming
  • Expert
  • Fanatic
  • *****
  • Posts: 1234
  • Games completed so far: 0
    • MSN Messenger - durnurd@hotmail.com
    • View Profile
    • Find My Ed
Re: Suggestion for Plans and Sprites
« Reply #21 on: 2010-04-26, 07:49:46 AM »
Well, okay.  Probably not, in this case.  But would it make sense to just have SpriteBase not be an abstract class in any way?  It would fix this issue for any subclass for any method (I think) and all you'd have to do is have an empty ExecuteRules method.  Not sure if it's the best way to do it though...
Edward Dassmesser

bluemonkmn

  • SGDK Author
  • Administrator
  • Fanatic
  • *****
  • Posts: 2752
    • ICQ Messenger - 2678251
    • MSN Messenger - BlueMonkMN@gmail.com
    • View Profile
    • http://sgdk2.sf.net/
    • Email
Re: Suggestion for Plans and Sprites
« Reply #22 on: 2010-04-26, 11:40:10 AM »
I don't think I'm understanding you correctly.

Are you suggesting that it would make sense to make the sprites not abstract -- not have any inheritance?  That would imply that either:
1. All sprites share the same class, or
2. Every sprite is its own class.

#1 would be problematic because the sprite parameters, states, and sizes are all implemented in the derived sprite classes.  The states and sizes could maybe be implemented generically in the base class somehow, but the sprite parameters would have to be drastically different (well, at least until I start using/requiring .NET 4.0, where you can dynamically add properties to an object, at least with VB.NET).  It's nice to have parameters so directly correspond to variables defined in the derived sprite class.  Also, eliminating object inheritance seems to be a step in the wrong direction with OOP, where right now you can define a base class and take advantage of the fact that your derived class inherits all the base class functions, and can add new functions and variables only applicable to this specific new type of sprite.
#2 would be problematic because the framework code needs to be able (among other things) to determine the position of a sprite generically.  And that would also mean a lot of overhead if every sprite type had to totally rewrite all those SpriteBase functions.

OR are you suggesting that SpriteBase should be abstract (asking the question "would it make sense to just have SpriteBase not be an abstract class" suggesting a "no" as the right answer)?

To that I say, SpriteBase already is abstract in some ways.  All these members are abstract and must be overridden by the derived sprite generated by SGDK2:
  • SolidWidth and SolidHeight
  • SpriteState
  • ExecuteRules
  • ClearParameters
  • RemoveFromCategories

Also, the framework takes advantage of the ability to refer to and interact with sprites generically in a number of ways as indicated above (sprite position, size and appearance).

But if you are saying that SpriteBase should be more abstract, I am undecided. I started adding "virtual" to many of the functions implemented in SpriteBase until I stopped and asked the question, "how am I deciding what makes sense as virtual and what doesn't?" and I didn't know the answer.  Under what circumstances will you need to override a function?  Was I correct to begin with in having only those members that the framework cares about be abstract?  So maybe you are suggesting that nothing more than the framework's minimum requirements should be abstract, and things are OK as they were?

Edit: Oh, also Processrules is virtual and can be overridden, but is not abstract because it has a default implementation.
« Last Edit: 2010-04-26, 11:45:43 AM by bluemonkmn »

durnurd

  • Lead Lemming
  • Expert
  • Fanatic
  • *****
  • Posts: 1234
  • Games completed so far: 0
    • MSN Messenger - durnurd@hotmail.com
    • View Profile
    • Find My Ed
Re: Suggestion for Plans and Sprites
« Reply #23 on: 2010-04-26, 05:09:55 PM »
After reading up more on C# (I haven't used it enough lately) I'll retract my main comment, which was essentially to just remove the 'abstract' keyword from SpriteBase and provide default implementations that would always be overridden.

However, having most methods be marked virtual makes sense in the sense that subclasses can then change them generically without having to change the base class (and lose those changes upon resetting the source code), so that two sprites can interact in a generic way without needing to know each others' types.
Edward Dassmesser

bluemonkmn

  • SGDK Author
  • Administrator
  • Fanatic
  • *****
  • Posts: 2752
    • ICQ Messenger - 2678251
    • MSN Messenger - BlueMonkMN@gmail.com
    • View Profile
    • http://sgdk2.sf.net/
    • Email
Re: Suggestion for Plans and Sprites
« Reply #24 on: 2010-04-27, 04:52:14 AM »
Ah, so you think functions that sprites and plans might want to call on each other would make sense as virtual functions because they might want to perform the operation on a SpriteBase.  So that would probably be all public functions and properties then?

bluemonkmn

  • SGDK Author
  • Administrator
  • Fanatic
  • *****
  • Posts: 2752
    • ICQ Messenger - 2678251
    • MSN Messenger - BlueMonkMN@gmail.com
    • View Profile
    • http://sgdk2.sf.net/
    • Email
Re: Suggestion for Plans and Sprites
« Reply #25 on: 2010-04-27, 06:18:41 PM »
I did an update, and found that either two files are missing or they're supposed to be generated somehow.  When I opened the project, it couldn't find the .config files for opentk.dll and fmod.dll.  When I deleted the references to them in the project I was able to run the application.  Will let you know more once I try it out

I don't see any reference to an fmod.config in my SGDK2.csproj.  Are you sure fmod.dll.config was one of the files?

bluemonkmn

  • SGDK Author
  • Administrator
  • Fanatic
  • *****
  • Posts: 2752
    • ICQ Messenger - 2678251
    • MSN Messenger - BlueMonkMN@gmail.com
    • View Profile
    • http://sgdk2.sf.net/
    • Email
Re: Suggestion for Plans and Sprites
« Reply #26 on: 2010-05-07, 05:53:10 AM »
If I specify a SpriteBase variable in a subclass of PlanBase, I can use the dropdown combo box to edit its value in the map editor (although it sometimes takes a few clicks to get it to refresh and show it), but I can't access that sprite in the plan editor.

This is a bigger change than I want to make now.  The plan editor is designed mainly for editing rules/details of a plan.  If you want to edit the design of a plan (its coordinates and parameter values) that's done in the map editor.  If I were to implement the ability to change parameters in the plan editor, I'd need a whole new page because there is no page for editing plan parameters.

durnurd

  • Lead Lemming
  • Expert
  • Fanatic
  • *****
  • Posts: 1234
  • Games completed so far: 0
    • MSN Messenger - durnurd@hotmail.com
    • View Profile
    • Find My Ed
Re: Suggestion for Plans and Sprites
« Reply #27 on: 2010-05-08, 07:52:43 AM »
I don't want to change the variable, I just want access to it.  If I select a rule like "FollowPath" I want it to show up in the list of sprites.  So I can create a PlanBase subclass with a Sprite variable spriteToFollowPath defined that I can set at design time, then in the FollowPath action, use that sprite instead of one of the specific sprites from the map.
Edward Dassmesser

durnurd

  • Lead Lemming
  • Expert
  • Fanatic
  • *****
  • Posts: 1234
  • Games completed so far: 0
    • MSN Messenger - durnurd@hotmail.com
    • View Profile
    • Find My Ed
Re: Suggestion for Plans and Sprites
« Reply #28 on: 2010-05-08, 07:55:40 AM »
I don't see any reference to an fmod.config in my SGDK2.csproj.  Are you sure fmod.dll.config was one of the files?

The files that are actually missing are OpenTK.dll.config and libfmodex-4.22.01.so
Edward Dassmesser

bluemonkmn

  • SGDK Author
  • Administrator
  • Fanatic
  • *****
  • Posts: 2752
    • ICQ Messenger - 2678251
    • MSN Messenger - BlueMonkMN@gmail.com
    • View Profile
    • http://sgdk2.sf.net/
    • Email
Re: Suggestion for Plans and Sprites
« Reply #29 on: 2010-05-09, 06:01:04 AM »
Since libfmodex-4.22.01.so isn't source code nor is it my own (like OpenTK.dll) you are expected to pick that one up from the Linux support package or exclude it from the project.