next »

[Ina Vegt]

Mikademus, that was two days ago. I had no intentions to start anything like that, and I don't think I did. First there was (what I thought was) a claim that Java wasn't fast enough. I felt it was relevant to point out that it is. When doing so I said some stupid things, which st33d pointed out. I then wanted to clarify what I meant. In both cases I wanted prevent bad information from spreading (in the first case no-one was wrong, in the second case I was wrong).

Edit:
Ina Vegt: You have accidentally misquoted me. It was drChengele who said that

Yes, I did. Sorry.

[Juhkystar]

Hmmm, just to clarify, this is a 2D game we are trying to create, although we can just as easily do it in 3D. Just throwing it out there (jtiot), but what does anyone think about Unity? I personally don't think it would be as flexible for us, but hey, you never know...

I think you may be better off using an API that is specifically designed for drawing 2D-graphics for games. There are so many things that can go wrong and take time, to begin with. When prototyping I think you want as distractions as possible (like the ability to use 3D-effects). If you have the opportunity to start using super-fancy stuff, it's way too easy to get distracted by it (I think).

Though if your main focus is making cool graphics, using 3D can he very helpful from what I understand. (But even then, prototyping in pure 2D with programmer-graphics can still be a great idea)

Great. Exactly the last bit I needed.

Thanks for giving us some direction guys, now it's just up to us to dig into the process of coding. Yea, we're still using GM to rapid prototype ideas and get a feel for how they'll look. Unless Burr has anymore Q's I think that wraps it up.

[drChengele]

Oh, right, I just now saw that it's 2D. I don't know how I got it into my head that it was a 3d game. I mean, it's right there in the thread title ffs    .

Well, then you run into the problem of manually keeping track of those pointers. Which in any sizable project is -quite- difficult. You also need to remember to free the memory those pointers point to, etcetera.
That's asking for memory leaks there.

Of course, development-time-wise that can be uneconomic. Fortunately I have a pretty tight grip on my code, I very rarely encounter bad pointer trouble, and it's never dramatic. I hear there are multiple ways of implementing safe pointers but I never felt the need for it. I fully expect that some day I might get stuck for 3 days trying to find an obscure lost pointer and reconsider my position.

Yea, we're still using GM to rapid prototype ideas and get a feel for how they'll look.

That's an awesome way to develop games and you should feel awesome.

[LemonScented]

I'm looking at the screenshot in the initial post (and the language war which appears to be trying to break out), and I can't help but feel that there's a big piece of this puzzle missing. Any language worth it's salt, on Any modern PC should be able to handle the stuff I see in that screenshot without breaking a sweat.

I'm going to sound horribly patronising here, but the question needs to be asked. Are you absolutely certain that the problem is the choice of language here? Have you profiled the game, optimised the obvious bottlenecks, and come to the definitive conclusion that there's absolutely nothing wrong with your code that can be explained by anything other than the language it's written in? Are you certain that the algorithms that you're using are adequate for the effects you're trying to achieve, and that there aren't other approaches that would get you the same (or similar) results an order of magnitude faster?

Games are complex realtime simulations, and a lot of astonishingly clever people have come up with astonishingly clever approaches to getting cool stuff happening onscreen as quickly as possible. I don't really know the ins and outs of GM but I don't see anything in the original post which would indicate that you're pushing it beyond its limits.

EDIT: I just went back and re-read the whole thread, and realised that a lot of other people have been saying what I've been saying. I think the point still stands that a request for a new language/framework is likely to be met with scepticism unless you can show that you've profiled the game enough to demonstrate that you've already ruled out the other options. Can you give some kind of performance breakdown of what you have now, to show where the spikes are? Could you describe your approach to some of the slower parts of the game (or post source) to see if anyone could suggest a better way of doing things without having to switch language? I'm not advocating any particular language or approach over any other, I'm just saying that if you've been suitably diligent in squeezing the most out of the tools you're using right now, you haven't shown it.

[st33d]

I actually did a group by group test with our objects.

I think we've covered that.

[Dacke]

(The language discussion actually originated in the "any language would do"-discussion.)

But on to something else:

I actually did a group by group test with our objects.

I think we've covered that.

I don't think testing objects on their own is necessarily enough.

The first thing I thought about was collision detection. If you have a world full of objects and everything can collide with everything else.. that's a lot of collisions to check for.

If you check every object against every other object, you will end up with O(n²) collisions to check for. That is: with 10 objects you have to make 45 checks each frame (which isn't bad). But with more objects, say a thousand (which isn't that much) you will get half a million collisions checks each frame. The number of checks keeps growing faster for every object you add.

It's quite possible that GM handles this for you. But if checks are made in a naïve way, you will get in to trouble. Any language will collapse under the weight, as you add more objects (if using a check-everything-against-everything algorithm).

There are also many other things in a game that can give you a bad time-complexity. It's something you have to watch our for.

It's even quite common to end up with algorithms that have a much worse time-complexity. Brute-force solutions for common problems can take 4 seconds for 10 items and about 10000000000000000000000000 years for 30 items. (Time complexity: O(n!))

[Juhkystar]

It's more like we anticipate encountering more problems as we add more objects. If we are losing fps already, albietly only about 5-10 frames on Burr's faster computer, when start adding things like enemies and creatures with their own AI, particles, bullets, etc. we will start running into major problems. Basically we are trying to stop a huge problem before it makes us rethink our strategy. Besides, there are quite a few more resources set up for more tradditional approaches and we'd like to also expand knowledge into that realm. It's partly personal preference to move away from GM and also because we'd like to take advantage of extra scripts and libraries out on the internet.

As to the thing about collision checking. I actually rearranged the collision code so that only the player and bullets checked for collisions. If they collided with another object, they activated the user0 event which I made the universal custom collision event. It helps a lot especially with the vine physics I added in...
[Edit to continue my line of thought. Had to go to work before...]
So basically my strategy for collisions is to cut down on making everything react. Yes, we do want everything to react with everything else, but there are different levels of interaction. EXAMPLE: The plant object doesn't need to check for collisions with enemies, the player, and bullets that drastically alter it's velocity and acceleration - those afermentioned objects can just tell the plant that it is being collided with. However, the plant may need to know about more passive things such as mildly bumping into another plant. But we can just check that about once a second without any visible delay, especially if the alarm is set to random(60) the first time so the checks are staggered. Once triggered, the plants can just exceute a one line velocity script to move away from each other until the next check.

[Falmil]

This is what I hate about programming in general. You might start in one language or using one library heavily, find out down the road that its insufficient, and then have to switch to a different language or important library. All I want is an easy way to port my code (algorithms) across different languages.
HaXe seems like a potential half solution to this because you can use one language to compile to many other languages, but I haven't tried out any language targets except for flash, and since I couldn't embed resources directly, I just said I would go back to it later.

[Juhkystar]

Oh yes, it's going to be a bit of a pain to convert our code over. Mainly because it's so basic compared to what C++ or C# requires. Maybe we should all just code in binary...

Sprink Break next week so I'll be testing XNA and C++ libraries then. Hopefully get the basic framework up in each to compare.

[st33d]

So weird...

I had a 1000+ bullets flying around the screen - all checking for collision - and monsters that were being generated from my own scripting language that was being parsed by regex.

In Flash.

And it still ran fine.

http://www.nitrome.com/games/fatcat

Bear in mind that it doesn't go mental till the 4th level. We had to nerf it up to level 10 to make it accessible.

[Dacke]

Juhkystar, that's an excellent idea on cutting down on collisions checks. I approve.
Another thing you can do is to only update things that are within view. If something is out of sight, you can get away with only updating them once in a while (or never, as in Spelunky).

St33d, I assume you didn't collide the bullets with each other?
If you have 1000 enemy bullets colliding with 1 player ship, you get 1000 checks.
If you have 1000 bullets that can collide with each other, you get 499500 checks.
(Both things are totally manageable, but you probably need to be clever about the second one.)  

[st33d]

So why not have a grid of data on screen that objects register themselves to. Any object in that grid square checks for interaction with its flatmates?

Like a fluid simulation.

[Falmil]

This is what QuadTrees are for.

[Dacke]

Indeed. All I'm saying is:
If you get big slowdowns, it can because the use of algorithms with bad time complexity. You would get the same problem no matter what language you were using. It can be a good idea to make sure you don't have any naïve/problematic algorithms slowing you down.

The good news is that there are clever solutions for most things. In this case good solutions could indeed be grids or quad trees or selective updating. It's just that you have to actively make sure to use something like that if you have lots of colliding objects (GM may do this automatically for you already).

This is just a common example, though. There are plenty of other things that can give you rampant computational trouble.

[nikki]

in my experience there is a 95% change the slowdown comes from the amount of your flip/blit/draw commands

[Dacke]

Does GM automatically make sure not to draw things that are out of sight?

[Juhkystar]

So why not have a grid of data on screen that objects register themselves to. Any object in that grid square checks for interaction with its flatmates?

Like a fluid simulation.

Quad Trees? Collision Grids? This is where my inexperience shows. I'm guessing that the grid collisions only check a certain area for collisions, so it's a coordinate check first, then a boundry check for instances within the selected area. No clue what Quad Trees are though. 

Does GM automatically make sure not to draw things that are out of sight?

Hmmmm... I have absolutely no clue, but we are deactivating instances in GM once they are a certain distance out of view, and when we start largescale generative world testing, we'll actually just destroy instances that are way too far out and assume that the ships in the area have moved off or the fuana and creatures have drifted into new positions.

I'm actually trying to figure out whether or not you can deactivate instances in C++/C#. I mean, it makes sense that you can, but I don't know how yet...

in my experience there is a 95% change the slowdown comes from the amount of your flip/blit/draw commands

We have a lot of draw commands. One huge problem with drawing we've had is the clouds (Mist, Algea, Gas, etc.). We have them layered so some are above and below the player, and they move according to the correct depth perspective to give a pseudo-3D feel to the environment. But we are using a bunch of alpha and blend commands that really bog down out framerate. Also, the plants in the picture in the first post use 4 draw commands, one for each branch. And the bullets and exhaust are also using alpha/blend along with fire effects, explosions, etc. Actually, that was one thing I was going to fix and never got around to. The guy that made the bullets back when this was a "community" project used objects instead of particles for the trails. But it doesn't really matter for our FPS because I did the tests with and without shooting and there was no difference that I could tell. The fire particles are evil though...

I'm absolutely thrilled to be able to use Structs though in whatever language we end up using. 

Edit: So yea, Burr is laughing at all my spelling mistakes in my posts. Just ignore the wierd grammar. I'm running on about 3-5 hours each night for the past 2 weeks.

Hours of sleep I mean. >.<

[Burr]

The guy that made the bullets back when this was a "community" project used objects instead of particles for the trails.

Oh, it was worse than that. We originally used motion trails, which meant keeping track of the projectile positions over 10+ steps, then drawing textured, blended, lengthdir'd polygons. Bleh. That has been changed. Now it simply draws a colored line between (x,y) and (xprevious,yprevious). Looks almost as good, and faster.

Does GM automatically make sure not to draw things that are out of sight?

I thought so. But! We have a zoom-in/zoom-out key, and there seems to be no change in FPS when it is zoomed out to the max (four times as much stuff on screen). Which tells me that, yes, GM does draw things off-screen.

[st33d]

I generally use a grid layout for games because I'm making platform games a lot that have walls laid out on a grid.

I did find a nice tutorial on QuadTrees though:

http://www.kyleschouviller.com/wsuxna/quadtree-source-included/

And here's a demo of what they can do (which sounds like you may need to reseach this if you want bullets hitting bullets):

http://lab.polygonal.de/2007/09/09/quadtree-demonstration/

[BlueSweatshirt]

I'm actually trying to figure out whether or not you can deactivate instances in C++/C#. I mean, it makes sense that you can, but I don't know how yet...

You have to make them yourself. The common method is to create a boolean variable which denotes whether the instance is active or not. In all of it's member functions, or at least the functions which make things happen, you just check that the said boolean variable is true.