Alphablending Problem / setBlendFunc

Averett

Hi all,

I know this has been kind of asked before here (http://www.giderosmobile.com/forum/discussion/comment/1759#Comment_1759), but I do need access to the OpenGL context on a per-frame basis.

Let me explain: The project we are working on was started on Cocos in XCode, and we have sprites moving around on a large tiled map in the darkness; some of the sprites are stationary and some are moving, and some have light sources and some don't.

To achieve this behaviour, the graphics engine will need to draw a darkness layer on top of everything, from which you "subtract" (i.e. cut out) the "light" so that you basically lay a huge alpha mask onto the entire screen, covering up the dark parts and leaving the "lit" areas as they are. For this (because you have moving light sources) you need to draw textures separately before applying them to the OpenGL surface (ie the lights need to 'multiply' with each other and the pixels of both the background and any other sprites drawn underneath).

Gideros does so far not allow for that -- what you can do is set the background to darkness and set its blendmode to multiply. That will however only "light up" the background, but not any sprites moving on top of the background. Any additional sprites added to your map will be drawn "on top" of the darkness, or will be multiplied with the background as well, which is not the effect we are looking for.

When we programmed this so far in XCode, we used a simple black sheet the size of the screen, and then drew the lights as multipliers on top of that by using the blend mode GL_ONE_MINUS_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA; this was to ensure that two light sources that overlap equally light up the area. Once finished, this would then be used as a cover mask. In other words, what I am looking for is access to glPushMatrix() and glPopMatrix() in the OpenGL ES Framework, or respectively, a way to create rendertextures in Gideros.

Does anyone know a way to achieve this, either directly or through plugins? Please please help!

If we can't get this done, we might have to switch back to XCode, and we are really starting to like Gideros a lot...

Any help or idea is much appreciated,

Averett

atilim

Hi @Averett,

You can set the blending mode with the function Sprite:setBlendMode() and multiply blend mode can work in your case.

Averett

Hi @atilim, thanks for your response!

Great to hear from the developers directly! However:
I sat a whole day on this problem, and I couldn't find a way to get it to work (FWIW this wouldn't work in Cocos2D, Corona or Moai either without RenderTexture access).

Multiply blend mode only multiplies the content of the texture with whatever is painted immediately underneath, in that order. You cannot blend two sprites first, and then put them on whatever is underneath. Therefore you can only create a "light" effect with _one_ layer, but not a light shining on a sprite that has another sprite on top of it (i.e. a light shining on an object and a background.).

The example that @GregBUG uses here (http://www.giderosmobile.com/forum/discussion/comment/17438#Comment_17438) to show that a lighting effect works, works only on one background, because it is the background that is using the multiply mode, and not the light itself. As soon as you wish to draw something on top of the background, the background also multiplies with the sprite on top, and suddenly looks like a fog.

If you need several lights on top that brighten up a "dark area", you need rendertexture access. Here are two example pictures: the first one shows the effect we need to achieve.
You see a dark sprite (the red thing at the bottom) moving on top of a background into the lit area surrounding the bright sprite (the blue-yellow thing). Both are on the grey background

Now, our game concept requires several light sources, some of them moving with the sprites they are attached to. These need to add to each other, and then you lay them on top. The second image shows how our current project would look on Gideros.

You see the problem? The two light sources do not blend with each other _before_ they get drawn on top of the background sprites.

So, we need RenderTextures, desperately. If we did and could get this to work, we'd buy your environment and switch over. But as things stand right now, we can't - and we would love to switch our project to Gideros.

I have seen that RenderTextures are on your to-do-list. When do you think they will become available? Or do you have a different solution for our problem?

In any case, thanks a lot for your time! I wish Gideros all the best, it is a wonderful environment to work in.

Fabian (aka Averett)

atilim

@Averett - yes you're right. render to texture is the solution here. I'm still thinking if there is solution here but most probably there isn't any without using render to texture.

In a couple of weeks, I'll start moving from OpenGL ES 1.1 to OpenGL ES 2.0. And while moving, I'll also implement render to texture.

Averett

That's great news! =D>
Even if a "couple of weeks" might be too late for us... (
Could you be more specific...? =P~

atilim

I'll start implementing in a couple of weeks but implementation will take longer. Most probably it won't be available on time

OZApps

@Averett, out of curiousity, which framework allows you to manage that at this time, i.e. what is the alternative framework that you are considering?

Averett

Thanks for your time, @atilim. Maybe with our next project then, or, if we should get massively delayed (something not unheard of in the games industry), we might switch if you should be faster than us...
You have a great concept and setup with Gideros, good luck with it -- I hope we can come back.

Averett

@OZApps:
We used Cocos2D before, through Kobold2D (see http://www.kobold2d.com).
The problem with our current framework are the constant update chains over the last three to four months: Cocos updated, XCode updated, iOS updated, kobold updated, and with each update come requirements, necessary code changes, etc. We found we were shooting at a moving target half of the time, programming so close to the actual system (in this case iOS). But having said all that, we were moving forward slowly ("we" is a team of 2, me and @Awoehrmann).
In late December, we had a moment of frustration, as Steffen Itterheim's Kobold2D also started moving to a commercial engine (now called KoboldTouch), and our progress had slowed to a creep due to all the fixing involved with updating -- updating XCode, Mountain Lion, updating Kobold, et c..
Don't get me wrong, we are willing to pay for a good developing environment, but if we have to pay between 300 and 400 Dollars per year for two developer licenses, we can as well get Unity and leave the constant bug fixing to the IDE developers, and get to actually do some game crafting.

So we began looking for alternatives, from high-end to low-end, and from close-to-machine to abstract performance engines. We had done the same when we started on our project, and we settled on Kobold for various reasons. So in December we decided to look again.
We've looked closely at:
Pure Objective C on XCode (meaning write your own game engine: not worth the time for a studio of 2)
Cocos2D on XCode: Great - but lacked the quick-starting-touch
Kobold2D: Cocos2D in a quick-start-wrapper. Had just the right sweet spot between this and higher end engines.
Moai: There is no documentation worth the term. You have to use XCode, but get to develop in Lua; it seemed the wrong compromise.
Gideros: Develop in Lua, and work with XCode once you're really ready to port. Fast, friendly and simple IDE. It seemed a good alternative.
Corona: You send away your code? _They_ compile it? Bye bye.
Unity: A dream. But the license cost makes me cringe.

So we decided to look at Gideros. And now we realize our game concept can't be done on it without rendertextures. Which means we're now either back to Cocos, or use Unity.

Do you know of any game engine we missed?

OZApps

Averett, I understand your situation and am with you in the pain you have described. I believe you have covered most of the frameworks (as I see you are not interested in cross-platform but iOS only). One thing that is important for me is the language, though I have worked with several languages over the years, I prefer not to change that now that I have found Lua, another reason for my book "Learn Lua for iOS Game Development" that covers the basic/foundation of using your game logic with other frameworks (Lua based).

The other thing that actually gets me is when companies offer a FREE license and then just down the road when they get a decent number of subscribers, discontinue that and replace it with a paid offering.

Since you work with Objective-C and are not afraid to take it on, have you considered the plug-in method? Where you can use UIView and Quartz to do some stuff for you via a plug-in or even extend via the Wax plug-in.

Averett

@OZApps,

yeah, I looked at the Hotwax (kudos to the Bowerhaus) plugin architecture et c. But it's one thing using the Cocos2D built-in RenderTexture from within a Cocos project, and another writing a plugin that then uses this bridge to call the OpenGL framework directly to create a RenderTexture that then needs to be drawn (i.e. re-created) once per frame. I have not fully looked at how the rendertexture part is implemented in Cocos (I only use it there), but what I saw seemed complex enough, and while I am confident I could probably understand and put together what I needed it to do, there are many reasons against:

-I would come up with a plugin that most likely only serves this particular purpose (laying a darkness texture minus light sources on top), while in the meantime, Gideros might change - and introduce the same functionality.
-The time I would have to spend developing this plugin is lost once Gideros switches to OpenGL ES 2.0 (as I would have to develop it currently for 1.0). Then we would have to-rewrite the code in Lua within Gideros, and the time spent was completely lost.
-Since I don't know OpenGL ES enough yet, there is a considerable time investment to be made to get this all to work, time that I don't have to invest anymore right now (the whole darkness layer business is already done and working in our Cocos/Kobold project version) since we're behind already.

One of the reasons why we looked for a game engine in the first place was simply that we don't want to have to program the bit blitting part of moving sprites. It's tedious, eats your time, and has been done by a zillion programmers before.

To make a long rant short: Sure, I _could_ do it. But it would simply cost me too much time. We're ready to pay for a solution (i.e. game engine) - if it does what we require.

As for cross-platform: We'd love to do cross-platform, but iOS comes first. No iOS, we're not interested. If Android is available on that engine, fine. We sure as hail don't care for Windows 8 (and I am looking at Gideros' move towards Windows 8 at this point in time with suspicion: it might turn into a huge time sink at the wrong moment, with no actual gain for Gideros, dragging the whole engine down with it while it's still not ready for prime time even on the platforms that they offer; but it's their decision and I respect it.)

OZApps

yes the time spend vs benefits, specially if the same gets introduced natively cannot be justified.

It would be interesting to note how the windows 8 (Mobile) pans out, because there would be more interest in the desktop on Microsoft platforms than the mobile (my perspective) and it would also mean using more of Windows in the VM than the mac

The switch from GLES 1.0 to GLES 2.0 would make a difference only if the benefits were accessible from the API. Gideros is getting there, albiet a bit slow as the list of feature requests are a bit varied.

I can only imagine the progress they can achieve once they get a couple of people on board. Compare the progress speed of Gideros (@Atilim) against the large team in Mexicana Beer SDK...

Mells

We sure as hail don't care for Windows 8 (and I am looking at Gideros' move towards Windows 8 at this point in time with suspicion: it might turn into a huge time sink at the wrong moment, with no actual gain for Gideros, dragging the whole engine down with it while it's still not ready for prime time even on the platforms that they offer; but it's their decision and I respect it.)

@Averett Reading your point of view was interesting. @Atilim will probably comment on the subject when he gets the time.

keszegh

i was also hoping to get rendertotexture soon. in some forum topic i was somewhat made believe it is aimed for 2012. i really need it for the game i'm working on so any more specific date would be appreciated.
also i prefer desktop over wp8 if that is any info for an imaginary poll about this.

Averett

Personally, I think there are enough development platforms out for desktop. The magic of course lies in "Write once, run anywhere." Yet, this holy grail of coding has never been fully delivered, Java got the closest, but Java on any platform looks always like a bad port, because the user interface on each platform is just, let's say, so 1992.

But the way the smartphone OS market has developed shows that this is increasingly difficult even just on smartphones: iOS is very Java-repelling (or better said, it is difficult to port Java properly to iOS, not impossible, but not easy either), so Java can't deliver its promise for iOS. Similarly, Objective-C is not ported to Android (Apple refuses). That is why app developers are wringing their hands picking the right engine to develop their stuff on. "Write once, run anywhere" for smartphones is a huge task to take on, especially if you're essentially one coder (@atilim).

If you now add desktops, that is easy on the Mac side since iOS and MacOS are not that different, but not so easy on the Windows side as Android and Windows are not even related.

So, instead of sticking to two platform groups (MacOS/iOS and ChromeOS(?)/Android), Gideros would now like to add a third group (Windows Desktop/Windows Phone).

It seems to me - and please correct me if I'm wrong - people are primarily using Gideros to gain easy access to the smartphone platforms. For desktop platforms there are enough accessible platforms already that cross-compile onto Mac/Win/Linux (Java, REALStudio, etc.). And you would only add these platforms to be able to claim that Gideros is for every platform, while the large majority of developers actually picked Gideros because of its smartphone OS portability. So, adding desktop platforms in general, and Windows phone too, is in my opinion a huge load to take on, while Gideros is not yet ready to fully measure up with its competition in its very core market, iOS and Android. And therein *might* be a big mistake. There is a good dozen engines right now in that market (Moai, Corona, Cocos, Gideros, moscrif, Titanium, etc.); most of them switch to a pay/subscription model, and almost all of them try to take on more platforms to compete, rather than trying to be full-featured on the platforms they offer. You see, it is actually easier taking on the rough basics of a new platform ("Hey developers! We are now also supporting ObscureOS 1.x for Hyundai Phones! But wait! There's more! We now also support BeOS!") than to actually deliver full feature parity on all platforms that you offer.
And that is where most engines run out of steam (and, sad to say, eventually die.)

But this is just my view; I have no market data to back this opinion up, and I presume @atilim has taken a hard look at their core market and business idea and know where they are heading.

OZApps

@Averett,
one point that generally gets overlooked is there is the Mac App Store and the Windows Store. So developers that create an app for the Mobile platforms look at also extending it for the Desktops. While there are various applications for building Desktop applications, ranging from using Basic, Pascal, C, C++ to C# and dotNet but that is in a way a rewrite. Unless of course there is a library that offers all of these functionalities within one of these platforms, so the code can be simply dropped and run.

So more than the claim that Gideros does all platforms, it is more about the value to the developer to create for all platfroms. Moai does create binaries for all, iOS, android, Mac OSX, Windows and Chrome (Web).

While there are features that many developers might be waiting for, including me, there are developers that are able to already use what's available and have apps on the markets and for them if they get desktop support, they would be able to add another platform, hence another revenue stream.

It differed from user to user and the onus unfortunately ends up on the people that make the framework for all the touch decisions and it always unfortunately means upsetting the smaller numbers