What's the code for, a platformer game?

-EDIT-

so, are you going to draw a green guy?

So did you typedef "surface" as a pointer to an SDL_Surface, or is that a new class containing an SDL_Surface?

Great, now all you need is to dynamically allocate the surface, and have a STL list that you can loop through when you want to draw. Oh, and have each surface autofree its actual SDL_Surface memory when it's not being used, so the overall game has less of a memory footprint (Really speeds up the game also). But data abstraction is great, as long as you only abstract once. Reminds me, I should really abstract all my image-specific code into XML so as little is hardcoded as possible...

Wouldn't you need to keep the SDL_Surface in order to remember the pixels? Otherwise you'd need to load the image again, which seems like it would make it even slower.

Also, you could just use vector<surface> if you wanted an STL list. Not a very specific one, but it would work.

Nope, "forgetting" the pixels and reloading them again is far faster. The hard drive is slow, yes, but if you aren't using an image for a long while and you take the data out of RAM, the processor has more RAM available and can use it more efficiently (actually, it's not RAM you're worried about so much as the system cache in this case, and having a cache of your own greatly helps out the system cache). When I implemented this in my game, it sped it up tremendously. One of those little programming tricks. Of course, if you're creating/deleting images quite regularly, the hard disk can become quite a performance bottleneck, and you may want to use a more intelligent algorithm than just "clean up the SDL_Surface when nobody's using it". So long as you're not using and deleting images constantly (as in, an image stays on the screen for a few seconds before it's deleted), it can speed up performance quite a lot.

Example: You have a background image for a particular level. Backgrounds, unless they're tiled, can be fairly large. You don't want to keep this data in memory unless you're using it, because it hogs up quite a good chunk of said memory. When the user isn't playing this level, then, you free the memory associated with the background image, and read it back from disk when the user starts playing the level. It adds a small amount of load time, but if you do it intelligently, it won't be very noticeable. You can also do something like World of Goo does, and display a level subtitle or something to disguise the loading of the resources for that level. World of Goo also defines what resources are used by each individual level, and unloads everything else, which is quite clever and helps reduce the memory footprint of the program by a huge deal (one of the many reasons that World of Goo has very low system requirements).

Also, only use STL vectors if you absolutely have to be able to access data in random order. In the case of surfaces, assuming you just have to blit them all to the screen, it's far more memory efficient to use an STL list<surface>, as lists use less memory than vectors. It's not a problem if you have a simplistic game without many images, but when you start adding more and more, depending on your algorithm for increasing the size of the vector, it could become an issue. And if you have a kind of object class, with each object having a surface that graphically represents the object, you definitely don't need random access to the surface list, since you should be using pointers there anyway.

TL;DR coding games is tricky stuff and seldom makes sense, especially when optimization comes into play.

Ah, sorry, I thought you meant within a level when stuff is off-camera. That makes MUCH more sense.

And you're right, lists are better. I don't know why I thought a vector would be better if you don't need the data to be continuous.

It's a class containing an SDL_Surface.

To run them all, I have an array of 1000 surfaces. The AddToQueue(int) function points that particular surface in the queue to the surface calling the function.

Otherwise, it's just 1000 surfaces. To keep it fast, I set a boolean in each one for whether or not there's a surface to load in it.

Would STL be better? Like significantly better? It runs fine. It's much better than what I was doing before, trying to blit every surface in the array every frame.

TL;DR version: Using an array of 1000 surfaces is about 10 times worse than using an STL vector, which is about 10 times worse than using an STL list...

walloftext version:
First off, if it's an array of pointers it's probably OK, but if it's an array of structures, you're using far, far too much of your stack scratch space. Hence why I talked about dynamic memory allocation earlier; huge chunks of data (such as multiple SDL_Surfaces) should always be on the heap, for quite a lot of very good reasons. An STL list would be on the heap... if you make a copy constructor for your "surface" class, it would do in a pinch I suppose. But suppose way down the road you need more than 1000 images at one time, your code would spontaneously start crashing where it worked before. And having a boolean to draw or not may seem to work fine now, but in reality it's behaving as a delay loop, and is likely slowing your program a lot more than you may realize. This would become magnified if you ever increased your maximum number of images. So, it's not too slow with only 1000. What if your game has 10,000? 1,000,000? Depending on your future plans for the game, it could become quite a severe bottleneck. If all you're doing right now is drawing, it's no big deal. But what if you add physics and collision calculations in? Everything else you add to the game or engine will slow it down more than it is currently, and eventually it may be too slow, and something will have to be cut out.
"It runs fine" should never be something you say in programming. Programs with memory leaks run great... for a while. It's only after a long time that they start bogging down your computer, and can completely crash your entire computer if they aren't shut down in time. It runs fine compared to what? Before it was horrible, so of course it will work better now. Does it run at 100 fps? Without vsync issues? There's always something that can be done to improve any program. Really good programmers know intuitively when something needs to be optimized more and when the benefits wouldn't be worth the time. In your case, it would depend on what you want to do with a particular engine or game. If you're planning on porting to iPhone or some low-power device, you should avoid STL like the plague. If you're planning on making a graphically intensive program like Braid or Super Meat Boy, STL can make your live a gazillion times easier, and help prevent memory management issues before they occur.

It's an array of pointers, but sure. I'll change it then.

anyone here use javascript? I need some help working out a problem

What's java script?(I know, did I have to do this?)

its another coding language. There's hundreds

But is there a download?

Specifically, a scripting language. An interpreted one. It was the first computer language I learned.

Butisthereadoenload!

What is a doenload? If you mean a download, you have JavaScript if you have a post-Lynx web browser.

Something odd: Using a list makes my CPU's fourth core usage blow through the roof.

I guess it's nothing..

thenoobtester wrote:

anyone here use javascript? I need some help working out a problem

I use ActionScript, Flash's coding language. Obviously they do different things but to my knowledge the syntax is fairly similar (I think AS is based off JS). If you could describe the problem I might be able to help, otherwise AP will probably know.

Red: Really? That's strange.

Puggsoy: AS2 is almost standards-compliant JavaScript (without functions like Document.GetElementById(id); which are meant for HTML), but AS3 has a lot of more Java stuff in it. For example, a class in JavaScript is declared by creating a constructor function, then using the new keyword. So

function MyClass(var1, var2){
    this.var1 = var1;
    this.var2 = var2;
}
 
function MyClass.DoSomething(){
    // do something
}
 
var thingy = new MyClass;

It might be javascript specific. Heres what I have

if (31+3===34) "is true";
{console.log"I am right"}
else
{console.log"I am wrong"}

Personally I would think you'd have to write it like this:

if (31+3===34) "is true";
{
console.log"I am right";
}
else
{
console.log"I am wrong";
}

The placement of the curly brackets is just personal preference, but my point is that you should try putting semicolons after your console.log statements. I'm not sure with JavaScript but that would be necessary in AS.

@AP: Well yeah, classes work differently. However, I did work with AS2 before AS3, so JavaScript still looks fairly familiar.

(By the way, shouldn't the line var thingy = new MyClass; be var thingy = new MyClass(foo, bar);?)

dont worry, that wasn't the problem. It had to do with some parenthesis shenanigans.

and i would've gotten away with it if it weren't for those melding parenthesis!

if (31+3===34) "is true";
{console.log"I am right"}
else
{console.log"I am wrong"}

Wouldn't you need it to be something more like this?

if(31+3===34){
     console.log("I am right.");
}else{
     console.log("I am wrong.");
}

You might also want == instead of === in this case, but either will work. Since JavaScript is weakly typed, === compares type as well as content. So 42 == 42.0 is true, but 42 === 42.0 is false (one is an int, the other is a double).

That's what I'd do too, but I thought "is true" and no parentheses after console.log was a JavaScript thing

@Red: That's definitely not good. Maybe an array would be better then, but I would suspect that something isn't quite working right if the STL list is using an entire CPU core.

By the way, for backup purposes, I'd highly recommend a version control system like git, subversion, mercurial, etc. github has unlimited free repos for open-source (public) code, and bitbucket has unlimited free private repos if you sign up with a .edu email address. Hard drives die, and having a backup in the cloud is really useful. git also makes it way easier to undo changes if something breaks, even if you don't have an online repo. I just use the basic features of git, and it's terrific. Something I definitely wish I'd been using a while ago.

Ah, it was something else.

I re-upload the entirety of my code to my Google Drive every time I implement a major change.

Hey, out of context, In which language Was programmed world of Goo?

C++

A list of 3rd-party libraries they used can be found in your WoG directory in the Readme.