Author Topic: SGDK 2.0 Status  (Read 293468 times)

cbass

  • Expert
  • Regular
  • *****
  • Posts: 97
  • script this
    • View Profile
    • Squest RPG
Re: SGDK 2.0 Status
« Reply #45 on: 2006-09-25, 04:31:57 PM »
sounds like a good solution.  I like the idea of keeping more stuff global instead of properties of a tilsets/layers/maps.

You going to stay with 256 tiles per tileset or up the maximum to 65536? (or somewhere in between)

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 #46 on: 2006-09-25, 05:12:28 PM »
sounds like a good solution.  I like the idea of keeping more stuff global instead of properties of a tilsets/layers/maps.

Oh, you're gonna love it.  The best part is that sprite definitions are global, so you can use the same type of sprite on any map and layer without having to re-define it on each map.  But you probably already read about that.  And sprite categories are global, so collision tests and platform interactions can be defined globally.  There's also a "Global Map" which you can use as your inventory display -- it gets drawn in front of whatever map you're playing on and allows you to create "rules" (and draw graphics) that are applied regardless of which map you're currently playing on.

You going to stay with 256 tiles per tileset or up the maximum to 65536? (or somewhere in between)

No more 256 limit; if you look at the pre-alpha demos going all the way back, there's a "Bytes Per Tile" setting on each layer that allows you to determine how many bytes each tile takes on that layer.  If your bytes per tile setting is 1, then yes, you will be limited to using the first 256 tiles in the layer's tileset.  But you can also set it to 2 bytes (which I think gets you 32768 because I think it's using a signed integer) or 4 bytes (which gets you over 2 billion, but I don't know who'd need this).

On to new developments:
I just finished my initial pass at a Sprite Import wizard.  I think this will be the primary means of creating sprites in a user friendly way.  Before I had this idea, I was trying to work out various kinds of wizards for various kinds of sprites and then remembered/realized my plan of using templates to create sprites.  So now there is an "Export sprite template" command on the sprite definitions window.  Anyone can use this to create a file that contains just the data needed by the current sprite definition.  That is:
  • Sprite Definition itself (the name)
  • Sprite States
  • Frames in each state
  • Sprite Parameters (just names again)
  • Sprite Rules
  • Frameset(s) referenced by all sprite states in the sprite
  • Graphic Sheet(s) referenced by those frameset(s)

So only that data is included in an exported sprite definition.  And when it is exported it is actually in exactly the same format as a regular SGDK2 project.  That means it will be possible to import sprites (and eventually other data) from sources that are created in 3 ways (which all happen to use the exact same format):
  • Exported sprite template files created by the user.
  • Sprite template files delivered with the application.
  • Arbitrary SGDK2 project files.

Furthermore, you can load a template file as if it were a project and edit it.  Using datasets has been wonderful in providing lots of extra features in an easy-to-implement way, and this is just one more example -- transferring data from one project to another and making the file format universal has been so much easier as a result of storing all the SGDK2 project data in a dataset.

As you import sprite definition(s), you can select one or more sprite definitions you are going to import from a single file, and specify alternate names to use for them within your project.  This allows you to import the same definition multiple times and specify alternate names for each definition.  (This is less necessary now that sprite definitions are global to all maps, but I'm sure it will still be a handy feature for different kinds of sprites that follow similar rules.)  Then, if you already have framesets and graphic sheets in the project that use the same name as those that you are importing, you will be prompted with the option to either import the frameset or graphic sheet with a new name (as a new object) or to assume that the already existing object is the same and make the sprite definition use the existing frameset(s) and graphic sheet(s) instead of importing new copies.

The nice thing about this design is that I don't necessarily have to have wizards to create 36-state sprites out of existing graphics.  I can create a single template file that has a 36-state rotating sprite and *includes* its frameset and graphic sheet.  When you import that, it all comes along (if you like) and then all you have to do is edit the graphic sheet to alter the graphic cell to your liking.  (a 36-state sprite will likely be based on a graphic sheet with just one cell which gets rotated into 36 frames by a frameset at runtime).  So you just change the one graphic cell and your whole rotated sprite is already ready to use.  I'm not sure how changing the size of the cells will affect the transforms in the frameset.  I might have to make templates for different sizes in order to get the rotations to center properly.  But I think once again a single relatively simple solution covers a whole lot of use cases... this allows me not only to deliver a wide range of pre-defined sprite types, but anyone can create new types to be used in any other project.  The primary limitations are that any rules referenced by the sprite definition must be compatible between the template and the target project, and you may have to create sprite categories or tile categories with specific names if the template refers to specific tile category names (like "Ladders") or sprite category names (like "Platforms").  But you can put as much or as little as you like into the template as far as rules go.  You can pre-define the sprite to climb ladders in a particular tile category, or you can leave that out and expect the user to define those rules after importing.

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 #47 on: 2006-10-03, 04:47:30 PM »
I'm in the process of implementing support for sound effects now.  Since sound effects and other media can come in such a variety of formats, I decided to implement sound/media and other custom code as a general purpose extension.  Instead of building hard-coded support for sound into SGDK2, I am adding a new concept of "Custom Objects".  A custom object is something that is added to the "Source Code" folder.  It can be imported from a template (such as an "MP3 File" template) or manually coded into the project.  A custom object can consist of a block of source code and/or a block of binary data, which can be imported into the project from any type of file (and will be saved embedded in the SGDK2 project file).  A special type of "custom object" will be added if you end the name with ".dll".  This type of custom object represents a reference to a .NET assembly and cannot contain any code or data.  This allows one to reference, for example, Microsoft.DirectX.DirectSound.dll if they want to use Microsoft's DirectSound framework for playing sound effects.  (Of course there will be a template that includes a reference to this for playing some types of sound effects.)

Custom objects can have dependencies on each other.  For example, the "Example WAV File" custom object might have a dependency on a "WAV File" custom object that knows how to play WAV sound effects.  That, in turn, might have a dependency on Microsoft.DirectX.DirectSound.dll.  Importing custom objects (such as sound effects) will work similarly to importing sprites.  When you import "Example WAV File" from the template, it would also import all the dependencies of that object, and merge them into the project.  If they are already there, they will be ignored.  If not, they will be imported.

Custom Objects could conceivably be used for much more than sound effects.  I forsee these as possibly becoming the replacement for GameDev 1.x's scripted event handlers that you'd find in a VBS file.  Sprite Definition rules and Sprite Plan rules will be able to interact with these custom objects by using interfaces defined in the rule source code files.  For example, if you want to create a new type of custom object "Message" that would display a message on the screen while you play, you might take these steps:
  • Create an interface in PlanBase.cs (the file that defines what rules you can use in Sprite Plans) called "IMessage".
  • Define a method "Draw" on this interface that takes a Point as a parameter.
  • Create a function "DrawMessage" in PlanBase.cs (that's a custom code file that is embedded in the project) that accepts an "IMessage" for the first parameter.
  • Create a custom object "Message" that inherits from (implements) the IMessage interface.
  • In the constructor of this object, load the embedded resource named this.GetType().Name + ".bin" using a .NET ResourceManager (SGDK2 will always compile the binary resources associated with a custom object into the EXE using the name of the custom object followed by ".bin").  This resource could be a string or a bitmap or whatever you want to store your message as.  Loading the resources in this way allows you to load the data associated with any derived object (based on the derived object's type name).
  • Create a function "Draw" that implements the Draw method of the IMessage interface by retrieving the Display object from the global GameForm object and making the appropriate DirectX calls to draw text (or bitmap) directly on to the display at the coordinate specified by the parameter.  Use the data that was loaded in the constructor.
  • In the code for the DrawMessage function in PlanBase, call the Draw method on the IMessage parameter, passing the current plan's first coordinate as the Point parameter.  (This will cause the message to be drawn at the coordinate of the first point in the plan.)
  • Create any number of dependent objects that derive from Draw and specify their own unique messages.  Each of these objects will expose only one member: a static read-only property that returns a global instance of itself (the instance would be created in a static constructor for the class so that each class has exactly one global instance always available).  So the code is very simple -- all the work is done in the base class.  Associate a binary resource (string or bitmap) with each of these objects.
  • Now you can use the the DrawMessage function on any plan you like.  The dropdown list will display all static functions that it can find in the custom object that return an object of type IMessage.  So that's how you easily get a list of all your available messages whenever you choose to use the DrawMessage function.

Drawing a message may be a silly thing to do using custom objects unless you want your message to be represented by bitmaps instead of strings.  But this is a nice example of the flexibility of this system.  And if people (especially me) start creating lots of custom object templates, I think it will be quite a user-friendly system too -- you want this feature?  Import this custom object into your project and you've got easy access to it.
« Last Edit: 2006-10-03, 04:54:50 PM 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 #48 on: 2006-10-08, 08:24:45 AM »
I have started to look into integrating the FMOD Ex API (http://www.fmod.org/) into SGDK2.  Looks like sound support could be really easy from my end -- FMOD has already done most of the work (and even provides a handy C# wrapper).  Anybody out there familiar with FMOD?  It looks like they also have a designer API.  I haven't had time to research yet -- does that mean that I could also integrate some sort of music composing interface into SGDK2 if I wanted to?

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 #49 on: 2006-10-08, 10:31:22 AM »
I don't think the designer api is meant for composing.  It's meant for a sound designer who already has all of the sound assets and needs to mix them and apply effects based on game mechanics during the game.  Basically you just define an event and then take the sounds you have and mix them how you want to in the designer api, then give the sounds and event list to the programmer who implements it in the game.

The designing of the actual sound elements is done elsewhere.

As for licensing, it is obvious that SGDK2 is free and therefore does not require a license to be purchased by anybody.  However, if somebody does want to sell their game, does this mean they would have to buy the hobbyist $100 single-product license first?
« Last Edit: 2006-10-08, 10:35:32 AM by durnurd »
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 #50 on: 2006-11-09, 09:34:21 AM »
Well, sound support with DirectSound and FMOD templates is reasonably well wrapped up (choose the template for whichever framework/technology you want your game to use, or both).  I don't actually have the templates yet, but the test project I have been working on has the code which I can export into templates, and the IDE framework is in place to allow FMODEX.DLL to be referenced/copied/generated from wherever it resides (DLL files can be embedded in the project, or left as files in the project directory or the directory where SGDK2IDE.exe resides, in which case the project file only stores the name of the DLL).

The latest thing I've been working on is Save/Load game support.  It's working out beautifully.  I marked every class whose data needs to be save-able as "Serializable", and then I just use .NET's built-in serialize feature to save the game to a byte array.  There were a couple tricks I used in the process.  For example, the DirectX display object referenced by some objects can't be serialized.  But I used a combination of implementing the ISerializable interface and creating a separate class that implements IObjectReference and ISerializable to stand-in for that object during serialization.  This allows me to override the serialization process for a class to the extent that I needed.  For the display object, I override the GetObjectData method to tell it to use a DisplayRef "stand-in" object during serialization instead of trying to serialize the Display object itself.  The DisplayRef stand-in simply returns the global display instance during de-serialization instead of trying to store anything to the byte array.  I used similar techniques for serializing Tilesets, Framesets and other objects that should not be changing at game runtime (which also reduces the size of the save file, of course).  They just refer to the static instances instead of trying to save their data.

The next thing I did was create a "SaveUnit" class whose purpose is to accumulate information about which information you want to save during your next call to a Save function.  Currently, you can choose to independently include
1) All maps
2) Any counters (you can add all counters and then remove some from the save unit or just selectively add individual counters)
3) An indicator of which map is currently being played

No more do you have to do an all-or-none save/load operation.  You can choose to do a Mario-style save by just saving all the counters and the current map indicator, without saving the state of any maps, for example.  I have not yet determined what kind of individual map selection should be allowed, but I might also allow specific maps to be included in the save unit instead of having to choose all maps or no maps (you might want to save the world map without saving any level maps, for example).

So far it appears to work great and the load/save functions operate instantly (at least in my little test project).  Oh, and another new feature is the ability to save to memory slots.  I actually haven't implenented the ability to save to file yet (I will be doing that shortly).  Right now, the functions are just saving to "memory slots".  A memory slot is simply represented by an integer.  You can save to as many separate numbered "slots" as available memory allows.  So if you want to use the save feature simply to help reset to a prior state, you don't have to be writing files to disk.  Also, you don't need to save a map in order to reset it.  Each map always knows how to reset to its initial state, and you can unload a map at any time which will force it to be re-created in its initial state next time you visit 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 #51 on: 2006-11-13, 07:14:54 AM »
When I said that load/save operates instantly, I hadn't realized just how instantly.  I can hold down the "L" key (which, in my test project, triggers the load function) and it will load the game every frame without affecting the frame rate.  That's a fast load! :)

Anyway, I'm on to the recently suggested additions to the graphics editor.  I'm going to try the random fill first.  Instead of implementing a new "fill" command, I figure I will implement it the way the GIMP does: as a filter.  I intend to create a tool or command that will simulate the behavior of the RGB Noise filter in the GIMP.  This appears to add a random value to the R, G and B component of each pixel (the value is the same for each of the R, G and B components, but a different value is chosen for each pixel).  I'm not sure how important it is to allow the user to specify how much this value can vary.  I would like to just pick some reasonable value and hard code the tool at that value instead of creating a whole new UI just to allow the user to specify the range for the RGB noise.  Maybe I'll make it a custom tool.  Oh... or maybe it would make sense to vary the value based on the currently selected alpha level... that kinda makes sense.  If you have a lot of alpha, the noise will affect the image a lot (lots of variation).  Small alpha will only affect the image a little (small variation).  I think I'll do that.

Another thing I was thinking about was making the custom tool code be something that can be updated and re-compiled at runtime, instead of having to download the source code and recompile all of SGDK2.  Then I could create RGB Noise (or anything else) as a custom tool, and if you wanted more or less noise, you just go to the custom tool code and change a number.  I'll have to try that... would be much more convenient than having to recompile SGDK2.

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 #52 on: 2006-11-15, 06:52:19 AM »
I had a productive evening yesterday.  I managed to implement both the "Add Noise" feature and the "Remap Hues" feature.  Both are working well.  Looks like I forgot about the hotkeys -- that should be the easy part.  Then maybe I'll move on to implementing more export/import support for graphics/tilesets.  You can already import and export graphics as PNG, but I think I still need to allow import/export between projects/templates.

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 #53 on: 2006-12-02, 06:15:56 PM »
I think I've finished implementing multi-player support, at least to the extent that I'm going to implement it for the initial release of 2.0.  I added a menu bar to the run-time form where the game is played.  So in windowed mode, you can access the menu to customize the controls for up to 4 players.  Each player can use either the keyboard or any gamepad or joystick that Windows knows about.  And if they use the keyboard, of course you can customize the keys.  This is a step better than 1.x in which you had to define the keys at design time and there was no standard multi-player support (you had to write a script and handle everything about the second player manually).

In the project settings window at design time, there are two new settings: Maximum Players and Maximum Views.  Maximum Players determines how many players are in the dropdown list on the Options dialog at runtime (and that's all it affects.  Most of the multi-player support is handled by what rules you choose to create in your game).  Maximum Views determines how many different views there are for each map.  For example, in a 4-player game you can have all players in one view, and make sure none of them can leave that view, or the view can be divided into 4 areas, one for each player.  (Or you can have 2 views each with 2 players; arrange it however you want).  The maximum number of views just lets the template code know how many views to manage for each map.  Then you can define your rules to select any of these views as the current view to perform scrolling on it.  Furthermore, at runtime, your rules determine how the views are laid out.  You can have 1 single view, 2 side-by-side views, a top and bottom view, or 4 quadrants.

Implementing the subdividing of the views complicated the scrolling a bit because when the view is smaller, it turns out, a layer that scrolls at a rate of 2 can show slightly more tiles than it can in a larger view.  But I think I did the best I could in the wizards and I adjusted the way that the map's scroll width and scroll height are defined.  So now for the most part it should behave pretty well with respect to making layers the right size to fill the map or finding the right scroll size for the map in order to reach the edges of the layers (these are functions of the wizards).

I updated the sample project I decided to try a split top and bottom view with two similar sprites in the top view (forced to remain within one screen of each other) and a ship in the bottom view.  I can press 1 to switch to single-view 1 player mode, 2 to switch into single-view 2 player mode (the two similar sprites), and 3 to switch to split screen 3 player mode.  Things seem to be working reasonably well.  The bottom half is scrolling independently from teh top half, and as I switch between the number of players (all determined by the way I defined my rules -- not hard coded) I see the screen re-arrange itself and sprites get removed or added for the extra players.

I'm not planning to support network play in the initial release of 2.0, but I expect it would be easier to make a networked game in 2.0 than it was in 1.x (and there was a demo of a network game in 1.x).  Could it be as simple as creating a new kind of player besides keyboard and joystick?  If you don't mind the possibility of synchronization problems (both players picking up the same item at the same time), maybe.  And I suspect it's all possible just by changing the custom code embedded in the project.  No need to change the SGDK2 IDE code.  I'm pleased that so many of the features are so largely contained in the customizable project code.  It means that projects in SGDK2 will be very flexible.

There are just a few details to clean up on multi-player support and then I move on to other clean-up and testing.  I have to improve the default keyboard settings when you switch a player from joystick to keyboard control.  Right now they all just default to settings similar to those in version 1.x, but I should make each player default to their own set of keys.  (Right now, BTW, player 1 defaults to keyboard, and player 2 through 4 default to whatever game controllers are available, all to the same one if only 1 is available.  If none are available they default to 4 different keyboard layouts.)  Then I have to make it possible to save the player settings when the game is saved.

tprime

  • Fanatic
  • ***
  • Posts: 395
    • View Profile
    • Email
Re: SGDK 2.0 Status
« Reply #54 on: 2006-12-08, 10:20:02 PM »
With SGDK, would Game Developing be easier, or harder. And would it be more easier to use for beginners? ???

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 #55 on: 2006-12-09, 08:23:08 AM »
You mean comparing SGDK2 to version 1.x?  I don't think creating a simple game will be much easier, but a few things will be easier, and much more will be possible without extra work.  For example, it will be much easier to create a 2-to-4 player game in SGDK2 than it was in version 1.x (I just finished the features to support that).  Creating a game with a complex set of sprite definitions shared accross maps will be much easier in SGDK2 because you won't have to re-create them for each map like you did before.  It will also be much easier to place new sprite instances and edit existing sprite instances on the map because you don't have to switch between the map editor and the sprite editor to do it, and you don't have to have a path for every sprite.  You just click a sprite on to the map like you do with a tile.  And some things that you can to with SGDK2 were just completely impossible/impractical in version 1.x: translucent sprites, real-time sprite color adjustment, compiling the game to machine code instead of intepreted code (optimization/speed enhancement), the ability to write custom code in C# and directly access DirectX instead of being restricted to VBScript (now you could draw arbitrary shapes on the display, or maybe even indroduce some 3D models into the display), .

In the end it will be up to users to tell me what's hard and what's easy, though.  As the developer, it can be hard for me to see SGDK2 with an inexperienced eye, and hard to see how hard and easy certain tasks are to learn.  What I can tell you is that many of the tedious tasks for an experienced user of version 1.x will be simplified for an experienced SGDK2 user.

tprime

  • Fanatic
  • ***
  • Posts: 395
    • View Profile
    • Email
Re: SGDK 2.0 Status
« Reply #56 on: 2006-12-09, 07:31:18 PM »
How much of the program is done? (Percentage) :)

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 #57 on: 2006-12-10, 05:11:55 PM »
I'd guess about 90% now, but it's hard to say.  I'm about ready to switch the current status of the project to "alpha" instead of "pre-alpha" indicating that the main coding is mostly done any my primary focus now is testing and developing samples, templates, art libraries and help content.  Of course, I may still do some more coding as problems and ideas come up during testing.  But the program is pretty much in a state where developing games is possible now, I think.  Of course I haven't developed any complete games with it yet, and I'm sure I'll come up with some more coding as I test developing my first real project with it.  The 90% figure might be a good estimate on design and coding, but that may only be about 60% of the overall work because there is going to be a lot of effort put into developing help content, graphics and sounds libraries and template/sample projects.  But I hope to get some help in this last phase, especially from Orion Pax (hint, hint :)).

bluemonkmn

  • SGDK Author
  • Administrator
  • Fanatic
  • *****
  • Posts: 2761
    • ICQ Messenger - 2678251
    • MSN Messenger - BlueMonkMN@gmail.com
    • View Profile
    • http://sgdk2.sf.net/
    • Email
Decapsulation
« Reply #58 on: 2007-01-02, 06:43:47 AM »
I've come up with an interesting term for a new feature I added over the weekend to help improve code reuse in templates.  The term is "decapsulation".  I have this file "fmod.cs" embedded in the sound library projects that has a couple hundred KB of code for wrapping the functions provided by fmodex.dll (the sound framework provided by FMOD).  And I want to use the functions in that file from every template in the sound library without having to create separate copies of it in each one.  So what I ended up doing was allowing the file to be "decapsulated" into a separate file called (for example) fmod.cs outside the SGDK2 file.  Then the code of the "fmod.cs" file that is embedded into the SGDK2 file simply reads:

~import "fmod.cs"

(you can also use relative paths -- relative to the SGDK2 file).  This causes SGDK2 to read the contents of an external file whenever the fmod.cs dependency is imported.  The final project (result of importing from templates) will still be entirely encapsulated because the file is embedded into the SGDK2 project as it is imported, but now the templates have the ability to share objects.  I did a similar thing for graphic sheets in case there are (for example) a number of sprite library templates that want to share the same graphic images.  There is a "decapsulate" button on the Graphic Sheet manager that prompts for a relative path to an external file.  If it already exists, it will delete the internal graphics and refer to the external file (which must be .PNG).  If it doesn't exist, the file will be exported and then the internal graphics will be deleted and replaced with a reference to the external file.

Currently those are the only two objects that support decapsulation.  Those seem like the biggest kinds of components with the most need for "decapsulation".

The creation of the sound/music library is going well.  Now I have to wait for SourceForge to respond to my support request.  It seems they have recently broken the ability to rename items in the Subversion tree, and I really need to rename my "Music" library to "Sound" since I am going to put a sound effects library in a single file in there too.

Oh, I also haven't mentioned yet that I have a feature that automatically imports the credits from a template (such as a music library) into the project when you import any item from the template.  That's why decapsulation was important.  I didn't want to just create one huge music library file because I wanted to provide separate credits for each library.  When you import a piece of music by "Ceekayed", only Ceekayed's name should automatically be added to the project's credits and not the name of every composer in the music library.  Of course the credits are editable so you can fine tune them, but I wanted some automatic system so that even those who aren't paying attention are giving proper credit where it's due by default.

mccool

  • Regular
  • **
  • Posts: 48
  • That's like trying to eat a burrito with no fork!
    • View Profile
Re: SGDK 2.0 Status
« Reply #59 on: 2007-01-03, 02:51:03 PM »
i know you cant really say for sure, but how long will it be till its done? i have a really good idea for a game but i dont know if i should wait till sgdk2 comes out.
Old Skool!