Personally, I wouldn’t care one bit if single texture and multitexture were removed, but don’t most current mobile systems not support GLSL? If we ever wanted to get BGE running on mobile systems, wouldn’t it make sense to keep multitexture mode? (I probably don’t know what I’m talking about, here)
I agree, singletexture mode can be removed, however I can think of few uses for multitexture mode.
game Launcher comes first in mind, I wouldn’t want GLSL to be running just for some pre-launcher window.
I dont understand, you could always use the old version of BGE.
Yup! Simple logic.
A very short-sighted perspective! With this argument any existing feature can be removed including GLSL.
The texture mode is a just one of many component of the game engine. I’m sure you still want to use any future updates AND the texture mode of your choice.
My opinion:
Keep at least one of the legacy shading modes for backwards compatibility. Not everyone lives in developed countries.
And a good chunk of blender users are students who don’t have access to capable hardware.
Our team uses singletexture because we had many reports of weird graphical glitches using multitexture.
There were >1000 downloads at the time so it affected quite a few people.
I would support the removal of singletexture if multitexture delivered more consistent results.
Or perhaps that’s no longer a problem. I haven’t tried MTX since 2.64
I never used other shading method than GLSL, we are in 2013 and blender still very outdated, Im not blaming the developers, actually BGE developers are saving it and for me, if this will make easier for them to make BGE a little better I would agree in remove this portion of the code completelly.
And if we think about it, the users that may want to use this other shading methods will allways have older versions of blender since it will not be mutch better than it is right now and we can make exactly the same thing using GLSL.
Other than that, I live in Brazil and even here any computer from 2009 to this day allready came with basic GLSL support, I dont know, for me , anything that could make blender easier to develop is a great deal, and allways somebody will think more about what is better for them than what is better to BGE, for me BGE development is mutch more important than anything.
Hi guys!
I love single texture mode because it’s fast and run everywhere.
Nowadays I believe that the Blender artists game community focus to much on modern visuals and too little on gameplay and speed on low end machines and that’s bad.
Don’t get me wrong, I was one the firts ones to publish games using normalmaps over here. But today I rather prefer things running fast.
Low level access for UV texturing display: that’s a treasure from NaN and Quake times, those guys kicked ass!
I think GLSL ES adds fragmentation to our developers and it’s something from the mainstream to keep 3D indie devs away of new devices such as tablets and smartphones.
I love GLSL, but I would prefer texture face running fast inside tablets and phones instead. Its much easier for small teams to achieve graphical homogeneity among different platforms by using static lighting. And porting materials for different platforms and hardware is always a pain in the ass compared to Uv mapping.
That’s it!
Yours,
Ortiz
Multi-texture mode should run about just as fast and do everything that single-texture mode can do (just give the object a material and check the ‘TexFace’ box if you want to keep all your face-assigned textures).
In this case, I also don’t see how the old NaN demos cannot run with multi-texture mode either out of the box or with some minor changes, you’d probably have to update them anyway if they had scripts due to API changes.
Single-texture mode has more or less not been updated for over ten years and right now it’s just sitting there making the code messier and getting in the way of development, sometimes you just have to remove old stuff so the devs. can more easily code new stuff.
Single texture is pointless, Multitexture can replace it with no performance difference.
Just to clear up some confusion about mobile, we would target OpenGL ES 2.0, which is similar to OpenGL 3 in that it requires the use of shaders. This means any work to port the BGE to mobile would be based on GLSL materials. Porting would be easier if the BGE didn’t have any fixed-function code since we wouldn’t have to add as much conditional code for mobile (e.g., if mobile: avoid this fixed-function code).
However, the same could also be accomplished by refactoring the rasterizer into two rasterizers: a modern OpenGL 3/OpenGL ES rasterizer and a legacy rasterizer. GLSL mode could be the basis for the modern rasterizer and multitexture could be the legacy rasterizer. But, I’d rather not have to worry about two fixed-function paths (Singletexture and Multitexture).
Can you make it possible to convert projects with single texture to multi texture? My project has 1,717 unique textures; if those had to be re-done manually then we’d never have the resources to update to newer Blender versions.
Allright, but shaders will be a trap if someone needs to make something simple in the future.
As an example just look at how difficult it is to make a game using the GE with mipmaps turned off and then test it under windows mac and linux.
The game engine needs to be fast at any platform and it isn’t at the moment. It’s fast to develop a prototype until a certain degree, that’s what the engine do so well (logic bricks).
Let’s stop to be EA wannabes with all that effort spent on countless FPSs and be next Mojang or Rovio.
Come on people! We had all the tools to make a Minecraft and we didn’t! We did YoFRankie instead XD
Moguri, you are the best, do whatever you want. Whatever you do will be great 
Greetings,
Ortiz
Multi-Texture mode should allow you to use all of your face-assigned textures through the ‘TexFace’ button available in the material context (you really should already have materials on your objects if you’re wanting to use the face flags as well as a few physics setting). If needed, perhaps write an addon that will iterate through all your materials and enable the option.
The game engine needs to be fast at any platform and it isn’t at the moment. It’s fast to develop a prototype until a certain degree, that’s what the engine do so well (logic bricks).
As I said, Multi-Texture mode should be about as fast as Single-Texture mode, just having Multi-Texture will allow for the removal and simplification of quite a bit of code (while preserving all of the fixed-function functionality that you like).
Come on people! We had all the tools to make a Minecraft and we didn’t! We did YoFRankie instead XD
There’s a lot of people out there who judge an engine by the graphical quality it is capable of producing, would you think the BGE forums would be near as active if the Apricot project focused on unfiltered 8-bit textures (that is, we force people to a lower graphical quality to ‘teach’ them to create better gameplay)? Also, there’s also a number of games being developed that is akin to Minecraft but with modern graphics and realistic terrain, and I can say that these games may give a whole new level of immersion to sandbox building games.
However, we didn’t have the technology to
Multi-Texture mode should allow you to use all of your face-assigned textures through the ‘TexFace’ button available in the material context (you really should already have materials on your objects if you’re wanting to use the face flags as well as a few physics setting). If needed, perhaps write an addon that will iterate through all your materials and enable the option.
You’re right. I retract my original request 
Your opinion is valid, but I’d just like to point out that Moguri recently pushed an ability to turn off mipmaps via Python. It should work under Windows, Mac, and Linux.
Also, we didn’t have the tools to make MineCraft. We still don’t, not really, as we can’t merge meshes or split meshes in-game. That ability is kind of core to how MineCraft works, I believe. Without it, you can’t really make it efficiently.
In any case, you mention that the BGE should be fast primarily, which is true. However, it’s going to take longer and be more difficult to optimize if you have disparate code that is interfering with development. This is especially true if optimizations or new features don’t take effect across the different modes.
For example, I actually made a patch that added multiply blend mode to materials like Add is available. It worked in Multitexture and GLSL mode, but it didn’t under SingleTexture mode. I spent a few hours looking around on a couple of different occasions, trying to figure out exactly why it didn’t work. In the end, I couldn’t figure it out, so I just gave up. If I knew the code base better, I could have implemented it on all three drawing modes, but you can see in my example that more drawing modes means more work and more opportunities for bugs to arise. If we kick out an unnecessary drawing mode, that’s a simpler code base overall and a more easy environment to develop in.
Finally, wouldn’t it make sense to focus development on the more feature-packed drawing modes, at least GLSL mode, and make them faster, rather than keeping all three, and making it tougher to work with just to keep the BGE running fast on one of them?
I think, thats going into the right direction. Having the ability to export to android will bring even more people to the BGE.
I would agree with this. When I’ve tried to use multi texture in the past I couldn’t get the results I wanted, it seemed almost random how something would come out when viewed in game. Something that would look just right in single texture would look completely different in multitexture.
One big example of this would be animated textures, which don’t display correctly at all in multitexture mode.
I guess this is probably a result of having the different shading modes though, if single texture: do this, if multiTexture do this etc…
If it were all cleaned up maybe we could get more consistent results from multi texture.
Or maybe I’m just not using it correctly, it’s hard to tell as there’s not much documentation about how to use multitexture correctly.
Animated textures in general is a bit particular, so if that’s an example of an issue, it might be best to just recommend that you program it in yourself via Python. You’ll have more control, and if you want to, you can only affect the UV map of a single mesh to affect all similar meshes, like the built-in animated texture.