That looks really useful. It looks a lot like a Japanese site where I saw similar sprite generation stuff. The link is probably floating on this thread somewhere.
I wonder if we could get someone to make an LPC version of this sprite sheet generator, that would be really super useful!
At this point it's beating a dead horse because you've clearly explained what you meant and I've continued to ramble on about the gc. I know I'm not responding directly to what you're saying but maybe an example will illustrate the point:
package { public interface IDisposable { dispose():void; } }
Using that interface on a class will promise to the compiler that there's always going to be a method defined with that signature, right? If I implement this on all my complicated classes with object references and I define the method that gets rid of all those references then I'm basically promising the compiler that the function I'm calling exists because the interface says so. In some situations (specifically with BitmapData and some other built-in types) there's already a dispose() method available. I called mine Trash() because I wanted to remind myself that it should be called after the object isn't needed and I forget to call it dispose().
The way all this talk ties to the gc is when you call the dispose() method it's supposed to prep that object for disposal. All the interface does is promise the compiler that the method dispose() is defined somewhere in the class that implements it. I didn't make any interfaces because I was still writing the core functionality for the engine. I know that's supposed to be part of that process but I change my mind a lot about how I want to name methods. Forcing classes to use interfaces while I'm still deciding the names doesn't make much sense.
Since you've mentioned using IDisposable and interfaces in general that's probably going to be one of the things I make next. There's enough there to benefit from using interfaces and since there are now two of us working on this project code it makes better sense to have them. So, after several walls of text and a lot of wordy non-sense, thank you for reminding me to use interfaces!
Now is the best time to make interfaces because now we're solidifying and building extended functionality.
I wrote a big, detailed reply and went to do something and hit ctrl+r instead of ctrl+c so it was eaten by the browser before you got to read it :(
The gc in Flash doesn't work that well. In fact, it doesn't work at all sometimes. I setup the gc to run between stage loads because it's sort of a natural break point and serves as a clean slate to work from (for the sake of memory management anyway). The only time the trash method gets called is right before a stage load so it serves the purpose of preparing everything that should be eaten by the gc and spoon feeds it accordingly.
It doesn't feel natural to do manual memory management in a gc'd environment, I agree. Here are some links that relate to why I wrote disposal methods instead of leaving it up to the gc:
I'm sure you're right about boiler plate in the Hero and NPC classes now that I think about it. I haven't looked at it for a while and some of it would make more sense to make a shared inherited class base since they do share a good bit of code. Again, haven't messed with it for a while and still haven't refactored it so it's still messy!
I did notice my NPC and Hero classes share some boilder plate. I copied several things directly from Hero to make the NPC class. They're separate intentionally because a few things are hard to extend and customize for each class since AS3 doesn't allow function overloading. It was easier to copy and modify the bits that were different between them and leave the same funciton signature in place. I would have done a simple function override in an extended class but the function would be a rewrite anyway so copying made more sense.
As far as garbage collection is concerned in Flash it's very hit-or-miss when things actually get garbage collected. There's no explicit delete and the only way to make an object go away is to remove all references to it. I don't understand why the gc in Flash is so weird but it only gets called when memory is bloated and only objects that don't have any open references are considered for gc. The tricky bit about that is if an object is referenced by enough other objects, even if there's an island of unreferenced crap that all references each other, Flash won't gc it! I don't know the exact number of nodes it takes to reference each other before Flash won't touch it but it's not very many. Because of that I started including a Trash routine on all objects with several references to other objects. It seems in Flash it's better to dereference everything by hand, otherwise memory bloat becomes a serious issue. Even if the gc runs it still might ignore abandoned objects with circular references, I don't know why...
I love the idea of making a map editor specific to this engine but I'd have to teach everyone else how to use it. I'd also have to document it and add features any time I ran into something I needed that it didn't already have. I settled on Tiled because it's already feature rich and people know how to use it effectively. It's also available for all major platforms, has a significant amount of documentation, an active developer and user base, and it can do everything I need. Choosing Tiled has more to do with enabling everyone else helping with this project.
This is a really awesome enemy! I wonder if you'd be willing to animate this in LPC style? If so drop me a line, I'd be interested to talk more about it. Thanks.
jasonisop seems interested in helping so the source is going up on git hub. I'll have a link once it's up and accessible. If anyone else is interested in contributing it's still an open project.
makrohn made the Universal-LPC-spritesheet repository, found here:
https://github.com/makrohn/Universal-LPC-spritesheet
I don't know if that's enough to help you without repacking the graphics. It should be everything needed to make a decent sprite sheet generator.
That looks really useful. It looks a lot like a Japanese site where I saw similar sprite generation stuff. The link is probably floating on this thread somewhere.
I wonder if we could get someone to make an LPC version of this sprite sheet generator, that would be really super useful!
AAAAAAAAAAAAAHHHH!
I'm sorry but someone had to do it. I couldn't resist any longer.
At this point it's beating a dead horse because you've clearly explained what you meant and I've continued to ramble on about the gc. I know I'm not responding directly to what you're saying but maybe an example will illustrate the point:
package {
public interface IDisposable {
dispose():void;
}
}
Using that interface on a class will promise to the compiler that there's always going to be a method defined with that signature, right? If I implement this on all my complicated classes with object references and I define the method that gets rid of all those references then I'm basically promising the compiler that the function I'm calling exists because the interface says so. In some situations (specifically with BitmapData and some other built-in types) there's already a dispose() method available. I called mine Trash() because I wanted to remind myself that it should be called after the object isn't needed and I forget to call it dispose().
The way all this talk ties to the gc is when you call the dispose() method it's supposed to prep that object for disposal. All the interface does is promise the compiler that the method dispose() is defined somewhere in the class that implements it. I didn't make any interfaces because I was still writing the core functionality for the engine. I know that's supposed to be part of that process but I change my mind a lot about how I want to name methods. Forcing classes to use interfaces while I'm still deciding the names doesn't make much sense.
Since you've mentioned using IDisposable and interfaces in general that's probably going to be one of the things I make next. There's enough there to benefit from using interfaces and since there are now two of us working on this project code it makes better sense to have them. So, after several walls of text and a lot of wordy non-sense, thank you for reminding me to use interfaces!
Now is the best time to make interfaces because now we're solidifying and building extended functionality.
I wrote a big, detailed reply and went to do something and hit ctrl+r instead of ctrl+c so it was eaten by the browser before you got to read it :(
The gc in Flash doesn't work that well. In fact, it doesn't work at all sometimes. I setup the gc to run between stage loads because it's sort of a natural break point and serves as a clean slate to work from (for the sake of memory management anyway). The only time the trash method gets called is right before a stage load so it serves the purpose of preparing everything that should be eaten by the gc and spoon feeds it accordingly.
It doesn't feel natural to do manual memory management in a gc'd environment, I agree. Here are some links that relate to why I wrote disposal methods instead of leaving it up to the gc:
I'm sure you're right about boiler plate in the Hero and NPC classes now that I think about it. I haven't looked at it for a while and some of it would make more sense to make a shared inherited class base since they do share a good bit of code. Again, haven't messed with it for a while and still haven't refactored it so it's still messy!
@jeremyW
Thanks for the comments!
I did notice my NPC and Hero classes share some boilder plate. I copied several things directly from Hero to make the NPC class. They're separate intentionally because a few things are hard to extend and customize for each class since AS3 doesn't allow function overloading. It was easier to copy and modify the bits that were different between them and leave the same funciton signature in place. I would have done a simple function override in an extended class but the function would be a rewrite anyway so copying made more sense.
As far as garbage collection is concerned in Flash it's very hit-or-miss when things actually get garbage collected. There's no explicit delete and the only way to make an object go away is to remove all references to it. I don't understand why the gc in Flash is so weird but it only gets called when memory is bloated and only objects that don't have any open references are considered for gc. The tricky bit about that is if an object is referenced by enough other objects, even if there's an island of unreferenced crap that all references each other, Flash won't gc it! I don't know the exact number of nodes it takes to reference each other before Flash won't touch it but it's not very many. Because of that I started including a Trash routine on all objects with several references to other objects. It seems in Flash it's better to dereference everything by hand, otherwise memory bloat becomes a serious issue. Even if the gc runs it still might ignore abandoned objects with circular references, I don't know why...
I love the idea of making a map editor specific to this engine but I'd have to teach everyone else how to use it. I'd also have to document it and add features any time I ran into something I needed that it didn't already have. I settled on Tiled because it's already feature rich and people know how to use it effectively. It's also available for all major platforms, has a significant amount of documentation, an active developer and user base, and it can do everything I need. Choosing Tiled has more to do with enabling everyone else helping with this project.
Yay, you made a tree, Awesome! This would probably fit well in a side scroller. Thanks!
If you have some bitmap fonts you'd like turned into a TTF I can do it. Just point to the bitmap font...
This is a really awesome enemy! I wonder if you'd be willing to animate this in LPC style? If so drop me a line, I'd be interested to talk more about it. Thanks.
jasonisop seems interested in helping so the source is going up on git hub. I'll have a link once it's up and accessible. If anyone else is interested in contributing it's still an open project.
https://github.com/jasonisop/Kujasa
Pages