PROSONIC IS NOW OPEN SOURCE

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.

 

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.

 

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. :>

 

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.

Of course. The easiest way to contribute is to create a server side clone, 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.

 

So, uh, what happens if you violate one of these so-called licenses, anyway? Jack shit, right?

 

You get sued. Hard.

 

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>  Generating DrawScreen_resource.obj
4. 2>  'windres' is not recognized as an internal or external command,
5. 2>  operable program or batch file.
6. 2>  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.

 

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.

 

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>  Building Custom Rule C:/Users/Philbert/Desktop/ProSonic/OLD/Engine/prosonic/Source/Engine/CMakeLists.txt
3. 2>  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>  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.

 

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.

 

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.

 

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.

 

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.   Could not find Allegro
4. Call Stack (most recent call first):
5.   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.

 

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>

 

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?

 

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.

 

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.

 

that's REALLY good news for us Open Sonic users thx for that!