From kukkerman at gmail.com Tue Sep 1 14:41:40 2009 From: kukkerman at gmail.com (=?ISO-8859-1?Q?G=E1bor_Szuromi?=) Date: Tue, 1 Sep 2009 16:41:40 +0200 Subject: [SamHaXe] Teszt! Message-ID: Gy??! From kukkerman at gmail.com Thu Sep 3 19:23:50 2009 From: kukkerman at gmail.com (=?ISO-8859-1?Q?G=E1bor_Szuromi?=) Date: Thu, 3 Sep 2009 21:23:50 +0200 Subject: [SamHaXe] List is finally working Message-ID: Hi! Sorry for the inconvenience but I accidentally mistyped the domain name of the mailing list on the admin page. It should work now. For those who sent something before please send it again. Cheers, Gabe From niel.drummond at grumpytoad.org Thu Sep 3 20:21:35 2009 From: niel.drummond at grumpytoad.org (Niel Drummond) Date: Thu, 03 Sep 2009 22:21:35 +0200 Subject: [SamHaXe] OK I think the code gods have blessed the mailing list now Message-ID: <4AA0254F.509@grumpytoad.org> :) From zjnue.brzavi at googlemail.com Sat Sep 5 05:46:16 2009 From: zjnue.brzavi at googlemail.com (Zjnue Brzavi) Date: Sat, 5 Sep 2009 06:46:16 +0100 Subject: [SamHaXe] Are the rumours true ?! Message-ID: <372634f90909042246r2cfbbe49u9109d287aed69b63@mail.gmail.com> So are the rumours true that the haXe compiler will delegate some of its responsibilities to samhaxe to gain from preloading, inline asset embedding (via -D use_rtti_doc), etc, etc ?! How exciting!! ;) From kukkerman at gmail.com Sat Sep 5 08:45:55 2009 From: kukkerman at gmail.com (=?ISO-8859-1?Q?G=E1bor_Szuromi?=) Date: Sat, 5 Sep 2009 10:45:55 +0200 Subject: [SamHaXe] Are the rumours true ?! In-Reply-To: <372634f90909042246r2cfbbe49u9109d287aed69b63@mail.gmail.com> References: <372634f90909042246r2cfbbe49u9109d287aed69b63@mail.gmail.com> Message-ID: Hi! Well, what preloading in this context means is that you place only a few (in bytes) assets on the first frame so flash player can start playing your animation early. AS3 code generated by haXe comipler resides on the first frame so as long as most of your assets are on the second (third, fourth, etc.) frame flash player executes your code long before loading the whole file. You can then monitor loading progress with an Event.ENTER_FRAME event handler as demonstrated in PreloadingDemo. Preloading with swfmill was problematic because flash player needs an AS3 class stub for every asset with a symbol class. HaXe generates class stubs for assets automatically but only on the first frame. So if you put an asset on the second frame with swfmill there wasn't any AS3 class stub generated and flash player threw an error. Sam HaXe generates AS3 class stubs for you (if you want) so you can put your asset on the frame you like. Hope that answers your question. Cheers, Gabe From zjnue.brzavi at googlemail.com Sat Sep 5 14:21:48 2009 From: zjnue.brzavi at googlemail.com (Zjnue Brzavi) Date: Sat, 5 Sep 2009 15:21:48 +0100 Subject: [SamHaXe] Are the rumours true ?! In-Reply-To: References: <372634f90909042246r2cfbbe49u9109d287aed69b63@mail.gmail.com> Message-ID: <372634f90909050721s72ab03c1obf2ceb35ce2a2bf3@mail.gmail.com> > ?Well, what preloading in this context means is that you place only a > few (in bytes) assets on the first frame so flash player can start > playing your animation early. AS3 code generated by haXe comipler > resides on the first frame so as long as most of your assets are on > the second (third, fourth, etc.) frame flash player executes your code > long before loading the whole file. You can then monitor loading > progress with an Event.ENTER_FRAME event handler as demonstrated in > PreloadingDemo. > ?Preloading with swfmill was problematic because flash player needs > an AS3 class stub for every asset with a symbol class. HaXe generates > class stubs for assets automatically but only on the first frame. So > if you put an asset on the second frame with swfmill there wasn't any > AS3 class stub generated and flash player threw an error. Sam HaXe > generates AS3 class stubs for you (if you want) so you can put your > asset on the frame you like. Hi Gabe! I was actually teasing a bit, but I'm glad I did, because now I understand the AS3 class stub role better, thanks! What I was getting at relates to two topics discussed or mentioned briefly on the haXe list recently: One is that maybe the SWF building exercise (which the haXe compiler also takes care of, currently), could be centralized into a modular unit - and I was playing with the idea that this may be a samhaxe module :) The other thing that sounds interesting is to allow metadata/annotations for assets within haXe code, in comments, where applicable. This seems easier to achieve for a compiler that can delegate the task (information) to a specialized asset tool such as samhaxe... Not sure if there is a notion to manage assets for another targets besides flash, but that may be an interesting thought also. Perhaps even -resource stuff, but that's maybe going a bit far? Just a few quick comments, not much time, but been a pleasure to look at the code, even just briefly. All the best, Zjnue From zjnue.brzavi at googlemail.com Sat Sep 5 14:32:34 2009 From: zjnue.brzavi at googlemail.com (Zjnue Brzavi) Date: Sat, 5 Sep 2009 15:32:34 +0100 Subject: [SamHaXe] doc dependencies Message-ID: <372634f90909050732j28a59966g713a35fa4e1545eb@mail.gmail.com> Hi! Another quick comment please. There seems a push to minimize external dependencies required for building samhaxe, which sounds like a good idea. While the NaturalDocs documentation is very nice, it seems to require Perl. I had to install strawberry-perl for Windows for example. Perhaps this can be overcome later by creating Neko bindings for NaturalDocs, or potentially use the Neko-based chxdoc like haxegui does: http://haxegui.googlecode.com/svn/trunk/docs/index.html I guess this is not a big issue, but perhaps worth mentioning. Later, Zjnue From kukkerman at gmail.com Sat Sep 5 15:17:44 2009 From: kukkerman at gmail.com (=?ISO-8859-1?Q?G=E1bor_Szuromi?=) Date: Sat, 5 Sep 2009 17:17:44 +0200 Subject: [SamHaXe] doc dependencies In-Reply-To: <372634f90909050732j28a59966g713a35fa4e1545eb@mail.gmail.com> References: <372634f90909050732j28a59966g713a35fa4e1545eb@mail.gmail.com> Message-ID: > While the NaturalDocs documentation is very nice, it seems to require > Perl. I had to install strawberry-perl for Windows for example. You're right NaturalDocs depends on perl but we listed only direct dependencies of Sam HaXe in documentation. > Perhaps this can be overcome later by creating Neko bindings for > NaturalDocs, or potentially use the Neko-based chxdoc like haxegui > does: http://haxegui.googlecode.com/svn/trunk/docs/index.html We chose NaturalDocs because it's easy to customize and handles a wide variety of file types. For example the compiling/installation manual is generated from a text file. That way you can download the source code, read the installation instructions as plain text and build the full documentation later. Maybe we should remove 'doc' from 'install' dependencies so you can build documentation (which needs NaturalDocs which then needs perl) independently. Gabe From zjnue.brzavi at googlemail.com Sat Sep 5 15:54:46 2009 From: zjnue.brzavi at googlemail.com (Zjnue Brzavi) Date: Sat, 5 Sep 2009 16:54:46 +0100 Subject: [SamHaXe] doc dependencies In-Reply-To: References: <372634f90909050732j28a59966g713a35fa4e1545eb@mail.gmail.com> Message-ID: <372634f90909050854w4905b625o9ae8270e6e1d6338@mail.gmail.com> >> Perhaps this can be overcome later by creating Neko bindings for >> NaturalDocs, or potentially use the Neko-based chxdoc like haxegui >> does: http://haxegui.googlecode.com/svn/trunk/docs/index.html > > We chose NaturalDocs because it's easy to customize and handles a wide > variety of file types. For example the compiling/installation manual > is generated from a text file. That way you can download the source > code, read the installation instructions as plain text and build the > full documentation later. Maybe we should remove 'doc' from 'install' > dependencies so you can build documentation (which needs NaturalDocs > which then needs perl) independently. NaturalDocs does look nice - new to me, so need to take a look. Not demanding any changes, just wanted to log the Perl factor as I forgot to mention it before. Zjnue From ron at mindless-labs.com Sun Sep 6 08:05:25 2009 From: ron at mindless-labs.com (Robin Palotai) Date: Sun, 06 Sep 2009 10:05:25 +0200 Subject: [SamHaXe] Are the rumours true ?! In-Reply-To: <372634f90909050721s72ab03c1obf2ceb35ce2a2bf3@mail.gmail.com> References: <372634f90909042246r2cfbbe49u9109d287aed69b63@mail.gmail.com> <372634f90909050721s72ab03c1obf2ceb35ce2a2bf3@mail.gmail.com> Message-ID: <4AA36D45.3080806@mindless-labs.com> Hi, In my opinion, mixing resource declarations into source code is not a good idea. By having a separate resource description file you have a centralised place of control - for example, if you would like to change the graphics used in different sprites, you can just do that by updating the resource file, while in the meta-description case you would have to locate and modify different sources. However, this is a matter of taste. If you would like to do something like this, the process would be to build using rtti, parse the comments, generate a resource description file, build asset lib, rebuild swf without rtti. Best regards, Robin Zjnue Brzavi ?rta: >> Well, what preloading in this context means is that you place only a >> few (in bytes) assets on the first frame so flash player can start >> playing your animation early. AS3 code generated by haXe comipler >> resides on the first frame so as long as most of your assets are on >> the second (third, fourth, etc.) frame flash player executes your code >> long before loading the whole file. You can then monitor loading >> progress with an Event.ENTER_FRAME event handler as demonstrated in >> PreloadingDemo. >> Preloading with swfmill was problematic because flash player needs >> an AS3 class stub for every asset with a symbol class. HaXe generates >> class stubs for assets automatically but only on the first frame. So >> if you put an asset on the second frame with swfmill there wasn't any >> AS3 class stub generated and flash player threw an error. Sam HaXe >> generates AS3 class stubs for you (if you want) so you can put your >> asset on the frame you like. >> > > Hi Gabe! > > I was actually teasing a bit, but I'm glad I did, because now I > understand the AS3 class stub role better, thanks! > > What I was getting at relates to two topics discussed or mentioned > briefly on the haXe list recently: > > One is that maybe the SWF building exercise (which the haXe compiler > also takes care of, currently), could be centralized into a modular > unit - and I was playing with the idea that this may be a samhaxe > module :) > > The other thing that sounds interesting is to allow > metadata/annotations for assets within haXe code, in comments, where > applicable. This seems easier to achieve for a compiler that can > delegate the task (information) to a specialized asset tool such as > samhaxe... > > Not sure if there is a notion to manage assets for another targets > besides flash, but that may be an interesting thought also. Perhaps > even -resource stuff, but that's maybe going a bit far? > > Just a few quick comments, not much time, but been a pleasure to look > at the code, even just briefly. > > All the best, > > Zjnue > _______________________________________________ > Sam HaXe - the friendly asset > From zjnue.brzavi at googlemail.com Sun Sep 6 12:54:56 2009 From: zjnue.brzavi at googlemail.com (Zjnue Brzavi) Date: Sun, 6 Sep 2009 13:54:56 +0100 Subject: [SamHaXe] Are the rumours true ?! In-Reply-To: <4AA36D45.3080806@mindless-labs.com> References: <372634f90909042246r2cfbbe49u9109d287aed69b63@mail.gmail.com> <372634f90909050721s72ab03c1obf2ceb35ce2a2bf3@mail.gmail.com> <4AA36D45.3080806@mindless-labs.com> Message-ID: <372634f90909060554r53df133cpc3d59154c25e10db@mail.gmail.com> > In my opinion, mixing resource declarations into source code is not a good > idea. By having a separate resource description file you have a centralised > place of control - for example, if you would like to change the graphics > used in different sprites, you can just do that by updating the resource > file, while in the meta-description case you would have to locate and modify > different sources. > > However, this is a matter of taste. If you would like to do something like > this, the process would be to build using rtti, parse the comments, generate > a resource description file, build asset lib, rebuild swf without rtti. Hi Robin, Thank you for the answer. Yes, will need to give it more thought - an external file sounds cleaner. Anyway, just wanted to scratch at some possibilities :) All the best, Zjnue From ron at mindless-labs.com Sat Sep 12 20:45:59 2009 From: ron at mindless-labs.com (Robin Palotai) Date: Sat, 12 Sep 2009 22:45:59 +0200 Subject: [SamHaXe] new svn release Message-ID: <4AAC0887.7040909@mindless-labs.com> Hi, Version R13 is out in svn and as Windows binary, fixing a bug which prevented accessing class definitions when loading the asset swf runtime. Thanks for Anton Truhan and Axel Huizinga for noting. Please check and report if anything seems buggy :) Best regards, Robin From ron at mindless-labs.com Sun Sep 20 10:20:34 2009 From: ron at mindless-labs.com (Robin Palotai) Date: Sun, 20 Sep 2009 12:20:34 +0200 Subject: [SamHaXe] SamHaxe preloader example Message-ID: <4AB601F2.3070602@mindless-labs.com> Hi, a small example of Haxe preloading is described at http://mindless-labs.com/blog/archive/2009/09/20/Preloading_example_with_Haxe_and_SamHaxe , for those who are interested. Feel free to comment! Robin