Jump to content


  • Posts

  • Joined

  • Last visited

  • Days Won


Everything posted by 8DashP

  1. Just noticed that the z-index is in the object_refs. Is this the z-index for drawing the individual sprite components? Since the painting happens in the timelineKeys, by which time the object_refs are passed, I've had to add the z-index into the Timelinekeys, and do a copy in the keyFromRef() function. Am I missing something here? Russell.
  2. Good question. I've been wondering myself about the transition when swapping between animations. It would seem there needs to be some sort of tweeting process between the exit positions and one animation, and the entrance positions of another. Almost need an inter-animation, animation and timeline. Russell.
  3. Looks good, great stuff. It's the kind of thing I'll be looking to do when I release my Shiva plugin, so users have a reference model to start with. I'm no artist though, so I reckon mine will be a lot worse than yours. Maybe I'll go with "stick man" :) Russell.
  4. I was actually in the middle of trying to implement this in my own code for exactly the same reason, to overcome performance issues of trawling through the whole set of animation keys to try and build a unique list of images used for a sprite, instead of pre-loading the whole SCML data, which may not be used in a game. Is this structure pretty much set for future use, or likely to change? Also, I assume checking for a type of "sprite" is sufficient to load this data set? Finally, do you have the full structure of this type? Is there only one per sprite, listing all folder/files for that sprite, or multiple, in which case, what does each represent? *EDIT* Actually, just looking at this, I'm slightly confused what the "name" in the example above represents. I was hoping it was the entity name, but it seems to match the name of an object_ref and a timeline? I've just run through all the object_refs, loading the folder/file combinations, which is probably sufficient, but still, a little more info would be good. Thanks. Russell.
  5. OK, I'm up to thinking in detail about how to implement my runtime classes. I was still hoping to get away with just pointer references to the base animation data, but it seems to cater for future functionality, the base data should be treated as static. I'm a bit concerned about performance when creating a copy of the base animation data tree, for every new runtime Entity, as that's no an insignificant number of levels of data to copy. I know most of it is simple numbers and a string or 2, but when you have animation->mainlinekey->bone/object refs & animation->timelines->keys->, that's quite a bit of iteration for each copy. If you consider in a shooter of some kind, if you have animated projectiles, then you could be creating 5, 10, 20 new runtime entities each second, all with their own independent animation data structures. This may be the edge case, but as plugin developers, we need to cater for the worst-case scenarios. Do yo have any actual data around issues with this approach, or is it still the great unknown? I guess my safest path while developing is to put the most flexible code in, at the cost of performance, and look for optimisations down the track when hard data is available.
  6. Me again. Question on time values now. There's a mixture of Float and Int in the pseudo code, mainly around interpolating time values and animation time. This of course is giving C++ a heart attack of warning with float<->int conversions. Now, I could explicit cast them all, but I think time is in milliseconds, right? So why would float values ever be needed. The only place I can find is an interim calculation when interpolating from one time to another, but the end result should be Int anyway. So, is there some reason all the floats shouldn't become Ints? Thanks. Russell.
  7. Thanks for the clarifications. I don't want to be annoying by continually pointing out stuff you already know, so I'll try to keep my clarifications to things confusing me. As such, one other minor question. In the mainlineKeyFromTime() and keyFromRef() methods, you are passing in "time" and "newTime" parameters, but in both functions, you only use "currentTime". I'm assuming currentTime should be replaced with the appropriate parameter? *EDIT* Something else I just found. The function GetTWithNextKey() has a parameter of NextKeyTime, which is unused. I assume since you can get NextKey.time directly, then this is an unnecessary parameter, or do you want to disassociate the nextkey time from the nextkey key? Thanks again. Russell.
  8. Thanks. That clears things up a bit. I guess I've been trying to conserve time and space by loading the whole .scml into a memory structure initially, but then not making copies of the file data at runtime, but seems that's not realistic. I'll have to keep my base version for reference, and then create runtime versions of at least the entity structures with their own control data.
  9. So Mike, in another post, you said entities and character maps are not related. But isn't an entity a single character? In the case where there are multiple entities in a single ScmlObject, the current definition has the default character info at the ScmlObject base level. Wouldn't you want your default character info assigned to a given entity instead? Character Maps, while I can see them being distinct from a given entity, still seem to be too generalised at the ScmlObject level as well. You may have the situation where you want a single entity but mapped to different charactermaps of the same entity, or even a mix and match where some versions are the same, and some are different. The current format of the CharacterMap & MapInstructions data does not seem to cater for different combinations of entities and maps. And while I'm here, on a slightly related matter, the current// fields at the ScmlObject level also seem slightly misplaced when considering multiple entity/animations running at the same time. I guess they could be used and swap the values between every update, but it would seem simpler to either put them down at the entity/animation level, or disassociate them directly from the reference structure, and require the implementer to implement them externally in a runtime structure, instead of in the fixed structure of the definition. Does that all make sense? I'm just really trying to get a good solid structure down first this time with my rewrite. After starting with the generic C++ implementation last time, and then having to modify it to bits to work with Shiva, it became a real mess. So I'd like to get it down as lean and efficient this time around, as I don't want a 3rd rewrite. Thanks. Russell.
  10. Hey again, Found several other issues with the doc, that I won't bother going through currently, as I know you are still working on this. One question though. As I'm refactoring my old code, I see there is a lot of stuff missing from the doc above, that was in the original file spec provided way back when. Since I already have code that has these additional values (such as pixel_art_mode, all of the extra file fields for atlas, offsets etc etc) am I safe to keep using the code I have, or are you likely to redefine the spec so those features change or are no longer usable? *EDIT* OK more questions. Trying to implement the XML load for the Timeline Keys and having a hard time deciding on what the structure should actually be. The whole TimelineKey pseudo-code section seems messed up. I realise it isn't supposed to be direct C++ code, but it's close enough that trying to fit it should be easy, however there are big discrepancies with the XML definition. The biggest question I have is whether the bone and object attributes are a hierarchy under the key attributes, or simply alternate versions of the 3 (or 4?) different types of keys. If they are a hierarchy, then really the TimelineKey definition should have them as sub-classes, acting as members within the TimelineKey class. That however will mess up the pseudo code for the other functions that do the updating. The alternative, trying to keep the TimelineKey as a base class, from which the others are derived, is going to require some fancy footwork to store a list of void pointers and then typecasting operations on them to find out the appropriate operators. The Timeline has an array of Timelinekeys to store the data, but looking at the XML, it's a 2-level structure, not a single level, even though by virtue of making all the keys inherited classes, it represents a single object structure. Looking at the sample file, it appears there is only one ever "sub-key" underneath the key entity. If this is always true, then maybe just a type specifier for the key, and collapsing the hierarchy down to one "key" level will suffice. Can we rely on only a single sub-key element type with each key element? A minor but significant point while I'm here, is that the spin attribute is in SpatialInfo, which is not part of the TimelineKey structure, but the XML attribute is part of the TimelineKey structure. All very confusing to try and implement consistent with the definition. Thanks. Russell.
  11. Hey, I'm rewriting my implementation to use your definitions here, so I'm just starting converting this to C++ code. I note the current doc had most of AzureBlaze's fixes, but you seem to have missed this one. And as per what sonder says, having some issues getting the pseudo code mapped correctly, as it seems in multiple places you are referring to a TimeLineKey and expecting it to have a .info member, but that only exists in a SpacialTimelineKey, so I'm having to do a bit of decrypting to figure out the correct class usages, as I don't really want to throw upcasts() in there if not necessary. If you could have a look at the updateCharacter() method and clarify key usage a bit, that'd be good.
  12. I've been on a long hiatus from development, and haven't updated my Shiva3D implementation for about 6 months. Now that I'm about to start again, how much different do you think the docs above are, compared to the current implementation? Do you have an ETA on an update? Should I wait, or go ahead an try to figure it out myself?
  13. Just an update on my own questions since I've progressed a little bit. 1. I have added a vector list of data_object pointers to keep the data object as an external reference. Not sure, but I might be able to remove this a a later date. 2. I've updated the entity::load functions to split the "entity" index value, into entityID, and data_entityID. This allows me to keep the original ID in the SCML file, pointing to the direct SCML info, but use an incrementing index into the "entities" vector as the actual entityID field in the "Entity" stand-alone class. This was fairly easy, and I think should give me a unique index for multiple file loads, across the whole application. 3. This one I'm currently struggling with, as it is used widely across the code, and during updates. From what I can see at the moment, the folderID/fileID is assumed to be unique across the app, which is obviously not true once you load more than one SCML file at the same time. Given the folder/file is associated more with the SCML data file than the Entities themselves, it's a bit trickier deciding how to uniquely identify these across data files. I am assigning an SCML ID for each file loaded, so I'm thinking the best bet at the moment is to add the SCML ID as an extra field in the FIlesystem class, and use that in combination with the folder/file ID's to create uniqueness, but this will be more work. I'm not 100% committed to that yet, so I'm going to give it some more thought. If anyone else has any other ideas, I'd love to hear them.
  14. Just a quick update. I have added multiple administrative type functions to set/get entity names, id's etc, modifying the overall scale and z-distance of sprite components (issues in 3d with perspective cameras and z-fighting make this necessary) and the ability to parent a spriter sprite to any 3D object. The spriter animation will them match the parents translation/rotation/scale to the scene object. There may still be some gimbal lock issues with rotations. I have to continue testing. I need to make some spriter animations with gater than 90 degree internal rotations to test. Trying to put multiple 2D images into a 3D scene as a single game object is not without it's challenges.
  15. Now I've got the basics of loading a single SCML file and texture atlas done, I'm expanding my APi to multiples of everything - files/entities/animations. I notice in your SDL main, you push all 3 SCML files onto the data file stack, but only render them one at a time, clearing everything between selection. Have you considered what is necessary for loading multiple SCML files at once, or even jus if/when Spriter gets multiple entities in the one file? It looks to me like there would be a couple of things needed :- 1. The Data object is only needed at load time, isn't it, and the actual data SCML ends up stored in the "list entities" list? So to load multiple SCML files at once, we would need to clear out the Data object and keep appending to the entities list? I'm still trying to see how the FIlesystem fs object links in, but I think we need a separate instance for each set of entity images, don't we? *EDIT* after looking closer, I see the stand-alone Entity class constructor is referencing a Data object, so we need to keep a reference to all Data objects until we are no longer using them? In which case, I guess there needs to be a vector list of data objects created, and indexes used to reference where appropriate? 2. If loading multiple SCML files, the Entity ID's are going to duplicate, so we would need to be able to add some form of uniqueness to the ID's. Not sure if the SCML data itself will provide enough uniqueness, via the name/ID combo, or maybe SCML filename, or whether it would be better to just add a run-time unique value. 3. I'm currently identifying my in-game assets using the folderID/fileID for uniqueness. This is not sufficient for even more than one entity, let alone multiple files, so some unique identifier needs to be added here as well. Any other thoughts on things I should look out for in trying to implement multiple files/entities? Thanks. Russell.
  16. Thanks to Grimfang for all his work on the C++ implementation, I've managed to create a plugin for the Shiva3D game engine. It still needs a lot of polish internally before it's production ready, but it is actually working as is, and works optimally, creating only 1 draw call per entity, using Shiva pre-loaded resources, consisting of an SCML file (renamed extension .xml so it loads as a Shiva XML resource), and a TexturePacker atlas & data file. It is currently using internal atlas management, as the Spriter atlas data is not available yet. As coping with the way Shiva handles loading resources and drawing has forced me to make numerous modifications to the C++ SCMLpp files, I thought it better if I split further discussion on Shiva into this separate topic, so I don't pollute the C++ topic. I still only have my original video to show. When something more concerte is available, I'll update. If any Shiva developers have any questions or comments, feel free to ask. Russell.
  17. @grimfang Slight update on this one, because I am doing some stupid testing and hit a problem. For edge cases, where a directory is being passed in that isn't actually a directory, this line will fail without a dirname with a '/' in it. So a little extra validation gives us :- SCML_STRING dirname(SCML_STRING source) { unsigned found = source.rfind('/'); if (found!=std::string::npos) { source.erase(found, source.length()); return source; } else { return ""; } } I think that's what it should be doing, you might want to double check. There will still probably be errors further along if you do something silly like I am, but that's an internal issue. This fix fill just stop the erase failing. Russell.
  18. Yeah I'm afraid I'll be changing SCMLpp a bit to fit Shiva, which is unfortunate. I'm not sure how long I'll be able to stay in sync with your updates. I've already had to adding begin-load and checkLoadStatus functions as shiva needs frame cycles to do external stuff, but as that is Shiva specific, I didn't mention it before. I'll continue to make suggestions where I think I find something generic though.
  19. That should be good for file complexity. I could probably get by with it as is, but because Shiva works implicitly with internal resources, and has its own xml functions, it just ends up being easier if I make all resources loaded at build time instead of runtime, although I will try and keep the runtime option for those who want full flexibility. So, I guess I'm not completely replacing it, just making the shiva internal XML the default, recommended method, so I'll have two processing flows within my code. Man, there sure are a lot of references to TiXML elements that I have to refactor :)
  20. Nice vid, best explanation of Spriter I've seen yet. Given I'm still in XML land and haven't used spriter really yet, the only newbie question I really had after the vid is, is there an easy way to centre the pivot automatically? There may have been a button, but I couldn't tell from the vid, otherwise it seems to have covered all the basics.
  21. Yeah I'm using a Mac, and it was brain dead simple. Built in svn client, and the Doxygen client I used worked perfectly, although I'm getting more understanding just browsing the code as I go through making my changes. For my work, i also just dragged all the required files into one directory, ss really TinyXML is the largest fileset, and even that I m replacing.
  22. Eh, OK. So is there a new version of the hero available? If not, this should be removed from the repository. Also, maybe the Spriter import should reject a bit nicer than CTD? :)
  23. Is the "hero" example supplied with this project supposed to load in A4.1? I just tried and it's crashing Sprite. The other two examples work. I did note other forum posts on issues with the Hero example, something about old file format? The XML data says it's generator version a2, which is the same as the monster. Any ideas why it isn't working?
  24. OK I have the basic functionality of loading an SCML and playing it working now. Here's a short vid of the example file playing in the Shiva IDE. I just set looping to true always for now.
  • Create New...