• Dear Cerberus X User!

    As we prepare to transition the forum ownership from Mike to Phil (TripleHead GmbH), we need your explicit consent to transfer your user data in accordance with our amended Terms and Rules in order to be compliant with data protection laws.

    Important: If you accept the amended Terms and Rules, you agree to the transfer of your user data to the future forum owner!

    Please read the new Terms and Rules below, check the box to agree, and click "Accept" to continue enjoying your Cerberus X Forum experience. The deadline for consent is April 5, 2024.

    Do not accept the amended Terms and Rules if you do not wish your personal data to be transferred to the future forum owner!

    Accepting ensures:

    - Continued access to your account with a short break for the actual transfer.

    - Retention of your data under the same terms.

    Without consent:

    - You don't have further access to your forum user account.

    - Your account and personal data will be deleted after April 5, 2024.

    - Public posts remain, but usernames indicating real identity will be anonymized. If you disagree with a fictitious name you have the option to contact us so we can find a name that is acceptable to you.

    We hope to keep you in our community and see you on the forum soon!

    All the best

    Your Cerberus X Team

$100 bounty for A Cerberus that's based on Monkey version 86e

mojo2 was only available in the distro as it was not open source regarding GitHub/FOSS. Only when Mark dumped MX he uploaded it to GH.
 
I got the chance this morning to quickly put together a few Win10 binaries.

As people will have so many different PC's (Apples are so much easier to categorise), I do realise that this is package of tests are not enough for everyone.

You'll also find a few good examples for weak machines here, and that's a good start.

If you don't own a weak machine and you want me to recompile a new binary that pushes your computer more (because this is a must to see what we want to see), just ask and I'll upload them here as quickly as humanly possible.

For now, the best test for the average/strong machine would be the 4x4 test. If it's too slow, use one of the other ones or again just ask me. It's hard to get the time right now to code a dynamic test that works as good.

If your computer seem to be able to handle 4x4 perfectly without any tearing (remind yourself that you need to wait for minutes and minutes before you may say; it has no tearing). Don't check one minute to say it has 60fps, that would go against everything we're working for.

All of these have 60fps guaranteed, the only exception would be 4x4 on a weak computer.

If it's truly smooth, please shout it out of course, all feedback is good.

It works on all my machines and I've done my best to test that it works on a wide range of machines, different versions, power, and resolutions. Just to be sure; I've done my best before asking other people to do the same.

If you have bad driver or you have some kind of system with a lot of junk, I expect that you can get problems even with these files. But I've had good experience with that too. Overloaded junk systems have not been a problem.

These examples works in my experience on all kinds of cheap notebooks and all Apple machines I've tried it on, there have not been a single exception. I just hope you can confirm this experience.

If you don't experience the same, it won't change my experience of course. The goal stays the same.

It might give us clues though what it is all about. What works and what does not.

Sorry for this long text, I just wanted to make everything very clear.

Have a very.. very.. smooth day!
 
These files are all 68e builds, right? At least the strong version differs from your former (source) package. Maybe provide both binaries (68e and 78a) so we can compare easily.
I tried some binaries and they crash here when pushing two arrow keys for some time. In your former source package is gives a memory access violation error.
 
These files are all 68e builds, right? At least the strong version differs from your former (source) package. Maybe provide both binaries (68e and 78a) so we can compare easily.
I tried some binaries and they crash here when pushing two arrow keys for some time. In your former source package is gives a memory access violation error.

The error is because you should not go outside the boundaries, go back and forth and up and down, use the 16MB world that you do have.

I noticed this after pressing the compile for the Millionth time and had transferred the files using bluetooth while eating breakfast in a hurry. I want to relief your worry. It just misses a IF X < 0 THEN X = 0, it has no technical issues.


The source-code given at the top of this thread is identical with this Win10 binary.
This is all we need actually as Cerberus is based on v7x and It has all the same properties and will behave as Monkey v7*, so we only need one binary, and that is MonkeyX version 86e.

Inside the original package (zip file) you'll see a folder called source-code and you'll also find the macOS binary. In this package above, you'll find the Win10 binary of the very same source-code.

They are absolutely identical; which have the .crx file which was temporary renamed monkey to produce the monkey binaries, and we have the binary files for both macOS and win10.

You also have additional files in here, they all come from the same exact source-code.
They are not important but they are very good to get a feeling for what your machine is able to do.
I named the files according to the sizes and the number of layers that they use.

So what we have now to work with is :

* source-code to compile using CerberusX
* macOS binary produced from MonkeyX v86e
* Win10 binary produced from a MonkeyX v86e (along with some bonus-files)
 
Last edited:
Could you supply us the old MonkeyX v86e download
 
Could you supply us the old MonkeyX v86e download

Of course, I'm just waiting for any sign from you so I know that it is legal. I'm still waiting.
Also it is big and it will need a permanent place, so we need to decide also where to put it. There's a size limit here.
 
You have to ask Mark Sibly if you are allowed to distribute this old version. I won't host it here or link to it.
 
Okay, that would be one more thing on the todo list. Ask Mark.

This morning I've been trying to use tools such as SplitDiff and Atom to spot the differences between the packages. Maybe it's not the best package to compare files, all I know is that there's a need to compare source-codes and be able to scroll them side by side to do this.
 
And if he says no? We go for metal and Vulkan directly? We still need to fix some of the bug that drives this behaviour I'm afraid. Am I the only one who owns Monkey v86e?
 
If you bought MonkeyX, you have the *right* to own also v86e. Just talk to me and some evidence that you bought it, or bother Mark if you want. It should be fixed.

We can't fix something that we are not allowed to read. This is ridiculous.
 
Let's think outside the box, and pretend it 's not the about the source-code after all, maybe it is just works because it's 32-bit? Then what are the odds that both 64-bit platforms get identical and better results then when they run the 64-bit counterparts output by the more modern CerberusX?

We know that MonkeyX86e had its ARCHS build set to the now depreciated i386 architecture.
But again, as it is noticeable on Win10 as well we can't really blame changes in Xcode for it.

If someone knows their platform inside and out and knows what route each OS goes for running "legacy" executables. Maybe it is about the number of bits and how compilers changed? There's so many stages that can go wrong here.

Back to the source-code, I haven't still found anything yet myself. I thought I was close several times.
Let's face it It's not like it's well coded or anything. So the compiler output idea might be worth investigating as well.
I don't know how to produces "better" 64-bit executables though, how do you do that? So I threw that idea away.

How can 32-bit be better than 64-bit.

So, I start to believe It's more about pure luck. He didn't even realise it himself what he did.
He just continued, and did not listen to me, and ruined everything basically.


I can't be asked to be active here because if I am, I want to be really around you and be able to answer you quickly and not let you wait, and think I'm rude or anything and I'm not too busy I'm just too stupid to do several things at the same time and I thought I would get some support and get a quick fix of this. Maybe people listened and would be co-operative. You know, money and everything?

Anyway, It's just a principle really. Each tear of graphic burns my poor soul..
I' guess I' just an old fart who loves graphics too much. Way too much.
 
If you bought MonkeyX, you have the *right* to own also v86e. Just talk to me and some evidence that you bought it
I bought MonkeyX long time ago.
 
Last edited:
I can't be asked to be active here because if I am, I want to be really around you and be able to answer you quickly and not let you wait, and think I'm rude or anything and I'm not too busy I'm just too stupid to do several things at the same time and I thought I would get some support and get a quick fix of this. Maybe people listened and would be co-operative. You know, money and everything?

With all respect, who did ask you? Please be more specific regarding who you address in your posts. Your usage of YOU and WE confuses the heck out of me.

For sure you are the first that voiced their convern about this tearing issue in CX. But I remember seeying post about tearing in MX even in much older versions than v86e.
@Martin and I made the choice to go 64bit from the get go back in July 2017. So there are definitely differences compared to the MX days. The compilers are different. Heck, if i use MSVC 2017 instead of MinGW, I get 25% better rendering performance. Just by using a different compiler.
Also that a tool like CX uses its own GC which you have no full control over it, makes it imho not the best canidate in what you want to achieve.
Is CX perfect? By all means, NO. But it does fine job in general. I really don't see it as an issue. So far SetUpdateRate(0) and a delta time logic has never failed me.

When I find time I will try to replicate and investigate in the issue. But it isn't my top priority.

Anyway you are free to fork CX and do whatever you want with it. The license allows it.

Btw. in MXs and most other software cases, someone buys a license to use it. You do not own it. And most of the time you are not allowed to redistribute it. Mark changed the license only with the last version of MX.
 
We go for metal and Vulkan directly?
As soon as OSX will announce that it will dump support for OpenGLES, CX needs to adapt. Or dump the OSX/IOS targets.
The support for Metal2 can come from its own implementation or using a 3rd party render lib that supports this.
I would not go for Vulkan as the rumours of Apple banning MoltenVK are already spreading.
 
Back
Top Bottom