|
Viewing 1 to (72 Total) |
|
Geo, is it possible to share your benchmarks?
Posted on July 31, 2012 at 11:52 AM
|
|
Have SFMLhttp://www.sfml-dev.org ever been considered as an alternative to SDL? It is more up-to-date and it's licensing is very liberal.
Posted on July 29, 2012 at 4:39 AM
|
|
Sorry again for stressing the matter, but it would've been great to hear some input - I still am not sure if this behavior isn't my fault somehow 
Posted on July 29, 2012 at 4:22 AM
|
|
I am able and willing to participate in modifying haXe Box2D port in attempt to increase it's effectiveness, but it's not reasonable to disregard Native Extension for cpp box2d (it uses floats).
libgdx (http://code.google.com/p/libgdx/) went that way with box2d - they did a jni wrapper. It is a really good reference in terms of what bits of code should be wrapped for external use.
Posted on July 29, 2012 at 4:12 AM
|
|
Thinking about physics - would it be reasonable to create a native extension (not the haxe version) of box2d? It would be quite a lot of work, but it would basically grant us native physics performance. Or there is something I'm not taking into account?
Posted on July 28, 2012 at 3:59 PM
|
|
Forgot to add: hxcpp, NME and gm2d are all svn versions.
Posted on July 27, 2012 at 1:55 PM
|
|
package;
import nme.display.Bitmap;
import nme.display.BitmapData;
import nme.display.Shape;
import nme.display.Sprite;
import nme.geom.Matrix;
import nme.Vector;
/**
* ...
* @author MagicForge vorren
*/
class MeshGeneration extends Sprite
{
public function new()
{
super();
var tex:BitmapData = new BitmapData(16, 16, false, 0xffffff);
var img:Shape = new Shape();
img.graphics.beginFill(0xff0000);
img.graphics.drawRect(0, 0, 16, 16);
img.graphics.endFill();
img.graphics.beginFill(0x555fff);
img.graphics.drawRect(5, 5, 6, 6);
img.graphics.endFill();
tex.draw(img);
var verts:Vector<Float> = new Vector();
verts.push(4);
verts.push(4);
verts.push(128);
verts.push(4);
verts.push(4);
verts.push(128);
var m:Matrix = new Matrix();
m.rotate(Math.PI / 4);
var bmp:Bitmap = new Bitmap(tex);
addChild(bmp);
bmp.x = 100;
graphics.clear();
graphics.beginBitmapFill(tex, m, true, true);
graphics.drawTriangles(verts);
graphics.endFill();
}
}
Conclusion: bitmapData.draw works consistently, so the texture is fine.
Posted on July 27, 2012 at 7:07 AM
|
|
I've tried to find any error in common/Graphics.cpp, but it is beyond my knowledge of the inner workings of nme  If the visual output is supposed to be exactly the same as flash target , then yes, it definitely is a bug, and important one - drawTriangles with bitmap textures is one of the performant rendering methods, and for such stuff as procedural caves - it's the way to go. If it is possible to take a look at the issue - I would be very gratefull
Posted on July 27, 2012 at 4:59 AM
|
|
Hi guys. I was doing a small experiment, which requires drawTriangles usage with floodfilling bitmap textures. Below is the sample code:
package;
import nme.display.Bitmap;
import nme.display.BitmapData;
import nme.display.Shape;
import nme.display.Sprite;
import nme.Vector;
class MeshGeneration extends Sprite
{
public function new()
{
super();
var tex:BitmapData = new BitmapData(16, 16, true, 0x00ffffff);
var img:Shape = new Shape();
img.graphics.beginFill(0x444444);
img.graphics.drawRect(0, 0, 16, 16);
img.graphics.endFill();
img.graphics.beginFill(0x555fff);
img.graphics.drawRect(5, 5, 6, 6);
img.graphics.endFill();
tex.draw(img);
var verts:Vector = new Vector();
verts.push(4);
verts.push(4);
verts.push(128);
verts.push(4);
verts.push(4);
verts.push(128);
graphics.beginBitmapFill(tex);
graphics.drawTriangles(verts);
}
}
For some reason cpp target (windows) behaves in a different way than flash target (flash does the texture filling ok, when cpp doesn't). Maybe I'm doing something wrong?
Posted on July 24, 2012 at 11:53 AM
|
|
Hi guys, could someone plz elaborate how to use cpp debugger that comes with haxe 2.10?
Posted on July 19, 2012 at 4:06 PM
|
|
NME's display list doesn't use batching because it's software, not mind-reader Display list objects, such as Bitmap operate with bitmapData objects, and some of the target platforms have bitmapData dimensions limits (iphone 3gs - 1024-1024, iphone4/ipad1/ipad2 - 2048-2048 etc.). That alone disables any adequate possibility to create under-the-hood batch renderer. IMHO.
Posted on July 01, 2012 at 10:19 AM
|
|
Hi guys!
This is a generic question, basically a wish for some sort of faq regarding the best practices and no-no's for haxe cpp target.
Example:
Don't use List over Array - the Iterator class is slow due to usage of member name to find next object in list
FastList is ok - it links objects to one another, and doesn't use Array as a backend
etc.
Posted on June 21, 2012 at 3:48 AM
|
|
As stated in topic - that's the issue. Basically bitmaps shouldn't capture mouse events at all. And the curious part - it doesn't. It just bubbles event to the parent (my scene), instead of bubbling it to other display objects on scene. Or at least it seems so
Posted on June 19, 2012 at 3:41 PM
|
|
@Zaphod
Hi, does your library support angelcode format? The way it parses through pixels is nice, but, well, redundant. Why do complex stuff, when we can have xml description file.
Posted on June 17, 2012 at 2:36 PM
|
|
Hi guys!
Memory management is crucial, especially for mobile development. With this notion in mind I thought that we should create a checklist (or maybe a small tutorial on nme website) of all the stuff, that could block GC of an object. Basically one should kill all references, but maybe there are some tricky things that I don't know? As for now I can think of the following:
-all event listeners (even if your object puts a listener on stage) should be removed, unless they use weak reference;
-if your object is placed in a data structure such as array, list, hash etc., it should be either removed from it, or the reference should be nulled
-an object, such as sprite can have children. If you want to kill it - get rid of the children because they have a reference to their parent (??? - could be wrong)
-beware bitmap objects. If you loaded an object via nme.Assets AND used caching - it could be dangerous to call yourBitmap.bitmapData.dispose() (in case other objects rely on the same bitmapData instance). Otherwise dispose of bitmapData explicitly.
-a special purge function (aka destructor) may be nice to have, in case the object is complex.
-null out the internals of your object - collections (arrays, hashes, lists, trees, whatever), bitmaps, sprites etc
Is it possible to force garbage collection? If it is - how? Is it crossplatform? This is a big topic of which all of the nme developers should be aware in order to maintain clean habbits of effective coding.
Please correct me if I'm wrong and add your knowledge to the list
Posted on June 14, 2012 at 6:19 PM
|
|
Jon, the issue you talk about (random graphics being drawn) can be (imho) brought by SparrowTilesheet.hx line:
if (defs[i].startsWith(name))
maybe your names start with the same word/letter pattern? In my case I had to rename my assets so that the names weren't too much alike.
Posted on June 12, 2012 at 1:38 PM
|
|
Mouse events:
getObjectUnderPoint is a prequisite for any pixelperfect mouse detection. If the number of children is more than certain N, than we should use space searching, otherwise - do bruteforce.
Registration point:
For now I wrote a small xml postprocessor, which adds centerX and centerY to the file, but that's a really bad solution just to get stuff done. Changing the spritesheet's registration point by code is great, but it would require to add capability to tilesheet interface to do that. No idea how that would be done. OR it's possible to do that via offsetX and offsetY private properties, not by actually changing texture rect center point.
We can create our own extended format with registration points and create exporter for (the tool that I use) TexturePacker, or any similiar product. But that seems to be less flexible all around.
Posted on June 10, 2012 at 11:14 AM
|
|
Philippe, may I suggest several much needed features for TileLayer, so that it can become really usefull without modifications?
-MouseEvents - a way to find a specific clicked object in tileLayer. As I see it, we would need some kind of space-searching algorythm + getpixel alpha-based decision wether to click through item, or throw a clicked event.
-support for animations and animation change + callbacks on completion, looping etc (but you already have some prefabs in place )
-registration point of BaseTile object. It's not allways correct to use tile center as it's registration point. That would require minor modification of SparrowTilesheet (or creation of new parser based on this one) + extending Sparrow format (thus creating our own?) with custom parameters centerX and centerY.
I've done some modifications to support all of these features, but this was done with an older version of tilelayer, and I'm using Events. I remember that you didn't want to to use Events, and wished to create a more lightweight callback system.
Thank's for your great work
Posted on June 10, 2012 at 7:23 AM
|
|
For now I decided to stick with File.applicationStorageDirectory.nativePath+"/dbName.db" . Maybe will have to change it for android, but for iOS it seems to work.
Posted on June 08, 2012 at 2:41 PM
|
|
Check TileLayer.hx . Philippe has done some refactoring as it seems, so yes - some stuff was changed
Posted on June 08, 2012 at 2:57 AM
|
