Author Topic: SGDK 2.0 Status  (Read 293467 times)

bluemonkmn

  • SGDK Author
  • Administrator
  • Fanatic
  • *****
  • Posts: 2761
    • ICQ Messenger - 2678251
    • MSN Messenger - BlueMonkMN@gmail.com
    • View Profile
    • http://sgdk2.sf.net/
    • Email
Re: SGDK 2.0 Status
« Reply #30 on: 2006-03-24, 07:02:27 AM »
OK, I think I got most of the runtime code worked out for everything that I've developed so far except for sprites and categories.  I am able to generate the project source code for a project and then I can relatively easily incorporate that into a Visual Studio project and compile it.  I can see a compiled project scroll through a bit of a map now, which is cool.  I've been spending the past couple days trying to optimize the DirectX Display object.  Performance isn't quite as good as I hoped it'd be.  I am only getting about 60 FPS with just 2 simple layers.  As I write, however, I did a new test where I include all my layers in a single batch instead of doing one batch per layer and was pleasantly surprised to see my FPS hit 75 FPS, which is my refresh rate.  Maybe there's no problem here after all.  I will formalize that optimization and do a little more work with the way I am handling textures, and then I hope to be ready to go back to designing/implementing sprites.

bluemonkmn

  • SGDK Author
  • Administrator
  • Fanatic
  • *****
  • Posts: 2761
    • ICQ Messenger - 2678251
    • MSN Messenger - BlueMonkMN@gmail.com
    • View Profile
    • http://sgdk2.sf.net/
    • Email
Re: SGDK 2.0 Status
« Reply #31 on: 2006-04-12, 09:17:54 PM »
I have been working on allowing the user to place sprites in the map editor, and things have been working out great.  This interface is a world better than the GameDev 1.x interface when it comes to adding sprites to a map.  No flipping back and forth between a full screen display, path editing and sprite editing.  Now you have all your sprites in the toolbox just like tiles, and you can select one, set it's properties right there on the side of the map editor and then add it to the map.  You can switch to sprite selection mode and when you click a sprite it's properties will show up in the same grid where a new sprites properties are edited.  The properties include all the intrinsic properties and the user-defined properties, which can all be edited on the fly.  I haven't implemented coordinate paths yet or "sprite plan".  The foundation is there, but there's no way to create an actual plan or a path or link it to a sprite yet.  The nice thing is that you won't have to have a path just to have a sprite any more.  I'm not entirely sure how sprite plans and coordinate paths will be related to each other and to sprites yet.  I suspect a plan will be a set of rules that can operate on either a single sprite or on all sprites in a category.  It will be used for things like making a sprite follow a coordinate path (a rule within the plan will reference both the sprite and the path to do this) and causing a sprite to teleport (for example the plan would contain a rule "if a sprite in the player category enters the area determined by the first two coordinates in path X, then teleport to the third coordinate in path X.")  I will have to make this simple for the user so they can easily (without a lot of extra thinking and steps) create a teleporter/door by just indicating the transport area and the destination and which category of sprites are affected.  Internally it will be stored in more general structures though (the aforementioned coordinate paths and plan rules).  In a sense, it will be like the graphics editor where you have various tools to achieve certain effects, but then you can get down to the detail level (graphics editor has pixels, plan editor has points and rules) and touch things up.

I still have a but more work to do on manipulating sprite instances in the map editor, and then I will probably move on either to this coordinate path / sprite plan work, or back to the code generator to see how sprites come out in the runtime code.  I have modified the display class and the layer class a bit in the process of implementing sprites.  For one thing, there is now a "priority" property on both the sprite instance and the layer -- when the priority of the sprite is the same as the priority of the layer, the sprite draws between the rows of tiles like you'd want to see for an isometric-style map.  If it is greater, then it draws in front of the layer, and the order of the sprites' drawings are determined purely by priority.  So now it's really easy to determine which sprites draw on top of which other sprites.  I hope nobody minds that it's a static setting and can't be changed at runtime, but I think that will help optimize performance.  And if you really want a sprite to move to a different priority, there's the option of creating an identical sprite with a different priority, deactiviting the old sprite and activating the new sprite to make it look like it changed priority.  If changeable priority is a big issue, though, I could consider the possibility of allowing priority to be swapped with another sprite's -- it's probably not a big deal to implement.  As I was saying, I modified the classes a bit and need to incorporate similar changes into the runtime copies of some of this code.

durnurd

  • Lead Lemming
  • Expert
  • Fanatic
  • *****
  • Posts: 1234
  • Games completed so far: 0
    • MSN Messenger - durnurd@hotmail.com
    • View Profile
    • Find My Ed
Re: SGDK 2.0 Status
« Reply #32 on: 2006-04-12, 10:29:15 PM »
The ease with which one may place a sprite makes me salivate... aaaaggghhh...
Edward Dassmesser

bluemonkmn

  • SGDK Author
  • Administrator
  • Fanatic
  • *****
  • Posts: 2761
    • ICQ Messenger - 2678251
    • MSN Messenger - BlueMonkMN@gmail.com
    • View Profile
    • http://sgdk2.sf.net/
    • Email
Re: SGDK 2.0 Status
« Reply #33 on: 2006-04-13, 02:14:26 PM »
<homer simpson>Mmmmmm, Spriiiiite.... *gurgle gurgle gurgle gurgle*</homer simpson>

bluemonkmn

  • SGDK Author
  • Administrator
  • Fanatic
  • *****
  • Posts: 2761
    • ICQ Messenger - 2678251
    • MSN Messenger - BlueMonkMN@gmail.com
    • View Profile
    • http://sgdk2.sf.net/
    • Email
Re: SGDK 2.0 Status
« Reply #34 on: 2006-04-28, 04:06:01 PM »
I've been deeply embedded in the code generation for a number of days now.  I'm developing code to generate code for storing and rendering sprites and tile categories and tile shapes among other things.  In thinking about tile shapes/solidity, however, I get a stronger impression every time I think about it that the current tile shape mechanism, although cool (with its preview feature), is not the best design.  I think the tile shapes should be "hard coded" into the source code section of the project data instead of being a dialog of its own.  That way people who know what they are doing can still define new tile shapes for their particular project (or copy them from somewhere).  But for the majority of people who can live with a preset set of shapes (like GameDev 1.x did), I don't have to make a mess of the code by allowing custom shapes and allow the possible confusion that only convex shapes may be handled entirely correctly, even though the current dialog allows you to define all kinds of wacky shapes.  I think the code will be a lot cleaner if I skip the step of pre-processing these shapes into arrays of numbers that define the boundaries and just have functions that calculate the boundaries in real time -- I don't think the math for calculating the boundaries of the intrinsic set of basic shapes will be any more complicated than the formula for locating a piece of data in the pre-processed array, so I could certainly save some time and space.  So when I get time, I'll probably remove the tile shape dialog and just hard code the same shapes that GameDev 1.x had.  I might also add shapes that TechnoVenture had (Slow Uphill 1st half, Slow Uphill 2nd half, Slow downhill first half, Slow Downhill 2nd half... and maybe similar ceilings).

But first I have to get through this whole Code Generator mess.  Every line of code I write seems to require me to implement another whole feature first and this results in a whole lot of loose ends to come back and clean up later.  I hope I don't miss any.

bluemonkmn

  • SGDK Author
  • Administrator
  • Fanatic
  • *****
  • Posts: 2761
    • ICQ Messenger - 2678251
    • MSN Messenger - BlueMonkMN@gmail.com
    • View Profile
    • http://sgdk2.sf.net/
    • Email
Re: SGDK 2.0 Status
« Reply #35 on: 2006-04-30, 07:55:57 AM »
I've gotten back to a state where I can generate a project that compiles and now I can see sprites being drawn on the map.

bluemonkmn

  • SGDK Author
  • Administrator
  • Fanatic
  • *****
  • Posts: 2761
    • ICQ Messenger - 2678251
    • MSN Messenger - BlueMonkMN@gmail.com
    • View Profile
    • http://sgdk2.sf.net/
    • Email
Re: SGDK 2.0 Status
« Reply #36 on: 2006-05-07, 07:37:43 AM »
I think I'm on a path that leads to a reasonable solution now.  The map editor will allow you to define coordinates for a plan (points in paths or corners for rectangles) and store them all in the same kinds of generic "plan" objects.  But it will not try to allow you to define all the rules associated with a "plan" on the same screen.  I will leave the specific rules to another screen.  I have the map editor allowing me to display and add coordinates to paths.  Now I am proceeding to complete that work, allowing coordinates to be selected and moved, etc.

bluemonkmn

  • SGDK Author
  • Administrator
  • Fanatic
  • *****
  • Posts: 2761
    • ICQ Messenger - 2678251
    • MSN Messenger - BlueMonkMN@gmail.com
    • View Profile
    • http://sgdk2.sf.net/
    • Email
Re: SGDK 2.0 Status
« Reply #37 on: 2006-05-10, 06:05:26 AM »
I got the path and coordinate editing working reasonably well now, but haven't gotten into the Rule editing for the paths yet.  As I was adding the paths to the main project tree, something occurred to me about the way I was handling data in memory.  First of all there were some problems/errors in the way I was detecting changes, so I fixed those.  But I also realized that I can use the .NET DataSet object to track all changes that have occurred since the file was loaded.  But in order to do that I have to eliminate some of the "AcceptChanges" calls I am doing throughout the code, which makes the changes permanent in memory and discards the information about where changes have been made.  If I can manage to keep that change information around, then I could allow multiple people to be working on different areas on the same file at the same time, and when they save, their changes could be merged if they don't conflict with each other.  So I'm currently trying to eliminate by extra "AcceptChanges" calls so that I can use the .NET data change tracking information for something useful.

bluemonkmn

  • SGDK Author
  • Administrator
  • Fanatic
  • *****
  • Posts: 2761
    • ICQ Messenger - 2678251
    • MSN Messenger - BlueMonkMN@gmail.com
    • View Profile
    • http://sgdk2.sf.net/
    • Email
Re: SGDK 2.0 Status
« Reply #38 on: 2006-06-05, 05:05:15 AM »
Rule editing for sprite plans works at a basic level now. Eventually I'll have to fill it out by adding more functions, but that's just adding code to the PlanBase base class (which any user can do at runtime).  The framework is there.  Oh, I'll also have to add support for listing more parameter types.  Right now all it will help you with is a parameter that accepts a sprite (it will list all the sprites on the layer) and a parameter that accepts a point (it will list all 1-coordinate Sprite Plans on the layer).  I will also want to be able to list sprite categories and other Sprite Plans.  And eventually I'll want to add a wizard to help ease the process of creating common plan types.  Right now the parameters are a bit cryptic because they list the values in the form that the actual generated code will represent them.  The name of the target object is contained in there, but it might be nice to have a wizard to combine a number of steps into a simpler process with simplified object names.  Also, I'm not sure yet how to handle integer parameters since there are so many in a project.  I don't want to list every parameter of every sprite.  So I'll either need to work that into the wizard somehow or make a "sub-wizard" that can be launched for each integer parameter.  Or maybe the dropdown lists can be smart enough to only show parameters of sprites that are passed in one of the other parameters.

So the next step, now that sprite plans are basically functional, is to go back to sprite definitions and make the rule system for sprite definitions work.  What are these Sprite Plans and Sprite Definitions you ask?

1) Sprite Definition: Contains all the information about a type of sprite.  This includes the user-defined parameters that this type of sprite can have (sprites that follow paths defined in plans will probably need a user-defined parameter to store the index of which point in the path they are currently heading toward).  It includes a list of all the states that the sprite can be in.  It includes the list of frames in each state.  And finally, it includes the list of rules that determine how a sprite moves and transitions from one state to another based on varying input and conditions.

2) Sprite Plan: These are layer-specific rules that determine what can happen to individual sprite instances on a particular map.  Every sprite plan can include a series of coordinates, a set of rules, or both.  It's kind of like a combined GameDev 1.x Path and Special Function merged into one.  These rules don't have to refer to a sprite at all (I use the term "Sprite Plan" loosely, and often just refer to these as "Plans").  I expect that these plans could also control things like the current scroll position of the map, regardless of any sprites.  There is currently no association between a plan and a sprite except that most rules that a sprite plan can use will accept a sprite or sprite category as a parameter, which determines which sprite(s) the plan affects.  Sprite plans can be edited in the map editor by adding coordinates to the plan and chaging their name.  They can also be edited independently to set the rules for the plans and create plans that don't have coordinates.

Now, if SourceForge would stop having random service outages I could continue :-\.  I must just be unlucky in my timing: a few days ago I tried to use the SourceForge secure shell service to upload screenshots for the first time in a couple months, and it happened to be the day that SSH service was out.  Then yesterday I tried to update the SGDK2 source code in SourceForge's Subversion service (for the first time in a few weeks), and it happened to have just gone down yesterday.
« Last Edit: 2006-06-05, 05:19:37 AM by bluemonkmn »

bluemonkmn

  • SGDK Author
  • Administrator
  • Fanatic
  • *****
  • Posts: 2761
    • ICQ Messenger - 2678251
    • MSN Messenger - BlueMonkMN@gmail.com
    • View Profile
    • http://sgdk2.sf.net/
    • Email
Re: SGDK 2.0 Status
« Reply #39 on: 2006-06-09, 10:45:23 PM »
I reached a kind of exciting milestone tonight.  I was finally able to compile and run a simple project in SGDK2 without any help from the Visual Studio IDE or manual steps.  SGDK2 can now generate, compile and run a game without any outside help.  All the project did was sit there showing a still map, but I think this was an important step.

bluemonkmn

  • SGDK Author
  • Administrator
  • Fanatic
  • *****
  • Posts: 2761
    • ICQ Messenger - 2678251
    • MSN Messenger - BlueMonkMN@gmail.com
    • View Profile
    • http://sgdk2.sf.net/
    • Email
Re: SGDK 2.0 Status
« Reply #40 on: 2006-06-27, 05:36:27 AM »
Well, I am now starting to get sprites moving around inside the layers of a map and react to the shapes of the tiles.  Solid tiles and sloped tiles going rightwards are working so far.  I haven't fully tested it yet, though.  I'm not sure how well it will work when the sprite's position suddenly becomes a non-integer (right now I'm only dealing with whole numbers).  I look forward to testing the new half-slope ("y=x/2") tile shapes and a new even more cool shape that I realized was possible in talking to durnurd.  I think we finally have an easy way to support tiles that are solid only when standing on them, and you can jump up through them and land on them!  There are a lot of similar possibilities for other 1-way tiles too.  Can't wait to try them out.  One thing I was impressed with was that the solidity of animated tiles worked as desired on the first try.  I had an animated tile that was designed to be solid when it was showing a visible frame and act as empty when it was showing an empty frame, and right off the bat I was standing on it when it was visible and falling through it when it wasn't.

I've been using some of the Super Happy Funland graphics for testing in a new project.  I finally implemented the import feature in the graphics editor to be able to import all those graphics into SGDK2.  Of course they don't take advantage of translucency, but they're good for testing.  They make for quite a nice test project without me having to spend hours developing test graphics.

Anybody hungry for another pre-alpha release so they can see what it's like so far?

sam

  • Fanatic
  • ***
  • Posts: 303
  • This statement is false.
    • MSN Messenger - samlancashire@hotmail.com
    • View Profile
    • samlancashire.com
    • Email
Re: SGDK 2.0 Status
« Reply #41 on: 2006-06-27, 02:35:05 PM »
me hungry...mmmmmm....pre-alpha release... :)

bluemonkmn

  • SGDK Author
  • Administrator
  • Fanatic
  • *****
  • Posts: 2761
    • ICQ Messenger - 2678251
    • MSN Messenger - BlueMonkMN@gmail.com
    • View Profile
    • http://sgdk2.sf.net/
    • Email
Re: SGDK 2.0 Status
« Reply #42 on: 2006-07-27, 06:05:54 AM »
I've been neglecting this thread.  Obviously I have released another pre-alpha demo since I last wrote (pre-alpha 5).  It demonstrates, among other things, how you can have *tiles* now (not just sprites) that you can jump up through and land on.  Since then I have managed to implement a function to help sprites follow paths defined in plans.

I'm currently working on collision detection.  I have added an "alpha" parameter associated with each sprite frame (next to the "repeat count" or "delay" or whatever I called it).  This allows you to specify how a specific sub-frame contributes to the shape of the overall frame within each sprite state's series of frames.  Let me (re-?) clarify the terminology I've been using since I may have extended it a bit by now:
1) Sprite Definition - Defines the general behavior of the sprite that applies to all maps
2) Sprite Instance - Many sprite instances can exist per sprite definition.  Each instance represents a specific sprite on a specific map and follows the rules defined by the sprite definition as well as the rules defined "plans" in the layer
3) Sprite State - A number of states can be defined in each sprite definition.  A sprite instance knows what state a sprite is currently in, but the definition is the one who defines what that state does/means.
4) Sprite Frame - Within each state are a series of frames that determine how the sprite animates when it's in that state.  Each sprite instance knows what frame its on within the state too.  Each frame has a "delay" or "repeat count" that determines how long that frame will be displayed before moving on to the next frame in the state.
5) Sub-Frame - When a frame sets a "repeat count" or "delay" of zero, it is merged with the next frame.  I have been using the term "Sub-frame" to distinguish these.  Multiple sub-frames come together to forma single frame which is what you see when the game is running (a combination of multiple sub-frames are drawn all at once in a single frame to represent the sprite at that instant).

The alpha level is a number between 0 and 255 and can be read as "pixels above this alpha level in the image should be considered solid for the purpose of collision detection".  A low alpha level (low threshhold) means more solid pixels and a high alpha level means fewer solid pixels (if you have semi-transparent pixels in your frame).  An alpha level of 0 will indicate that a sprite does not have a collision mask and will just perform rectangular collision detection.  An alpha level of 255 will indicate that there are no solid pixels in this (sub-)frame so it does not contribute to the shape of the overall frame.

I've got all the code written.  Now I just have to test it and presumably fix it.

bluemonkmn

  • SGDK Author
  • Administrator
  • Fanatic
  • *****
  • Posts: 2761
    • ICQ Messenger - 2678251
    • MSN Messenger - BlueMonkMN@gmail.com
    • View Profile
    • http://sgdk2.sf.net/
    • Email
Re: SGDK 2.0 Status
« Reply #43 on: 2006-09-02, 03:39:54 PM »
I'm still making good progress on SGDK2.  I noticed that the last pre-alpha (6) that I posted had a problem when riding a platform upwards.  I have fixed that locally by switching the order of the "ProcessRules" call within the ReactToPlatform function (it should be called before checking to see if the sprite has stopped riding the platform instead of after IIRC).  But unfortunately you can't fix that locally unless you directly edit the SGDK2 file in notepad because there's also a problem with the source code editor that limits the number of characters you can enter into the textbox to 32767.  I have remedied these problems locally and am currently working on syntax highlighting in the code editor.  It's looking good.

bluemonkmn

  • SGDK Author
  • Administrator
  • Fanatic
  • *****
  • Posts: 2761
    • ICQ Messenger - 2678251
    • MSN Messenger - BlueMonkMN@gmail.com
    • View Profile
    • http://sgdk2.sf.net/
    • Email
Re: SGDK 2.0 Status
« Reply #44 on: 2006-09-19, 10:48:23 AM »
I'm starting to work on some of the wizards now.  I have a wizard to help calculate the map scrolling size based on the size and position of the layers in the map.  I also have a wizard to set every property of a layer with some more graphical interaction and detailed help.  It too will look at the scrolling size of the map to help calculate a reasonable size for a layer based on its scroll rate and offset.

I'm also working on supporting ladders.  I added some new sprite rule functions to help determine what state the sprite is in and switch states.  I also added one to check what tile is on the layer at the position where the sprite is.  Combining these it is possible to define rules that allow the player to be in a "climbing" state when there is a ladder behind the player (and automatically switch back to a normal state if they leave the ladder).  Then when I started thinking about how to incorporate that into a wizard I realized that checking the tile number in a sprite rule could be problematic.  What if the sprite is sometimes on a layer that uses tileset "Main", and other times on a different map's layer that uses tileset "Alternate"?  What if tile #100 on layer Main represents a ladder, but tile #100 on tileset "Alternate" is something completely different.  Defining a rule that allows the player to climb on tile #100 would be a problem in that case.  Then I noticed the same problem might exist with tile categories.  A tile is in a category based on the index of the tile in it's tileset... what happens if you use the same category on a different tileset?  Maybe it would work correctly, but it wasn't clear to me the way things were designed.

So yesterday I spent a few hours doing a little bit of re-work in the framework.  Now a tile category can include tiles from multiple tilesets in a smart way.  As it turns out, the runtime/generated code didn't really change, just the design time interface.  Categories are relatively simple at runtime (they have to be to be fast).  Allowing the category to be aware of tiles in multiple tilesets allows me to create a function that takes a category of ladder tiles and return true if the player is on one or false if not.  The category can include ladder tiles from all tilesets so it doesn't have to worry about the sprite being on different layers with different tilesets.  Other good things that came out of this:
* You don't have to re-create the same categories for multiple tilesets, and make multiple sets of rules if you want your sprite to interact with the same kinds of tiles from multiple tilesets.
* Solidity doesn't have to be defined by tileset because now when you reference a tile category from your solidity definition, it applies to a category that can encompass all tilesets.  So solidity definitions are simplified.