Porting Voxlap

Miscellaneous projects by the Build and Shoot community.
222 posts Page 2 of 15
Sonarpulse
Coder
Coder
Posts: 443
Joined: Thu Dec 13, 2012 7:18 pm


Just remebered that I think MinGW only comes 32-bit, so if you are on windows you should hopefully be fine.

My one guess on a possible location for the LAST GREAT BUG is this commit. https://github.com/Ericson2314/Voxlap/c ... 6a0c8efdcf The C is Ken's, not mine, but for some reason it causes destruction sprites to be white, and not the color of the voxels that were destroyed. It's the one commit I can with certainty tie to a bug. This code should only effect distruction animations, but who knows? Perhaps it somehow corrupts the main frame buffer with a GCC build.
gamax92
Deuce
Posts: 17
Joined: Sat Dec 15, 2012 5:18 pm


Great work! It would be extremly cool if we could merge iceball with voxlap.
Sonarpulse
Coder
Coder
Posts: 443
Joined: Thu Dec 13, 2012 7:18 pm


Well I thought I was getting somewhere, but I didn't. Ken is not willing to duel-license Voxlap under the GPL.
Cajun Style
Deuced Up
Posts: 145
Joined: Fri Dec 07, 2012 11:04 am


Voxlap is practically under the zlib license, which Wikipedia claims is GPL compatible. Over such things you shouldn't strain your brain, unless you have a special interest in law.
What part of Voxlap needs porting? I can imagine the assembly is in the wrong order for Linux :P
Sonarpulse
Coder
Coder
Posts: 443
Joined: Thu Dec 13, 2012 7:18 pm


http://advsys.net/ken/voxlap/readme.txt Yes, the other 3 parts of the license are like zip, but the first says NO COMMERCIAL USE, unless you contact ken and negotiate a new license (What Ben did). Anyways I am no longer worried as I would try to make this compatible with PySnip too, giving this and Iceball pretty different goals. Assets would be usefully for sharing, but that is not a problem as those are CC-BY-SA, not GPL.

By "order" I assume you mean AT&T vs Intel syntax. Well gnu as can now read mixed intel and at&t so that is no longer a problem. However due the other idiosyncrasies you still need a copy of the inline assembly for each compiler.

The real problem is you really have no idea what the compiler/assembly actually does with that inline assembly. And seeing that gcc builds don't work at all, I'd say it doesn't something i very much don't expect. The only real solution is to convert everything to normal C. If you would like to help with that, I would very much appreciate it. There is only a little bit of inline asm left.

After that is done we can make some tests and what not to figure out where the assembly went wrong, and maybe replace it with builtin functions, or gcc generic vector stuff.

The other way to help with a 0.75 clone is to start working on the client with MSVC, and occasionally making sure it will at least build with mingw until I finish this damn port.

Lastly I sent an email to the gcc-help mailing list. Hopefully continued emailing there will help things progress.
Cajun Style
Deuced Up
Posts: 145
Joined: Fri Dec 07, 2012 11:04 am


Ah, yes. I forgot how big of a bitch porting can be, if not extreme care was taken in the first place. In my humble experience the errors are usually something that any compiler should have produced erroneous binaries for, but for some dark reasons the program works on compiler X. Try to compile with compiler Y, and you've got a serious bug seemingly out of nowhere.
I've started using valgrind. I've heard great things about it. And it looks very promising for my porting needs.
There probably is a pointer too high/low somewhere, or an operation that has undefined behaviour is used somewhere.
Did the Iceball boys get voxlap to work on Linux? And are you implying you'd like to sell your game?
rakiru
Coder
Coder
Posts: 1349
Joined: Sun Nov 11, 2012 12:26 pm


Cajun Style wrote:
Did the Iceball boys get voxlap to work on Linux? And are you implying you'd like to sell your game?
Iceball is an entirely different engine from voxlap. Also, commercial does not necessarily mean selling.
Sonarpulse
Coder
Coder
Posts: 443
Joined: Thu Dec 13, 2012 7:18 pm


I ran Valgrind once on it, didn't seem to help with much as Valgrind seems best for optimizing a working but leaky program. Maybe I am just using it wrong however. SDL grabs all input without exception ATM making working on Voxlap on Linux a bit annoying.

Yeah it's just me porting right now, but I'd imagine that if I can finish the porting stage, some fellow Linux users working on Iceball would help me whip up an ENet client. raiku has already done some documentation of the protocol on his wiki, which is very useful as PySpades/PySnip is largely undocumented.

The problem with the "no commercial use" bit is that the GPL requires that commercial use be allowed. I don't want to use this commercially, but the issue has nothing to do with how you actually use your code.
Cajun Style
Deuced Up
Posts: 145
Joined: Fri Dec 07, 2012 11:04 am


I see your only branch focuses on rewriting assembly as C. That's a shame IMHO. I know it won't work for ARM and whatnot otherwise. ARM devices often support OpenGL ES though, and should be catered to by some Iceball renderer. I'm not sure how much of a performance hit C to asm will give (probably negligible on modern systems). But it's a shame you won't even be able to compare them.
You are trying to port to MSVC mainly? Then you're doing explicitly the opposite of Iceball, which would perhaps make later integration troublesome.
Your focus on getting rid of assembly and using MSVC actually make me want to start a new project from the original source. Though it should be instructive to find real bugs in MSVC this way, as I mentioned earlier.
GNUMakefile gives me these errors on Linux:
Spoiler:
Code: Select all
source/voxed.cpp:3208:85: warning: trigraph ??) ignored, use -trigraphs to enable
source/voxed.cpp:3234:85: warning: trigraph ??) ignored, use -trigraphs to enable
source/voxed.cpp: In function ‘void getfilenames(char*)’:
source/voxed.cpp:453: error: aggregate ‘find_t fileinfo’ has incomplete type and cannot be defined
source/voxed.cpp:456: error: ‘_A_SUBDIR’ was not declared in this scope
source/voxed.cpp:456: error: ‘_dos_findfirst’ was not declared in this scope
source/voxed.cpp:457: error: ‘_A_NORMAL’ was not declared in this scope
source/voxed.cpp:457: error: ‘_dos_findfirst’ was not declared in this scope
source/voxed.cpp:463: error: ‘strlen’ was not declared in this scope
source/voxed.cpp:465: error: ‘strcpy’ was not declared in this scope
source/voxed.cpp:470: error: ‘_dos_findnext’ was not declared in this scope
source/voxed.cpp: In function ‘char* fileselect(char*)’:
source/voxed.cpp:540: error: ‘getcwd’ was not declared in this scope
source/voxed.cpp:547: error: ‘chdir’ was not declared in this scope
source/voxed.cpp:553: warning: deprecated conversion from string constant to ‘char*’
source/voxed.cpp:583: error: ‘strcpy’ was not declared in this scope
source/voxed.cpp:585: error: ‘strcpy’ was not declared in this scope
source/voxed.cpp:599: error: ‘breath’ was not declared in this scope
source/voxed.cpp:656: error: ‘strcat’ was not declared in this scope
source/voxed.cpp:665: warning: deprecated conversion from string constant to ‘char*’
source/voxed.cpp: In function ‘long int insertsprite(char*, char*, long int)’:
source/voxed.cpp:1422: error: ‘memset’ was not declared in this scope
source/voxed.cpp:1423: error: ‘strlen’ was not declared in this scope
source/voxed.cpp:1450: error: ‘memcpy’ was not declared in this scope
source/voxed.cpp: In function ‘long int voxedloadsxl(char*)’:
source/voxed.cpp:1618: warning: deprecated conversion from string constant to ‘char*’
source/voxed.cpp: In function ‘void notepaddraw()’:
source/voxed.cpp:1870: error: ‘memset’ was not declared in this scope
source/voxed.cpp: In function ‘void helpdraw()’:
source/voxed.cpp:2267: error: ‘memset’ was not declared in this scope
source/voxed.cpp:2281: error: ‘memset’ was not declared in this scope
source/voxed.cpp:2284: error: ‘memset’ was not declared in this scope
source/voxed.cpp:2291: error: ‘memset’ was not declared in this scope
source/voxed.cpp: In function ‘void uninitapp()’:
source/voxed.cpp:2304: error: ‘chdir’ was not declared in this scope
source/voxed.cpp: In function ‘void doframe()’:
source/voxed.cpp:2440: error: ‘strcmp’ was not declared in this scope
source/voxed.cpp:2467: error: ‘strlen’ was not declared in this scope
source/voxed.cpp:2662: error: ‘strlen’ was not declared in this scope
source/voxed.cpp:2778: error: ‘strlen’ was not declared in this scope
source/voxed.cpp:3780: warning: deprecated conversion from string constant to ‘char*’
source/voxed.cpp:3780: warning: deprecated conversion from string constant to ‘char*’
source/voxed.cpp:3802: error: ‘ddflip2gdi’ was not declared in this scope
source/voxed.cpp:3802: error: ‘loadfileselect’ was not declared in this scope
source/voxed.cpp:3804: error: ‘strcpy’ was not declared in this scope
source/voxed.cpp:3805: error: ‘strlen’ was not declared in this scope
source/voxed.cpp:3809: warning: deprecated conversion from string constant to ‘char*’
source/voxed.cpp:3838: error: ‘ddflip2gdi’ was not declared in this scope
source/voxed.cpp:3838: error: ‘loadfileselect’ was not declared in this scope
source/voxed.cpp:3840: error: ‘strcpy’ was not declared in this scope
source/voxed.cpp:3916: error: ‘ddflip2gdi’ was not declared in this scope
source/voxed.cpp:3916: error: ‘loadfileselect’ was not declared in this scope
source/voxed.cpp:3918: error: ‘strcpy’ was not declared in this scope
source/voxed.cpp:4022: error: ‘ddflip2gdi’ was not declared in this scope
source/voxed.cpp:4022: error: ‘fileselectnam’ was not declared in this scope
source/voxed.cpp:4022: error: ‘strcpy’ was not declared in this scope
source/voxed.cpp:4023: error: ‘savefileselect’ was not declared in this scope
source/voxed.cpp:4035: error: ‘ddflip2gdi’ was not declared in this scope
source/voxed.cpp:4035: error: ‘loadfileselect’ was not declared in this scope
source/voxed.cpp:4036: error: ‘strcpy’ was not declared in this scope
source/voxed.cpp:4065: error: ‘ddflip2gdi’ was not declared in this scope
source/voxed.cpp:4065: error: ‘fileselectnam’ was not declared in this scope
source/voxed.cpp:4066: error: ‘savefileselect’ was not declared in this scope
source/voxed.cpp:4464: error: ‘strcpy’ was not declared in this scope
source/voxed.cpp:4470: error: ‘strcmp’ was not declared in this scope
source/voxed.cpp:4476: error: ‘strcmp’ was not declared in this scope
source/voxed.cpp: In function ‘long int initapp(long int, char**)’:
source/voxed.cpp:4489: error: ‘getcwd’ was not declared in this scope
source/voxed.cpp:4501: error: ‘strcasecmp’ was not declared in this scope
source/voxed.cpp:4502: error: ‘strcasecmp’ was not declared in this scope
source/voxed.cpp:4503: error: ‘strcasecmp’ was not declared in this scope
It seems it's not properly configured for Linux either :-/ I'll look into it, but perhaps you have some quick answers.
Iceball is an entirely different engine from voxlap.
That explains a lot. And makes the progress even more admirable.
Also, commercial does not necessarily mean selling.
<tsoukalos>advertising</tsoukalos> Forgot about that. Taking on Voxlap's license is something that should be considered. The GPL isn't holy.

After a quick glance at the original code I feel silly. It originally was a MSVC6 project. I'll be comparing the original code with yours.
Sonarpulse
Coder
Coder
Posts: 443
Joined: Thu Dec 13, 2012 7:18 pm


Cajun Style wrote:
I see your only branch focuses on rewriting assembly as C. That's a shame IMHO. I know it won't work for ARM and whatnot otherwise. ARM devices often support OpenGL ES though, and should be catered to by some Iceball renderer. I'm not sure how much of a performance hit C to asm will give (probably negligible on modern systems). But it's a shame you won't even be able to compare them.
Nope, I have multiple branches locally and on github. In fact right now my current project is to port all my changes that have nothing to do with removing assembly on to my master branch, and then rebasing no_asm on master, as no_asm is many commits a head right now. I really need to get SOMETHING running with gcc first but have no fear, I will make sure that my port is just as performant as the original. Performance is really the only reason to use voxlap, and thus it is an absolute top priority.
Cajun Style wrote:
You are trying to port to MSVC mainly? Then you're doing explicitly the opposite of Iceball, which would perhaps make later integration troublesome.
Your focus on getting rid of assembly and using MSVC actually make me want to start a new project from the original source. Though it should be instructive to find real bugs in MSVC this way, as I mentioned earlier.
What are you saying? Voxlap has always run when compiled with MSVC, my goal is to make it run just as well when compiled with SDL and GCC on windows, mac, or linux (or android and iOS with no asm). I think you are confused because I back-ported the SDLmain so it can be used with msvc, before you had to use directX directly (lol pun) when compiling with windows. This was the only way to make sure that the SDL code actually worked since gcc was not working.
Cajun Style wrote:
GNUMakefile gives me these errors on Linux
You notice all these errors come from voxed right? that means game compiled correctly! voxed calls directx directly, and thus is not ported yet. the example game however only calls directX through winmain and thus simply dropping in sdlmain instead removes that dependency.

Cajun Style wrote:
Iceball is an entirely different engine from voxlap.
That explains a lot. And makes the progress even more admirable.
Also, commercial does not necessarily mean selling.
<tsoukalos>advertising</tsoukalos> Forgot about that. Taking on Voxlap's license is something that should be considered. The GPL isn't holy.
After a quick glance at the original code I feel silly. It originally was a MSVC6 project. I'll be comparing the original code with yours.
Yes GPL is not holy. I personally am a fan of the FSF and all that, but if I can't use voxlap with the GPL so be it. My port is open source, and as I am making run on gnu/linux I feel I am doing my part for free software.

All in all, I am glad you are taking a good luck at this, Cajun Style. The more you can help me port it, the better.
Cajun Style
Deuced Up
Posts: 145
Joined: Fri Dec 07, 2012 11:04 am


The repository I copied only had a branch "no_asm". One of us fumbled.
Sonarpulse
Coder
Coder
Posts: 443
Joined: Thu Dec 13, 2012 7:18 pm


you must of only fetched the default branch, which is no_asm.
Code: Select all
git fetch git://github.com/Ericson2314/Voxlap.git
do that and you should get them all. Or just fork me repo on github and clone that.
Cajun Style
Deuced Up
Posts: 145
Joined: Fri Dec 07, 2012 11:04 am


Sonarpulse
Coder
Coder
Posts: 443
Joined: Thu Dec 13, 2012 7:18 pm


Well, I have finally wrangled with the history long enough to update my master branch with changes that don't really belong in just no_asm. That means you can now compile SDL+MSVC+assembly, and it runs just like the original.

The next step is to rebase no_asm off the updated master branch. I also read on what the equivalent of "-ffast-math" is for MSVC, which should make the msvc no_asm build less buggy. It is important to verify this as the gcc no_asm build does not currently work as I said before.
Last edited by Sonarpulse on Wed Dec 26, 2012 2:15 pm, edited 1 time in total.
Cajun Style
Deuced Up
Posts: 145
Joined: Fri Dec 07, 2012 11:04 am


I'm trying to get it to compile on Linux. (Going for -Wall without errors Green_Sunglasses1) voxlap5.cpp doesn't compile with a weird error. Namely:
Code: Select all
‘__builtin_unreachable’ was not declared in this scope
TIL learned about hinting the compiler about unreachable locations. __assume(0) seems to rightly be translated to this, but why it can't find the built-in is a mystery. I tried -fbuiltin, and -fnonansi-builtins with no effect. Replacing the macro's with __builtin_unreachable written out also ineffective. Google turned up nothing.
TIL stacks aren't aligned and assembly doesn't like that. Which was irrelevant in this case <_< The existing __ALIGN macro's were expanded, but on the wrong side of the declarations. __attribute__ ((aligned(16))) goes after it, and the compiler no longer warns that it is unused. You could define a macro to take care of MSVC and GCC... or #ifdef for each separate case. I'm not really sure. I usually don't use this low-level stuff.
Also for some reason it tries to compile the v5.jwasm wit jwasm, even though I set AsmName to nasm in the makefile. Hope this helps.
222 posts Page 2 of 15
Return to “Noteworthy Picks”

Who is online

Users browsing this forum: No registered users and 2 guests