Register
Email: Password:
Forum » please release Notrium source code!!
  • « previous
  • 1
  • 2
  • » next
    •

    please release Notrium source code!!

    Notriumyay (guest) 11 years ago
    ooo pls!!!
    #
    INFERNUS 11 years ago
    I always wanted to look in the Notrium source code.
    :3
    #
    ville 11 years ago
    Well, it's a possibility. But hey, I've yet to release any of my other games besides Bikez II! Wazzal next?
    #
    Amarth 11 years ago
    Err.

    You open sourced Wazzal two years ago.

    I'm still trying to get it to compile.
    #
    ville 11 years ago
    Drats, I'm running out of excuses then. Actuall, I kind of seem to recall sending the Notrium sources to you Amarth at one point because you wanted to look at it, but I can't for the life of me remember what kind of a license I gave it.
    #
    Amarth 11 years ago
    Yeah, you did, there was a kind of "if you do something with it we might work something out"-license on it which I interpreted as a non-disclosure agreement.

    I don't know where I left the code though. :/ But I remember it was easy to make it compile! I even had a whole Linux build running, replacing Grim2D with SDL.

    Hmm. I think I have an idea where I left it.. Might be able to dig it up if the particular computer still works. It's still your code though, so it's your call to decide what to do with it.
    #
    SpeedBlade 11 years ago
    Amarth said:
    Err.

    You open sourced Wazzal two years ago.

    That post has a comment about Notrium's source code and Notrium 2 from two years ago.
    #
    E_net4 10 years ago
    I'm shamefully bumping this because somehow Notrium grabbed my attention again last week. May we have the source code? I even recall the latest version having a few bugs, so who knows what the community can do on that.
    #
    Anonymous1157 10 years ago
    On a related note, I just discovered that the source code to the Pakoon games was released. I looked at the V1.One! sources, but they're kind of a mess.

    I'd love to have Amarth's SDL port of Notrium. I'd like to try to fix the graphics corruption at non-standard resolutions, if it's still present in the port, 'cause that's the bug that bothers me the most.
    #
    E_net4 10 years ago
    Well, we may have to poke Amarth into looking deeper into his archives. It would be great to have Notrium open-sourced.
    Edited 10 years ago
    #
    Amarth 10 years ago
    I have recovered the code from (literally) a dusty and broken computer. Had to relearn a few Linux-tricks along the way. It was cool in the sense of this-is-so-not-2014 cool.

    Haven't tried building the code yet, but I think that will not be a big problem.

    It's still Ville's copyright obviously, so I'm waiting for his word.

    Ideally, I hope to release it on Github, which would make it easiest to collaborate.
    Edited 10 years ago
    #
    E_net4 10 years ago
    Amarth said:
    Ideally, I hope to release it on Github, which would make it easiest to collaborate.
    I approve of this!
    #
    ville 10 years ago
    Feel free to post it on GitHub Amarth. The license to it shall be that:
    -Ville Mönkkönen will retain all rights to the Notrium intellectual property, including name, source code, game content and characters. I'm probably going to release a Notrium 2 at some point, so I still want to own everything related to it.
    -Any changes (be it source code or game content) from the original Notrium posted on the Open Notrium version shall be under some nice open source license.
    -The Open Notrium shall have a perpetual license to use material and source code from the original 2003 Notrium, and to release new binary versions of the game to the public. Any releases shall be free for the end user.
    -The original developers shall be credited in a clearly visible place.

    In short, the idea is that people can make changes, and they can release new versions of the Open Notrium for free if they like, but I will be able to make new Notrium versions without releasing my new stuff for free.

    I think it's great that there are still people interested in good old Notrium! If Amarth's version is missing something or broken, I can look up my own version of the source. And there's still Magebane 2 to release, isn't there? I haven't open sourced that yet?
    Edited 10 years ago
    #
    Amarth 10 years ago
    https://github.com/verhoevenv/OpenNotrium

    Go wild!

    PS: Ville, you might want to get some game news sites notified.
    Edited 10 years ago
    #
    MageKing17 10 years ago
    Awesome! I'll be trying to compile this later.

    EDIT: After some finagling, I managed to compile, but there are a couple of... oddities...
    First, this source is apparently based on 1.3.4.1 instead of 1.3.4.5. Were there any engine changes between the two, other than the addition of the launcher window? The release post mentioned bugfixes, but nothing more specific.
    Secondly, I'm not sure if it's just not having set a compilation option right, but the copyright notice on the bottom of the screen declares the game to have been created by "Ville MMMMnkkkkknen" (clearly, text_output::write_line() is repeating the last good character when it comes to the "ö", which is being spread across three bytes, so it doesn't seem to be UTF-8...).
    Thirdly, the combination timer is throwing out seemingly-random numbers instead of counting down normally. I don't remember that happening in the original release of 1.3.4.1...
    Edited 10 years ago
    #
    E_net4 10 years ago
    MageKing17 said:
    Awesome! I'll be trying to compile this later.

    EDIT: After some finagling, I managed to compile
    I'd really like to have that shared from either you or Amarth, because I have no idea what version of SDL you are using and what other compilation flags are appropriate.
    Later on, we should use autotools and maybe even provide a VS project file for people under Windows.

    MageKing17 said:
    First, this source is apparently based on 1.3.4.1 instead of 1.3.4.5. Were there any engine changes between the two, other than the addition of the launcher window? The release post mentioned bugfixes, but nothing more specific.
    Secondly, I'm not sure if it's just not having set a compilation option right, but the copyright notice on the bottom of the screen declares the game to have been created by "Ville MMMMnkkkkknen" (clearly, text_output::write_line() is repeating the last good character when it comes to the "ö", which is being spread across three bytes, so it doesn't seem to be UTF-8...).
    Thirdly, the combination timer is throwing out seemingly-random numbers instead of counting down normally. I don't remember that happening in the original release of 1.3.4.1...
    All I know about that is that 1.3.4.1 presented a better performance than 1.3.4.5, and the latter had a very bad bug that would make me rather choose the former: remember the camera positioning when entering the hover bike? But sure, we can list those bugs as issues and let the community work on them.

    EDIT: I did it! It's running under my linux installation!
    Allow me to fork the repository and get some useful stuff done.

    EDIT x2: There we go. https://github.com/Enet4/OpenNotrium
    Hopefully it will be ok for me to make future pull requests.
    Edited 10 years ago
    #
    ville 10 years ago
    Momentous!
    Actually I can't seem to find my logs on what's the difference between the versions, but I'd say if anything was fixed, it should be a minor issue to fix it again. It's most likely just the launcher window though.
    #
    Anonymous1157 10 years ago
    I just ran E_net4's fork on Gentoo!

    I've already noticed several problems, but I'll get a Github account and post them there.
    #
    NeoGangster 10 years ago
    This looks like fun.
    So how ashamed are you of your 10 years old code ville?
    #
    E_net4 10 years ago
    I just ran E_net4's fork on Gentoo!

    I've already noticed several problems, but I'll get a Github account and post them there.
    Well, you may wish to work on Amarth's repository, to keep things centralized. I only have a fork right now so I can make pull requests.
    Also, at least one issue is known right now. It'd be nice to have more people looking at it.
    Edited 10 years ago
    #
    Anonymous1157 10 years ago
    E_net4 said:
    Well, you may wish to work on Amarth's repository, to keep things centralized. I only have a fork right now so I can make pull requests.
    Ah. The main reason I used your fork is because yours has a Makefile that Amarth seems not to have pulled in, because he'll be setting up CMake. I just quickly wanted to get one or the other working to see what happens.
    #
    E_net4 10 years ago
    Anonymous1157 said:
    E_net4 said:
    Well, you may wish to work on Amarth's repository, to keep things centralized. I only have a fork right now so I can make pull requests.
    Ah. The main reason I used your fork is because yours has a Makefile that Amarth seems not to have pulled in, because he'll be setting up CMake. I just quickly wanted to get one or the other working to see what happens.
    Ah, the wonders of a simple Makefile.

    I wonder if the CMake facilities are to be installed soon. Indeed, right now there are hardly any clues on how it should be built and what dependencies are needed.
    #
    RedBreadcat 10 years ago
    Last time I posted here was under the username "Aegix" or something almost a decade ago! Those were the days. Looking back through my post history I'm quite embarrassed. >_<
    Anyways, It was ludicrously difficult to get the code working on Windows with Visual Studio, as there were many hoops to jump through and several unexpected problems. However, now that I look back on it, things certainly wouldn't be so bad if I were more proficient. I didn't even really understand the purpose of .lib files before jumping into this. Obviously, I'm quite inexperienced with C++. I must say I felt quite incompetent having so many problems, where everyone else here didn't have a single complaint!
    To help other people, here's a rough list of stuff to keep an eye out on when getting OpenNotrium to work:
    -Download physfs and cmake. Use cmake on physfs and you'll get a bunch of files in a folder. You want to include "physfs.lib" into your project. None of the other files matter, I think.
    -You need SDL 1.2. Not 2.0! You'll also need SDL_image and SDL_mixer, both v1.2. Include all the libs, header files, and make sure the DLLs are in your working directory
    -Visual Studio will complain about fopen, sprintf and other things. It'll want fopen_s and similar instead. I went through the effort of replacing all that stuff, but it'll be easier just Google "_crt_secure_no_warnings" and follow the instructions from there.
    -For some reason I got lots of complaints about libstdc++-6.dll, libgcc_s_dw2-1.dll and other stuff. Just download them and stick them with the rest of the DLLs. There's probably a smarter way to resolve this >_>
    -You need to include opengl32.lib and glu32.lib along with the other libs. Don't worry, these come with your graphics drivers (I think), and the compiler will find them for you. No need to have them in your project's directory.
    -Visual Studio's debug working directory conflicts with physfs. You see, when you debug the program it THINKS it's running in the solution directory. So, all the file access and relative paths go through there. However, the actual executable is in YourSolutionDirHere\debug. The problem is that the program uses physfs to load its files, and physfs is clever enough to know the TRUE location of the executable. Therefore, your texture, data, etc folders need to be in YourSolutionDirHere\debug. You also need to put all of SDL's DLLs in there. And you also need to set the debug working directory to $(SolutionDir)\debug. This took a great deal of suffering, trial and error to discover.
    -I was getting errors with all the max() and min() functions not actually existing. Apparently they actually need to be fmax() and fmin(). I have no idea how this could happen, given that such functions were from a standard library.

    All of this stuff was probably entirely my own fault, but it may be useful to other people.
    #
    Amarth 10 years ago
    CMake and README are definitely urgent. I hope to get some work done this weekend. A proper CMake file should solve about half the issues listed by RedBreadCat. The other half is just C++ being a really old technology.

    ibstdc++-6.dll, libgcc_s_dw2-1.dll etc are caused by the SDL_mixer.dll they distribute being compiled with dynamic linking. IMO they made a mistake there, but I can't do much about it. You can add the dll's or recompile SDL_mixer kind of like you compiled physfs.

    I hope to upgrade to SDL 2.0 somewhat soon, but it's less urgent than CMake at this moment.

    max() and min(), and fopen() etc shouldn't be causing errors I believe - it doesn't for me anyway. What version of Visual Studio are you using?
    #
    RedBreadcat 10 years ago
    Amarth said:

    max() and min(), and fopen() etc shouldn't be causing errors I believe - it doesn't for me anyway. What version of Visual Studio are you using?
    I'm using VS 2013 Professional (with a student license). fopen() isn't *really* causing an error per se. The compiler just hates it for being unsafe, and will refuse to compile because of it. You can force it to compile by changing a setting in the preprocessor options. Older versions of Visual Studio are less stringent and only give a warning. It's far less irritating IMO!

    As for max() and min(), those functions are coming from math.h right? According to this, at least, those two functions don't even exist, whereas fmax() and fmin() do.... http://www.cplusplus.com/reference/cmath/

    I DUNNO.
    #
    E_net4 10 years ago
    You have some good points there, RedBreadcat. Let me comment on a few of the troubles that you've encountered.

    -Download physfs and cmake. Use cmake on physfs and you'll get a bunch of files in a folder. You want to include "physfs.lib" into your project. None of the other files matter, I think.
    CMake shouldn't be needed yet, at least until Amarth gets the CMake build file done. As for other required libraries, I simply had a look at the error messages and found the need to install and link with physfs. In a linux distribution, installing such things is often straightforward with the use of a package manager. Adding the link would then be as simple as adding the -lphysfs flag to GCC. There are different approaches in Visual Studio for the linking part. The other required libraries such as SDL were found the same way.

    -You need SDL 1.2. Not 2.0! You'll also need SDL_image and SDL_mixer, both v1.2. Include all the libs, header files, and make sure the DLLs are in your working directory
    My hunch is that SDL 2 wasn't stable back when Amarth ported the game. So yeah, that's required. Switching to SDL 2 could bring a few advantages, but I wouldn't prioritize the migration.

    -Visual Studio will complain about fopen, sprintf and other things. It'll want fopen_s and similar instead. I went through the effort of replacing all that stuff, but it'll be easier just Google "_crt_secure_no_warnings" and follow the instructions from there.
    It's true that Microsoft made its own bits of strangeness in their C++ headers. Yeah, forcing the compiler to allow that should be fine. We could also make a macro for each of those functions, if that really becomes important.

    -For some reason I got lots of complaints about libstdc++-6.dll, libgcc_s_dw2-1.dll and other stuff. Just download them and stick them with the rest of the DLLs. There's probably a smarter way to resolve this >_>
    Curious. I wonder if that can be fixed by making a static link to the standard C++ library, rather than a dynamic link.

    -You need to include opengl32.lib and glu32.lib along with the other libs. Don't worry, these come with your graphics drivers (I think), and the compiler will find them for you. No need to have them in your project's directory.
    That's OpenGL all right. Open Notrium uses that, so you have to add those to the linking process.
    -Visual Studio's debug working directory conflicts with physfs. You see, when you debug the program it THINKS it's running in the solution directory. So, all the file access and relative paths go through there. However, the actual executable is in YourSolutionDirHere\debug. The problem is that the program uses physfs to load its files, and physfs is clever enough to know the TRUE location of the executable. Therefore, your texture, data, etc folders need to be in YourSolutionDirHere\debug. You also need to put all of SDL's DLLs in there. And you also need to set the debug working directory to $(SolutionDir)\debug. This took a great deal of suffering, trial and error to discover.
    Well, regardless of what physfs is doing, you need the extra resource files of the game in order to make it work.
    -I was getting errors with all the max() and min() functions not actually existing. Apparently they actually need to be fmax() and fmin(). I have no idea how this could happen, given that such functions were from a standard library.
    The max and min functions actually do exist, but in the <algorithm> header. See that "main.h" includes <algorithm> rather than <cmath>. The Visual C++ compiler seems to know it too...

    @Amarth:
    The other half is just C++ being a really old technology.
    We can move to C++11, which makes the language feel much easier to play with.
    Edited 10 years ago
    #
    Amarth 10 years ago
    E_net4 said:
    CMake shouldn't be needed yet, at least until Amarth gets the CMake build file done.
    For clarity: physfs doesn't distribute binaries for Windows, and they build with CMake. On Windows you'll need CMake to build physfs which you'll need to build OpenNotrium, even if OpenNotrium itself doesn't need CMake yet.

    @Amarth:
    The other half is just C++ being a really old technology.
    We can move to C++11, which makes the language feel much easier to play with.
    Hmm, I like the idea. We need to see if it does not come at the cost of losing support with Visual Studio and whatever other platforms we want to support.

    I'm secretly thinking about Wii Homebrew.
    #
    E_net4 10 years ago
    Amarth said:
    E_net4 said:
    CMake shouldn't be needed yet, at least until Amarth gets the CMake build file done.
    For clarity: physfs doesn't distribute binaries for Windows, and they build with CMake. On Windows you'll need CMake to build physfs which you'll need to build OpenNotrium, even if OpenNotrium itself doesn't need CMake yet.
    All right....

    @Amarth:
    The other half is just C++ being a really old technology.
    We can move to C++11, which makes the language feel much easier to play with.
    Hmm, I like the idea. We need to see if it does not come at the cost of losing support with Visual Studio and whatever other platforms we want to support.
    I agree on both ends, actually. I've been using C++11 for a while now, and it's great. However, even the latest version of Visual Studio doesn't have the entire collection of new features in the language. The ones that bother me the most are the lack of constexpr and noexcept. In the event that we could use these features, switching to MinGW GCC might become a better choice.

    I'm secretly thinking about Wii Homebrew.
    I don't have a Wii, but if you can keep the code nicely portable, feel free to give that a try.
    Edited 10 years ago
    #
    Amarth 10 years ago
    CMake support is in. For me it works under Ubuntu and Visual Studio 10. I would love it if others gave it a try.

    I've also added a README with extensive instructions on how to build, hope it helps.
    #
    E_net4 10 years ago
    CMake is working fine from here! Generating both Unix Makefiles and a Code::Blocks project for them was successful.

    I've also noticed that we now have many more issues to attend to. Let's keep discussing and working on them.

    The readme file is nice, but providing an Ubuntu solution for the case of a linux environment feels a bit too harsh, IMO.

    And as for C++11, I would thumbs up on it. But Visual Studio users might get upset in the long run.
    #
    NeoGangster 10 years ago
    I wouldn't trust MinGW blindly. To this day it hasn't implemented atomics(and probably other threading stuff) correctly even though GCC has since around 4.6.

    Thumbs up from me for using C++11, but I would suggest to only use features that are implemented in GCC and VS.
    #
    E_net4 10 years ago
    NeoGangster said:
    I wouldn't trust MinGW blindly. To this day it hasn't implemented atomics(and probably other threading stuff) correctly even though GCC has since around 4.6.
    Are you sure? I've had no troubles using those in MinGW, and I have an up-to-date installation of it.

    Thumbs up from me for using C++11, but I would suggest to only use features that are implemented in GCC and VS.
    Well, that is sort of feasible if we establish some coding guidelines. How about using the wiki for this?
    Edited 10 years ago
    #
    ville 10 years ago
    NeoGangster said:
    This looks like fun.
    So how ashamed are you of your 10 years old code ville?

    A lot of the code is actually from year 2000, back from when I was 17. My method back then was to reuse my previous engine for every new game I made, it made things a bit messy, but I could finish a game every half a year or so.

    The code is not pretty for sure, just don't open it trying to learn proper coding. I think back then I wasn't even so sure on how to make classes. It's nice to notice I've learned a trick or two since those days.
    #
    Anonymous1157 10 years ago
    CMake is working for me on Gentoo. Excellent!
    #
    NeoGangster 10 years ago
    E_net4 said:
    ... Are you sure? I've had no troubles using those in MinGW, and I have an up-to-date installation of it.
    I haven't tested the most recent version but I assume they aren't fixed because this and this are still open. Related StackOverflow Question. I think I ran the test with mingw 4.8.x last year and it was still not generating the fences. But feel free to prove me wrong, it would make me sleep better if you did

    ville said:
    ...It's nice to notice I've learned a trick or two since those days.
    I honestly felt a little like looking at my old code from 10 years back. It's nice to see how everyone started small at some point .
    Edited 10 years ago
    #
    Forum » please release Notrium source code!!
  • « previous
  • 1
  • 2
  • » next
    •

    Post Reply
    Your email:
    Your name: