don't click here

PROSONIC IS NOW OPEN SOURCE

Discussion in 'Fangaming Discussion' started by saxman, Jul 16, 2008.

Thread Status:
Not open for further replies.
  1. Dude

    Dude

    Tech Member
    3,138
    0
    16
    Southbridge, MA
    Random VR/AR trash
    <!--quoteo(post=494553:date=Aug 22 2010, 01:21 PM:name=Hinchy)--><div class='quotetop'>QUOTE (Hinchy @ Aug 22 2010, 01:21 PM) <a href="index.php?act=findpost&pid=494553">[​IMG]</a></div><div class='quotemain'><!--quotec-->Hey, if I could chime in, please only use GPL if you find it necessary. LGPL's a little better. I just don't like the idea of using the ProSonic engine to make a fangame and then under the GPL being forced to release the source to your Sonic fangame, because then a million people will recolor your sprites and call it their "MODDED VERSION!!".

    Just my $0.02.<!--QuoteEnd--></div><!--QuoteEEnd-->


    This will happen in any sonic related release. However, I second the notion as I don't think my code is something that should ever see the light of day, its just not good enough for the competent programmer to look at. And besides, who says I want to share MY code? Its ok if the owner wants to share his but my additions are mine. I don't mind telling people which engine I used, and what code I used but I like keeping my code to myself until it outlives its useful lifespan.
     
  2. Conan Kudo

    Conan Kudo

    「真実はいつも一つ!」工藤新一 Member
    478
    1
    18
    <!--quoteo(post=494715:date=Aug 22 2010, 06:21 PM:name=Dude)--><div class='quotetop'>QUOTE (Dude @ Aug 22 2010, 06:21 PM) <a href="index.php?act=findpost&pid=494715">[​IMG]</a></div><div class='quotemain'><!--quotec--><!--quoteo(post=494553:date=Aug 22 2010, 01:21 PM:name=Hinchy)--><div class='quotetop'>QUOTE (Hinchy @ Aug 22 2010, 01:21 PM) <a href="index.php?act=findpost&pid=494553">[​IMG]</a></div><div class='quotemain'><!--quotec-->Hey, if I could chime in, please only use GPL if you find it necessary. LGPL's a little better. I just don't like the idea of using the ProSonic engine to make a fangame and then under the GPL being forced to release the source to your Sonic fangame, because then a million people will recolor your sprites and call it their "MODDED VERSION!!".

    Just my $0.02.<!--QuoteEnd--></div><!--QuoteEEnd-->


    This will happen in any sonic related release. However, I second the notion as I don't think my code is something that should ever see the light of day, its just not good enough for the competent programmer to look at. And besides, who says I want to share MY code? Its ok if the owner wants to share his but my additions are mine. I don't mind telling people which engine I used, and what code I used but I like keeping my code to myself until it outlives its useful lifespan.
    <!--QuoteEnd--></div><!--QuoteEEnd-->

    Considering that ProCode scripts are not bound to the GPL explicitly, and that the idea is that you could create a game with a combination of m68k and pcs, pcs alone, or m68k alone, both of which don't fall under the GPL's license compliance clause due to the exception, I doubt it would really be as big of a problem. I think of the ProSonic codebase itself as a baseline. To create fangames, it shouldn't be necessary to modify the core code, but modifying the core code will help improve all games using the engine.
     
  3. saxman

    saxman

    Oldbie Tech Member
    Let me attempt to put to rest any misconceptions about the so-called licensing of ProSonic:

    Nothing about ProSonic is GPL bound. The only license attached to it is the license I wrote. You can do anything you want with my code. If you want to borrow some code and insert it into a program you will later be selling for $100 a pop, that's fine. Nobody has to see the code, and nobody is restricted as far as what they can do with the code. The only restrictions are the portions I don't personally own -- the Obj01 code for example.

    Here is the license as read in README.TXT:

    Code (Text):
    1. PROSONIC PUBLIC SOURCE CODE RELEASE
    2. AUGUST 17, 2010
    3.  
    4.  
    5. Here it is, the entire source code to the ProSonic engine. This by no means is
    6. an indication that I have stopped work on this engine forever. However, I also
    7. have other interests that need my attention, so I decided to go public with my
    8. source code to this project.
    9.  
    10. You will need the Allegro, Zlib, and HawkNL libraries to compile this code.
    11. The DOS version is the exception, where all HawkNL references are ignored.
    12.  
    13. My goal with this project was always to make the perfect game engine for Sonic
    14. games that everyone would want to use to make their very own Sonic game. I am
    15. hoping with the release of this code, someone will come along and make this
    16. the engine I always envisioned it becoming. I have laid what I feel is a good
    17. foundation for beginning something big in terms of a quality Sonic fan game.
    18.  
    19. There are things that could be improved. The object manager could be tweaked
    20. to be more flexible with moving objects. The PROCODE scripting support could
    21. be improved to allow more complex routines and arithmetic. The 68000 code
    22. support is only good enough to allow a certain number of objects to run in
    23. ProSonic, and no VRAM emulation is implemented.
    24.  
    25. I am granting permission to everyone to use this code in any way they see fit.
    26. It would be great to get credit for anything that is used, but I won't try to
    27. sue you if you don't, because at the end of the day it's only a video game!
    28.  
    29. If you plan to use my source code for anything at all, even if it's just a
    30. portion of it, I'd love to hear about it. Send me an e-mail about it. My
    31.  
    32. Enjoy!
    33.  
    34.  
    35. —Saxman
     
  4. Vinchenz

    Vinchenz

    Yo! Hustle! Hustle! Member
    Are we allowed to modify the repository if we think that our contributions are for the better? I would love to contribute this the second I can code again on this laptop.

    For starters, even though it would be basic, I wouldn't mind unifying the variable/function names to a set standard (like the way Taxman mentioned) myself. :>
     
  5. Conan Kudo

    Conan Kudo

    「真実はいつも一つ!」工藤新一 Member
    478
    1
    18
    <!--quoteo(post=494874:date=Aug 23 2010, 03:20 AM:name=saxman)--><div class='quotetop'>QUOTE (saxman @ Aug 23 2010, 03:20 AM) <a href="index.php?act=findpost&pid=494874">[​IMG]</a></div><div class='quotemain'><!--quotec-->Let me attempt to put to rest any misconceptions about the so-called licensing of ProSonic:

    Nothing about ProSonic is GPL bound. The only license attached to it is the license I wrote. You can do anything you want with my code. If you want to borrow some code and insert it into a program you will later be selling for $100 a pop, that's fine. Nobody has to see the code, and nobody is restricted as far as what they can do with the code. The only restrictions are the portions I don't personally own -- the Obj01 code for example.

    Here is the license as read in README.TXT:

    Code (Text):
    1. PROSONIC PUBLIC SOURCE CODE RELEASE
    2. AUGUST 17, 2010
    3.  
    4.  
    5. Here it is, the entire source code to the ProSonic engine. This by no means is
    6. an indication that I have stopped work on this engine forever. However, I also
    7. have other interests that need my attention, so I decided to go public with my
    8. source code to this project.
    9.  
    10. You will need the Allegro, Zlib, and HawkNL libraries to compile this code.
    11. The DOS version is the exception, where all HawkNL references are ignored.
    12.  
    13. My goal with this project was always to make the perfect game engine for Sonic
    14. games that everyone would want to use to make their very own Sonic game. I am
    15. hoping with the release of this code, someone will come along and make this
    16. the engine I always envisioned it becoming. I have laid what I feel is a good
    17. foundation for beginning something big in terms of a quality Sonic fan game.
    18.  
    19. There are things that could be improved. The object manager could be tweaked
    20. to be more flexible with moving objects. The PROCODE scripting support could
    21. be improved to allow more complex routines and arithmetic. The 68000 code
    22. support is only good enough to allow a certain number of objects to run in
    23. ProSonic, and no VRAM emulation is implemented.
    24.  
    25. I am granting permission to everyone to use this code in any way they see fit.
    26. It would be great to get credit for anything that is used, but I won't try to
    27. sue you if you don't, because at the end of the day it's only a video game!
    28.  
    29. If you plan to use my source code for anything at all, even if it's just a
    30. portion of it, I'd love to hear about it. Send me an e-mail about it. My
    31.  
    32. Enjoy!
    33.  
    34.  
    35. —Saxman
    <!--QuoteEnd--></div><!--QuoteEEnd-->

    Yes, your codebase you released IS under that license. But that license explicitly allows for relicensing to whatever anybody wants. I chose to license it GPLv2 with exceptions in my codebase. If anyone has a problem with that, and he/she can convince me that the LGPL, MIT, or BSD license would be a better choice, then I'll change it.

    But my rationale for licensing it GPLv2 with exceptions is that the core codebase should remain open source, and that everybody should benefit from anyone's hard work at improving the core engine. The parts that actually would make up the actual fangame (ProCode scripts, m68k assembler, sprites, other art, music, etc.) can be any license you want. Additionally, Public Domain code can be legally problematic in some regions of the world, hence the explicit license. Finally, Google only lets you choose among the GPL, LGPL, MIT, and 3-clause BSD ("New" BSD) licenses.

    So, in short: The zipped release you made is under the license you made. However, your license stated that anyone could take that code and relicense as they see fit, so I modified the codebase, reorganized it, and uploaded it with the licensing terms I chose.

    If they don't like the license, and believe that LGPL, BSD, or MIT would be better, they can talk to me and convince me otherwise. Or they can create their own fork with a different license.

    <!--quoteo(post=494878:date=Aug 23 2010, 03:52 AM:name=Vinchenz)--><div class='quotetop'>QUOTE (Vinchenz @ Aug 23 2010, 03:52 AM) <a href="index.php?act=findpost&pid=494878">[​IMG]</a></div><div class='quotemain'><!--quotec-->Are we allowed to modify the repository if we think that our contributions are for the better? I would love to contribute this the second I can code again on this laptop.

    For starters, even though it would be basic, I wouldn't mind unifying the variable/function names to a set standard (like the way Taxman mentioned) myself. :><!--QuoteEnd--></div><!--QuoteEEnd-->

    Of course. The easiest way to contribute is to <a href="http://code.google.com/p/prosonic/source/clones" target="_blank">create a server side clone</a>, download that clone, and modify it as you wish. You can then publish your changes to your clone and request them to be merged. If they are really good changes, you'll probably be added to the committers' team if you request it, so that you can commit directly to the master repository.
     
  6. Ritz

    Ritz

    Subhedgehog Member
    4,062
    86
    28
    So, uh, what happens if you violate one of these so-called licenses, anyway? Jack shit, right?
     
  7. Techokami

    Techokami

    For use only on NTSC Genesis systems Researcher
    1,362
    63
    28
    HoleNet!
    Sonic Worlds Next
    <!--quoteo(post=495162:date=Aug 23 2010, 04:24 PM:name=Ritz)--><div class='quotetop'>QUOTE (Ritz @ Aug 23 2010, 04:24 PM) <a href="index.php?act=findpost&pid=495162">[​IMG]</a></div><div class='quotemain'><!--quotec-->So, uh, what happens if you violate one of these so-called licenses, anyway? Jack shit, right?<!--QuoteEnd--></div><!--QuoteEEnd-->
    <a href="http://www.theregister.co.uk/2010/08/04/gpl_violation_westinghouse/" target="_blank">You get sued. Hard.</a>
     
  8. HighFrictionZone

    HighFrictionZone

    Hi. Member
    855
    0
    16
    Katy, Texas
    Nothing
    So, like, I guess I just fail hard at getting it to compile. Running cmake from a regular command prompt window prompts that it can't find allegro. If I use a Visual Studio command prompt window, it finds it just fine!

    When I generate a visual studio 10 solution file and attempt to build that, I meet with...
    Code (Text):
    1. 1>------ Build started: Project: ZERO_CHECK, Configuration: Debug Win32 ------
    2. 2>------ Build started: Project: ProSonic, Configuration: Debug Win32 ------
    3. 2>&nbsp;&nbsp;Generating DrawScreen_resource.obj
    4. 2>&nbsp;&nbsp;'windres' is not recognized as an internal or external command,
    5. 2>&nbsp;&nbsp;operable program or batch file.
    6. 2>&nbsp;&nbsp;The system cannot find the batch label specified - VCReportError
    7. 2>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets(151,5): error MSB6006: "cmd.exe" exited with code 1.
    8. 3>------ Build started: Project: ALL_BUILD, Configuration: Debug Win32 ------
    9. 4>------ Skipped Build: Project: INSTALL, Configuration: Debug Win32 ------
    10. 4>Project not selected to build for this solution configuration
    11. ========== Build: 2 succeeded, 1 failed, 0 up-to-date, 1 skipped ==========
    Attempting to instead have it generate (in a different output directory, for gods sake I'm not retarded) a Code::Blocks project file results in the following error on attempt to compile:
    Code (Text):
    1. ||=== ProSonic, all ===|
    2. C:\PROGRA~2\MICROS~1.0\VC\include\vadefs.h|48|error: syntax error before "unsigned"|
    3. C:\PROGRA~2\MICROS~1.0\VC\include\crtdefs.h|402|error: syntax error before "unsigned"|
    4. C:\PROGRA~2\MICROS~1.0\VC\include\crtdefs.h|409|error: syntax error before "rsize_t"|
    5. C:\PROGRA~2\MICROS~1.0\VC\include\crtdefs.h|418|error: syntax error before "int"|
    6. C:\PROGRA~2\MICROS~1.0\VC\include\crtdefs.h|436|error: syntax error before "int"|
    7. C:\PROGRA~2\MICROS~1.0\VC\include\crtdefs.h|473|error: syntax error before "long"|
    8. C:\PROGRA~2\MICROS~1.0\VC\include\crtdefs.h|478|error: syntax error before "__time64_t"|
    9. C:\PROGRA~2\MICROS~1.0\VC\include\crtdefs.h|486|error: syntax error before "time_t"|
    10. C:\PROGRA~2\MICROS~1.0\VC\include\crtdefs.h|550|error: syntax error before "uintptr_t"|
    11. C:\PROGRA~2\MICROS~1.0\VC\include\stdio.h|234|error: wrong number of arguments specified for `deprecated' attribute|
    12. ...
    13. Truncated because loooooooooooong
    14. ...
    15. C:\PROGRA~2\MICROS~1.0\VC\include\stdio.h|366|error: syntax error before "size_t"|
    16. C:\PROGRA~2\MICROS~1.0\VC\include\stdio.h|371|error: wrong number of arguments specified for `deprecated' attribute|
    17. C:\PROGRA~2\MICROS~1.0\VC\include\stdio.h|371|error: wrong number of arguments specified for `deprecated' attribute|
    18. ||More errors follow but not being shown.|
    19. ||Edit the max errors limit in compiler options...|
    20. ||=== Build finished: 50 errors, 0 warnings ===|

    Obviously, I'd prefer if the Visual Studio project could be fixed because hot damn that's far fewer errors. I attempted to diagnose why it couldn't find windres (hint, the program exists, and it is in my path - opening up a regular command prompt window and typing "windres -help" produces the appropriate help file. As a matter of fact, "windres" is located in C:\MinGW\bin (exactly where I installed it), and none of the project's files are located anyplace with a space in the path. I am confused.
     
  9. Conan Kudo

    Conan Kudo

    「真実はいつも一つ!」工藤新一 Member
    478
    1
    18
    <!--quoteo(post=495767:date=Aug 24 2010, 10:01 PM:name=HighFrictionZone)--><div class='quotetop'>QUOTE (HighFrictionZone @ Aug 24 2010, 10:01 PM) <a href="index.php?act=findpost&pid=495767">[​IMG]</a></div><div class='quotemain'><!--quotec-->So, like, I guess I just fail hard at getting it to compile. Running cmake from a regular command prompt window prompts that it can't find allegro. If I use a Visual Studio command prompt window, it finds it just fine!

    When I generate a visual studio 10 solution file and attempt to build that, I meet with...
    Code (Text):
    1. 1>------ Build started: Project: ZERO_CHECK, Configuration: Debug Win32 ------
    2. 2>------ Build started: Project: ProSonic, Configuration: Debug Win32 ------
    3. 2>&nbsp;&nbsp;Generating DrawScreen_resource.obj
    4. 2>&nbsp;&nbsp;'windres' is not recognized as an internal or external command,
    5. 2>&nbsp;&nbsp;operable program or batch file.
    6. 2>&nbsp;&nbsp;The system cannot find the batch label specified - VCReportError
    7. 2>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets(151,5): error MSB6006: "cmd.exe" exited with code 1.
    8. 3>------ Build started: Project: ALL_BUILD, Configuration: Debug Win32 ------
    9. 4>------ Skipped Build: Project: INSTALL, Configuration: Debug Win32 ------
    10. 4>Project not selected to build for this solution configuration
    11. ========== Build: 2 succeeded, 1 failed, 0 up-to-date, 1 skipped ==========
    Attempting to instead have it generate (in a different output directory, for gods sake I'm not retarded) a Code::Blocks project file results in the following error on attempt to compile:
    Code (Text):
    1. ||=== ProSonic, all ===|
    2. C:\PROGRA~2\MICROS~1.0\VC\include\vadefs.h|48|error: syntax error before "unsigned"|
    3. C:\PROGRA~2\MICROS~1.0\VC\include\crtdefs.h|402|error: syntax error before "unsigned"|
    4. C:\PROGRA~2\MICROS~1.0\VC\include\crtdefs.h|409|error: syntax error before "rsize_t"|
    5. C:\PROGRA~2\MICROS~1.0\VC\include\crtdefs.h|418|error: syntax error before "int"|
    6. C:\PROGRA~2\MICROS~1.0\VC\include\crtdefs.h|436|error: syntax error before "int"|
    7. C:\PROGRA~2\MICROS~1.0\VC\include\crtdefs.h|473|error: syntax error before "long"|
    8. C:\PROGRA~2\MICROS~1.0\VC\include\crtdefs.h|478|error: syntax error before "__time64_t"|
    9. C:\PROGRA~2\MICROS~1.0\VC\include\crtdefs.h|486|error: syntax error before "time_t"|
    10. C:\PROGRA~2\MICROS~1.0\VC\include\crtdefs.h|550|error: syntax error before "uintptr_t"|
    11. C:\PROGRA~2\MICROS~1.0\VC\include\stdio.h|234|error: wrong number of arguments specified for `deprecated' attribute|
    12. ...
    13. Truncated because loooooooooooong
    14. ...
    15. C:\PROGRA~2\MICROS~1.0\VC\include\stdio.h|366|error: syntax error before "size_t"|
    16. C:\PROGRA~2\MICROS~1.0\VC\include\stdio.h|371|error: wrong number of arguments specified for `deprecated' attribute|
    17. C:\PROGRA~2\MICROS~1.0\VC\include\stdio.h|371|error: wrong number of arguments specified for `deprecated' attribute|
    18. ||More errors follow but not being shown.|
    19. ||Edit the max errors limit in compiler options...|
    20. ||=== Build finished: 50 errors, 0 warnings ===|

    Obviously, I'd prefer if the Visual Studio project could be fixed because hot damn that's far fewer errors. I attempted to diagnose why it couldn't find windres (hint, the program exists, and it is in my path - opening up a regular command prompt window and typing "windres -help" produces the appropriate help file. As a matter of fact, "windres" is located in C:\MinGW\bin (exactly where I installed it), and none of the project's files are located anyplace with a space in the path. I am confused.<!--QuoteEnd--></div><!--QuoteEEnd-->

    At the moment, Visual Studio isn't supported (mainly because I don't have an MSVC install), but I think your messages have made me figure out what is wrong. Even if it could find windres, MSVC cannot accept the compile output of MinGW's windres. I think I've managed to work a fix for it into the latest revision of the scripts. Pull from the repository and try again, please.
     
  10. HighFrictionZone

    HighFrictionZone

    Hi. Member
    855
    0
    16
    Katy, Texas
    Nothing
    Just pulled from repository and attempted again. This one produces a lot more of a different set of errors.
    Code (Text):
    1. >------ Build started: Project: ProSonic, Configuration: Debug Win32 ------
    2. 2>&nbsp;&nbsp;Building Custom Rule C:/Users/Philbert/Desktop/ProSonic/OLD/Engine/prosonic/Source/Engine/CMakeLists.txt
    3. 2>&nbsp;&nbsp;CMake does not need to re-run because C:\Users\Philbert\Desktop\ProSonic\OLD\Engine\prosonic\output\Source\Engine\CMakeFiles\generate.stamp is up-to-date.
    4. 2>cl : Command line warning D9025: overriding '/W1' with '/w'
    5. 2>cl : Command line warning D9002: ignoring unknown option '-funroll-loops'
    6. 2>cl : Command line warning D9002: ignoring unknown option '-funswitch-loops'
    7. 2>cl : Command line warning D9002: ignoring unknown option '-fexpensive-optimizations'
    8. 2>cl : Command line warning D9002: ignoring unknown option '-march=i586'
    9. 2>cl : Command line warning D9002: ignoring unknown option '-mmmx'
    10. 2>cl : Command line warning D9002: ignoring unknown option '-msse'
    11. 2>&nbsp;&nbsp;demo.c
    12. 2>c:\users\philbert\desktop\prosonic\old\engine\prosonic\source\engine\common.h(98): error C2054: expected '(' to follow 'inline'
    13. 2>c:\users\philbert\desktop\prosonic\old\engine\prosonic\source\engine\common.h(98): error C2085: 'ProcessSound' : not in formal parameter list
    14. 2>c:\users\philbert\desktop\prosonic\old\engine\prosonic\source\engine\common.h(99): error C2085: 'ResetSound' : not in formal parameter list
    15. 2>c:\users\philbert\desktop\prosonic\old\engine\prosonic\source\engine\common.h(100): error C2085: 'PlayPCM' : not in formal parameter list
    16. 2>c:\users\philbert\desktop\prosonic\old\engine\prosonic\source\engine\common.h(101): error C2085: 'PlayFM' : not in formal parameter list
    17. 2>c:\users\philbert\desktop\prosonic\old\engine\prosonic\source\engine\common.h(103): error C2085: 'StreamPCM' : not in formal parameter list
    Etc, on down the line of "not in formal parameter list" type errors. Honestly, though, chances are pretty good that I probably fucked something up. I am not, how you might say, an expert on these things. I'm just about to head to bed, so I wouldn't be able to respond back until tomorrow. Hopefully, sleeping on it will make me realize some simple and obvious mistake I made, like forgetting to set a config or something.

    EDIT: Also, most of my problems probably stem from mixing and matching libraries or something. I imagine that if I get allegro to work with mingw directly, I'll probably end up ditching MSVC 2010 and going straight with regular-old-makefiles and a good text editor. Still though, Visual Studio support would be nice to get other people in on the coding, I guess.
     
  11. Conan Kudo

    Conan Kudo

    「真実はいつも一つ!」工藤新一 Member
    478
    1
    18
    <!--quoteo(post=495823:date=Aug 24 2010, 11:59 PM:name=HighFrictionZone)--><div class='quotetop'>QUOTE (HighFrictionZone @ Aug 24 2010, 11:59 PM) <a href="index.php?act=findpost&pid=495823">[​IMG]</a></div><div class='quotemain'><!--quotec-->Just pulled from repository and attempted again. This one produces a lot more of a different set of errors.
    Code (Text):
    1. >------ Build started: Project: ProSonic, Configuration: Debug Win32 ------
    2. 2>&nbsp;&nbsp;Building Custom Rule C:/Users/Philbert/Desktop/ProSonic/OLD/Engine/prosonic/Source/Engine/CMakeLists.txt
    3. 2>&nbsp;&nbsp;CMake does not need to re-run because C:\Users\Philbert\Desktop\ProSonic\OLD\Engine\prosonic\output\Source\Engine\CMakeFiles\generate.stamp is up-to-date.
    4. 2>cl : Command line warning D9025: overriding '/W1' with '/w'
    5. 2>cl : Command line warning D9002: ignoring unknown option '-funroll-loops'
    6. 2>cl : Command line warning D9002: ignoring unknown option '-funswitch-loops'
    7. 2>cl : Command line warning D9002: ignoring unknown option '-fexpensive-optimizations'
    8. 2>cl : Command line warning D9002: ignoring unknown option '-march=i586'
    9. 2>cl : Command line warning D9002: ignoring unknown option '-mmmx'
    10. 2>cl : Command line warning D9002: ignoring unknown option '-msse'
    11. 2>&nbsp;&nbsp;demo.c
    12. 2>c:\users\philbert\desktop\prosonic\old\engine\prosonic\source\engine\common.h(98): error C2054: expected '(' to follow 'inline'
    13. 2>c:\users\philbert\desktop\prosonic\old\engine\prosonic\source\engine\common.h(98): error C2085: 'ProcessSound' : not in formal parameter list
    14. 2>c:\users\philbert\desktop\prosonic\old\engine\prosonic\source\engine\common.h(99): error C2085: 'ResetSound' : not in formal parameter list
    15. 2>c:\users\philbert\desktop\prosonic\old\engine\prosonic\source\engine\common.h(100): error C2085: 'PlayPCM' : not in formal parameter list
    16. 2>c:\users\philbert\desktop\prosonic\old\engine\prosonic\source\engine\common.h(101): error C2085: 'PlayFM' : not in formal parameter list
    17. 2>c:\users\philbert\desktop\prosonic\old\engine\prosonic\source\engine\common.h(103): error C2085: 'StreamPCM' : not in formal parameter list
    Etc, on down the line of "not in formal parameter list" type errors. Honestly, though, chances are pretty good that I probably fucked something up. I am not, how you might say, an expert on these things. I'm just about to head to bed, so I wouldn't be able to respond back until tomorrow. Hopefully, sleeping on it will make me realize some simple and obvious mistake I made, like forgetting to set a config or something.

    EDIT: Also, most of my problems probably stem from mixing and matching libraries or something. I imagine that if I get allegro to work with mingw directly, I'll probably end up ditching MSVC 2010 and going straight with regular-old-makefiles and a good text editor. Still though, Visual Studio support would be nice to get other people in on the coding, I guess.<!--QuoteEnd--></div><!--QuoteEEnd-->

    I've added equivalent options for MSVC (when available) for compilation, so no more unknown option warnings, hopefully. The formal parameter list errors.... Hmm...

    I see a parameter list for the functions.... I'm confused....

    In any case, it should work fine if you use MinGW. I've made some more fixes and updated the repository's CMake scripts.
     
  12. Revival

    Revival

    The AppleTalk Network System Member
    200
    0
    16
    <!--quoteo(post=495926:date=Aug 25 2010, 08:54 AM:name=Conan Kudo)--><div class='quotetop'>QUOTE (Conan Kudo @ Aug 25 2010, 08:54 AM) <a href="index.php?act=findpost&pid=495926">[​IMG]</a></div><div class='quotemain'><!--quotec--><!--quoteo(post=495823:date=Aug 24 2010, 11:59 PM:name=HighFrictionZone)--><div class='quotetop'>QUOTE (HighFrictionZone @ Aug 24 2010, 11:59 PM) <a href="index.php?act=findpost&pid=495823">[​IMG]</a></div><div class='quotemain'><!--quotec-->Just pulled from repository and attempted again. This one produces a lot more of a different set of errors.
    Code (Text):
    1. >------ Build started: Project: ProSonic, Configuration: Debug Win32 ------
    2. 2>&nbsp;&nbsp;Building Custom Rule C:/Users/Philbert/Desktop/ProSonic/OLD/Engine/prosonic/Source/Engine/CMakeLists.txt
    3. 2>&nbsp;&nbsp;CMake does not need to re-run because C:\Users\Philbert\Desktop\ProSonic\OLD\Engine\prosonic\output\Source\Engine\CMakeFiles\generate.stamp is up-to-date.
    4. 2>cl : Command line warning D9025: overriding '/W1' with '/w'
    5. 2>cl : Command line warning D9002: ignoring unknown option '-funroll-loops'
    6. 2>cl : Command line warning D9002: ignoring unknown option '-funswitch-loops'
    7. 2>cl : Command line warning D9002: ignoring unknown option '-fexpensive-optimizations'
    8. 2>cl : Command line warning D9002: ignoring unknown option '-march=i586'
    9. 2>cl : Command line warning D9002: ignoring unknown option '-mmmx'
    10. 2>cl : Command line warning D9002: ignoring unknown option '-msse'
    11. 2>&nbsp;&nbsp;demo.c
    12. 2>c:\users\philbert\desktop\prosonic\old\engine\prosonic\source\engine\common.h(98): error C2054: expected '(' to follow 'inline'
    13. 2>c:\users\philbert\desktop\prosonic\old\engine\prosonic\source\engine\common.h(98): error C2085: 'ProcessSound' : not in formal parameter list
    14. 2>c:\users\philbert\desktop\prosonic\old\engine\prosonic\source\engine\common.h(99): error C2085: 'ResetSound' : not in formal parameter list
    15. 2>c:\users\philbert\desktop\prosonic\old\engine\prosonic\source\engine\common.h(100): error C2085: 'PlayPCM' : not in formal parameter list
    16. 2>c:\users\philbert\desktop\prosonic\old\engine\prosonic\source\engine\common.h(101): error C2085: 'PlayFM' : not in formal parameter list
    17. 2>c:\users\philbert\desktop\prosonic\old\engine\prosonic\source\engine\common.h(103): error C2085: 'StreamPCM' : not in formal parameter list
    Etc, on down the line of "not in formal parameter list" type errors. Honestly, though, chances are pretty good that I probably fucked something up. I am not, how you might say, an expert on these things. I'm just about to head to bed, so I wouldn't be able to respond back until tomorrow. Hopefully, sleeping on it will make me realize some simple and obvious mistake I made, like forgetting to set a config or something.

    EDIT: Also, most of my problems probably stem from mixing and matching libraries or something. I imagine that if I get allegro to work with mingw directly, I'll probably end up ditching MSVC 2010 and going straight with regular-old-makefiles and a good text editor. Still though, Visual Studio support would be nice to get other people in on the coding, I guess.<!--QuoteEnd--></div><!--QuoteEEnd-->

    I've added equivalent options for MSVC (when available) for compilation, so no more unknown option warnings, hopefully. The formal parameter list errors.... Hmm...

    I see a parameter list for the functions.... I'm confused....

    In any case, it should work fine if you use MinGW. I've made some more fixes and updated the repository's CMake scripts.
    <!--QuoteEnd--></div><!--QuoteEEnd-->

    Compiler specific features are used by the source code. I might have a go at adding the relevant #ifdefs to get it working with MSVC.
     
  13. Conan Kudo

    Conan Kudo

    「真実はいつも一つ!」工藤新一 Member
    478
    1
    18
    <!--quoteo(post=495975:date=Aug 25 2010, 11:32 AM:name=Revival)--><div class='quotetop'>QUOTE (Revival @ Aug 25 2010, 11:32 AM) <a href="index.php?act=findpost&pid=495975">[​IMG]</a></div><div class='quotemain'><!--quotec-->Compiler specific features are used by the source code. I might have a go at adding the relevant #ifdefs to get it working with MSVC.<!--QuoteEnd--></div><!--QuoteEEnd-->

    That would be great! I have near no experience with modern MSVC (the last version I used was VC2003, the last I used frequently was VC6). Just make your commits available in a server side repository and I'll pull them into the master repository.
     
  14. HighFrictionZone

    HighFrictionZone

    Hi. Member
    855
    0
    16
    Katy, Texas
    Nothing
    Unknown option warnings are gone, yes. Still scratching my head over the parameter list thing.

    In an attempt to move on and avoid an reference to Visual Studio (including the copy of allegro which I probably did a shoddy job of "integrating" into it), I scrubbed my system of anything relating to mingw and allegro and any of that sort of thing, and then I started from the top.
    MinGW, installed.
    Zlib, installed.
    libpng, installed.
    libogg/libvorbis compiled from source and installed.
    allegro 4.4... source code downloaded, cmake generates a mingw makefile, mingw duitifilly compiles it (now that I've installed the required components), and "mingw32-make install" installs it... I think.

    Attempting to have cmake generate a mingw makefile for prosonic, however, results in
    Code (Text):
    1. ...snip...
    2. CMake Error at CMakeModules/FindAllegro.cmake:61 (message):
    3. &nbsp;&nbsp;Could not find Allegro
    4. Call Stack (most recent call first):
    5. &nbsp;&nbsp;CMakeLists.txt:56 (FIND_PACKAGE)
    6.  
    7.  
    8. -- Configuring incomplete, errors occurred!
    9.  
    10. C:\Prosonic\source\mingw>
    Yes, this is from a clean copy of the source, freshly pulled from the repository.

    Searching online, I found this an... alternative method of locating allegro libraries and attempted to use it as my "FindAllegro.cmake" file.
    It resulted in... success? At any rate, a makefile is generated.

    Of course, it still doesn't compile for me. It's possible that it still isn't finding allegro correctly and is now merely suppressing the error or ignoring it. At any rate, attempting to compile produces like 280 errors, along the lines of "undefined reference to '_allegro_message'" or "undefined reference to '_system_driver'" - leading me to believe that though a makefile was generated, allegro was not found. Is there some way I could have it ignore allegro while generating the makefile, and then manually specify the correct locations after-the-fact? Is being unable to find allegro even the problem?

    I don't know, but I have to go to work. Clearly, working on this in my freetime isn't very efficient.
     
  15. Conan Kudo

    Conan Kudo

    「真実はいつも一つ!」工藤新一 Member
    478
    1
    18
    <!--quoteo(post=496056:date=Aug 25 2010, 02:58 PM:name=HighFrictionZone)--><div class='quotetop'>QUOTE (HighFrictionZone @ Aug 25 2010, 02:58 PM) <a href="index.php?act=findpost&pid=496056">[​IMG]</a></div><div class='quotemain'><!--quotec-->Unknown option warnings are gone, yes. Still scratching my head over the parameter list thing.

    In an attempt to move on and avoid an reference to Visual Studio (including the copy of allegro which I probably did a shoddy job of "integrating" into it), I scrubbed my system of anything relating to mingw and allegro and any of that sort of thing, and then I started from the top.
    MinGW, installed.
    Zlib, installed.
    libpng, installed.
    libogg/libvorbis compiled from source and installed.
    allegro 4.4... source code downloaded, cmake generates a mingw makefile, mingw duitifilly compiles it (now that I've installed the required components), and "mingw32-make install" installs it... I think.

    Attempting to have cmake generate a mingw makefile for prosonic, however, results in
    Code (Text):
    1. ...snip...
    2. CMake Error at CMakeModules/FindAllegro.cmake:61 (message):
    3. &nbsp;&nbsp;Could not find Allegro
    4. Call Stack (most recent call first):
    5. &nbsp;&nbsp;CMakeLists.txt:56 (FIND_PACKAGE)
    6.  
    7.  
    8. -- Configuring incomplete, errors occurred!
    9.  
    10. C:\Prosonic\source\mingw>
    Yes, this is from a clean copy of the source, freshly pulled from the repository.

    Searching online, I found this an... alternative method of locating allegro libraries and attempted to use it as my "FindAllegro.cmake" file.
    It resulted in... success? At any rate, a makefile is generated.

    Of course, it still doesn't compile for me. It's possible that it still isn't finding allegro correctly and is now merely suppressing the error or ignoring it. At any rate, attempting to compile produces like 280 errors, along the lines of "undefined reference to '_allegro_message'" or "undefined reference to '_system_driver'" - leading me to believe that though a makefile was generated, allegro was not found. Is there some way I could have it ignore allegro while generating the makefile, and then manually specify the correct locations after-the-fact? Is being unable to find allegro even the problem?

    I don't know, but I have to go to work. Clearly, working on this in my freetime isn't very efficient.<!--QuoteEnd--></div><!--QuoteEEnd-->
    If it can't find allegro, you can just point it to the alleg_s.lib file directly if you use ccmake or cmake-gui.

    For using the cmake command, just append the following to it: -DALLEG_LIBRARY=<path-to-liballeg_s> -DALLEGRO_INCLUDE_DIR=<path-to-directory-containing-allegro-header-files>

    It's a bit more difficult to efficiently make it detect anything on Windows. If you have any suggestions on improving that, great!

    Also, after you've taken care of allegro, it'll probably complain about zlib, and then HawkNL.

    For zlib, append the following: -DZLIB_LIBRARY=<path-to-zlib> -DZLIB_INCLUDE_DIR=<path-to-folder-containing-zlib.h>

    For HawkNL, append the following: -DHAWKNL_LIBRARY=<path-to-hawknl-lib> -DHAWKNL_INCLUDE_DIR=<path-to-folder-containing-hawknl-headers>
     
  16. HighFrictionZone

    HighFrictionZone

    Hi. Member
    855
    0
    16
    Katy, Texas
    Nothing
    <!--quoteo(post=496414:date=Aug 26 2010, 07:04 AM:name=Conan Kudo)--><div class='quotetop'>QUOTE (Conan Kudo @ Aug 26 2010, 07:04 AM) <a href="index.php?act=findpost&pid=496414">[​IMG]</a></div><div class='quotemain'><!--quotec-->If it can't find allegro, you can just point it to the alleg_s.lib file directly if you use ccmake or cmake-gui.

    For using the cmake command, just append the following to it: -DALLEG_LIBRARY=<path-to-liballeg_s> -DALLEGRO_INCLUDE_DIR=<path-to-directory-containing-allegro-header-files>

    It's a bit more difficult to efficiently make it detect anything on Windows. If you have any suggestions on improving that, great!

    Also, after you've taken care of allegro, it'll probably complain about zlib, and then HawkNL.

    For zlib, append the following: -DZLIB_LIBRARY=<path-to-zlib> -DZLIB_INCLUDE_DIR=<path-to-folder-containing-zlib.h>

    For HawkNL, append the following: -DHAWKNL_LIBRARY=<path-to-hawknl-lib> -DHAWKNL_INCLUDE_DIR=<path-to-folder-containing-hawknl-headers><!--QuoteEnd--></div><!--QuoteEEnd-->

    Ah. That explains, well, everything, but not in the manner you might have expected. Upon searching through all my allegro related folders, I could find no instance of the "alleg_s.lib" - not in the version I compiled and not in pre-compiled version I grabbed. So I grabbed a different copy and still couldn't find such a file. But I manually copied over the newly downloaded copy and ran cmake anyway and lo and behold, it "Found Allegro: C:/MinGW/lib/liballeg.a"


    And yet.... it still does not yet compile! But the number of errors is greatly reduced and I think we are on the verge of figuring out why.

    Code (Text):
    1. ||=== ProSonic, all ===|
    2. ||Info: resolving _system_driver by linking to __imp__system_driver |
    3. ||Info: resolving _screen by linking to __imp__screen |
    4. ||Info: resolving _key by linking to __imp__key |
    5. ||Info: resolving _key_shifts by linking to __imp__key_shifts |
    6. ||Info: resolving _mouse_x by linking to __imp__mouse_x |
    7. ||Info: resolving _mouse_y by linking to __imp__mouse_y |
    8. ||Info: resolving _mouse_z by linking to __imp__mouse_z |
    9. ||Info: resolving __current_palette by linking to __imp___current_palette |
    10. ||Info: resolving _mouse_pos by linking to __imp__mouse_pos |
    11. ||warning: auto-importing has been activated without —enable-auto-import specified on the command line.|
    12. This should work unless it involves constant data structures referencing symbols from auto-imported DLLs.fu000001.o(.idata$2+0xc)||undefined reference to `_lib_mingw32_liballeg_a_iname'|
    13. fu000002.o(.idata$2+0xc)||undefined reference to `_lib_mingw32_liballeg_a_iname'|
    14. fu000003.o(.idata$2+0xc)||undefined reference to `_lib_mingw32_liballeg_a_iname'|
    15. fu000004.o(.idata$2+0xc)||undefined reference to `_lib_mingw32_liballeg_a_iname'|
    16. fu000005.o(.idata$2+0xc)||undefined reference to `_lib_mingw32_liballeg_a_iname'|
    17. nmth000000.o(.idata$4+0x0)||undefined reference to `__nm__system_driver'|
    18. nmth000008.o(.idata$4+0x0)||undefined reference to `__nm__screen'|
    19. nmth000021.o(.idata$4+0x0)||undefined reference to `__nm__key'|
    20. nmth000222.o(.idata$4+0x0)||undefined reference to `__nm__key_shifts'|
    21. nmth000224.o(.idata$4+0x0)||undefined reference to `__nm__mouse_x'|
    22. nmth000226.o(.idata$4+0x0)||undefined reference to `__nm__mouse_y'|
    23. nmth000228.o(.idata$4+0x0)||undefined reference to `__nm__mouse_z'|
    24. nmth000236.o(.idata$4+0x0)||undefined reference to `__nm___current_palette'|
    25. nmth000238.o(.idata$4+0x0)||undefined reference to `__nm__mouse_pos'|
    26. ||=== Build finished: 14 errors, 1 warnings ===|
    Any other theories?
     
  17. Conan Kudo

    Conan Kudo

    「真実はいつも一つ!」工藤新一 Member
    478
    1
    18
    <!--quoteo(post=496566:date=Aug 26 2010, 02:46 PM:name=HighFrictionZone)--><div class='quotetop'>QUOTE (HighFrictionZone @ Aug 26 2010, 02:46 PM) <a href="index.php?act=findpost&pid=496566">[​IMG]</a></div><div class='quotemain'><!--quotec--><!--quoteo(post=496414:date=Aug 26 2010, 07:04 AM:name=Conan Kudo)--><div class='quotetop'>QUOTE (Conan Kudo @ Aug 26 2010, 07:04 AM) <a href="index.php?act=findpost&pid=496414">[​IMG]</a></div><div class='quotemain'><!--quotec-->If it can't find allegro, you can just point it to the alleg_s.lib file directly if you use ccmake or cmake-gui.

    For using the cmake command, just append the following to it: -DALLEG_LIBRARY=<path-to-liballeg_s> -DALLEGRO_INCLUDE_DIR=<path-to-directory-containing-allegro-header-files>

    It's a bit more difficult to efficiently make it detect anything on Windows. If you have any suggestions on improving that, great!

    Also, after you've taken care of allegro, it'll probably complain about zlib, and then HawkNL.

    For zlib, append the following: -DZLIB_LIBRARY=<path-to-zlib> -DZLIB_INCLUDE_DIR=<path-to-folder-containing-zlib.h>

    For HawkNL, append the following: -DHAWKNL_LIBRARY=<path-to-hawknl-lib> -DHAWKNL_INCLUDE_DIR=<path-to-folder-containing-hawknl-headers><!--QuoteEnd--></div><!--QuoteEEnd-->

    Ah. That explains, well, everything, but not in the manner you might have expected. Upon searching through all my allegro related folders, I could find no instance of the "alleg_s.lib" - not in the version I compiled and not in pre-compiled version I grabbed. So I grabbed a different copy and still couldn't find such a file. But I manually copied over the newly downloaded copy and ran cmake anyway and lo and behold, it "Found Allegro: C:/MinGW/lib/liballeg.a"


    And yet.... it still does not yet compile! But the number of errors is greatly reduced and I think we are on the verge of figuring out why.

    Any other theories?
    <!--QuoteEnd--></div><!--QuoteEEnd-->

    Well, first, I've still not made some logic for determining the difference between static link and dynamic link allegro on Windows. As of right now, only static link library will link properly, because of the definition ALLEGRO_STATICLINK in the CFLAGS and CXXFLAGS on Windows. On Unix, CMake will detect and configure allegro by itself in the proper way.

    On MinGW, you need to be linking to liballeg_s.a. For MSVC, the equivalent library is alleg_s.lib. If you are going to try liballeg.a, you probably need to remove the "-DALLEGRO_STATICLINK" definition using ccmake or cmake-gui manually from CMAKE_C_FLAGS and CMAKE_CXX_FLAGS.
     
  18. HighFrictionZone

    HighFrictionZone

    Hi. Member
    855
    0
    16
    Katy, Texas
    Nothing
    Thanks! That did it. For the record, I went ahead and used cmake-gui to force it to use the liballeg_s.a - primarily because I don't want to have to include the allegro dll files and potentially confuse the user.

    So now that I managed to set up a working build environment, first I'm going to make a backup copy of the entire directory system so that if I fuck up, I can recover from it. (I realize that this is part of what mercurial is supposed to do, track changes so we can revert to earlier versions. But that's no excuse not to have an off-site backup just in case.)

    Then, I can get right down to actually modifying things. I do recommend that this little troubleshooting be left for future reference. No doubt somebody else will have similar problems working with allegro in the future.
     
  19. saxman

    saxman

    Oldbie Tech Member
    w00t! Took them long enough to approve it, but the ProSonic engine is now on the Allegro Depot -- <a href="http://www.allegro.cc/depot/ProSonicEngine/" target="_blank">http://www.allegro.cc/depot/ProSonicEngine/</a>

    Nothing super fancy, but I wanted it to get out there with Open Sonic. I hope some people decide to do something spectacular with the engine source code.
     
  20. FeliciaVal

    FeliciaVal

    Member
    <!--quoteo(post=503108:date=Sep 8 2010, 10:48 PM:name=saxman)--><div class='quotetop'>QUOTE (saxman @ Sep 8 2010, 10:48 PM) <a href="index.php?act=findpost&pid=503108">[​IMG]</a></div><div class='quotemain'><!--quotec-->w00t! Took them long enough to approve it, but the ProSonic engine is now on the Allegro Depot -- <a href="http://www.allegro.cc/depot/ProSonicEngine/" target="_blank">http://www.allegro.cc/depot/ProSonicEngine/</a>

    Nothing super fancy, but I wanted it to get out there with Open Sonic. I hope some people decide to do something spectacular with the engine source code.<!--QuoteEnd--></div><!--QuoteEEnd-->
    that's REALLY good news for us Open Sonic users :) thx for that!
     
Thread Status:
Not open for further replies.