Planning phase

I am guilty again for a long delay since the last post. Sorry about that. But because of that I decided to work on a release plan to commit my self more to ShugenDo. ShugenDo is one of my life time projects and I really want release it as bad as some of you are waiting for it. Please keep in mind that I am also a human begin with up and downs but never the less this will not stop me.

The release plan involves mainly the ShugenDoEngine which is the engine which powers ShugenDo. In the next weeks I will launch the web site for the ShugenDoEngine which will be mainly dedicated for the ShugenDoEngine.

Additionally to that I will release the old code of ShugenDo to GitHub and it will be open source. Here the reasons.

Over the years I read a lot of source code. Nearly every engine on the web which is open source ( Doom 1,2,3, Quake 1,2,3,4, Duke Nukem, UT4 ) I read the source code of it . For me it was a good inspiration and I am really glad that this source code was made open source. I strongly believe in giving back. This is my way of giving back.

The main thing I want to show is what the pure will can accomplish. Back in the days my coding and understanding of game engines was not good, lets face it I had no clue ;).  But I had the will to create a 2D Beat’em Up engine. Along the way to create this engine I learned so much and the source code of ShugenDo reflects that.

Currently the old source code is not in a good shape. It is not even compile able at the moment. But since it is open source the community can work on this to get it working again. I will also use the code base as an example on how you can do things better in code and what my mistakes were and still is on most junior programmers which want to understand on how a game engine works.


Posted in DeveloperBlog, ShugenDo

Multi Window Support : Done

On the weekend I was able to finish my multi window support task and now we have the ability to create an editor with different windows which are able to use the ShugenDoEngine. The purpose of the editor is to have an “what you see is what you get” editor. So basically the editor uses the same engine as ShugenDo and you should be able to make changes and test them right out of the editor.

BTW guys thanks you very much for you support. This really motivates me to go on. I know that most of the time I lack in terms of information but still you are here and support me.

THANKS alot.


Posted in DeveloperBlog

Multi Window Support

Here is a little update on what I am working right now. Currently I am about to finalize the ShugenDoEngine which is used by ShugenDo. Right now I am working on a feature which is essential to create an editor.

The ShugenDoEngine can handle multiple windows with different content at the same time. Imagine that those windows are embedded into an editor. The main window would show the stage, another one would show a character animation editor.

Here a screen shot about this feature.  Notice that all those windows are powered by the same engine and how they show complete different contents. With the ShugenDoEngine you can use 2D or 3d content and even 2d and 3d at the same. Btw the carefull viewer will notice that the ShugenDoEngine also supports 2D physics. This is based on Box2D.



I hope to finalize this feature in the next week so I can continue to finalize the ShugenDoEngine.

Posted in DeveloperBlog, ShugenDo

Alive and still kicking

Hey Guys,

I am still alive and lucky to see your comments. Seeing you comments and knowing my lack of updates makes me sad and I apologize for this. It is good to see your support. As mentioned in the post before and in the comments there is a split between ShugenDo and the ShugenDoEngine. The ShugenDoEngine is the engine which is created to create ShugenDo itself. News about the ShugenDoEngine will be published here . As soon as this website is online I will inform you.

Since April I have a new Job and a little less time, thats why I did not wrote so much for updates. But the good news is that I now created schedule for myself to work on ShugenDoEngine on a daily basis to improve progress on this. I have a list of items I want to finish for the ShugenDoEngine before I begin my work on ShugenDo. In the mean time I will try to update you guys on a weekly or maybe a biweekly basis.

BTW As of today the ShugenDoEngine is a official registered trade mark and I am very happy about that.



Posted in ShugenDo

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