News update

Hi guys,

first of all thank you for your long time support with ShugenDo. It is time again to give some updates about the progress. The ShugenDoEngine which empowers ShugenDo is nearly done. Now its time to create ShugenDo with that engine. The engine does most of the bulk work, so creating ShugenDo will be more effective. ShugenDo is on my long term ToDo list and it is about 10 years since my first attempts to create  a 2D beat em up engine. I started  ShugenDo as a M.U.G.E.N clone in the first place since M.U.G.E.N. was not in active development back in that time. Over the years I spend a lot of time trying to emulate M.U.G.E.N. but I also got better in my skills. I soon realized that M.U.G.E.N is not worth to emulate it ( BTW no offense against M.U.G.E.N ) when I can do it better with my new skills. So I decided go a complete different way.

I think I was developing the old ShugenDo with M.U.G.E.N support for about 4 years and then decided to change my direction in development. ShugenDo was developed with SDL back then, but I was not satisfied with SDL. Because of this I decided to create an engine which would fit my needs, that was the beginning in creating the ShugenDoEngine. The ShugenDoEngine is incredible and I like to use it for my own projects. Now it is time to create ShugenDo. But to do so I need time. To get time I need money. It is my deepest wish to release ShugenDo. To do so I decided to make it commercial. Without commercial support such a great product wont be possible.  What do you think about it?

I do not know when and how it will happen but I will inform you guys.

Posted in ShugenDo

Transparency vs RenderState Grouping

Update: Unity3D does it as intended and renders the scene the right way. When you write your own shader in unity and you want to support transparency, then do not forget add “QUEUE”=”Transparent” as a tag. Also do not post it as a bug report to Aras then … Finding out that you did a mistake after you posting it to aras as an bug report  is a priceless feeling ;)


This post is about a tricky problem in real time rendering. It is about “Transparency vs RenderState Grouping”. It is also a bug report for Unity3D, since I was getting so much information from  Aras Pranckevičius about Unity3D and rendering its time to give back.

Some of you may ask, what does the ShugenDoEngine and Unity3D has in common? We have the same problem( I would like to test UnrealEngine 4 for the same problem as well ). Here the problem. In today’s graphic APIs a render state change is expensive and you try to avoid it as much as possible. A common approach is to group all render objects with the same render state. So you set the render state once for a group of render objects which are sharing the same render state and render all elements in that group. When you rendering only solid objects, this approach works pretty straightforward.  But rendering transparent objects is a different story. Rendering transparent objects are a special case which we have to handle carefully. You have to render transparent objects in the right order. The order is from back to front relative to the position of your camera. When your set of render objects can be divided into solid and transparent objects it is easy to solve. First you render your solid objects in any kind of order. Here you can apply your render state grouping for solid objects and everything works fine. Second you render all your transparent objects. Before you do that, you sort them relative to your cameras position from back to front and render them in that order. As long as all transparent objects are sharing the same render state everything works fine. But when you have transparent objects with different render states and you want to group them by their render state, you will destroy the back to front render order of transparent objects. Now let me illustrate this problem.

Here a test scene. The red boxes share the same render state( Material in Unity3D which contains the render state ) and the green box has a sightly different render state but it is also a transparent render state. The green box is the stress maker because it does not share the same render state as the transparent red boxes and will stress us later.

Editor - Copy


Lets take a look on how the scene is rendered in Unity3D. The first step is to render the solid white box. Great!


Now lets see what happens next.


Wow the stress maker appears! Of course it is the stress maker and it is its job to stress us. We would expect that the red box behind the green box would be rendered first. Which would be the right order of rendering. Lets look at the next render step and we will see what happens.



Aha now we see the “Transparency vs RenderState Grouping” problem. In this case it is not only render state grouping, Unity3D also merged the two red boxes into one draw call( nice one ). This is done for performance reasons as well. The problem is that it destroys the right order of rendering for transparent objects. In this case the red box is not seen through the green box no matter how you move the camera. Remember transparent objects are sorted relative to the position of the camera.

So we have the problem now but how do we solve it? The solution for me was pretty easy. We have to handle transparent objects in a different but also efficient way in avoiding render state changes as much as possible. I call the solution “interleaved render state grouping for transparent objects”. Here the pseudo code.

  • Sort all transparent objects from back to front relative to the position of your camera
  • lastRenderState = undefined
  • for all sorted render objects do
    • if( lastRenderState != renderStateOfCurrentObject ){
      • SetRenderState( renderStateOfCurrentObject )
      • lastRenderState = renderStateOfCurrentObecjt;
    • }
    • render object

This problem is a special case, because normally you will use the same render state for nearly all of your transparent objects. But it bothered my that I did not handled this special case and I was curious about how Unity3D would handle it. BTW as a side note. Unity3D does not only group the render states it also groups the meshes into one draw call. Doing so it also manages to draw them in the right order with one draw call. You can do that by either packing the vertices in the right order into the vertex buffer or you can play around with the indices in the index buffer, which seems the way Unity3D is doing it.

It was fun to write about technical insides. I think I will share more of my knowledge. Hopefully this helps someone.

So enough Unity3D, the next post will be about ShugenDo ;)


Posted in DeveloperBlog

Web site back online

I had some trouble with my server over new year. But now the web site is online again.

Posted in Uncategorized


As promised the Showcase Video. Sadly it took ages to process it yesterday but finally here it is. Thank you guys for your support. I will be more in touch with you and will make more updates on this page.

Posted in ShugenDo

ETA ShowCaseVideo 25.12.2014

The ETA for the ShowCaseVideo will be 25.12.2014. See it as a little present from me ;)

Posted in ShugenDo

Comments are working

The comment problem is fixed. Now you can comment with your twitter or facebook account. I am happy to see your future comments.

Posted in DeveloperBlog

ShowcaseVideo will be delayed.

Hi guys,

I am really sorry to tell you that I have to delay the video presentation to next week. But it will be worth it I promise ;)

PS. I am still working on the comment problem. Meanwhile you can always ping me via twitter.



Posted in DeveloperBlog, ShugenDo

Comments are not Working

Sorry guys for some reason some comments are getting marked as spam when you use your twitter or facebook account. You can comment on my twitter channel here . As soon as the comments are working again I will post about it.


Posted in DeveloperBlog

KFM back in a 3D stage

Its time for a new update post. Right now I am still preparing a presentation video to show you guys what ShugenDo can do. As you can see here.  Hopefully I will post the presentation video on next Sunday.

image002The feature you can see in this image is our good old KFM in a 3D stage. This stage is a “real 3D” stage like in Blaze Blue or Marvel vs Capcom 2. Here some screen shots which will illustrate it better. In the upcoming video I will show you how to create and load them in ShugenDo.


ShugenDoPlayer 2014-09-28 17-20-32-71 ShugenDoPlayer 2014-09-28 17-20-45-56 ShugenDoPlayer 2014-09-28 17-20-56-61Stay tuned for next week ;)

Best Sahin



Posted in DeveloperBlog, ShugenDo, Uncategorized

1234 commits


Today we reached the 1234 commit count on the ShugenDoEngine(C++). Here are some statistics about the whole project. ShugenDoEngine(C++)

  • We have 1234 commits.
  • The project file size is 1894 MB.
  • 11 external libraries in use.
  • die hard programmers.
  • Total files including the libraries 7049
  • Project started on 2010-03-13


  • We have 619 commits.
  • The project file size is 12.43 MB
  • die hard programmers.
  • Total files including the 395
  • Project started on 2013-03-29

See you on Sunday

Posted in DeveloperBlog, ShugenDo