• Hello everyone,

    We're happy to announce that our forum is back online! We needed to take some time off to discuss and decide on how to handle sensitive topics in our community.

    The team has posted an in-depth comment regarding a recent incident and our stance on politics and sexuality in our forum. We also added a dedicated paragraph about this in the forum guidelines. This is part of our commitment to maintain a welcoming and inclusive environment for all our users. Your understanding and continued support in building a creative and respectful community are highly appreciated.

    Thank you, the CX Dev-Team

bgfx module/target

I have no preferation about this. But i can see devs using several atlas where names collide.
Anyway someone could always use a selfmade solution. I would have implented it differently but each dev has their own way of doing things.

I would love to hear how you would have done this. I am really bad at creating API :confused:
I would return an id when you load the atlas. This way you have them identifiable and there will be no duplicates when you add this as a parameter to your load image command.
@Ferdi: What you need to do is read up on game asset management to find a suitable solution to files with the same name.
I would return an id when you load the atlas. This way you have them identifiable and there will be no duplicates when you add this as a parameter to your load image command.

*slap forehead* Thanks Mike. I think you better check my code. Make sure I don't do silly things like this.

@dawlane: I like Mike's solution. I had a look at how LibGDX does it. I did not like it. It returns Stack<AtlasImage>, but it also can return individual AtlasImage.

So the code now becomes:

Local atlasId:Int = LoadAtlas("td_spritesheet.txt")
' Local atlasId:Int = ATLAS_NULL ' = -1, this is if you want to load individual files

destroyerImg = LoadAtlasImage(atlasId, "sprites/Destroyer.png")
ekstraLiveImg = LoadAtlasImage(atlasId, "sprites/EkstraLive.png")
goldImg = LoadAtlasImage(atlasId, "sprites/Gold.png")
Example 6 bump texture. I had to load the texture using bimg, and it has conflict with Cerberus because both were using stb_image. It is working, but need to do ALOT of clean up underneath. Anyway source code is attached and screenshot:



  • 06-bump.cxs
    13.5 KB · Views: 245
That looks interesting. Cant wait to play with that target.
I was going to give a github link, but I decided otherwise. So hopefully this works and it is easy to use.

I have put a highly experimental build together. It is Cerberus + bgfx (compiled) + MinGW (64-bit). It is 207 MB download. It is Windows only. And it is 64-bit only. It is mainly to try bgfx. Here is the link:

https://www.dropbox.com/s/vhvd88j5ulfs00n/ceberus+bgfx-v2018-12-18.zip?dl=0 (207 MB)

Several notes:

1. It is ~700MB when unzipped. Each build directory that you make is ~150MB. So remember to delete your build directory when you have tried the example!

2. I have put the MinGW in it because I compiled bgfx, bimg and bx with that compiler. To be precise, this is the MinGW I am using/downloaded:

https://sourceforge.net/projects/mingw-w64/files/Toolchains targetting Win64/Personal Builds/mingw-builds/8.1.0/threads-posix/seh/

I have set the config.winnt.txt to point to the MinGW:


3. If there are any bugs, I am going to ask for source code, so I don't have to waste time reproducing the problem. But I am still going to change the core of bgfx (because of all examples I still need to do) and I will definitely going to introduce more problems.

4. This build includes bgfx in modules, mojo1bgfx in modules and Glfw 3 + bgfx in target. (desktop & Windows only)

5. Bgfx examples are in modules/bgfx/examples/... To compile these examples, Cerberus must use the "Glfw 3 + bgfx" target. (desktop & Windows only)

6. To compile Mojo examples with bgfx, you have to change "Import mojo" to "Import mojo1bgfx" and set the target to "Glfw 3 + bgfx". Remember only Mojo 1.

7. The Github link is at: https://github.com/Ferddi/cxbgfx
Example 7 hooks 2 classes during init. I have done this before to get ReadPixels working. I think what I am going to do is just give functions (like SaveScreenshot or SavePng etc) instead of giving the option to hook 2 classes.

Example 8 updating texture is working. Here is a screenshot:

The source code is at: https://github.com/Ferddi/cxbgfx/tree/bgfx/modules/bgfx/examples/08-update

I did several changes, you can read it in the commits section. And I also merged the latest develop branch from Cerberus main repository to the bgfx branch. So it should be all the latest stuff there
I have managed to get example 9-hdr working. Here is a screenshot:

Source code: https://github.com/Ferddi/cxbgfx/blob/bgfx/modules/bgfx/examples/09-hdr/hdr.cxs

I had problem with calling bgfxSetViewOrder. I was passing in an array of ViewId as and Int (which in Cerberus is 32-bit). I was wondering why it wasn't drawing after 5 frame buffers. It is because ViewId is 16-bit. Took me a while to figure this one out. Once I created a DataBuffer and use PokeShort to set the ViewId in an array, the example started working.

I looked very carefully at this bit of code in the header file while I was debugging:

#define BGFX_HANDLE_T(_name) \
    typedef struct _name##_s { uint16_t idx; } _name##_t



Basically it creates every handle using a macro. And that handle is basically a uint16. Currently handle I wrapped in a class. So I had a think about this for several days now. I think I am going to remove the classes and try to change it as an Int (32-bit). Unfortunately this is will be a big change, but I think it will make the code ALOT easier to read. The next update will probably be really boring.

FYI, I have merge the develop branch into the bgfx branch.
Sorry for not responding earlier. I definitely have to try what you have posted before.
Sorry for the delay. I actually change all the handle from class to int 3 weeks ago. But I wanted to use it, to make sure it is the right decision. It is a big change. Also I had a really bad bug when I was doing example 13 stencil, took like a week to solve it. :(

I have committed my changes and I have merged the develop branch from https://github.com/KrautApps/cerberus.

Since we are now passing an int, the C++ code does casting magically! Here is a C++ code for destroying vertex buffer:

void _bgfx_destroy_vertex_buffer( uint16_t _handle )
    bgfx_destroy_vertex_buffer( *(bgfx_vertex_buffer_handle_t *)&_handle ); // <-- from uint16_t to a bgfx_vertex_buffer_handle_t struct

I tried using int as handle on 2 examples, example 12 lod and example 13 stencil.

Here is a screenshot of example 12 lod:
And here are two screenshots of example 13 stencil:

Notes and problems:

1. 32-bit int array of size 2 for 64-bit int is causing headache. For example, example 9 hdr I need to create an if statement like this:


It works but not readable at all! And will probably cause problem down later on.

Also in example 13 stencil there is a table of render states:

static RenderState s_renderStates[RenderState::Count] =
    { // StencilReflection_CraftStencil
        , UINT32_MAX
        , BGFX_STENCIL_TEST_ALWAYS         // pass always
        | BGFX_STENCIL_FUNC_REF(1)         // value = 1
        | BGFX_STENCIL_OP_PASS_Z_REPLACE   // store the value

Currently I just hard coded these render states:

    rs.m_state[0]        = $01000040
    rs.m_state[1]        = $00000017
    rs.m_blendFactorRgba = $ffffffff
    rs.m_fstencil        = $2228ff01
    rs.m_bstencil        = $00000000

I am not sure how to solve this problem.

2. In example 13 stencil, bgfxFrame is not called at the end:

            // Setup view rect and transform for all used views.
            setViewRectMask(s_viewMask, 0, 0, uint16_t(m_viewState.m_width), uint16_t(m_viewState.m_height) );
            setViewTransformMask(s_viewMask, m_viewState.m_view, m_viewState.m_proj);
            s_viewMask = 0;

            // Advance to next frame. Rendering thread will be kicked to
            // process submitted rendering primitives.

            //reset clear values on used views
            clearViewMask(s_clearMask, BGFX_CLEAR_NONE, m_clearValues);
            s_clearMask = 0;

            return true;

In Cerberus, I called bgfxFrame() in glfw bgfx target. This is so that Mojo 1 program does not need to call bgfxFrame.

3. Currently Mojo 1 uses bgfx dynamic create buffer. But after doing some of the example, I think I may need to use bgfx transient buffer. I am not sure what is the difference. I need to look into it.
Wow. Lots of work you put into this. Looks great for sure. Regarding readability and usability. Having the user deal with it directly is indeed difficukt and it screams for a much more simple wrapper luke mojo does.
@Mike sorry I have been sick. I am still sick, but getting better. I updated it in Github (https://github.com/Ferddi/cxbgfx/commits/bgfx) before easter and wanted to do the particle example going, but I got sick. I have been resting. I really want to do the particle example first before I update.
No problem Ferdi. Get well. Health is more important than anything.
I hope you are ok @Ferdi. Just tried to run your examples from your latest and OMG, you did an awesome job. Thank you for sharing!
Hi @MikeHart, I am ok, just been taking it easy. I am slowly getting back into it. I got an example working 2 weeks ago, but nothing to report about. It is working but not fully. Now that I know bgfx better, I am going to try to refactor the mojo 1 code that I was working on. My big problem is the current interface between CX and C++ is slow. I model it like DataBuffer. But calling the method PokeFloat for every x y z co-ordinate + normal + texture ... etc is just slow. I tried other weird method like casting a float into an int and putting everything into an int array, it works but I think it is complicated. I want to try writing it in C++ to see what speed increase I get.
Top Bottom