At 4/10/14 10:41 AM, GeoKureli wrote: I heard Haxe has some crazy for loop style inline array declaration, so I can create a for loop with ordered multiples of 2 up to 100. is that a thing?

I heard Haxe has some crazy for loop style inline array declaration, so I can create *an array* with ordered multiples of 2 up to 100 *in one line*. is that a thing?

At 4/10/14 10:41 AM, GeoKureli wrote: switches without breaks, what if several groups of values have the same outcome?

I don't quite understand. The breaks are implied, if you wan't the same effect as a fall-through switch case:

Std.is (vehicle, Car)
why not just make a it a damn operator?

Yeah, I find it strange it's not an infix operator.

var car:Car = cast vehicle;

why change it at all.

I'd much a C-like cast

public var x (get, set):Float;
function get_x ():Float { return _x; }
function set_x (value:Float):Float { return _x = value; }

I'm half for this and half against it, but why the underscore in the function name?

Do they have to have the underscore? I'm really not sure, I tend to just write my own getter and setter which aren't actual proper ones (I'm such a bad programmer).

basically, if ou have the ability to change AS3 to look like this, why not just make it look like C#?

Good points:

function hello (msg:String):Void {}
var type:String->Void = hello;

that's just genius! maybe even better than C# delegates.

Someone correct me if I'm wrong, but is this functions being "first-class citizens"? Anyway, agreed, it's nice. The functional programming module I took actually might help me with something after all!

I heard Haxe has some crazy for loop style inline array declaration, so I can create a for loop with ordered multiples of 2 up to 100. is that a thing?

I know you can do that with lists in Python, but I've not tried or seen it done in haXe.

At 4/10/14 10:44 AM, GeoKureli wrote:

At 4/10/14 10:41 AM, GeoKureli wrote: I heard Haxe has some crazy for loop style inline array declaration, so I can create a for loop with ordered multiples of 2 up to 100. is that a thing?

I heard Haxe has some crazy for loop style inline array declaration, so I can create *an array* with ordered multiples of 2 up to 100 *in one line*. is that a thing?

Array comprehension is amazing, plus the great and powerful Lambda for other goodies.

You can use traditional for loops as well.

From Nic on underscores:
"Syntax is a not beauty contest, it's here to express a given semantics,
and while sometimes we need to abstract things out to write quick
programs (such as for...in), most of the time, having the syntax
expressing what will actually happen at runtime.

That's why I'm still in favor of using get_xxx/set_xxx, because we need
to create actual real methods that will be callable at runtime and
visible through reflection. Hiding them by using abstract concepts will
just trigger more misunderstanding by the haXe user."

At 4/10/14 10:23 AM, Sam wrote: One thing that I think is a bad design choice is the omission of the protected keyword, and the change of the private keyword to be what protected means in AS3.

You could make a public var with set access set to "never." It would still be gettable from within subclasses, but setting would throw an error.

At 4/10/14 11:18 AM, MSGhero wrote: You could make a public var with set access set to "never." It would still be gettable from within subclasses, but setting would throw an error.

Or maybe set and get are set to "null." Idk never tried it, not sure if subclasses still have access.

At 4/10/14 11:18 AM, MSGhero wrote: var a = [for (i in 0...100) if (i % 2 == 0) i];
Lib.trace(a); // 0,2,4,6,...

It'd be nice if the IntIterator included a step variable rather than just a min and max.

From Nic on underscores:
"Syntax is a not beauty contest, it's here to express a given semantics,
and while sometimes we need to abstract things out to write quick
programs (such as for...in), most of the time, having the syntax
expressing what will actually happen at runtime.

That's why I'm still in favor of using get_xxx/set_xxx, because we need
to create actual real methods that will be callable at runtime and
visible through reflection. Hiding them by using abstract concepts will
just trigger more misunderstanding by the haXe user."

Generally, what are your opinions on using essentially empty getters and setters? I should definitely start using the correct syntax for them, but the only time I use them now is when I need to do some checks or calculations before setting and getting. If they're empty (return x, x = X), then I really see it pointless and just set the scope to public.

At 4/10/14 10:23 AM, Sam wrote:

You could make a public var with set access set to "never." It would still be gettable from within subclasses, but setting would throw an error.

Good to know.

At 4/10/14 11:31 AM, Sam wrote:

At 4/10/14 11:18 AM, MSGhero wrote: var a = [for (i in 0...100) if (i % 2 == 0) i];
Lib.trace(a); // 0,2,4,6,...

It'd be nice if the IntIterator included a step variable rather than just a min and max.

Use array comprehension maybe? Kinda gross.

Generally, what are your opinions on using essentially empty getters and setters? I should definitely start using the correct syntax for them, but the only time I use them now is when I need to do some checks or calculations before setting and getting. If they're empty (return x, x = X), then I really see it pointless and just set the scope to public.

If set and get are both empty, I just leave it public and don't add access modifiers. Which would be the same as doing

"default" uses the empties, so you could go (default, null) for read-only access.

At 4/10/14 11:14 AM, Sam wrote: switch(value)
{
case c1, c2:
trace("Matched");
}

Awesome, thanks! Didn't know I could comma delimit.

I'd much a C-like cast
(Car) vehicle;

Right, just some kind of type indicator

howver Haxe has a nice Type.getType(), util, if its not as costly as reflections, then there's a lot of parts in my serializer that could benefit from:

rather than a series of if(x is y)

Do they have to have the underscore? I'm really not sure, I tend to just write my own getter and setter which aren't actual proper ones (I'm such a bad programmer).

You mean like this:

If it's any consolation, property-like getters are overused by bad programmers, sometime you need that parenthesis to say "Hey there's more going on here, don't treat me like a variable"

At 4/10/14 11:18 AM, MSGhero wrote: Array comprehension is amazing, plus the great and powerful Lambda for other goodies.

var a = [for (i in 0...100) if (i % 2 == 0) i];
Lib.trace(a); // 0,2,4,6,...

yeah, that's what I was thinking of. But this raises a previous suspicion I was worried about. In the "Loops" section of PSVills link, the as3 section has type declarations, where Haxe does not. do I just not have to type loop incrementers?

You can use traditional for loops as well.

good to know.

From Nic on underscores:
That's why I'm still in favor of using get_xxx/set_xxx, because we need
to create actual real methods that will be callable at runtime and
visible through reflection. Hiding them by using abstract concepts will
just trigger more misunderstanding by the haXe user."

I guess that makes sense, but when would I use reflection on a getter/setter? I guess you can use it like a pointer or something. either way using C# style get/set and having a Reflect.findGetter(thing, 'x'), would be preferable.

At 4/10/14 10:23 AM, Sam wrote: One thing that I think is a bad design choice is the omission of the protected keyword, and the change of the private keyword to be what protected means in AS3.

You could make a public var with set access set to "never." It would still be gettable from within subclasses, but setting would throw an error.

It's just lame, one of the main benefits of encapsulation is not having every private variable pop up when I type 'this.' in a derived class.

At 4/10/14 11:42 AM, MSGhero wrote: for (i in [for (j in 0...100) if (j % 2 == 0) j]) {
do stuff to evens
}

why not just:

also, it would be nice if that slimmed down for loop had a way to specify an interval other than one, I.E.: -1 or 2

something like :

At 4/10/14 12:34 PM, GeoKureli wrote: You mean like this:

public function getX():Number { return _x; }

Yeah, exactly.

If it's any consolation, property-like getters are overused by bad programmers, sometime you need that parenthesis to say "Hey there's more going on here, don't treat me like a variable"

I suppose, but using the getters and setter syntax with the variable function visibility (is that even a correct way of describing it?) is still something I should be conforming to I think. It irks me a lot when getters and setters are written and all they do is return or set with no other logic - I see no value to it, it just creates lots of redundant methods. It must have been a practice taught by my lecturers in one of their Java lectures because when working with people on my course, they all do it.

It's just lame, one of the main benefits of encapsulation is not having every private variable pop up when I type 'this.' in a derived class.

This. I thought FD was bugging out when it was showing my private definitions in the subclasses. It was only when I tried to write "protected" I realised it wasn't used in Haxe.

why not just:

for (i in 0...100) if (i % 2 == 0) {
do stuff to evens
}

Well, considering the original array was just the index multiplied by 2 and was scoped to the loop, you could halve the loops and multiple i, right?

Obviously the example was showing more than that from MSGhero but you know...

Also, I just realised I was typing Haxe like "haXe". Am I going mad or was it previously stylised like that?

At 4/10/14 12:34 PM, GeoKureli wrote: for(i in 0...100; i+=2)

Sorry for the double post, but I quite like:

At 4/10/14 12:57 PM, Sam wrote: using the getters and setter syntax with the variable function visibility is still something I should be conforming to I think.

Well, yeah. totally use them they're awesome. just don't go overboard like people at my office.

why not
for (i in 0...100) if (i % 2 == 0) {
do stuff to evens
}

Well, considering the original array was just the index multiplied by 2 and was scoped to the loop, you could halve the loops and multiple i, right?

Durr, can't believe I couldn't think of that.

Also, I just realised I was typing Haxe like "haXe". Am I going mad or was it previously stylised like that?

Yes

At 4/10/14 01:00 PM, Sam wrote:

At 4/10/14 12:34 PM, GeoKureli wrote:

k

On phone

You don't have to type anything except for class level vars. haXe (pronounced hex) and FD as of a couple nightlies ago can figure out what type it is. Code completion bring up private vars is annoying, even public vars within a huge class like Sprite. I wish it organized it like eclipse where this subclass's stuff shows up first, and maybe private stuff separated from public.

Next subject

http://haxe.org/ref/inline

they cannot be redefined at runtime

does this only apply to inline anonymous functions? Is there such a thing?

they cannot be overridden in subclasses
an function containing "super" accesses or declare another function cannot be inlined

^ makes sense, surprised inline isn't the default

if the inline function has arguments, then the arguments evaluation order is undefined and some arguments might even be not evaluated, which is good unless they have some expected side-effects

no idea what that means

if the inline returns a value, then only "final returns" are accepted, for example :

This isn't horrible, but weird, it's like a C++ pre-compiler #define. although I like the syntax of these more because it's object oriented. I have a feeling that I'll be making a ton of inline things and eventually removing the inline keyword when I need to, leaving a bunch of weird "else return null;" and people will think I'm stupid.

At 4/10/14 02:19 PM, GeoKureli wrote:

they cannot be redefined at runtime

does this only apply to inline anonymous functions? Is there such a thing?

It's a (pre)compile-time feature, so no that's not possible. It's basically a const function (static inline var = const).

This isn't horrible, but weird, it's like a C++ pre-compiler #define. although I like the syntax of these more because it's object oriented. I have a feeling that I'll be making a ton of inline things and eventually removing the inline keyword when I need to, leaving a bunch of weird "else return null;" and people will think I'm stupid.

For me inlining is part of "don't optimize early." Simple things, like converting cartesian to isometric and vice versa, are ok, but actual meaty functions I'm leaving alone for now.

At 4/10/14 02:31 PM, MSGhero wrote: For me inlining is part of "don't optimize early." Simple things, like converting cartesian to isometric and vice versa, are ok, but actual meaty functions I'm leaving alone for now.

you should (almost) never explicitly inline functions, the compiler will do it on its own when it makes sense to. And if you ever manually inline a function you should always do performance tests on it to make sure it actually makes an impact.

Smaller code has benefit sometimes, less code in memory means less chance for cache issues

http://en.wikipedia.org/wiki/Inline_expansion#Problems

specifically
"The increase in code size may cause a small, critical section of code to no longer fit in the cache, causing cache misses and slowdown."

this is not just based on the size of the function you're explicitly inlining, but also how many times its actually called in a block (like a for loop, for instance). If the inner loop with all inlined functions expands too much, it can start slowing down

just let the compiler do what it's supposed to do

I was about to complain about the haxe trace statement how it only takes one parameter and not a ...args like in as3. I was about to hate on java and everyone else who does that. Then I realized I could put the parameters into my own array and trace that. Beats what I used to do:

It did have a nice rhythm when typing it, though.

Still working on the server-side of my game. I have authentication totally working now on client and server. Now I am moving on to writing gameplay code on the server-side, and porting code over from the prototype and cleaning it up. I'm hoping I have something interactive and playable in the next few weeks. I have already finished a lot of the client work of rendering units, and the game board. I'm kind of approaching it from both ends which will hopefully eventually connect.

Pic related: epic screenshot

At 4/12/14 01:22 PM, PrettyMuchBryce wrote: Pic related: epic screenshot

Nice fps.

I made copyPixels for my last gameboy C programming assignment. Parameter mergeAlpha isn't very useful here, though.

Yay, screenshot Saturday. I'm fixing bugs and finishing a final game mode. Then it's on to the actual options menu, which I'm actually quite proud of :D

Developing for Android, on Android.

Apple should take note and open up iOS, though i highly doubt that would ever happen considering I've been developing apps for the platform since "iPhone OS 1.1.4" all of which would've been rejected by Apple if I submitted them in. If only more people were in the Android bandwagon, the platform would see a wider variety of quality apps and games. This is coming from a long-time Apple fan boy BTW :P

I've not done much in terms of programming recently because I have exams approaching way too quickly, but I've been trying to build a little framework to use. It's heavily influenced in terms of structure and naming by Flixel right now (it'll more than likely change as I work on it more), but there are a lot of things I didn't like with Flixel. So far all I have is drawing, state management, some "low level" classes and key input implemented but I'm happy with how it's working.

I'm not usually one for reinventing the wheel, but it's been fun to write. It's given me a chance to benchmark some stuff and learn the ins and outs of Haxe a little better.

At 4/13/14 12:52 PM, Sam wrote: but there are a lot of things I didn't like with Flixel

I don't like how my button has a health variable.

At 4/12/14 08:32 PM, slugrail wrote: Developing for Android, on Android.

I had to do some debugging on a kindle fire recently, and I was pleasantly surprised by adb. It didn't take long and I had shell access to the device. I was thinking.. wow. I was surprised that Android gives the end user so much control. You could never do that with Apple's blessing on an iOS device.

At 4/12/14 08:32 PM, slugrail wrote: Developing for Android, on Android.

Apple should take note and open up iOS, though i highly doubt that would ever happen considering I've been developing apps for the platform since "iPhone OS 1.1.4" all of which would've been rejected by Apple if I submitted them in. If only more people were in the Android bandwagon, the platform would see a wider variety of quality apps and games. This is coming from a long-time Apple fan boy BTW :P

more people DO use android, but nobody buys stuff on android, iOS is like 20x the rev on apps than android for the same app

At 4/13/14 01:04 PM, MSGhero wrote:

At 4/13/14 12:52 PM, Sam wrote: but there are a lot of things I didn't like with Flixel

I don't like how my button has a health variable.

I've got mixed feelings towards things like that. a lot of things make sense to have in FlxSprite, but I'm still really happy they ended up in FlxObject.

At 4/14/14 01:59 AM, GeoKureli wrote: I've got mixed feelings towards things like that. a lot of things make sense to have in FlxSprite, but I'm still really happy they ended up in FlxObject.

FlxButton extends FlxSprite anyway, I think.

MSG, when you make a game one day about killing clickable buttons and Flixel takes the health variable away from you, then you'll be very sad :(

At 4/14/14 02:32 AM, egg82 wrote: FlxButton extends FlxSprite anyway, I think.

I'm just referring to the idea of putting 9% of the functionality way up in the hierarchy base. You get a lot of unused properties in many derived classes, but it's safer in the long. but honestly after trying unity, I wish flixel (and everything else) adopted it's component structure instead of having an awesome beefy base class.

At 4/14/14 03:04 AM, GeoKureli wrote: I'm just referring to the idea of putting 9% of the functionality way up in the hierarchy base.

meant to say 90%*

At 4/13/14 07:43 PM, Glaiel-Gamer wrote:

At 4/12/14 08:32 PM, slugrail wrote: Developing for Android, on Android.

Apple should take note and open up iOS, though i highly doubt that would ever happen considering I've been developing apps for the platform since "iPhone OS 1.1.4" all of which would've been rejected by Apple if I submitted them in. If only more people were in the Android bandwagon, the platform would see a wider variety of quality apps and games. This is coming from a long-time Apple fan boy BTW :P

more people DO use android, but nobody buys stuff on android, iOS is like 20x the rev on apps than android for the same app

Wow 20x??!!?
I assumed it would be higher (because iOS users obviously have money to burn) but not that much higher! Have you got a source on this?

If your app is ad supported I guess it doesn't make a difference, but are we talking in-app sales or straight up app purchases?

At 4/14/14 05:44 AM, Rustygames wrote: Wow 20x??!!?
I assumed it would be higher (because iOS users obviously have money to burn) but not that much higher! Have you got a source on this?

Partly due to it being a lot easier to download apps for Android and install them not from the Play Store.

At 4/14/14 05:44 AM, Rustygames wrote: Wow 20x??!!?
I assumed it would be higher (because iOS users obviously have money to burn) but not that much higher! Have you got a source on this?

I've gotten some numbers in private from friends who have made successful games for both platforms.

reasons mostly:
- iOS users are more likely to spend money on software
- iOS users are more likely to have up to date hardware [lots of android devices are old or lower spec]
- apple's storefront promotes games a lot better
- android offers app refunds no questions asked within 24 hours
- piracy is a ton easier on android
- toucharcade.com is a MASSIVE influencer on iOS sales