This is a very good question. Flash is obviously not going to disappear tomorrow, but its days are probably numbered, for many reasons. I'm personally removing it from all of my computers except my gamebox on principle alone. But you know why I'm keeping it on that box? Because it's really sproinking good at powering games! If you're comfortable with it already, why jump ship now?

Now let's talk about Haxe. I haven't used it but based on what I've heard my impression (for the $0.02 it's worth) is that it's simply too ambitious to really deploy to all those targets without a hitch. Too good to be true, once we move beyond Hello World and start making real things. Yes, it's similar to AS3 and you can use "Flixel", but I suspect (again this is just my hunch, I have no evidence to back this up) that it's JUST similar enough to throw you a curveball when you least suspect it. Ain't nothing like the real thing. Haxe is fascinating and I applaud the effort, but I don't think it will stick around.

So, what will? I have no clue. Could be JS. Maybe Elm. Maybe even some weird native thing like Rust or Jai. It's too soon to tell. As a long-time code monkey who tried but could never quite grok AS3, I'm sitting on the sidelines with C again while all these newcomers duke it out  .

That said, you should totes play around with Haxe and see if it's to your liking! But seriously bro, don't panic. No need to up and sacrifice all your hard-won AS3 knowledge (especially mid-project!) just because Flash might maybe someday fade away and Haxe might maybe someday rise to fill its shoes.

I'm glad I can finally watch YouTube on Linux without giving my firstborn...but Flash is far from dead.

It's actually a pretty gnarly problem to come precisely to a complete stop, check out https://en.wikipedia.org/wiki/PID_controller

Depending on how "physical" you want to be, you can cheat a little bit, e.g. once inside the radius switch to a linear deceleration or even a position lookup type thing. But I don't know of any concise way to get a perfect slowdown.

Personally I think toilet-bowling has character, but that's just me.

[Dig Dug + Rhythm]

Dig Dug + Rhythm

Dig on the beat. Some tiles may have a different cadence than others.

Uh, well CMake gets confused* in OSX and I have to fiddle with flags to get everything kosher. Then I get a black screen and a crash and this

Assertion failed: (p_tileset_), function init, file /Users/cheezmeister/stuff/hax/last-ditch-cpp/src/systems/RenderSystem.cpp, line 23.

I don't think that's your problem, though

* Looks like it doesn't ship with a FindSDL2.cmake. Are you providing your own?

Yeah I'm on a Mac. Hence the "broken implementation" comment. On the bright side, if it works here, it'll work anywhere, right? Right?

Thanks for the halp, everyone! :D

Man, this is frustrating. It seems as though a 3.3 context with a compatibility profile is simply not a thing. Or perhaps just not with my broken implementation. 3.0, 3.1, 3.2, no dice. SDL reports that it can't create the context without further detail. I finally managed to get a compat profile with 2.1 and render a triangle with #version 120 shaders, but it sure would be nice to start learning with the latest and greatest API. I cannot for the life of me get glDrawArrays() to succeed under any circumstances with a core profile. WTF?

It's not listed at all under glewinfo, although I'm not quite sure whether I should even expect it to be there...

Code:

% glewinfo | grep glDrawArrays
  glDrawArraysInstanced:                                       OK
  glDrawArraysInstancedANGLE:                                  MISSING
  glDrawArraysInstancedBaseInstance:                           MISSING
  glDrawArraysIndirect:                                        OK
  glDrawArraysInstancedARB:                                    OK
  glDrawArraysInstancedEXT:                                    MISSING
  glDrawArraysEXT:                                             MISSING

Call me jaded, but ain't it a little absurd to have to explicitly request a very specific context and utilize a 3rd-party (?) library, just to get a triangle on the screen? Yeesh.

Whatever. I can haz shaderz. Time to move on with my life.

Namespaces are the proper C++ solution.  Classes with static methods are largely a hack used by languages like Java that don't support free functions.

In other words, Namespaces are what JC would do.

More likely it's about whatever GMS puts into the exe. AFAIK, it does some peculiar form of zipping to bundle up all your assets into a single fat executable, and "peculiar" executables are the kind of thing that AV software looks for. That's just a guess, though.

Have you asked GM and/or Avira support if they can help you troubleshoot?

That's a great explanation, thanks Polly. Perhaps I could/should drop down to 2.1, but in any case I want to solve this because now it's personal =P

I also found the gl wiki article on compatibility mode illuminating. I haven't managed to get compat context, though. Here's what I'm currently working with: https://gist.github.com/Cheezmeister/70cd71c6c6359f412b1e

The output includes everything in the OP plus the following. Interestingly, if you remove the early return, the screen clears to cyan just fine even though glClearColor complains.

Code:

GLEW version: 1.11.0
clearcolor reported error: 1280
taking raw addresses:
glda is 1
gleva is 1
gldva is 1
SDL_GL_GetProcAddress:
glda is 1
gleva is 1
gldva is 1
enabling vaa reported error: 1282
drawing arrays reported error: 1282
disabling vaa reported error: 1282

I also noticed the following error if I try explicitly taking the address of the /VertexAttrib/ functions. What exactly is going on here?

Code:

gl.cpp:170:16: error: cannot initialize a variable of type 'void (*)(GLuint)' with an rvalue of type
      'PFNGLDISABLEVERTEXATTRIBARRAYPROC *' (aka 'void (**)(GLuint)')
        void (*gldva)(GLuint) = &glDisableVertexAttribArray;

Hitbox a.k.a. collision mask is what gets used to check for collisions. It never gets drawn. Unlike sprites, which are what gets drawn, but never used for collisions. This separation is how you get stuff like invisible checkpoints or pass-through walls.

Player State can mean a lot of things depending on context and how you choose to use it, but you might use it to track things like power-ups, stances, or hats.

A state machine is a weird idea that you don't really need to grok, but the picture in your tutorial pretty much sums it up. Sort of a more pedantic form of "state" where you don't have individual variables. It underlies much of computing and you can read the wikipedia page if you are so inclined.

I don't know a blasted thing about GML, so I can't help you there.

The "remainder" operation is called modulo, and it's usually present as either mod or "%" (percent) in just about every programming language ever. See http://en.wikipedia.org/wiki/Modular_arithmetic

Why are you using OpenGL Core anyway ( there are valid reasons for this, i'm just wondering )?

Missed this post. My understanding is that it's the lowest common denominator of new/recommended api, and I generally try to stick to the same--no platform left behind. If that's not the case, then you're right and I have no reason to use it, really.

Hi nox, jgrams, thanks for the input. Interspersing glGetError() calls with each line is exactly what I've been doing. None of the documented reasons apply, hence my confuzzlement. I didn't realize the matrix stacks and friends were removed too, but it makes sense, given shaders do all this plus wait there's more. Still, it'd be nice if they were present for dev purposes, even via some wonky degraded emulation, or even a GL_NOT_HERE_ANYMORE error code, throw me a bone here. Moot point, though.

After nixing the old moldy api calls, calling glewInit() and finally wiring up some shaders (yes they're compiling successfully), all the calls to /gl.*Array.*/ are still failing. I have yet to try SDL_GL_GetProcAddress(), but tomorrow's another day. This is why we can't have nice things.

Hi motorherp!

Sounds like you need to include and initialise GLEW

Sorry, I don't follow. Am I using extensions here without realizing it? Are random, copious 1282 errors an indication of that? Or does glew provide some other diagnostics that'll help me figure out what's going on?

Well, I sprinkled  `glGetError` checks everywhere, and there are 1282 (invalid operation) codes getting thrown all over the place. glDrawArrays reports 1282, glColor does also, and interestingly, the innocuous line `glMatrixMode(GL_MODELVIEW);` throws it as well.

So at least there's something to go on.

Thanks for taking a look. I'm trying to avoid shaders (at first) to cut down on confounding factors.

There's no particular reason for the w coord, I think that's how the arcsynthesis tut does it but I can try without and see what happens.

Are you recommending I use the color buffer when drawing triangles? Can I do that?

I decided to take another stab at GL, and starting to remember why I gave up the first time around. I've been loosely following the arcsynthesis tutorial, using SDL instead of glut. I've gotten as far as opening a window and filling it with blue. Trying to get a triangle on the screen without cheating with immediate mode, setting a flat color instead of a shader for the time being.

Nothing's being drawn, there's no error reported, and I'm not sure how to diagnose further. I'm working on a macbook, which I understand has pitiful gl support, but challenge accepted.

The whole code is here:
https://gist.github.com/anonymous/5316e620c0881f625c59

The snippet in question is

Code:

        glColor3f(0, 0, 1.0);
        glBindBuffer(GL_ARRAY_BUFFER, vbo);
        glEnableVertexAttribArray(0);
        glVertexAttribPointer(0, 4, GL_FLOAT, GL_FALSE, 0, 0);
        glDrawArrays(GL_TRIANGLES, 0, 3);

Reported at runtime:

Code:

        SDL version: 2.03
        runtime version: 2.03
        OpenGL vendor: 'Intel Inc.'
        OpenGL renderer: 'Intel HD Graphics 3000 OpenGL Engine'
        OpenGL version: '3.3 INTEL-8.24.16'
        GLSL version: '3.30'

What am I doing wrong here? 

I really love the idea of starting with music first, then building a game rather than the other way around.

Hey, me too! I'm a professional code monkey, and I've been keen to collab with a musician on some kind of sonic delight. Drop me a mail with what you're hoping to accomplish, maybe we can help each other out.

On topic, I love CoffeeScript something fierce, but I think it's important to start with JS (it's a very simple language compared to Python, and CoffeeScript itself) so you know the pitfalls and gotchas, what coffee buys you and what it doesn't, and how to troubleshoot when (not if) funky stuff happens. Crawl before you walk and all that.

I love me some TDD but as others have pointed out,  it's just not well-suited to gameplay logic. It'd generally cost you more in terms of dev time than it saves in terms of bugs avoided.

I can definitely see it being useful for core logic and utils, though.

As they say "as you think, so you become". We have enough man slaughtering games as it is.

Arguably. I'd say it really and critically depends on the style/aesthetic/feel/vibe you're going for. If it's an aggressive, competitive, old-school-cool kind of arcade game, you *know* 90% of your players--including the 5-year-olds--are going to call it shooting, killing and dying anyway, so IMO, why bother?

On the other hand, if you're crafting more of a make-blooms-not-war kind of title, I *would* tone the verbiage down, in which case, yup, thesaurus!

My $0.02!