MineCraft (MineTest) work in progress help need it

	Bottom Previous Topic Next Topic
Register To Post	« 1 2 (3) 4 5 6 »

kas1e

Re: MineCraft (MineTest) work in progress help need it

Posted on: 2021/1/7 14:17 #41

Home away from home

@salas00

I just tried your new semaphore code without new debugs at first: and it passed that damn atomicsemaphore test! That how it looks like now :

Quote:

Before ObtainSemaphore in __gthread_create
After ObtainSemaphore in __gthread_create
after findtask + strcutprocess_userData , but before Wait for the parent task
after while with (SIGBREAKF_CTRL_F) & SIGBREAKF_CTRL_F)
Before ObtainSemaphore in __gthread_create
after findtask + strcutprocess_userData , but before Wait for the parent task
After ObtainSemaphore in __gthread_create
after while with (SIGBREAKF_CTRL_F) & SIGBREAKF_CTRL_F)
Before ObtainSemaphore in __gthread_create
After ObtainSemaphore in __gthread_create
after findtask + strcutprocess_userData , but before Wait for the parent task
after while with (SIGBREAKF_CTRL_F) & SIGBREAKF_CTRL_F)
Before ObtainSemaphore in __gthread_create
After ObtainSemaphore in __gthread_create
after findtask + strcutprocess_userData , but before Wait for the parent task
after while with (SIGBREAKF_CTRL_F) & SIGBREAKF_CTRL_F)
Before ObtainSemaphore in __gthread_entry
Before ObtainSemaphore in __gthread_entry
After ObtainSemaphore in __gthread_entry
After ObtainSemaphore in __gthread_entry
Before ObtainSemaphore in __gthread_entry
Before ObtainSemaphore in __gthread_entry
After ObtainSemaphore in __gthread_entry
After ObtainSemaphore in __gthread_entry

And that how it looks like from our debugs when we run test units (for both tests now):

Quote:

======== Testing module TestThreading
before join
so we try to join()
after join
before join
so we try to join()
after join
before join
so we try to join()
after join
before join
so we try to join()
after join
before join
so we try to join()
after join
[PASS] testStartStopWait - 591ms
we in the testAtomicSemaphoreThread
first for() count = 0
before thread = new AtomicTestThread(val, trigger);
thread->start seems fine too
first for() count = 1
before thread = new AtomicTestThread(val, trigger);
thread->start seems fine too
first for() count = 2
before thread = new AtomicTestThread(val, trigger);
thread->start seems fine too
first for() count = 3
before thread = new AtomicTestThread(val, trigger);
thread->start seems fine too

before trigger.post(num_threads);
after trigger.post(num_threads);

Second for() count = 0
before thread->wait
before join
so we try to join()
after join
before delete thread
Second for() count = 1
before thread->wait
before join
so we try to join()
after join
before delete thread
Second for() count = 2
before thread->wait
before join
so we try to join()
after join
before delete thread
Second for() count = 3
before thread->wait
before join
so we try to join()
after join
before delete thread
[PASS] testAtomicSemaphoreThread - 193ms
======== Module TestThreading passed (0 failures / 2 tests) - 786ms

So, that means that to the Adtools repo we need to commit just one fix about the first test: in __gthread_mutex_trylock add missing mx->u.i.acquired++; before return 0 at the end.

Can you do plz so you already set up Github stuff for adtools and already merge the previous fix? (and Sebastian will for sure accept it from you fast).

As for other issues I had:

When trying to choose in "join game" any server, it didn't connect but exit back.

Also, when I tried to connect to the game I create, then have:

Quote:

ERROR[Main]: ModError security: Blocked attempted to read from /Work/minetest/builtin/common/strict.Lua
ERROR[Main]: Check debug.txt for details.
ACTION[Main]: Server: Shutting down

This one I fixed by set secure.enable_security = false in config.

But then create my own server and connect to just cause crash in ServerStart(), damn :)

I then run all the command line tests , and find out those still fail:

module TestServerModManager :

functions testGetModWrongDir(), testGetMods(), testGetModspec(), testGetModNamesWrongDir(), testGetModNames() and testGetModMediaPathsWrongDir().

module TestSerialisation :

functions testStreamRead() and testBufReader()

All other tests seem passed well.

On the running I have also that:

"please insert volume minetest_menu_footer.png in any drive"
and
"please insert volume minetest_menu_header.png in any drive"

Those ones about amiga paths, but I build the whole thing with -Linux, and those seem can come from Lua scripts (though I didn't find anything about those names in). And doing a search in the whole minetest directory didn't show me any files with such names. So it seems those file names "Constructs" somehow from lua scripts or so ..

Resized Image

I need now double-check everything and sorting all issues better. But we very close now!

Thank you a bunch as always, some donation will find a way you to as well soon! (btw, part of the donations I made also come from Skateman, so it not only me :) )

Edited by kas1e on 2021/1/7 15:09:00
Edited by kas1e on 2021/1/7 15:10:32

Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites

kas1e

Re: MineCraft (MineTest) work in progress help need it

Posted on: 2021/1/7 20:06 #42

Home away from home

@all
Started from failed test in TestSerialisation's testStreamRead() firstly:

https://github.com/minetest/minetest/b ... st_serialization.cpp#L216

Everything which comes from line 233 is a fail (all the calls till the end). All those functions are there:

https://github.com/minetest/minetest/b ... ster/src/util/serialize.h

Strangely, that this file have endian-aware code, and i am surely check that i "#if HAVE_ENDIAN_H" code. But still all the tests fail.

For example that one : UASSERT(readF1000(is) == 53.534f);

It is :


inline f32 readF1000(const u8 *data)

{

    return (f32)readS32(data) / FIXEDPOINT_FACTOR;

}



inline s32 readS32(const u8 *data)

{

    return (s32)readU32(data);

}



inline u32 readU32(const u8 *data)

{

    u32 val;

    memcpy(&val, data, 4);

    return be32toh(val);

}

and i have in my "endian.h" for big endian: #define be32toh(x) (x)

There is my updated endian.h file I use for a build that game (sadly our SDK miss half of this):


#ifndef __MACHINE_ENDIAN_H__



/* Swap bytes in 16 bit value.  */

#ifdef __GNUC__

# define __bswap_16(x) \

    (__extension__                                  \

     ({ unsigned short int __bsx = (x);                          \

        ((((__bsx) >> 8) & 0xff) | (((__bsx) & 0xff) << 8)); }))

#else

static __inline unsigned short int

__bswap_16 (unsigned short int __bsx)

{

  return ((((__bsx) >> 8) & 0xff) | (((__bsx) & 0xff) << 8));

}

#endif



/* Swap bytes in 32 bit value.  */

#ifdef __GNUC__

# define __bswap_32(x) \

    (__extension__                                  \

     ({ unsigned int __bsx = (x);                          \

        ((((__bsx) & 0xff000000) >> 24) | (((__bsx) & 0x00ff0000) >>  8) |    \

     (((__bsx) & 0x0000ff00) <<  8) | (((__bsx) & 0x000000ff) << 24)); }))

#else

static __inline unsigned int

__bswap_32 (unsigned int __bsx)

{

  return ((((__bsx) & 0xff000000) >> 24) | (((__bsx) & 0x00ff0000) >>  8) |

      (((__bsx) & 0x0000ff00) <<  8) | (((__bsx) & 0x000000ff) << 24));

}

#endif



#if defined __GNUC__ && __GNUC__ >= 2

/* Swap bytes in 64 bit value.  */

# define __bswap_constant_64(x) \

     ((((x) & 0xff00000000000000ull) >> 56)                      \

      | (((x) & 0x00ff000000000000ull) >> 40)                      \

      | (((x) & 0x0000ff0000000000ull) >> 24)                      \

      | (((x) & 0x000000ff00000000ull) >> 8)                      \

      | (((x) & 0x00000000ff000000ull) << 8)                      \

      | (((x) & 0x0000000000ff0000ull) << 24)                      \

      | (((x) & 0x000000000000ff00ull) << 40)                      \

      | (((x) & 0x00000000000000ffull) << 56))



# define __bswap_64(x) \

     (__extension__                                  \

      ({ union { __extension__ unsigned long long int __ll;              \

         unsigned int __l[2]; } __w, __r;                  \

         if (__builtin_constant_p (x))                          \

       __r.__ll = __bswap_constant_64 (x);                      \

     else                                      \

       {                                      \

         __w.__ll = (x);                              \

         __r.__l[0] = __bswap_32 (__w.__l[1]);                  \

         __r.__l[1] = __bswap_32 (__w.__l[0]);                  \

       }                                      \

     __r.__ll; }))

#endif







#include <sys/config.h>



#ifndef BIG_ENDIAN

#define BIG_ENDIAN 4321

#endif

#ifndef LITTLE_ENDIAN

#define LITTLE_ENDIAN 1234

#endif



#ifndef BYTE_ORDER

#ifdef __IEEE_LITTLE_ENDIAN

#define BYTE_ORDER LITTLE_ENDIAN

#else

#define BYTE_ORDER BIG_ENDIAN

#endif

#endif



#ifndef ntohl

   #define ntohl(x) (x)

#endif

#ifndef ntohs

   #define ntohs(x) (x)

#endif

#ifndef htonl

   #define htonl(x) (x)

#endif

#ifndef htons

   #define htons(x) (x)

#endif



#ifndef NTOHL

   #define NTOHL(x) (x)

#endif

#ifndef NTOHS

   #define NTOHS(x) (x)

#endif

#ifndef HTONL

   #define HTONL(x) (x)

#endif

#ifndef HTONS

   #define HTONS(x) (x)

#endif





#if __BYTE_ORDER == __LITTLE_ENDIAN



#define htobe16(x) __bswap_16(x)

#define htobe32(x) __bswap_32(x)

#define htobe64(x) __bswap_64(x)



#define be16toh(x) __bswap_16(x)

#define be32toh(x) __bswap_32(x)

#define be64toh(x) __bswap_64(x)



#define htole16(x) (x)

#define htole32(x) (x)

#define htole64(x) (x)



#define le16toh(x) (x)

#define le32toh(x) (x)

#define le64toh(x) (x)



#endif /*__BYTE_ORDER == __LITTLE_ENDIAN*/



#if __BYTE_ORDER == __BIG_ENDIAN



#define htobe16(x) (x)

#define htobe32(x) (x)

#define htobe64(x) (x)



#define be16toh(x) (x)

#define be32toh(x) (x)

#define be64toh(x) (x)



#define htole16(x) __bswap_16(x)

#define htole32(x) __bswap_32(x)

#define htole64(x) __bswap_64(x)



#define le16toh(x) __bswap_16(x)

#define le32toh(x) __bswap_32(x)

#define le64toh(x) __bswap_64(x)



#endif /*__BYTE_ORDER == __BIG_ENDIAN*/







#endif /* __MACHINE_ENDIAN_H__ */

So, wtf ?:)

Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites

salass00

Re: MineCraft (MineTest) work in progress help need it

Posted on: 2021/1/8 9:02 #43

Just can't stay away

@kas1e

Try printing the float number generated by readF1000(is) and if it's close enough to 53.534 you can just disable the assert.

BTW for gcc >= 4.8 you can change the bswap macros to:
#define __bswap_16(x) __builtin_bswap16(x)
#define __bswap_32(x) __builtin_bswap32(x)
#define __bswap_64(x) __builtin_bswap64(x)

kas1e

Re: MineCraft (MineTest) work in progress help need it

Posted on: 2021/1/8 10:37 #44

Home away from home

@Salas00
Quote:

Try printing the float number generated by readF1000(is) and if it's close enough to 53.534 you can just disable the assert.

Their:

UASSERT(readF1000(is) == 53.534f);
UASSERT(readF1000(is) == -300000.32f);

our:

53.534004
-300000.343750

What is also strange that this one also fails:

UASSERT(deSerializeString(is) == "foobar!");

While if i just do :

printf("test !! : %s\n",deSerializeString(is).c_str());

it prints me correctly "foobar!"

With readU16(is) == 0xF00D thigs even worse, if i printf on our side like: printf("test readu16 : %04X\n", readU16(is)); then i have 01F4 , kind of different..

Edited by kas1e on 2021/1/8 10:55:52

Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites

billyfish

Re: MineCraft (MineTest) work in progress help need it

Posted on: 2021/1/8 12:53 #45

Just popping in

@kas1e

Quote:

What is also strange that this one also fails:

UASSERT(deSerializeString(is) == "foobar!");

While if i just do :

printf("test !! : %s\n",deSerializeString(is).c_str());

it prints me correctly "foobar!"

What do you get if print out deSerializeString(is).c_str() byte by byte? Something like


char *temp =  deSerializeString(is).c_str();

const size_t l = strlen (temp);

size_t i;



for (i = 0; i < l; ++ i)

{

  printf ("temp [%lu] = \\'%c\\'\\n", i, * (temp + i));

}

salass00

Re: MineCraft (MineTest) work in progress help need it

Posted on: 2021/1/8 17:08 #46

Just can't stay away

@kas1e

Quote:

UASSERT(deSerializeString(is) == "foobar!");

That looks like it's just doing a pointer comparison to me (but maybe the equality operator is supposed to be overloaded?).

Try replacing it with:

UASSERT(strcmp(deSerializeString(is).c_str(), "foobar!") == 0);

to see if it works better.

kas1e

Re: MineCraft (MineTest) work in progress help need it

Posted on: 2021/1/8 20:34 #47

Home away from home

@Salas00
Quote:

UASSERT(strcmp(deSerializeString(is).c_str(), "foobar!") == 0);

For that one saying "Caigh unhandled exception: deSerializeString: couldn't read all chars".

Now question is, if all those things in the test didn't passed as expected, can it be the cause of bugs in the game/parsing_data/etc ? Just too much fail. Those ones all fail:

From testStreamRead()


UASSERT(readF1000(is) == 53.534f);

    UASSERT(readF1000(is) == -300000.32f);

    UASSERT(readF1000(is) == F1000_MIN);

    UASSERT(readF1000(is) == F1000_MAX);    

    UASSERT(deSerializeString(is) == "foobar!");



    UASSERT(readV2S16(is) == v2s16(500, 500));

    UASSERT(readV3S16(is) == v3s16(4207, 604, -30));

    UASSERT(readV2S32(is) == v2s32(1920, 1080));

    UASSERT(readV3S32(is) == v3s32(-400, 6400054, 290549855));



    UASSERT(deSerializeWideString(is) == L"\x02~woof~\x5455");



    UASSERT(readV3F1000(is) == v3f(500, 10024.2f, -192.54f));

    UASSERT(readARGB8(is) == video::SColor(255, 128, 50, 128));



    UASSERT(deSerializeLongString(is) == "some longer string here");



    UASSERT(is.rdbuf()->in_avail() == 2);

    UASSERT(readU16(is) == 0xF00D);

    UASSERT(is.rdbuf()->in_avail() == 0);

from testBufReader():


UASSERT(buf.getF1000() == 53.534f);

    UASSERT(buf.getF1000() == -300000.32f);

    UASSERT(buf.getF1000() == F1000_MIN);

    UASSERT(buf.getF1000() == F1000_MAX);

    UASSERT(buf.getString() == "foobar!");

    

    UASSERT(buf.getV2S16() == v2s16(500, 500));

    UASSERT(buf.getV3S16() == v3s16(4207, 604, -30));

    UASSERT(buf.getV2S32() == v2s32(1920, 1080));

    UASSERT(buf.getV3S32() == v3s32(-400, 6400054, 290549855));

    

    UASSERT(buf.getWideString() == L"\x02~woof~\x5455");

    

    UASSERT(buf.getV3F1000() == v3f(500, 10024.2f, -192.54f));

    UASSERT(buf.getARGB8() == video::SColor(255, 128, 50, 128));

    UASSERT(buf.getLongString() == "some longer string here");



    // Verify the offset and data is unchanged after a failed read

    size_t orig_pos = buf.pos;

    u32_data = 0;

    UASSERT(buf.getU32NoEx(&u32_data) == false);

    UASSERT(buf.pos == orig_pos);

    UASSERT(u32_data == 0);



    // Now try the same for a failed string read

    UASSERT(buf.getStringNoEx(&string_data) == false);

    UASSERT(buf.pos == orig_pos);

    UASSERT(string_data == "");



    // Now try the same for a failed string read

    UASSERT(buf.getWideStringNoEx(&widestring_data) == false);

    UASSERT(buf.pos == orig_pos);

    UASSERT(widestring_data == L"");



    UASSERT(buf.getU16() == 0xF00D);



    UASSERT(buf.remaining() == 0);

Just too much, I fear we can't ignore them (or can ?)

Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites

billyfish

Re: MineCraft (MineTest) work in progress help need it

Posted on: 2021/1/9 10:52 #48

Just popping in

@kas1e

Quote:

@Salas00
Quote:

UASSERT(strcmp(deSerializeString(is).c_str(), "foobar!") == 0);

For that one saying "Caigh unhandled exception: deSerializeString: couldn't read all chars".

Ok looking at the API doc at http://doxy.minetest.net/serialize_8c ... 35e6a8f405f880373bf1284ed, can you try


std::string str = deSerializeString(is);



std::cout << "The size of str \\"" << str << "\\" is " << str.length() << " bytes.\\n";

I'm just wondering if there are some non-printable characters or maybe initial whitespace at the start of str that is causing the UASSERT to fail.

As since it's a string we haven't got to worry about endian issues and the == operator is overloaded


str == "foobar!"

should work although you could try


std::string temp ("foobar!");

if (str.compare (temp))

{

 std::cout << "matched\\n";

}

just to check

kas1e

Re: MineCraft (MineTest) work in progress help need it

Posted on: 2021/1/9 11:27 #49

Home away from home

@salas00

Sorry was a bit dumb, and this "caught unhandled exception: deSerializeString: couldn't read all chars" were caused by the fact that i do that:


printf("test !! : %s\n",deSerializeString(is).c_str());



    UASSERT(strcmp(deSerializeString(is).c_str(), "foobar!") == 0);

So seems the first printf already did what it should do with "is", and then all next tests with deSerializeString fail. But if I remove that printf, then your version passed fine.

@billyfish

tried your example with cout, and it says that says of "foobar!" is 7 bytes. So that as expected, but still pure UASSERT(deSerializeString(is) == "foobar!"); fail, why ?:)

And tested your:

Quote:

std::string str = "foobar!";
std::string temp ("foobar!");
if (str.compare (temp))
{
std::cout << "matched\n";
}

That one didn't match! Seems to fail too? I haven't this printf. Wtf it means?:)

Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites

billyfish

Re: MineCraft (MineTest) work in progress help need it

Posted on: 2021/1/9 11:33 #50

Just popping in

@kas1e

Sorry I was being dumb

compare returns 0 when they match so


if (str.compare (temp) == 0)

{

 std::cout << "matched\\n";

}

is what it should be. So what does


std::string t ("foobar!");

std::string s = deSerializeString(is);



if (s.compare (t) == 0)

{

  std::cout << "matched\\n");

}

else

{

  std::cout << "not matched\\n");

}

give?

kas1e

Re: MineCraft (MineTest) work in progress help need it

Posted on: 2021/1/9 11:42 #51

Home away from home

@billyfish

Quote:

is what it should be. So what does ... give?

matched.

Then, why UASSERT(deSerializeString(is) == "foobar!"); fail if both matches, it's 7 bytes, etc ?

Basically, that all doesn't bother me much, just I fear if tests fail in the game, then the game's code may fail too.

Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites

billyfish

Re: MineCraft (MineTest) work in progress help need it

Posted on: 2021/1/9 11:52 #52

Just popping in

@kas1e

so if you change the assert to line to

Quote:

UASSERT(deSerializeString(is).compare ("foobar!") == 0);

it works? If so, that means the == overloaded operator has not been compiled correctly

kas1e

Re: MineCraft (MineTest) work in progress help need it

Posted on: 2021/1/9 12:34 #53

Home away from home

@salas00, billyfish

Ops, it seems it all false alarm, sorry for loosing your time on things which different.

Issue is that their foobar assert works too. It just me messing things up in "C" terms, i didn't see/noticed that i should use this "is" thing at least one time when i comment out failed one. So, deSerializeString(is) stuff surely works.

Now, when I correctly replace nonworking one by one with printf (so, this "IS" thing is used and for next tests going to be ok), i have found that we have only 3 tests failed in the testStreamRead():

Quote:

UASSERT(readF1000(is) == 53.534f);
UASSERT(readF1000(is) == -300000.32f);

and the last one:

UASSERT(readV3F1000(is) == v3f(500, 10024.2f, -192.54f));

When I print first two that what we have:

Quote:

readF1000(is) == 54.534 , our = 53.534004
readF1000(is) == -300000.32, our = -300000.343750

And the third one are:

Quote:

inline v3f readV3F1000(const u8 *data)
{
v3f p;
p.X = readF1000(&data[0]);
p.Y = readF1000(&data[4]);
p.Z = readF1000(&data[8]);
return p;
}

This means the same readF1000 which has failed with "f".

Now i carefull test again second failed tests from testBufReader(), and failed ones are:

Quote:

UASSERT(buf.getF1000() == 53.534f);
UASSERT(buf.getF1000() == -300000.32f);
UASSERT(buf.getV3F1000() == v3f(500, 10024.2f, -192.54f));
UASSERT(f32_data == 53.534f);
UASSERT(f32_data2 == -300000.32f);
UASSERT(v3f_data == v3f(500, 10024.2f, -192.54f));

So everything is about the same in both tests: F1000 + f32data.

Can we somehow tell the compiler to change the behavior with those floats, or it impossible? I mean, can we something to do automatically, so tests in those regards will be passed fine, and so the game's code will not fail in those places?

Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites

kas1e

Re: MineCraft (MineTest) work in progress help need it

Posted on: 2021/1/9 15:03 #54

Home away from home

Edited by kas1e on 2021/1/9 15:23:40
Edited by kas1e on 2021/1/9 15:25:47
Edited by kas1e on 2021/1/9 17:32:00

Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites

kas1e

Re: MineCraft (MineTest) work in progress help need it

Posted on: 2021/1/9 17:31 #55

Home away from home

@salas00,capehill

Seems we not fully done with that damn threading stuff: i find out in previous sources there was a testThreadKill() which they remove from tests after for some reasson , but which one i have in my sources:

https://github.com/minetest/minetest/b ... t/test_threading.cpp#L114

So, when I activate this one it also halts forever in the "Waiting for thread" loop. And line after which i never had any prinf is : UASSERT(thread->kill() == true);

On serial at this time i have:

Quote:

Before ObtainSemaphore in __gthread_create
after findtask + strcutprocess_userData , but before Wait for the parent taskAfter ObtainSemaphore in __gthread_create
after while with (SIGBREAKF_CTRL_F) & SIGBREAKF_CTRL_F)
Waiting for thread
Waiting for thread
Waiting for thread
Waiting for thread
Waiting for thread
Waiting for thread
Waiting for thread
Waiting for thread
Waiting for thread
Waiting for thread
Waiting for thread
Waiting for thread
Waiting for thread
Waiting for thread

And "kill" in the thread.cpp looks like this :

https://github.com/minetest/minetest/b ... threading/thread.cpp#L139

Maybe it just "kill" function need to be fixed for os4 as well? They probably remove it lately from the test units because tested it well, but while the "kill" functionality of the threading still in their sources even today, and that didn't work for us, it can cause some problems with the game for sure.

On our side is pthread_cancel(getThreadHandle()); called, but i also tried pure "wait()" - same result. UASSERT(thread->kill() == true); never passes. And we come to that never endina "Waiting for thread" loop.

Maybe just getThreadHandle() fail ?

I also find out native_handle() example:

https://en.cppreference.com/w/cpp/thread/thread/native_handle

When compiling that one on Cygwin/window, got in output that:

Quote:

$ ./test
Thread 1 is executing at priority 20
Thread 2 is executing at priority 16

When compiling it for amigaos4, have that:

Quote:

$ ./test
Failed to setschedparam:
Thread 1 is executing at priority 0
Thread 2 is executing at priority 0

Maybe the reason why "kill" fail?

Edited by kas1e on 2021/1/9 17:49:17

Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites

kas1e

Re: MineCraft (MineTest) work in progress help need it

Posted on: 2021/1/10 7:28 #56

Home away from home

@Frederik

I also switched now to the latest sources of minecraft (so avoid any possible issues with 3 years old version we testing now). And they add sem_trywait() which we didn't have in our posix_semaphores. See how they use it in semaphore.cpp


int ret;

    if (time_ms > 0) {

        struct timespec wait_time;

        struct timeval now;



        if (gettimeofday(&now, NULL) == -1) {

            std::cerr << "Semaphore::wait(ms): Unable to get time with gettimeofday!" << std::endl;

            abort();

        }



        wait_time.tv_nsec = ((time_ms % 1000) * 1000 * 1000) + (now.tv_usec * 1000);

        wait_time.tv_sec  = (time_ms / 1000) + (wait_time.tv_nsec / (1000 * 1000 * 1000)) + now.tv_sec;

        wait_time.tv_nsec %= 1000 * 1000 * 1000;



        ret = sem_timedwait(&semaphore, &wait_time);

    } else {

        ret = sem_trywait(&semaphore);

    }

Can you add this one as well ?

Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites

salass00

Re: MineCraft (MineTest) work in progress help need it

Posted on: 2021/1/10 9:32 #57

Just can't stay away

@kas1e

I've updated the posix semaphore implementation at:

https://www.dropbox.com/s/43b4g16kvhd7 ... emaphore-amigaos4.7z?dl=0

by adding the sem_trywait() function and refactoring the sem_timedwait() function.

kas1e

Re: MineCraft (MineTest) work in progress help need it

Posted on: 2021/1/10 9:54 #58

Home away from home

@salas00

Tested:

1). no needs anymore for (structs aaa*) casts for ports, all compiles as it for c++
2). sem_trywait() compiles fine

Thanks! Donation on the way!

Through that damn testThreadKill() still, fail, showing me a lot of those "Waiting for thread" on serial

And I also find out how to deal with serialization failed tests: before it was

Quote:

ppc-amigaos-g++ -athread=native -std=c++11 -DNDEBUG -Wall -pipe -funroll-loops -O3 -ffast-math -fomit-frame-pointer

Now i do like:

Quote:

ppc-amigaos-g++ -athread=native -std=c++11 -DNDEBUG -Wall -pipe -funroll-loops -O3 -ffast-math -fomit-frame-pointer -fno-math-errno -fno-trapping-math -ffinite-math-only -fno-signed-zeros

And serialization tests all passed! I.e. add "-fno-math-errno -fno-trapping-math -ffinite-math-only -fno-signed-zeros".

Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites

billyfish

Re: MineCraft (MineTest) work in progress help need it

Posted on: 2021/1/10 10:35 #59

Just popping in

@kas1e

Quote:

readF1000(is) == 54.534 , our = 53.534004
readF1000(is) == -300000.32, our = -300000.343750

Ok can you change readF1000 to


inline f32 readF1000(const u8 *data)

{

    printf ("raw: 0x%04x\\n", data);

    return (f32)readS32(data) / FIXEDPOINT_FACTOR;

}

And tell us what their, ours and the raw values are for the values that fail the asserts? I just want to check what the raw byte values are to see if that helps. They should all be IEEE 754 values, I just want to check.

FWIW comparing floating point values with == is a bad idea anyway, they should really be checking that the two values are within a specified tolerance of each other. The thing is this tolerance is dependent on how big the values are in the first place due to the way that floating point values are stored in memory.

cheers

salass00

Re: MineCraft (MineTest) work in progress help need it

Posted on: 2021/1/10 11:35 #60

Just can't stay away

@billyfish

Quote:

And tell us what their, ours and the raw values are for the values that fail the asserts? I just want to check what the raw byte values are to see if that helps. They should all be IEEE 754 values, I just want to check.

'data' does not point to a floating point if that is what you mean. Instead it points to a signed 32-bit fixed point number which is converted to a float by casting and then dividing by the number FIXEDPOINT_FACTOR which is probably a power of two.

Register To Post	« 1 2 (3) 4 5 6 »
	Top Previous Topic Next Topic

Currently Active Users Viewing This Thread: 1 ( 0 members and 1 Anonymous Users )