Porting Voxlap

[Cajun Style]

Nice to have some non-work posts around here.

If you guys want to clean trailing whitespaces, we'd better to do it coordinated and in one commit. That way we'll have the minimum amount of "conflicts" due to whitespace. Maybe it's time for picking a specific formatting style when we're at it?
I had some stylistic doubts. I've taken the liberty of using (array + x + y * z) instead of &array[x+y*z], because I thought it was weird to have so much arithmetic AND take the resulting address. Slightly more disputable, I indented something like this:

Code: Select all

	xysiz = ((
		((xs*ys)<<1) + 3
	)&~3);

Are we sticking with the shifts for power of two multiplications? I think GCC with -O3 turns those multiplications into shifts anyhow.
BTW I'm getting undefined memcasecmp in game.cpp. :(

[Sonarpulse]

If you guys want to clean trailing whitespaces, we'd better to do it coordinated and in one commit. That way we'll have the minimum amount of "conflicts" due to whitespace.

I actually already did a commit that was just cleaning up white-space in voxlap5.

Maybe it's time for picking a specific formatting style when we're at it?
I had some stylistic doubts. I've taken the liberty of using (array + x + y * z) instead of &array[x+y*z], because I thought it was weird to have so much arithmetic AND take the resulting address.

Haha. Some of that array stuff is there because I thought at the time that ptr[x] = (ptr + sizeof(ptr_type)*x). But some might be ken's.

Slightly more disputable, I indented something like this:

Code: Select all

	xysiz = ((
		((xs*ys)<<1) + 3
	)&~3);

I wouldn't say breaking up the line is mandatory, but if you do yeah I don't see a problem with that. On windows I use notepad++ which doesn't do auto-indent. On Linux I use emacs with BSD-Style C indentation, which I find most like what Ken did. So far my main goal is to change as little as possible. It may make sense to rigorously re-indent everything automatically.

Are we sticking with the shifts for power of two multiplications? I think GCC with -O3 turns those multiplications into shifts anyhow.

I would keep them as shifts. You never know if MSVC is that smart. Also a good number shifts seem to do with optimizing for 32-bit word size at the expense of accuracy, so when it's stable enough to shoot for 64 bit this will help them stand out.

BTW I'm getting undefined memcasecmp in game.cpp. :(

Porthacks is supposed to take care of this. It was one of the first things I fixed. perhaps you changed something in there to check compiler as opposed to LibC. (Mingw uses the MSVC run time and not glibc.)

[Cajun Style]

Porthacks is supposed to take care of this. It was one of the first things I fixed.

Indeed it was. I've spent quite a while making up for an error on my part familiarizing myself with git. IIUC memcasecmp could actually be provided by "Gnulib". You've copied the relevant part, though.
I've made some changes to porthacks.h. Perhaps you can see why I was confused: I needed the standard headers on MinGW. Then I mistook some conditions for typoes >_>''''''''''.
BTW I'm using NASM at the moment. Does the readme still apply and is NASM unsupported ATM in favor of JWASM? I'm hoping to get voxed ported and debugged. Then we can edit maps in Linux. I'll stick to the details of the functions I've touched for now, though...

[Sonarpulse]

Oh shit does it still say that? Nasm, JWasm, and Masm all work now on both no_asm and conservative.

[VladVP]

Oh shit does it still say that? Nasm, JWasm, and Masm all work now on both no_asm and conservative.

Lol, the reason that I started helping you guys in the first place was because I noticed that the readme said that v5.nasm didn't work... xD

Oh, and I had some errors with that unreachable macro, but this should fix everything:

Code: Select all

#ifdef __GNUC__
	// Maps __gtfo() to __builtin_unreachable()
	#define GCC_VERSION (__GNUC__ * 10000 \
		     + __GNUC_MINOR__ * 100 \
		     + __GNUC_PATCHLEVEL__)

	#if GCC_VERSION >= 40500
        #define _gtfo() __builtin_unreachable()
    #endif

	// Aligns symbol
	#define __ALIGN(num) __attribute__((aligned(num)))
	#define MUST_INLINE __attribute__((always_inline))
	#define FORCE_NAME(symbol) asm(symbol)
#endif

#ifdef _MSC_VER
    // Maps _gtfo() to __assume(0)
    #if _MSC_VER >= 1310
        #define _gtfo() __assume(0)
    #endif

	// Aligns symbol
	#define __ALIGN(num) __declspec(align(num))
	#ifndef __cplusplus
		#define inline __inline
	#endif
	#define MUST_INLINE __forceinline
	#define FORCE_NAME(symbol)
#endif

I shamelessly just edited the other stuff directly in GitHub, without really thinking about the syntax... xD
Sorry for being a bit passive recently, but I've been given shitloads of work from school this week... I hadn't really time for working concentrated on this...

EDIT: Forgot to say: I also found out why my GCC didn't recognize the MMX registers! Apparently you have to set a few processor-architecture-specific compiler flags for it to work, but now it throws some completely new errors and warnings... at least which I understand xD

[Sonarpulse]

Wow, took another look at my readme. Later I talk about how NASM does work, but the beginning is supposed to be sort of a story and ends up sounding like I am talking about the present. I'll have to fix it again. (Maybe I should just cut the intro and rely on the list of branches, but I'd to have something to help people get started. What do you guys think?)

Rebase and checkout porthacks again. I think I did something like that (moving the MSVC _gtfo stuff to the right spot).

What compiler flag is it?!?!?!?! I thought -msse2 would do it but I guess not.

And don't worry about being busy. I've been busy too, and probably will be for some days to come.

[Jdrew]

so is this just voxlap with better graphics?

[rakiru]

so is this just voxlap with better graphics?

No, this is voxlap, but cross-platform. The regular voxlap engine only works on x86 compatible platforms running windows. The aim of this is to make it work on a wider range of platforms.

[VladVP]

so is this just voxlap with better graphics?

http://en.wikipedia.org/wiki/Porting

Well, according to Wikipedia, "porting" means:

In software engineering, porting is the process of adapting software so that an executable program can be created for a computing environment that is different from the one for which it was originally designed (e.g. different CPU, operating system, or third party library).

That might answer most of your questions concerning our work

But, at least I, have thought about continuing development of Voxlap, when we're done porting. For example, I've been looking a lot into polymetric voxels (aka 'poxels') recently...

No, this is voxlap, but cross-platform. The regular voxlap engine only works on x86 compatible platforms running windows. The aim of this is to make it work on a wider range of platforms.

Actually, it's also compiler dependent (the original only works with MSVC)... it has even prooven to not work with newer versions of MSVC. But thanks to Sonarpulse and Cajun Style, this also compiles in GCC now

[Sonarpulse]

Ok, just did these things.

1. Figured out what was wrong with the _gtfo macro so it compiles on gcc again.
2. Found where this random ";draw" text appeared in no_asm and removed it from the source (used to be fixed in later commit).

Piemboymoubre, you seem to have pretty strong feeling about this project. Might you want to help?

Lastly and shamelessly, a hundred posts in this thread!

[Handles]

101 Awesome!!!!!!!

Anyway good job with what you have already done!

[VladVP]

Ok, just did these things.

1. Figured out what was wrong with the _gtfo macro so it compiles on gcc again.

Oh... I just did that a few days ago. I though I had pushed it...

Let me check...

Hmm... seems that my changes are gone... damn you Git...
Oh, well! Glad that someone fixed it anyways! I'll just pull in your changes then...

[MrHaaax]

Since me and a couple of others are not that smart at C nor programming, could you give us a.. percentage on the progress porting Voxlap? Sorry if this annoys you guys.

[Cajun Style]

Progress: x?%.
The original source has been modified in such a way that we can make a program. The resulting program for some mysterious reasons doesn't do what it is intended to do.
You could say over 50% (most of which SonarPulse did BTW); on the other hand it really is a "black box" and it's hard to tell how much needs fixing. Over 50% is a very optimistic estimation. If I say 50%, I mean to a first release. It'd probably need some patching after that.

BTW noobish question: does the C style cast normally do C++ style "static_cast", and a "reinterpret_cast", if that's undefined?
I'll have to look at the docs for the kv6 format, because some functions do some weird stuff.
Oh, and I think it's crucial that umulshr32 is changed to take two int64_t. I'm not sure if that'd give a performance hit, but it'd definitely get rid of some premature rounding.
@VladVP: have you pushed a (make)file with the necessary changes to compile the assembly as you said? Then I'll have a look at it.

[HoboHob]

"Black Box"

Is it really that far along?