[Ohrrpgce] SVN: james/3865 Reload editor also browses for *.editor
james 2010-10-10 22:44:57 -0700 (Sun, 10 Oct 2010) 40 Reload editor also browses for *.editor --- U wip/browse.bas ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
[Ohrrpgce] SVN: james/3864 Reload editor and both browse for and export filenames *.reld *.reload *
james 2010-10-10 22:32:10 -0700 (Sun, 10 Oct 2010) 236 Reload editor and both browse for and export filenames *.reld *.reload *.slice *.rsav File browser is smart enough to tell the difference between valid and invalid reload files. "." is no longer a forbidden character in inputfilename() --- U wip/browse.bas U wip/customsubs.bas U wip/ohrhelp/reload_editor.txt U wip/reloadedit.bas ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
[Ohrrpgce] Fwd: Sprites, animation food for thought
Yikes, I fail at email forever. This was meant to go to the rest of the list. -- Forwarded message -- From: Mike Date: Sun, Oct 10, 2010 at 11:35 PM Subject: Re: [Ohrrpgce] Sprites, animation food for thought To: Seth Hetu (Oops, I figured it would. Thunderbird claimed the email didn't send the first two times) Anyway, yes. As I mentioned below the relevant snippet, each frame in an animation can have its own delay. deftime simply specified the default delay for that animation as a whole. -- Mike Caron -Original Message- From: Seth Hetu Date: Mon, 11 Oct 2010 11:32:41 To: ; Subject: Re: [Ohrrpgce] Sprites, animation food for thought 3 times, but nevermind that. I've got a question about animations. Is it possible to add a "delay" value, which delays the next frame in the animation? Like: > > > stand-down > > > stand-up > > > stand-right > > > stand-left > > Then the person remains standing for 3s longer than the other directions? The reason I ask is that I like your idea of defining the animation by "wrapping" a PNG sheet with XML. So maybe it would be possible/easy to add more tags and options to an animation to increase its power. Then, it's all described in the XML+PNG combo, which makes it really easy to edit external to the OHR. Just throwing out ideas, since your first email seemed to encourage it. Cool system overall. -->Seth On Mon, Oct 11, 2010 at 2:01 AM, Mike wrote: > Shoot, if this email went out multiple times, I apologise. > > If not, please disregard this. > -- > Mike Caron > > -Original Message- > From: Mike Caron > Date: Sun, 10 Oct 2010 13:37:53 > To: > Subject: Sprites, animation food for thought > > First off, a disclaimer: This is not an actual proposal for a data > format for the OHR. This is something I've cooked up for another project > which may or may not ever see the light of day (hopefully, it will, but > it's immaterial to this discussion). > > This is how I've implemented sprites and animations in this other project: > > First, all pixel data is stored in sprite sheets. These are PNGs that > contain all the sprites for a given on-screen entity. Technically, as I > am writing it in .NET, nothing is stopping them from being BMP or JPG or > something, but I prefer PNG for its true-colour and transparency support. > > Then, with each sprite sheet, there is an XML document that describes it: > > http://mike-caron.com/za"; name="link1" file="link.png"> > name="stand-down" /> > > name="walk1-down" /> > name="walk2-down" /> > > > > Each frame has a name, a position and size on the sheet, and an origin. > The origin is aligned up with the actual entity's origin (which, ATM is > always their (x,y) position, but that may be customizable later on) > > Then, after the frame definitions, we have the animation definitions: > > > This is mostly self explanitory. Every frame has either one or four > directions defined, depending on if the sprite has meaningful directions > (an item on the ground, for example, probably only has one direction. An > NPC, on the other hand, will have all four). > > Each frame in a direction can have a time parameter, which describes how > many ticks the frame is displayed for. deftime is just the default such > value. Obviously, as well, if loop is yes, the animation will start from > the beginning. If no, it will just stop on the last frame forever. > > Finally, every entity in the game references both a sprite sheet and an > animation. The idea is that you could change one or the other. For > example, if you get a better shield, the sprite sheet changes from > "link1" to "link2". And, obviously, the animation changes based on what > is happening in the game. > > A few notes on this structure: > > - There is no accounting for palettes. If you wanted to use a paletted > sprite, then by all means you are able, but don't expect to be able to > change that palette in game. The canonical way to add palette swaps is > to have a different sprite sheet with the same animations (and, I may > add some way to automate this. Eg, "this sprite sheet is exactly the > same as this other sprite sheet, so use those definitions") > > - There is also no way to get any fancier animations. I.e, there's no > way to automatically oscillate or go backwards or whatever. The way to > achieve these effects would be to duplicate the frames in the animation. > - I may or may not add sprite flipping. > > - The way the images are laid out on the sheet has absolutely nothing > to do with how they are animated or displayed. If you wanted the same > frame, but offset by 5 pixels or whatever, you just modify the origin. > No muss, no fuss. > > - Also, there are no inherent limitations on how large or small the > sprite is. If you want to make a 2d version of Shadow of the Colossus, > then b
Re: [Ohrrpgce] Sprites, animation food for thought
3 times, but nevermind that. I've got a question about animations. Is it possible to add a "delay" value, which delays the next frame in the animation? Like: > > > stand-down > > > stand-up > > > stand-right > > > stand-left > > Then the person remains standing for 3s longer than the other directions? The reason I ask is that I like your idea of defining the animation by "wrapping" a PNG sheet with XML. So maybe it would be possible/easy to add more tags and options to an animation to increase its power. Then, it's all described in the XML+PNG combo, which makes it really easy to edit external to the OHR. Just throwing out ideas, since your first email seemed to encourage it. Cool system overall. -->Seth On Mon, Oct 11, 2010 at 2:01 AM, Mike wrote: > Shoot, if this email went out multiple times, I apologise. > > If not, please disregard this. > -- > Mike Caron > > -Original Message- > From: Mike Caron > Date: Sun, 10 Oct 2010 13:37:53 > To: > Subject: Sprites, animation food for thought > > First off, a disclaimer: This is not an actual proposal for a data > format for the OHR. This is something I've cooked up for another project > which may or may not ever see the light of day (hopefully, it will, but > it's immaterial to this discussion). > > This is how I've implemented sprites and animations in this other project: > > First, all pixel data is stored in sprite sheets. These are PNGs that > contain all the sprites for a given on-screen entity. Technically, as I > am writing it in .NET, nothing is stopping them from being BMP or JPG or > something, but I prefer PNG for its true-colour and transparency support. > > Then, with each sprite sheet, there is an XML document that describes it: > > http://mike-caron.com/za"; name="link1" file="link.png"> > name="stand-down" /> > > name="walk1-down" /> > name="walk2-down" /> > > > > Each frame has a name, a position and size on the sheet, and an origin. > The origin is aligned up with the actual entity's origin (which, ATM is > always their (x,y) position, but that may be customizable later on) > > Then, after the frame definitions, we have the animation definitions: > > > This is mostly self explanitory. Every frame has either one or four > directions defined, depending on if the sprite has meaningful directions > (an item on the ground, for example, probably only has one direction. An > NPC, on the other hand, will have all four). > > Each frame in a direction can have a time parameter, which describes how > many ticks the frame is displayed for. deftime is just the default such > value. Obviously, as well, if loop is yes, the animation will start from > the beginning. If no, it will just stop on the last frame forever. > > Finally, every entity in the game references both a sprite sheet and an > animation. The idea is that you could change one or the other. For > example, if you get a better shield, the sprite sheet changes from > "link1" to "link2". And, obviously, the animation changes based on what > is happening in the game. > > A few notes on this structure: > > - There is no accounting for palettes. If you wanted to use a paletted > sprite, then by all means you are able, but don't expect to be able to > change that palette in game. The canonical way to add palette swaps is > to have a different sprite sheet with the same animations (and, I may > add some way to automate this. Eg, "this sprite sheet is exactly the > same as this other sprite sheet, so use those definitions") > > - There is also no way to get any fancier animations. I.e, there's no > way to automatically oscillate or go backwards or whatever. The way to > achieve these effects would be to duplicate the frames in the animation. > - I may or may not add sprite flipping. > > - The way the images are laid out on the sheet has absolutely nothing > to do with how they are animated or displayed. If you wanted the same > frame, but offset by 5 pixels or whatever, you just modify the origin. > No muss, no fuss. > > - Also, there are no inherent limitations on how large or small the > sprite is. If you want to make a 2d version of Shadow of the Colossus, > then be my guest! (just, don't expect the video card to necessarily play > along ;) > > So... yeah. Make of that what you will, I'm just adding ideas to the > pot. I am aware that this format, as is, is unsuitable for the OHR. It's > just my two cents. > ___ > Ohrrpgce mailing list > ohrrpgce@lists.motherhamster.org > http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org > ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
[Ohrrpgce] SVN: james/3863 Get rid of the remaining GOSUB in browse.bas
james 2010-10-10 18:55:18 -0700 (Sun, 10 Oct 2010) 122 Get rid of the remaining GOSUB in browse.bas clean up a place where f was an integer in one place and a string in another --- U wip/browse.bas ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
[Ohrrpgce] SVN: james/3862 Some cleanup of browse.bas including option explict for the whole file
james 2010-10-10 18:39:45 -0700 (Sun, 10 Oct 2010) 71 Some cleanup of browse.bas including option explict for the whole file --- U wip/browse.bas ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] better palette options
On Mon, Oct 11, 2010 at 08:50:58AM +1030, David Gowers (kampu) wrote: > On Mon, Oct 11, 2010 at 3:36 AM, Mike Caron wrote: > > What about RELOAD (or, I guess, XML's) data model don't you like? > That nodes with children can also have values. > That's a pretty extraordinary behaviour for a tree data model, IMO. > > Unless you expect people to XSLT their XML source data, > I think a model like YAML or JSON is much simpler while still > supporting the basic data model. > > (you can currently convert YAML or JSON to RELOAD with a bit of work. > I'm just arguing that the "nodes with children can also have values" > is a specific, and probably unneeded, accommodation for XML's strange > behaviour.) In defense of this model, I have been getting a lot of good mileage out of this feature. --- James Paige ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] better palette options
On Sun, Oct 10, 2010 at 6:20 PM, David Gowers (kampu) <00a...@gmail.com> wrote: > On Mon, Oct 11, 2010 at 3:36 AM, Mike Caron wrote: >> What about RELOAD (or, I guess, XML's) data model don't you like? > That nodes with children can also have values. > That's a pretty extraordinary behaviour for a tree data model, IMO. > > Unless you expect people to XSLT their XML source data, > I think a model like YAML or JSON is much simpler while still > supporting the basic data model. > > (you can currently convert YAML or JSON to RELOAD with a bit of work. > I'm just arguing that the "nodes with children can also have values" > is a specific, and probably unneeded, accommodation for XML's strange > behaviour.) Oh. I see. Originally, it was such that nodes could have either children or a value. However, TMC suggested we do it this way as an optimization. > I'm not >> trying to defend it, I honestly want to know what you don't like. Perhaps >> something could be improved? >> But it is now. >>> >>> I wasn't actually requesting it. RELOAD as container for animation >>> data, as in your proposal, seems like a fairly good idea. RELOAD as >>> container for pixel data may be overly heavy. >> >> I agree that pixel data should not be stored in a RELOAD container. >> >> Rather, all the animation data should be stored in a single RELOAD document, >> and the images separate from that. >> >>> RELOAD annoys me a >>> little too, due to much increased complexity of read/writing. >> >> But, surely, you agree that the benefits of having a strongly typed and >> named data format outweigh the complexity, right? >> >> Honestly, I think the lump resizing scheme for older lumps is a lot more >> complex than RELOAD... > >> >> >> I think that's a really bad idea. The point of bounding boxes is that they >> are independent of the graphic on screen. Case in point: >> >> What if, on a frame with a small bounding box, a character moves up against >> a wall. Then, on the next frame, he has a large bounding box, which now >> intersects with the wall. Which of the following happens? >> >> 1. The character can now move into the wall? >> 2. The character is ejected (a la super mario bros)? >> 3. The character can only move out from the wall? >> 4. The character can't move at all? >> 5. The character is disintegrated since two particles cannot share the same >> quantum state? >> >> If the bounding boxes are fixed (or, at least, independent of sprites), >> > > ..?? Hello sentence which is not there. :\ I have no idea how that happened, but I think the rest of the sentence was something like: If the bounding boxes are fixed (or, at least, independent of sprites), then you don't have to worry about this. > > I don't understand the difference between the 'animset' command, and > chaining to another animation using 'end'. animset != anim. it doesn't set the anim, it sets the animset. Anyway I removed that by allowing varlength tuples. >>> >>> What varlength tuples? >>> > > You're also missing animation names. I think naming animations is > better than numbering them. > Then you can add a attackee flinch > animation to an enemy, say, just by adding an animation and naming it > "hurt". +1. I was thinking about this problem and couldn't figure out how to do it nicely, but this is excellent. >>> >>> But there's a complication, referring to animations by name may not >>> always be appropriate. Quoting from the 'text tags' thread, where I >>> proposed embedding tags in textboxes which trigger portrait >>> animations: >>> > Maybe animations should get both a name and a number. The name can be > used everywhere that it makes sense to use a name, and the number can be > used in whatever small number of places a name isn't practical (like > here) OK, sounds practical. But I wonder whether the ID number should be an index into the big global table of animation names (shared by all spritesets of any sort), or refer to the n-th animation currently defined for this spriteset. I'd prefer the first, since it might make sense to sort animations, say alphabetically. >>> >>> >>> > > The check/setctr codes seem to be very inefficient for creating loops: > > setctr ctr0 = x > label 1 > ...loop contents > setctr ctr0 -= 1 > checkctr ctr0 == 0 > goto label 2 > goto label 1 > label 2 > > Those last 5 instructions could be replaced with a loop(ctr,label) > code: decrement ctr and goto label if ctr> 0. A relative frame change > code would also be very useful for loops. oh right, ctr and label can fit into 16 bits easily(3+8) Good idea. (note that I'm leaving in the original ops -- they have a specific use that cannot be readily attained by a loop command : interleaving instructions, like 'wait 1' that only execute eg on>= second loop through a particular area
Re: [Ohrrpgce] better palette options
On Mon, Oct 11, 2010 at 3:36 AM, Mike Caron wrote: > What about RELOAD (or, I guess, XML's) data model don't you like? That nodes with children can also have values. That's a pretty extraordinary behaviour for a tree data model, IMO. Unless you expect people to XSLT their XML source data, I think a model like YAML or JSON is much simpler while still supporting the basic data model. (you can currently convert YAML or JSON to RELOAD with a bit of work. I'm just arguing that the "nodes with children can also have values" is a specific, and probably unneeded, accommodation for XML's strange behaviour.) I'm not > trying to defend it, I honestly want to know what you don't like. Perhaps > something could be improved? > >>> But it is now. >> >> I wasn't actually requesting it. RELOAD as container for animation >> data, as in your proposal, seems like a fairly good idea. RELOAD as >> container for pixel data may be overly heavy. > > I agree that pixel data should not be stored in a RELOAD container. > > Rather, all the animation data should be stored in a single RELOAD document, > and the images separate from that. > >> RELOAD annoys me a >> little too, due to much increased complexity of read/writing. > > But, surely, you agree that the benefits of having a strongly typed and > named data format outweigh the complexity, right? > > Honestly, I think the lump resizing scheme for older lumps is a lot more > complex than RELOAD... > > > I think that's a really bad idea. The point of bounding boxes is that they > are independent of the graphic on screen. Case in point: > > What if, on a frame with a small bounding box, a character moves up against > a wall. Then, on the next frame, he has a large bounding box, which now > intersects with the wall. Which of the following happens? > > 1. The character can now move into the wall? > 2. The character is ejected (a la super mario bros)? > 3. The character can only move out from the wall? > 4. The character can't move at all? > 5. The character is disintegrated since two particles cannot share the same > quantum state? > > If the bounding boxes are fixed (or, at least, independent of sprites), > ..?? Hello sentence which is not there. I don't understand the difference between the 'animset' command, and chaining to another animation using 'end'. >>> >>> animset != anim. >>> it doesn't set the anim, it sets the animset. >>> Anyway I removed that by allowing varlength tuples. >> >> What varlength tuples? >> You're also missing animation names. I think naming animations is better than numbering them. Then you can add a attackee flinch animation to an enemy, say, just by adding an animation and naming it "hurt". >>> >>> +1. I was thinking about this problem and couldn't figure out how to >>> do it nicely, but this is excellent. >> >> But there's a complication, referring to animations by name may not >> always be appropriate. Quoting from the 'text tags' thread, where I >> proposed embedding tags in textboxes which trigger portrait >> animations: >> Maybe animations should get both a name and a number. The name can be used everywhere that it makes sense to use a name, and the number can be used in whatever small number of places a name isn't practical (like here) >>> >>> OK, sounds practical. But I wonder whether the ID number should be an >>> index into the big global table of animation names (shared by all >>> spritesets of any sort), or refer to the n-th animation currently >>> defined for this spriteset. I'd prefer the first, since it might make >>> sense to sort animations, say alphabetically. >> >> >> The check/setctr codes seem to be very inefficient for creating loops: setctr ctr0 = x label 1 ...loop contents setctr ctr0 -= 1 checkctr ctr0 == 0 goto label 2 goto label 1 label 2 Those last 5 instructions could be replaced with a loop(ctr,label) code: decrement ctr and goto label if ctr> 0. A relative frame change code would also be very useful for loops. >>> >>> oh right, ctr and label can fit into 16 bits easily(3+8) >>> Good idea. (note that I'm leaving in the original ops -- they have a >>> specific use that cannot be readily attained by a loop command : >>> interleaving instructions, like 'wait 1' that only execute eg on>= >>> second loop through a particular area >>> of code. >> >> Your definition of loop isn't correct. >> >> The actual encoding of the bytestring, bits per opcode and argument, >> isn't specified. Making them all 16 bit signed is easy, but we if want >> to cram multiple arguments into the same short, maybe it would just be >> simpler to same that opcodes are 8 bit, and arguments are either 8 or >> 16 bit signed (or a string (wouldn't be necessary if we numbered >> animations internally?)). >> I suggest a 'reset' command. Changing the sprite state after the end may be desired (ie. a transitio
[Ohrrpgce] SVN: james/3861 Reload editor now supports copy and paste of nodes.
james 2010-10-10 13:53:35 -0700 (Sun, 10 Oct 2010) 164 Reload editor now supports copy and paste of nodes. I had to make it CTRL+SHIFT+C and CTRL+SHIFT+V to avoid conflict with copying and pasting node names and values --- U wip/ohrhelp/reload_editor.txt U wip/reloadedit.bas ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
[Ohrrpgce] SVN: james/3860 Add NodeHasAncestor() checking function to reload
james 2010-10-10 13:50:53 -0700 (Sun, 10 Oct 2010) 50 Add NodeHasAncestor() checking function to reload --- U wip/reload.bas U wip/reload.bi ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
[Ohrrpgce] SVN: james/3859 Add CloneNodeTree to reload
james 2010-10-10 13:05:38 -0700 (Sun, 10 Oct 2010) 28 Add CloneNodeTree to reload --- U wip/reload.bas U wip/reload.bi ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] Sprites, animation food for thought
Shoot, if this email went out multiple times, I apologise. If not, please disregard this. -- Mike Caron -Original Message- From: Mike Caron Date: Sun, 10 Oct 2010 13:37:53 To: Subject: Sprites, animation food for thought First off, a disclaimer: This is not an actual proposal for a data format for the OHR. This is something I've cooked up for another project which may or may not ever see the light of day (hopefully, it will, but it's immaterial to this discussion). This is how I've implemented sprites and animations in this other project: First, all pixel data is stored in sprite sheets. These are PNGs that contain all the sprites for a given on-screen entity. Technically, as I am writing it in .NET, nothing is stopping them from being BMP or JPG or something, but I prefer PNG for its true-colour and transparency support. Then, with each sprite sheet, there is an XML document that describes it: http://mike-caron.com/za"; name="link1" file="link.png"> Each frame has a name, a position and size on the sheet, and an origin. The origin is aligned up with the actual entity's origin (which, ATM is always their (x,y) position, but that may be customizable later on) Then, after the frame definitions, we have the animation definitions: stand-down stand-up stand-right stand-left This is mostly self explanitory. Every frame has either one or four directions defined, depending on if the sprite has meaningful directions (an item on the ground, for example, probably only has one direction. An NPC, on the other hand, will have all four). Each frame in a direction can have a time parameter, which describes how many ticks the frame is displayed for. deftime is just the default such value. Obviously, as well, if loop is yes, the animation will start from the beginning. If no, it will just stop on the last frame forever. Finally, every entity in the game references both a sprite sheet and an animation. The idea is that you could change one or the other. For example, if you get a better shield, the sprite sheet changes from "link1" to "link2". And, obviously, the animation changes based on what is happening in the game. A few notes on this structure: - There is no accounting for palettes. If you wanted to use a paletted sprite, then by all means you are able, but don't expect to be able to change that palette in game. The canonical way to add palette swaps is to have a different sprite sheet with the same animations (and, I may add some way to automate this. Eg, "this sprite sheet is exactly the same as this other sprite sheet, so use those definitions") - There is also no way to get any fancier animations. I.e, there's no way to automatically oscillate or go backwards or whatever. The way to achieve these effects would be to duplicate the frames in the animation. - I may or may not add sprite flipping. - The way the images are laid out on the sheet has absolutely nothing to do with how they are animated or displayed. If you wanted the same frame, but offset by 5 pixels or whatever, you just modify the origin. No muss, no fuss. - Also, there are no inherent limitations on how large or small the sprite is. If you want to make a 2d version of Shadow of the Colossus, then be my guest! (just, don't expect the video card to necessarily play along ;) So... yeah. Make of that what you will, I'm just adding ideas to the pot. I am aware that this format, as is, is unsuitable for the OHR. It's just my two cents. ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
[Ohrrpgce] Sprites, animation food for thought
First off, a disclaimer: This is not an actual proposal for a data format for the OHR. This is something I've cooked up for another project which may or may not ever see the light of day (hopefully, it will, but it's immaterial to this discussion). This is how I've implemented sprites and animations in this other project: First, all pixel data is stored in sprite sheets. These are PNGs that contain all the sprites for a given on-screen entity. Technically, as I am writing it in .NET, nothing is stopping them from being BMP or JPG or something, but I prefer PNG for its true-colour and transparency support. Then, with each sprite sheet, there is an XML document that describes it: http://mike-caron.com/za"; name="link1" file="link.png"> name="walk1-down" /> name="walk2-down" /> Each frame has a name, a position and size on the sheet, and an origin. The origin is aligned up with the actual entity's origin (which, ATM is always their (x,y) position, but that may be customizable later on) Then, after the frame definitions, we have the animation definitions: stand-down stand-up stand-right stand-left This is mostly self explanitory. Every frame has either one or four directions defined, depending on if the sprite has meaningful directions (an item on the ground, for example, probably only has one direction. An NPC, on the other hand, will have all four). Each frame in a direction can have a time parameter, which describes how many ticks the frame is displayed for. deftime is just the default such value. Obviously, as well, if loop is yes, the animation will start from the beginning. If no, it will just stop on the last frame forever. Finally, every entity in the game references both a sprite sheet and an animation. The idea is that you could change one or the other. For example, if you get a better shield, the sprite sheet changes from "link1" to "link2". And, obviously, the animation changes based on what is happening in the game. A few notes on this structure: - There is no accounting for palettes. If you wanted to use a paletted sprite, then by all means you are able, but don't expect to be able to change that palette in game. The canonical way to add palette swaps is to have a different sprite sheet with the same animations (and, I may add some way to automate this. Eg, "this sprite sheet is exactly the same as this other sprite sheet, so use those definitions") - There is also no way to get any fancier animations. I.e, there's no way to automatically oscillate or go backwards or whatever. The way to achieve these effects would be to duplicate the frames in the animation. - I may or may not add sprite flipping. - The way the images are laid out on the sheet has absolutely nothing to do with how they are animated or displayed. If you wanted the same frame, but offset by 5 pixels or whatever, you just modify the origin. No muss, no fuss. - Also, there are no inherent limitations on how large or small the sprite is. If you want to make a 2d version of Shadow of the Colossus, then be my guest! (just, don't expect the video card to necessarily play along ;) So... yeah. Make of that what you will, I'm just adding ideas to the pot. I am aware that this format, as is, is unsuitable for the OHR. It's just my two cents. ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
[Ohrrpgce] Sprites, animation food for thought
First off, a disclaimer: This is not an actual proposal for a data format for the OHR. This is something I've cooked up for another project which may or may not ever see the light of day (hopefully, it will, but it's immaterial to this discussion). This is how I've implemented sprites and animations in this other project: First, all pixel data is stored in sprite sheets. These are PNGs that contain all the sprites for a given on-screen entity. Technically, as I am writing it in .NET, nothing is stopping them from being BMP or JPG or something, but I prefer PNG for its true-colour and transparency support. Then, with each sprite sheet, there is an XML document that describes it: http://mike-caron.com/za"; name="link1" file="link.png"> name="walk1-down" /> name="walk2-down" /> Each frame has a name, a position and size on the sheet, and an origin. The origin is aligned up with the actual entity's origin (which, ATM is always their (x,y) position, but that may be customizable later on) Then, after the frame definitions, we have the animation definitions: stand-down stand-up stand-right stand-left This is mostly self explanitory. Every frame has either one or four directions defined, depending on if the sprite has meaningful directions (an item on the ground, for example, probably only has one direction. An NPC, on the other hand, will have all four). Each frame in a direction can have a time parameter, which describes how many ticks the frame is displayed for. deftime is just the default such value. Obviously, as well, if loop is yes, the animation will start from the beginning. If no, it will just stop on the last frame forever. Finally, every entity in the game references both a sprite sheet and an animation. The idea is that you could change one or the other. For example, if you get a better shield, the sprite sheet changes from "link1" to "link2". And, obviously, the animation changes based on what is happening in the game. A few notes on this structure: - There is no accounting for palettes. If you wanted to use a paletted sprite, then by all means you are able, but don't expect to be able to change that palette in game. The canonical way to add palette swaps is to have a different sprite sheet with the same animations (and, I may add some way to automate this. Eg, "this sprite sheet is exactly the same as this other sprite sheet, so use those definitions") - There is also no way to get any fancier animations. I.e, there's no way to automatically oscillate or go backwards or whatever. The way to achieve these effects would be to duplicate the frames in the animation. - I may or may not add sprite flipping. - The way the images are laid out on the sheet has absolutely nothing to do with how they are animated or displayed. If you wanted the same frame, but offset by 5 pixels or whatever, you just modify the origin. No muss, no fuss. - Also, there are no inherent limitations on how large or small the sprite is. If you want to make a 2d version of Shadow of the Colossus, then be my guest! (just, don't expect the video card to necessarily play along ;) So... yeah. Make of that what you will, I'm just adding ideas to the pot. I am aware that this format, as is, is unsuitable for the OHR. It's just my two cents. ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
[Ohrrpgce] Sprites, animation food for thought
First off, a disclaimer: This is not an actual proposal for a data format for the OHR. This is something I've cooked up for another project which may or may not ever see the light of day (hopefully, it will, but it's immaterial to this discussion). This is how I've implemented sprites and animations in this other project: First, all pixel data is stored in sprite sheets. These are PNGs that contain all the sprites for a given on-screen entity. Technically, as I am writing it in .NET, nothing is stopping them from being BMP or JPG or something, but I prefer PNG for its true-colour and transparency support. Then, with each sprite sheet, there is an XML document that describes it: http://mike-caron.com/za"; name="link1" file="link.png"> name="walk1-down" /> name="walk2-down" /> Each frame has a name, a position and size on the sheet, and an origin. The origin is aligned up with the actual entity's origin (which, ATM is always their (x,y) position, but that may be customizable later on) Then, after the frame definitions, we have the animation definitions: stand-down stand-up stand-right stand-left This is mostly self explanitory. Every frame has either one or four directions defined, depending on if the sprite has meaningful directions (an item on the ground, for example, probably only has one direction. An NPC, on the other hand, will have all four). Each frame in a direction can have a time parameter, which describes how many ticks the frame is displayed for. deftime is just the default such value. Obviously, as well, if loop is yes, the animation will start from the beginning. If no, it will just stop on the last frame forever. Finally, every entity in the game references both a sprite sheet and an animation. The idea is that you could change one or the other. For example, if you get a better shield, the sprite sheet changes from "link1" to "link2". And, obviously, the animation changes based on what is happening in the game. A few notes on this structure: - There is no accounting for palettes. If you wanted to use a paletted sprite, then by all means you are able, but don't expect to be able to change that palette in game. The canonical way to add palette swaps is to have a different sprite sheet with the same animations (and, I may add some way to automate this. Eg, "this sprite sheet is exactly the same as this other sprite sheet, so use those definitions") - There is also no way to get any fancier animations. I.e, there's no way to automatically oscillate or go backwards or whatever. The way to achieve these effects would be to duplicate the frames in the animation. - I may or may not add sprite flipping. - The way the images are laid out on the sheet has absolutely nothing to do with how they are animated or displayed. If you wanted the same frame, but offset by 5 pixels or whatever, you just modify the origin. No muss, no fuss. - Also, there are no inherent limitations on how large or small the sprite is. If you want to make a 2d version of Shadow of the Colossus, then be my guest! (just, don't expect the video card to necessarily play along ;) So... yeah. Make of that what you will, I'm just adding ideas to the pot. I am aware that this format, as is, is unsuitable for the OHR. It's just my two cents. ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] better palette options
On 10/10/2010 7:04, Ralph Versteegen wrote: On 9 October 2010 14:39, David Gowers (kampu)<00a...@gmail.com> wrote: On Sat, Oct 9, 2010 at 5:07 AM, Ralph Versteegen wrote: On 9 October 2010 02:48, David Gowers (kampu)<00a...@gmail.com> wrote: On Fri, Oct 8, 2010 at 11:42 PM, David Gowers (kampu)<00a...@gmail.com> wrote: http://bpaste.net/show/10001/ ^ The format proposition Generally this looks good. Aside from the following long string of criticisms ;) I'm not sure, but I believe you're suggesting using a plain binary lump instead of Reload for animation? If Reload is actually part of it, I don't see much point in a separate lump per animation. RELOAD was not part of it (well, honestly RELOAD vaguely annoys me, the way it replicates XML's weird data model. So it's not the first thing I would think of.) What about RELOAD (or, I guess, XML's) data model don't you like? I'm not trying to defend it, I honestly want to know what you don't like. Perhaps something could be improved? But it is now. I wasn't actually requesting it. RELOAD as container for animation data, as in your proposal, seems like a fairly good idea. RELOAD as container for pixel data may be overly heavy. I agree that pixel data should not be stored in a RELOAD container. Rather, all the animation data should be stored in a single RELOAD document, and the images separate from that. > RELOAD annoys me a > little too, due to much increased complexity of read/writing. But, surely, you agree that the benefits of having a strongly typed and named data format outweigh the complexity, right? Honestly, I think the lump resizing scheme for older lumps is a lot more complex than RELOAD... I notice that separate image size and bounding box size/offset are missing. Intentionally? Missing? I understood the base bounding box size and location as being immutable (and based off say, a manually definable box - see slice editor). While this was a bit annoying, it made some amount of sense. I'm not sure how to avoid confusing the user if they are not immutable. Please, explain further how you conceive of the interaction of bounding boxes and image offsets? It's a conflation of two (or three) different ideas. Perhaps they should be separated. A "srcrect" is just a reference point (offset) plus width and height equal to the existing frame size limits. I called these "bounding boxes" because in the current tile-based movement system (and also somewhat in in-battle movement and positioning) the frame size is effectively a bounding box. But if/when we add pixel-based movement one may well want the bounding box to depend on the current frame. I think that's a really bad idea. The point of bounding boxes is that they are independent of the graphic on screen. Case in point: What if, on a frame with a small bounding box, a character moves up against a wall. Then, on the next frame, he has a large bounding box, which now intersects with the wall. Which of the following happens? 1. The character can now move into the wall? 2. The character is ejected (a la super mario bros)? 3. The character can only move out from the wall? 4. The character can't move at all? 5. The character is disintegrated since two particles cannot share the same quantum state? If the bounding boxes are fixed (or, at least, independent of sprites), I don't understand the difference between the 'animset' command, and chaining to another animation using 'end'. animset != anim. it doesn't set the anim, it sets the animset. Anyway I removed that by allowing varlength tuples. What varlength tuples? You're also missing animation names. I think naming animations is better than numbering them. Then you can add a attackee flinch animation to an enemy, say, just by adding an animation and naming it "hurt". +1. I was thinking about this problem and couldn't figure out how to do it nicely, but this is excellent. But there's a complication, referring to animations by name may not always be appropriate. Quoting from the 'text tags' thread, where I proposed embedding tags in textboxes which trigger portrait animations: Maybe animations should get both a name and a number. The name can be used everywhere that it makes sense to use a name, and the number can be used in whatever small number of places a name isn't practical (like here) OK, sounds practical. But I wonder whether the ID number should be an index into the big global table of animation names (shared by all spritesets of any sort), or refer to the n-th animation currently defined for this spriteset. I'd prefer the first, since it might make sense to sort animations, say alphabetically. The check/setctr codes seem to be very inefficient for creating loops: setctr ctr0 = x label 1 ...loop contents setctr ctr0 -= 1 checkctr ctr0 == 0 goto label 2 goto label 1 label 2 Those last 5 instructions could be replaced with a loop(ctr,label) code: decrement ctr and goto label if ctr> 0
Re: [Ohrrpgce] better palette options
On 9 October 2010 14:39, David Gowers (kampu) <00a...@gmail.com> wrote: > On Sat, Oct 9, 2010 at 5:07 AM, Ralph Versteegen wrote: >> On 9 October 2010 02:48, David Gowers (kampu) <00a...@gmail.com> wrote: >>> On Fri, Oct 8, 2010 at 11:42 PM, David Gowers (kampu) <00a...@gmail.com> >>> wrote: http://bpaste.net/show/10001/ ^ The format proposition >> >> Generally this looks good. Aside from the following long string of >> criticisms ;) >> >> I'm not sure, but I believe you're suggesting using a plain binary >> lump instead of Reload for animation? If Reload is actually part of >> it, I don't see much point in a separate lump per animation. > > RELOAD was not part of it (well, honestly RELOAD vaguely annoys me, > the way it replicates XML's weird data model. So it's not the first > thing I would think of.) > > But it is now. I wasn't actually requesting it. RELOAD as container for animation data, as in your proposal, seems like a fairly good idea. RELOAD as container for pixel data may be overly heavy. RELOAD annoys me a little too, due to much increased complexity of read/writing. >> >> I notice that separate image size and bounding box size/offset are >> missing. Intentionally? > > Missing? > I understood the base bounding box size and location as being > immutable (and based off say, a manually definable box - see slice > editor). While this was a bit annoying, it made some amount of sense. > I'm not sure how to avoid confusing the user if they are not > immutable. > > Please, explain further how you conceive of the interaction of > bounding boxes and image offsets? It's a conflation of two (or three) different ideas. Perhaps they should be separated. A "srcrect" is just a reference point (offset) plus width and height equal to the existing frame size limits. I called these "bounding boxes" because in the current tile-based movement system (and also somewhat in in-battle movement and positioning) the frame size is effectively a bounding box. But if/when we add pixel-based movement one may well want the bounding box to depend on the current frame. >> >> I don't understand the difference between the 'animset' command, and >> chaining to another animation using 'end'. > animset != anim. > it doesn't set the anim, it sets the animset. > Anyway I removed that by allowing varlength tuples. What varlength tuples? >> >> You're also missing animation names. I think naming animations is >> better than numbering them. >> Then you can add a attackee flinch >> animation to an enemy, say, just by adding an animation and naming it >> "hurt". > +1. I was thinking about this problem and couldn't figure out how to > do it nicely, but this is excellent. But there's a complication, referring to animations by name may not always be appropriate. Quoting from the 'text tags' thread, where I proposed embedding tags in textboxes which trigger portrait animations: > > Maybe animations should get both a name and a number. The name can be > > used everywhere that it makes sense to use a name, and the number can be > > used in whatever small number of places a name isn't practical (like > > here) > > OK, sounds practical. But I wonder whether the ID number should be an > index into the big global table of animation names (shared by all > spritesets of any sort), or refer to the n-th animation currently > defined for this spriteset. I'd prefer the first, since it might make > sense to sort animations, say alphabetically. >> >> The check/setctr codes seem to be very inefficient for creating loops: >> >> setctr ctr0 = x >> label 1 >> ...loop contents >> setctr ctr0 -= 1 >> checkctr ctr0 == 0 >> goto label 2 >> goto label 1 >> label 2 >> >> Those last 5 instructions could be replaced with a loop(ctr,label) >> code: decrement ctr and goto label if ctr > 0. A relative frame change >> code would also be very useful for loops. > oh right, ctr and label can fit into 16 bits easily(3+8) > Good idea. (note that I'm leaving in the original ops -- they have a > specific use that cannot be readily attained by a loop command : > interleaving instructions, like 'wait 1' that only execute eg on >= > second loop through a particular area > of code. Your definition of loop isn't correct. The actual encoding of the bytestring, bits per opcode and argument, isn't specified. Making them all 16 bit signed is easy, but we if want to cram multiple arguments into the same short, maybe it would just be simpler to same that opcodes are 8 bit, and arguments are either 8 or 16 bit signed (or a string (wouldn't be necessary if we numbered animations internally?)). >> >> I suggest a 'reset' command. Changing the sprite state after the end >> may be desired (ie. a transition animation), and sometimes not. >> 'reset' would return to the original gfxset, frame, palette, and >> offset. Wondering why you noted reset as only resetting gfxset - you don't think the rest is useful? >>> Note that I intentionally made it as unrestric
