Downgrading a tech level seems like quite a leap.

Did you consider moving the FreeType implementation to your own code and rendering via your abstracted interface?
A basic sf::Window, which is all you would need if you're not using the text rendering, implements a GL context but doesn't draw anything with it itself, it simply allows you to draw to the context it holds. By that logic you should be able to make a context in the mode you desire without limitations, since you are deciding what features you'll be using.
The context generation is handled by 3 OS specific implementation files:

• <SFML/Window/Win32/WglContext.hpp>
  <SFML/Window/Linux/GlxContext.hpp>
  <SFML/Window/OSX/SFContext.hpp>

As an example, the part that controls the context mode for windows openGL is: Here: WGL_CONTEXT_PROFILE_MASK_ARB, WGL_CONTEXT_COMPATIBILITY_PROFILE_BIT_ARB, is by sfml default a compatibility context.
Where: WGL_CONTEXT_PROFILE_MASK_ARB, WGL_CONTEXT_CORE_PROFILE_BIT_ARB, would be only forward-compatible features.

The only thing other than maintaining the context that sf::Window does in regards to drawing is buffer swapping, sf::Window.display(), and that is implemented in terms of the OS's windowing system. It doesn't even implement context resizing logic, you handle that via an event for maximum control.
Only sf::RenderWindow uses sfml's built in drawing code and might require legacy commands due to that.

I'm quite interested in your thought processes regarding this latest hurdle and would love to hear a bit more about the choices you're making and your opinions on what's best for you and LT. The thoughts behind software engineering are really interesting to me.

It's an interesting option, and it's what Laurent suggested to someone else who brought up the same issue. I'm still considering it.

From my perspective, this is probably the "longer, more thorough" approach. I don't particularly look forward to handling all of my own text rendering (via libfreetype, which is not a very attractively-coded library), but at the same time, text rendering is pretty much the only graphical thing that the engine doesn't already handle by itself. So in some sense it would be fitting. I don't particularly like outsourcing this job to SFML, especially since I know SFML doesn't implement it as efficiently as possible.

On the other hand, I want to get at least a basic version running as soon as I can on Mac. The fastest route would seem to be to rewrite the shaders for 1.2 compatibility. I've already finished most of that. This approach has the added bonus of increasing the compatibility of LT across other pieces of hardware.

Probably my best option for the moment is to work towards GL 2.1 compatibility on another machine (so that I can check as I go that things aren't breaking), then start exploring moving away from SFML text rendering. If I can downgrade to 2.1, then I'm in no hurry to get libfreetype working, and can continue working on other things as I explore that option.

Ah, GL. Always a fun time

Thanks for the reply, if you do move on to rendering text yourself stick this in your bookmarks. Chances are you've seen it, or even that freetype implements it, but I couldn't find out from the documentation for it and I don't want to make a project just to find out.

I have seen it, but I do not know much about libft, so I don't know if it can create distance field glyphs or not. It would be amazing if that were the case....I would love to get some shadows / glows / etc going on for the text!!

PS ~ Awesome news. GLSL 120 does support textureLod as long as you have GL_EXT_gpu_shader4 extension! Woohoooo yay for things that make absolutely zero sense but in the end work out favorably!!

In theory, OpenGL supports anything you have a driver extension for, in practice, well, we know the story. That extension seems to have pretty wide adoption, the paper for that extension says it was introduced in 2006, but there's data saying it works on cards all the way back to 2003. No one should expect for their 10 year old card to be supported, so that's a step above most games.

Katawa wrote:In theory, OpenGL supports anything you have a driver extension for, in practice, well, we know the story. That extension seems to have pretty wide adoption, the paper for that extension says it was introduced in 2006, but there's data saying it works on cards all the way back to 2003. No one should expect for their 10 year old card to be supported, so that's a step above most games.

Awesome, that's good to know...thanks for the link.

Well, I've got the game running now under this extension, so Woohoo for old device support!

Katawa wrote:In theory, OpenGL supports anything you have a driver extension for, in practice, well, we know the story. That extension seems to have pretty wide adoption, the paper for that extension says it was introduced in 2006, but there's data saying it works on cards all the way back to 2003. No one should expect for their 10 year old card to be supported, so that's a step above most games.

OK, so what if the requirement is "support all of Open GL 2.1" and GL_EXT_gpu_shader4 is required as well
*goes off for a bit of internet research*

I understand the downgrade to Open GL 2.1 is aimed at getting Intel HD Graphics to run and it does the job. That leaves older AMD and Nvidia GPUs to consider.

On the Nvidia side, http://en.wikipedia.org/wiki/Comparison ... sing_units lists the 6xxx series, launched in 2004, as the first Nvidia series supporting OpenGL 2.1. Katawa's link shows the 8xxx as the first series that supports GL_EXT_gpu_shader4.

In terms of performance, the Nvidia 8600GT, which was considered a midrange card in the 8xxx series, has a performance similar to the Intel HD 3000. I am familiar with that model because I still have one in an older PC. It is sufficient for games with lesser GPU demands (such as World Of Tanks), but clearly showing its age. I think it could be reasonably considered the low end of what a developer wants to support in a game developed today.

On the ATI side, Wikipedia lists the Radeon HD 2xxx as the first series that supports more than Open GL 2.0. Several HD 2xxx models also show up in Katawa's link as supporting GL_EXT_gpu_shader4, so the Radeon HD 2xxx seems fine support wise.
What about the X1xxx series? I found some old benchmarks on the net where the high end X1xxx GPUs outperform the Nvidia 8600GT, so these may be good for a handful of extra sales if you can support them. But I would not lose much sleep about it .

TL:DR
Specifying the Radeon HD 2xxx and the Nvidia 8xxx series as minimum should cover the Open GL needs and keep things simple. Performance wise, edit: most GPUs from older series may be disqualified anyway.

Thanks for the info Rabiator, it's good to know I would be happy with GeForce 8000+ support!