c# distinguishes a byte from a char. i hate c#; i am a c programmer, but that makes sense to me.

c# chars are not 8-bit (they are unicode chars)

Huh, interesting, I feel like more than 1.3% of my users wound up having problems after I started requiring OpenGL 2.0.

Does having a card that supports OpenGL 2 necessarily mean you have the drivers that support OpenGL 2?

In your metroidvania do you gain hair and facial accessories as power ups

- I will go to just about any lengths to avoid ever using git

May I ask why? I don't want to derail the thread with an argument, so I'm not planning to respond to your post, I'm just curious what could be the reason behind this decision.

Since you asked-- I agree it would be undesirable to have an actual discussion on this subject:

- Generally makes things much more complicated than they need to be

- User interface appears to have been designed as some sort of medieval torture device
"git rev-parse HEAD"
This is an example of a thing that git expects you to understand what it means

Also if you can't figure out how to use git/hg/svn whatever on your own, download the Tortoise programs, they make it super easy.

Bitbucket isn't as slick as github, but gives you free private repositories and lets you use mercurial as well as git.

I use bitbucket for everything, there are some things I think github does better and some things I think bitbucket does better but the things I like about bitbucket are:

- Private repositories for up to 5 users on the free account
- You can clone your own projects by pressing 1 button (if you want to do this on github you will have to download the project to your computer, then upload it to a new project). Since I mostly start projects by forking old projects I use this a lot.
- I will go to just about any lengths to avoid ever using git

http://github.com
http://bitbucket.org
https://launchpad.net/

SIGN UP FOR ONE OF THESE

USE VCS

dropbox is probably about as good a solution also as long as you keep a history of your old versions there

To my knowledge there is nothing in 3.1 that is not in 2.1 that will benefit you for a 2D platformer.

Targeting OpenGL ES 2.x rather than OpenGL will benefit you because (1) doing so will produce OpenGL-compatible code, and (2) it will allow you to run on mobile.

(As Evan points out, if you write to OpenGL 3 spec you are basically writing OpenGL ES 2.x.)

Using VBOs, shaders, and other OpenGL 2.x features can benefit you when writing a 2D platformer. This is because VBOs, RTT, postprocessing allow you to do fancy "special effects" like screen blurring or warping with very little effort.

I don't think the 2.x standard is going away anytime soon. Actually there are good reasons to target 1.x (compatibility, I run into people who can't run my OpenGL 2.x games)

I think you're asking the wrong questions though. You should first ask "what do I want my platformer to look like?". This will then help you decide which 3d card features you do or don't need.

I have used interfaces very little because I mostly have programmed in languages where they are not a language feature-- for games I tend to use either languages with duck typing, or C++, where interfaces (although they do exist, as rivon points out) are a bit awkward. What I do use a lot is interface-like polymorphism.

For example, in the engine I designed from the ground up, the way levels would behave would be controlled by a series of "idiom" objects. There would be a "level_idiom" object, a "graphics_idiom" object, and a "sound_idiom" object. level_idiom, graphics_idiom and sound_idiom were all abstract classes; child classes would implement virtual methods on this class, like "draw this object" or "take user input" or "an enemy AI is at a corner; now what"?. Different child classes could implement these methods in different ways. So if I wanted a level to look fundamentally different, I could just instantiate a different display_idiom object with different implementations of those methods. Similarly, my sound management consists of a list of objects from a common Sound superclass, and a virtual method "nextValue()" (this is oversimplifying, but it's like that); different Sound objects (a square wave sound, a sine wave sound, a sample) would implement nextValue() in different ways, and return the next short of PCM data to play to the speakers.

I'm talking about examples of polymorphism rather than examples of interfaces specifically because I think that is the right way to think about interfaces. Interfaces are just a more general example of class inheritance, a special case where you do not actually need any data members or method implementations to be passed on to the child classes. Anytime you have a place where you want to do something to a general "kind of" object or a series of objects which may be heterogenous, and the objects themselves potentially could be associated with unique "behavior", using something like an "interface"-- or thinking of your class inheritance as if it were an interface adoption-- is potentially appropriate. The time where using literal java/C# interfaces becomes *more* appropriate than doing it with class inheritance is when your "i have a behavior i want to bundle into this object" coexists in a program with an existing class hierarchy. For a contrived example, maybe you have a small hierarchy of FFT utility classes-- there's a base FFTMachine, and inheriting from it is 2DFFTMachine and 1DFFTMachine. Maybe you want to make something that is a "Sound" object, as in my example of sound generators above, but, it would be convenient from a coding perspective if it could inherit from 1DFFTMachine. At that point it suddenly becomes better if your "Sound" class were an interface instead of a literal class, because then you could freely have a child of Sound inherit from 1DFFTMachine or whatever is most convenient, without running into the limitations of Java/C# or the awkwardness of real multiple inheritance in C++.

So in other words, I would look at it like, anytime you have child classes inheriting from parent classes but really it's only so that you can call a "virtual" method that's implemented different ways for different objects, you might as well be using an Interface-- at that point you are using the "implied interface" pattern, even if you are not using the literal interface feature. This is what you want to be focusing on-- when is the interface pattern relevant to my code? And if at some point, if the interface pattern is appropriate, but inheritance would cause a conflict with an existing class hierarchy, then you can go "well, I guess I definitely need a literal interface here".

EDIT: Actually thinking about it, I'm remembering that sometimes if I have a abstract parent class in C++ that exists only to be implemented, I actually put "interface" in the class name to make it clear why it's there...

I think the important thing about platform compatibility is whether you plan. If you plan ahead and make some careful decisions early on (like library choice) platform compatibility is really easy. If you start development and then later or after release think about cross platform ness, it can be very hard.

Distributing binaries on Linux is just plain hell. It's possibly easier to get stuff on mobile. The problem here though is not that porting to Linux itself is hard but rather that different types of Linux are not compatible with each other.

Ah, I take it you're referring to the fabled framework, where your engine is so advanced you call one function and it procedurally generates a perfect game...

EMACS?

When I save the document at the left side of the save button there is a dropdown menu with says Encoding. I just put Unicode there as it asked.

"Unicode" could mean at least three different things (UTF-8, UTF-16, UTF-32). If you are saving in something other than UTF-8, I would expect Python to mess up. Microsoft Notepad i would imagine is using UTF-16 and will thus break things. If IDLE has a text editor I would expect it is using whatever is correct for use with Python.

At least get a program on your computer that lets you distinguish UTF-8 from UTF-16 from "Windows Encoding", so you can be sure.

I currently use two engines, depending on project:

- Jumpcore-- this is really just a way of saying "my custom engine", which uses raw OpenGL ES + Chipmunk.
- Polycode -- This is Ivan's thing, and I have a hacked version of it that lets me write my games part in C++ and part in Lua.

I am leery of overcomplex third-party engines for several reasons, some sensible some not, the largest one being that I want my games to be very portable.

I'm not familiar with the SFML code, it seems like a conversion to vertex arrays would be great because then you're potentially ES compatible? (Or did they do this with SFML 2 already?)

I think the fact you just took *37 lines of code* to write a (very correct and nicely written) function that just draws a rectangle, doesn't handle the case of textures, indexing or draw call coalescing, and will have to be mostly rewritten in a switch to GLES 2 kind of demonstrates why calling directly is not worth it for basic 2D stuff and you'd rather find a library to do this for you :/

I have a little set of personal raw OpenGL utility calls like this. When I was using them in my primary development, I spent an unreasonable amount of time debugging them and adjusting them and then it would all turn out to be useless when the day comes I found myself going-- oh right, what if I unexpectedly want to draw a *triangle*? And then I'm starting over.

Basically, I spent a good long time using raw OpenGL ES to just display pixel art and simple shapes, and it was bullshit and I wouldn't recommend it to anyone. The upshot of my time doing this is that the art in the games I made this way were way simpler than they even needed to be, because it was so much work for me to do something simple like draw a square and this didn't leave me much of any time to do the fancy GLSL stuff because I'd used up my time budget on writing code to laboriously draw rectangles.

So I'd recommend, find a library at least one level of abstraction higher than OpenGL.

Having access to shaders can be very useful even with 2D, there are a LOT of ways to make pixel art + postprocessing look very attractive.

However I think you can get that without having to give up high-level abstractions, I bet you can use SFML and still have access to opengl's more powerful features when you need it.

Stelok what editor are you saving these files in? Do you know what text encoding is being used?

Windows console can do Unicode, you just have to change the code page or something.

https://www.google.com/search?q=windows+console+unicode&ie=UTF-8&oe=UTF-8&hl=en&client=safari

Because raw OpenGL is not very user friendly and directx is not cross platform, I would recommend using a library built on top of OpenGL. I have heard many good things about SFML.