Author Topic: OSX port  (Read 2809 times)

tintor

  • Newbie
  • *
  • Posts: 3
    • View Profile
OSX port
« on: October 14, 2014, 06:19:46 am »
Casting my vote for OSX port of Blackvoxel. :)

olive

  • Administrator
  • Full Member
  • *****
  • Posts: 149
    • View Profile
Re: OSX port
« Reply #1 on: October 15, 2014, 03:19:14 am »
Hi tintor,

Thanks  :)

We are planning to make an OSX version of Blackvoxel.

We think about launching an Indiegogo campaign to fund the purchase of a Mac and the development work.

The Blackvoxel Team
Blackvoxel is now a free software!  Visit the official website http://www.blackvoxel.com
Follow us on twitter | Follow us on facebook

cortices

  • Newbie
  • *
  • Posts: 3
  • ¯\_(ツ)_/¯
    • View Profile
Re: OSX port
« Reply #2 on: July 28, 2015, 02:35:54 am »
I'm looking into how much work porting would be at the moment. I would be interested to be involved, depending on how much work is needed. I'll get back when I've had a look.

cortices

  • Newbie
  • *
  • Posts: 3
  • ¯\_(ツ)_/¯
    • View Profile
Re: OSX port
« Reply #3 on: July 28, 2015, 11:36:20 am »
As they say, a picture is worth a thousand words  ;D

« Last Edit: July 28, 2015, 11:38:36 am by cortices »

Enigma

  • Administrator
  • Jr. Member
  • *****
  • Posts: 54
    • View Profile
Re: OSX port
« Reply #4 on: July 28, 2015, 06:37:35 pm »
Hi cortices,

Welcome to Blackvoxel forum and thank you for your involvment for the Mac Os port  :)

As we don't have Mac, we are searching volunteer for porting Blackvoxel on mac.

We see you have managed to make it running.  :D

Do you compiled it natively or used some stuff to run some Linux version ?

The Blackvoxel Team

cortices

  • Newbie
  • *
  • Posts: 3
  • ¯\_(ツ)_/¯
    • View Profile
Re: OSX port
« Reply #5 on: July 29, 2015, 05:49:00 am »
    This is running natively. It took about 4 hours work of source modification, adding extra platform checks everywhere necessary, but most were identical to linux (the things that were unix filesystem operations). It took an hour to get SDL 1.2 working with the mac-specific header files, and to work through a bunch of linker errors. It's a very messy job, but the main outcome is it didn't actually require that much work, and I'd be happy to help more on it. Otherwise the Mac system OpenGL frameworks (libraries) were easy to link to.

    I started trying to use clang (Apple LLVM compiler) with makefile, but couldn't resolve linker errors, so I imported into an Xcode project so it would manage compiling properly. Having got it to run now though, the makefile could be fixed to work.
    BTW there were 395 compiler warnings -- your C++ is a bit outdated and messy :D
    (BTW the 'register' tag is completely ignored by modern compilers, that was most of the warnings)

    There are some obvious problems and as I'm a complete noob to the game I don't actually know how to play to test more things, but generally it worked and created a universe and loaded it.

    Confirmed working:
    • Game graphics
    • World gen, save & load
    • Movement (WASD, jump)
    • Placing voxel (at least the one that was in inventory to start)
    • Key mapping
    • Fullscreen & windowed

    Not completely working or not working at all:
    • Audio (kinda works, but system complains it's using deprecated API. Upgrading to SDL 2.0 would fix). Volume setting has no effect
  • Opening inventory ('I' key) didn't seem to work? Not sure why
  • Retina graphics (this is normal, no openGL games support retina well)

BTW J'ai remarqué que vous êtes français -- je parle français bien mais je vais mieux à comprendre qu'à parler/écrire (j'ai aucune doute qu'il y a plusieurs d'erreurs dans cette phrase).
« Last Edit: July 29, 2015, 05:56:02 am by cortices »

Enigma

  • Administrator
  • Jr. Member
  • *****
  • Posts: 54
    • View Profile
Re: OSX port
« Reply #6 on: July 29, 2015, 11:53:25 pm »
    This is running natively. It took about 4 hours work of source modification, adding extra platform checks everywhere necessary, but most were identical to linux (the things that were unix filesystem operations). It took an hour to get SDL 1.2 working with the mac-specific header files, and to work through a bunch of linker errors. It's a very messy job, but the main outcome is it didn't actually require that much work, and I'd be happy to help more on it. Otherwise the Mac system OpenGL frameworks (libraries) were easy to link to.

    I started trying to use clang (Apple LLVM compiler) with makefile, but couldn't resolve linker errors, so I imported into an Xcode project so it would manage compiling properly. Having got it to run now though, the makefile could be fixed to work.
    BTW there were 395 compiler warnings -- your C++ is a bit outdated and messy :D
    (BTW the 'register' tag is completely ignored by modern compilers, that was most of the warnings)
    There are some obvious problems and as I'm a complete noob to the game I don't actually know how to play to test more things, but generally it worked and created a universe and loaded it.

    Confirmed working:
    • Game graphics
    • World gen, save & load
    • Movement (WASD, jump)
    • Placing voxel (at least the one that was in inventory to start)
    • Key mapping
    • Fullscreen & windowed

    Not completely working or not working at all:
    • Audio (kinda works, but system complains it's using deprecated API. Upgrading to SDL 2.0 would fix). Volume setting has no effect
  • Opening inventory ('I' key) didn't seem to work? Not sure why
  • Retina graphics (this is normal, no openGL games support retina well)

BTW J'ai remarqué que vous êtes français -- je parle français bien mais je vais mieux à comprendre qu'à parler/écrire (j'ai aucune doute qu'il y a plusieurs d'erreurs dans cette phrase).

Congratulation for this work  :)

We'll try to help you as far as we can....

About SDL sound, we already got sound problems on Windows depending on how the SDL library is compiled. The problem with SDL audio is that this library is built differently depending on which audio library header was detected. As we understood, if no "modern" audio system header is detected on SDL compilation, it revert on some kind of default codepath.
We suggest to try a precompiled library from the official SDL website to test if it's working better.

We'll certainly make an SDL 2 official transition soon. (That's a change the core team will do all internally because that's an important move, we have to master it).

At this point, the "not working" inventory seem to be the only serious issue.

The inventory opening is triggered in ZGame_Events.cpp at line 869.

First, we suggest you insert a breakpoint (or a printf) into the "if" block to see if the execution reach in when you press the "I" key. If not the case, it could be a problem about keyboard scancode.

If execution enters well into the "if", make the following tests :
Look at the sidebar : does the sidebar is displaying well ? (Image showing the sidebar at the right of the screen http://www.blackvoxel.com/view.php?node=1239).

Try to hit the "F12" key : A little transparent window should show on the upper left of the screen displaying framerate. (This test is for ensuring that the Blackvoxel windowing system is working well. )

An opengl display problem is always possible, but very unlikely as we choosed a "most compatible" way to make display an never get any serious opengl display problems despite various drivers and platforms.

As we understand, you used the LLVM compiler. As currently, the status of Blackvoxel is "untested" with LLVM, we can not exclude the possibility that some problems can come from.

Like a lot of video games, Blackvoxel uses a rather "low level" programming style and a lot of optimisation (in order to make the dynamic MVI concept running at a good speed : http://www.blackvoxel.com/view.php?node=1569 ).
That can make compiler little differences more important than in regular programs.

Ultimately, if nothing else works, we suggest to make a try with the gcc compiler to see if some issues goes out.

Oui, nous sommes français. Nous avons bien compris ce que vous avez dit.  ;)
Ne vous inquietez pas pour les petites fautes. Nous sommes certains que nous en faisons beaucoup quand nous parlons ou écrivons en anglais.  :)

The Blackvoxel Team

d3x0r

  • Jr. Member
  • **
  • Posts: 69
    • View Profile
Re: OSX port
« Reply #7 on: August 02, 2015, 11:21:28 am »
Re Deprecated register keyword...

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4340.html
http://stackoverflow.com/questions/10675072/is-the-register-keyword-still-used

I personally disagree that this should be deprecated... but apparently has, and will be removed in C++17.
There are certainly more ideally things the compiler can't figure out, and doesn't. I've seen worse and worse code generation by more modern compilers than things in the mid 90's. 

The argument goes like 'it was only a hint, and the compiler has register coloring anyway so it's meaningless.' but I've seen little effort by the compiler to preserve values in registers, mostly because by nature it assumes things are 'volatile' so it reloads them (I guess, can't otherwise figure why just bad code would be generated).

I certainly don't want people to go to inline assembly for something so simple since that's far from portable between compilers... this really all makes me sad.