1
Programming / Re: Guide to compiling, using Libtcod/SDL/CodeBlocks/Mingw64/GCC4.8.1 on Win7/64bit
« on: February 12, 2014, 06:30:31 PM »
Aye, will indeed do so (just a matter of passing -m64 or -m32 to g++)
Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
2
Programming / Re: Guide to compiling, using Libtcod/SDL/CodeBlocks/Mingw64/GCC4.8.1 on Win7/64bit
« on: February 12, 2014, 03:39:25 PM »
Its also to use POSIX-threads (i.e. C++#1's std::thread) on Win7.
3
Programming / Guide to compiling, using Libtcod/SDL/CodeBlocks/Mingw64/GCC4.8.1 on Win7/64bit
« on: February 11, 2014, 08:35:28 PM »
Using Libtcod/SDL/Code::Blocks/Mingw64/GCC4.8.1 on Win7/64bit
So I decided to switch over to using a 64-bit version of my toolchain for my roguelike in development, as well as moving to C++11, and I encountered a lot of hassle in doing so. So I wrote up some instructions on how to do it. I will at some point put all this up on a webpage somewhere with relevant screenshots.
Let me know if I've missed anything or screwed anything up, or just let me know your thoughts.
1. First, download and install the 64-bit MinGW-builds version of MinGW at: http://sourceforge.net/projects/mingwbuilds/files/?source=navbar
You want the Web Installer labelled "Download mingw-builds-install.exe (170.0 kB)".
Install this in somewhere like "C:\MINGW64". Please don't use any spaces in the path, as CodeBlocks can't handle spaces very well in library filepaths.
When you are installing, please select the following options:
64-bit,
POSIX threads (to enable C++11 std::threads)
SJLJ debugging (not important AFAIK)
2. When this is done, add c:\MINGW64\bin to the system path (Computer/Properties/Advanced System Settings/Environment Variables). Note when you apply the change, you will have to restart any command prompts, programs etc as the PATH only is read at their startup.
3. Now set up and configure Codeblocks following the instructions given in:
http://stackoverflow.com/questions/16716454/setting-up-mingw-and-codeblocks-in-windows-8-64-bit
There are a few minor differences however, mainly seemingly in the layout of the latest Mingw (in the Search directiories settings). Here are my settings:
Global Compiler Settings/Toolchain Executibles/Program Files
Compiler's Installation Directory: C:\Mingw64
C Compiler: x86_64-w64-mingw32-gcc.exe (found in C:\Mingw64\bin)
C++ Compiler: x86_64-w64-mingw32-g++.exe (found in C:\Mingw64\bin)
Linker for Dynamic Libs: x86_64-w64-mingw32-g++.exe (found in C:\Mingw64\bin)
Linker for Static Libs: x86_64-w64-mingw32-gcc-ar.exe (found in C:\Mingw64\bin)
Resource Compiler: windres.exe (found in C:\Mingw64\bin)
Make Program: mingw32-make.exe (found in C:\Mingw64\bin)
Global Compiler Settings/Toolchain Executibles/Additional Paths
Add C:\Mingw64\libexec\gcc\x86_64-w64-mingw32\4.8.1 here
Global Compiler Settings/Search Directories/Compiler
Add the following:
C:\mingw64\include
C:\mingw64\x86_64-w64-mingw32\include
C:\Mingw64\lib\gcc\x86_64-w64-mingw32\4.8.1\include\c++
C:\Mingw64\lib\gcc\x86_64-w64-mingw32\4.8.1\include\c++\backward
C:\Mingw64\lib\gcc\x86_64-w64-mingw32\4.8.1\include\c++\x86_64-w64-mingw32
C:\Mingw64\lib\gcc\x86_64-w64-mingw32\4.8.1\include
Global Compiler Settings/Search Directories/Linker
Add the following:
C:\Mingw64\Lib
C:\Mingw64\x86_64-w64-mingw32\lib
Global Compiler Settings/Compiler Settings/Other options
Add "-m64"
Now save everything, making sure to "Auto-detect" first. Best to restart code blocks.
4. Now download a 64-bit version of SDL. This can be found at
http://sourceforge.net/projects/mingw-w64/files/External%20binary%20packages%20%28Win64%20hosted%29/SDL/
You want the file "SDL-1.2-20111107-win64.tar.gz"
Extract it to something like C:\SDL so the path is C:\SDL\SDL-1.2-20111107-win64 (for example).
Don't do anything else with this at the moment.
5. Now following the instructions at
http://doryen.eptalys.net/data/libtcod/doc/1.5.2/html2/compile_libtcod_mingw.html?c=true&cpp=true&cs=true&py=true&lua=true
down to, but not including, "Compiling libtcod" download the latest Libtcod code to somewhere like C:\libtcod. Don't compile anything yet, we have further changes to do.
5a. Note you may need to download and install MSYS (the version you want is MSYS-1.0.11.exe http://sourceforge.net/projects/mingw/files/?source=navbar) if you haven't it already to follow the instructions in step 5.
5b. And you may also need TortoiseHg (http://tortoisehg.bitbucket.org/) if you haven't got it already either. Note that if an error such as "An error occured during the insallation of assembly 'Microsoft.VC90.CRT, version="9.0.30729.1",publikKeyToken-"1fc8b3b9a1e18e3b", processorArchitecture="amd64", type="win32". Please refer to Help and Support for more information. HRESULT:0x80070BC9." occurs, you have outstanding updates/reboots, so you need to reboot your Windows first before installing Tortoise hg 2.4.1 (see https://bitbucket.org/tortoisehg/thg-winbuild/issue/26/error-when-attempting-to-install-ver-241 for more information).
Note that using the hg clone command will create a libtcod directory inside C:\Libtcod. I've kept the structure of C:\Libtcod\libtcod\ though you may want to squish it to make it neater.
6. Now, before compiling libtcod, we have to copy over compatible 64-bit SDL library and headers. To do this, first create a new directory in C:\Libtcod\libtcod\dependencies called SDL-1.2.20. We're going to duplicate the layout of the existing SDL-1.2.15 directory, only with the updated 64-bit files.
Make a nested subdirectory called include\SDL (for example C:\Libtcod\libtcod\dependencies\SDL-1.2.20\include\SDL) and copy all the header files (*.h) from the equivalent directory in the 64-bit SDL distribution (in my case C:\SDL\SDL-1.2-20111107-win64\include\SDL) into it.
Note that the SDL-1.2.15 directory that comes with Libtcod contains two additional .h files not in the .20 verson - SDL_config_win32.h and SDL_copying.h. No idea if these are needed, but I copied these over also.
Now make a lib\mingw\ nested subdirectory (for example C:\Libtcod\libtcod\dependencies\SDL-1.2.20\lib\mingw) and copy over libSDL.dll.a from the lib subdirectory of the 64-bit SDL (e.g. C:\SDL\SDL-1.2-20111107-win64\lib) into ...\SDL-1.2.20\lib\mingw.
Verifiy that the contents of the SDL-1.2.15 and SDL-1.2.20 directories now mirror each other. Remember that the .20 version will contain 64-bit versions of SDL.
6a. You will also have to replace the SDL.dll file in the root libtcod directory (e.g. C:\Libtcod\libtcod\SDL.dll) with the one from the 64-bit SDL distribution (found in \bin there, e.g. C:\SDL\SDL-1.2-20111107-win64\bin\SDL.dll).
7. Now go to back to the libtcod directory and go into the makefiles directory (in my case it is C:\Libtcod\libtcod\makefiles). Make copies of the makefile-mingw and makefile-samples-mingw files and name them makefile-mingw-64 and makefile-samples-mingw-64 respectively.
8. Editing makefile-mingw-64, you need to change the following lines:
#9: From "SDL_DIR=dependencies/SDL-1.2.15" to "SDLDIR=dependencies/SDL-1.2.20"
#22: From "CC=mingw32-gcc" to "CC=x86_64-w64-mingw32-gcc"
#23: From "CPP=mingw32-g++" to "CPP=x86_64-w64-mingw32-g++"
This is to ensure that the proper 64-bit version of mingw that we installed in Step 1. is used to compile.
9. Editing makefile-samples-mingw-64, you need to change the following lines:
#6: From "SDLDIR=dependencies/SDL-1.2.15"
#8: From "CC=mingw32-gcc" to "CC=x86_64-w64-mingw32-gcc"
#9: From "CPP=mingw32-g++" to "CPP=x86_64-w64-mingw32-g++"
10. Now you can compile libtcod, and the samples. To do this, replace the makefiles targeted in the make commands given in "Compiling libtcod" with the new 64-bit makefiles:
"make -f makefiles/makefile-mingw" becomes "make -f makefiles/makefile-mingw-64"
and
"make -f makefiles/makefile-samples-mingw" becomes "make -f makefiles/makefile-samples-mingw-64"
Note that the call to the UPX executable packer may fail at the end of the build process. Ignore this, its not that important (IMHO).
11. You can now run the 64-bit samples app to make sure it runs ok. Which it should.
12. For informational purposes, here are my relevant Code::Blocks "Build Options" for compiling a 64-bit libtcod project successfully in C++11. Please remember to highlight the top-level build option on the left-hand side of the "Project Build Options" to apply these to both Debug and Release and any other build types you have defined":
Compiler Settings/Compiler Flags:
Checked: "Have G++ follow the C++11 ISO C++ Language Standard [-std=c++11]"
Compiler Settings/Other Options:
-Wno-c++0x-compat
-isystem "C:/Libtcod/libtcod/include" (this is set to avoid generating warnings for Libtcod files when building)
Linker Settings/Link Libraries:
Add ..\..\..\Libtcod\libtcod\lib\libtcod-mingw.a (in my case this is C:\Libtcod\libtcod\lib\libtcod-mingw.a, i.e. it refers to the rebuilt libtcod library)
Search Directories/Compiler:
..\..\..\Libtcod\libtcod\include (in my case this is C:\Libtcod\libtcod\include)
Pre/post build steps/Post-build steps:
cmd /c copy "C:\Libtcod\libtcod\lib\libtcod-mingw.a" $(TARGET_OUTPUT_DIR)
cmd /c copy "C:\Libtcod\libtcod\libtcod-mingw.dll" $(TARGET_OUTPUT_DIR)
cmd /c copy "C:\Libtcod\libtcod\SDL.dll" $(TARGET_OUTPUT_DIR)
(note the quotes around the paths. Although not needed in this case, Code::blocks doesn't handle spaces in paths very well (see Step 1)).
And success!
So I decided to switch over to using a 64-bit version of my toolchain for my roguelike in development, as well as moving to C++11, and I encountered a lot of hassle in doing so. So I wrote up some instructions on how to do it. I will at some point put all this up on a webpage somewhere with relevant screenshots.
Let me know if I've missed anything or screwed anything up, or just let me know your thoughts.
1. First, download and install the 64-bit MinGW-builds version of MinGW at: http://sourceforge.net/projects/mingwbuilds/files/?source=navbar
You want the Web Installer labelled "Download mingw-builds-install.exe (170.0 kB)".
Install this in somewhere like "C:\MINGW64". Please don't use any spaces in the path, as CodeBlocks can't handle spaces very well in library filepaths.
When you are installing, please select the following options:
64-bit,
POSIX threads (to enable C++11 std::threads)
SJLJ debugging (not important AFAIK)
2. When this is done, add c:\MINGW64\bin to the system path (Computer/Properties/Advanced System Settings/Environment Variables). Note when you apply the change, you will have to restart any command prompts, programs etc as the PATH only is read at their startup.
3. Now set up and configure Codeblocks following the instructions given in:
http://stackoverflow.com/questions/16716454/setting-up-mingw-and-codeblocks-in-windows-8-64-bit
There are a few minor differences however, mainly seemingly in the layout of the latest Mingw (in the Search directiories settings). Here are my settings:
Global Compiler Settings/Toolchain Executibles/Program Files
Compiler's Installation Directory: C:\Mingw64
C Compiler: x86_64-w64-mingw32-gcc.exe (found in C:\Mingw64\bin)
C++ Compiler: x86_64-w64-mingw32-g++.exe (found in C:\Mingw64\bin)
Linker for Dynamic Libs: x86_64-w64-mingw32-g++.exe (found in C:\Mingw64\bin)
Linker for Static Libs: x86_64-w64-mingw32-gcc-ar.exe (found in C:\Mingw64\bin)
Resource Compiler: windres.exe (found in C:\Mingw64\bin)
Make Program: mingw32-make.exe (found in C:\Mingw64\bin)
Global Compiler Settings/Toolchain Executibles/Additional Paths
Add C:\Mingw64\libexec\gcc\x86_64-w64-mingw32\4.8.1 here
Global Compiler Settings/Search Directories/Compiler
Add the following:
C:\mingw64\include
C:\mingw64\x86_64-w64-mingw32\include
C:\Mingw64\lib\gcc\x86_64-w64-mingw32\4.8.1\include\c++
C:\Mingw64\lib\gcc\x86_64-w64-mingw32\4.8.1\include\c++\backward
C:\Mingw64\lib\gcc\x86_64-w64-mingw32\4.8.1\include\c++\x86_64-w64-mingw32
C:\Mingw64\lib\gcc\x86_64-w64-mingw32\4.8.1\include
Global Compiler Settings/Search Directories/Linker
Add the following:
C:\Mingw64\Lib
C:\Mingw64\x86_64-w64-mingw32\lib
Global Compiler Settings/Compiler Settings/Other options
Add "-m64"
Now save everything, making sure to "Auto-detect" first. Best to restart code blocks.
4. Now download a 64-bit version of SDL. This can be found at
http://sourceforge.net/projects/mingw-w64/files/External%20binary%20packages%20%28Win64%20hosted%29/SDL/
You want the file "SDL-1.2-20111107-win64.tar.gz"
Extract it to something like C:\SDL so the path is C:\SDL\SDL-1.2-20111107-win64 (for example).
Don't do anything else with this at the moment.
5. Now following the instructions at
http://doryen.eptalys.net/data/libtcod/doc/1.5.2/html2/compile_libtcod_mingw.html?c=true&cpp=true&cs=true&py=true&lua=true
down to, but not including, "Compiling libtcod" download the latest Libtcod code to somewhere like C:\libtcod. Don't compile anything yet, we have further changes to do.
5a. Note you may need to download and install MSYS (the version you want is MSYS-1.0.11.exe http://sourceforge.net/projects/mingw/files/?source=navbar) if you haven't it already to follow the instructions in step 5.
5b. And you may also need TortoiseHg (http://tortoisehg.bitbucket.org/) if you haven't got it already either. Note that if an error such as "An error occured during the insallation of assembly 'Microsoft.VC90.CRT, version="9.0.30729.1",publikKeyToken-"1fc8b3b9a1e18e3b", processorArchitecture="amd64", type="win32". Please refer to Help and Support for more information. HRESULT:0x80070BC9." occurs, you have outstanding updates/reboots, so you need to reboot your Windows first before installing Tortoise hg 2.4.1 (see https://bitbucket.org/tortoisehg/thg-winbuild/issue/26/error-when-attempting-to-install-ver-241 for more information).
Note that using the hg clone command will create a libtcod directory inside C:\Libtcod. I've kept the structure of C:\Libtcod\libtcod\ though you may want to squish it to make it neater.
6. Now, before compiling libtcod, we have to copy over compatible 64-bit SDL library and headers. To do this, first create a new directory in C:\Libtcod\libtcod\dependencies called SDL-1.2.20. We're going to duplicate the layout of the existing SDL-1.2.15 directory, only with the updated 64-bit files.
Make a nested subdirectory called include\SDL (for example C:\Libtcod\libtcod\dependencies\SDL-1.2.20\include\SDL) and copy all the header files (*.h) from the equivalent directory in the 64-bit SDL distribution (in my case C:\SDL\SDL-1.2-20111107-win64\include\SDL) into it.
Note that the SDL-1.2.15 directory that comes with Libtcod contains two additional .h files not in the .20 verson - SDL_config_win32.h and SDL_copying.h. No idea if these are needed, but I copied these over also.
Now make a lib\mingw\ nested subdirectory (for example C:\Libtcod\libtcod\dependencies\SDL-1.2.20\lib\mingw) and copy over libSDL.dll.a from the lib subdirectory of the 64-bit SDL (e.g. C:\SDL\SDL-1.2-20111107-win64\lib) into ...\SDL-1.2.20\lib\mingw.
Verifiy that the contents of the SDL-1.2.15 and SDL-1.2.20 directories now mirror each other. Remember that the .20 version will contain 64-bit versions of SDL.
6a. You will also have to replace the SDL.dll file in the root libtcod directory (e.g. C:\Libtcod\libtcod\SDL.dll) with the one from the 64-bit SDL distribution (found in \bin there, e.g. C:\SDL\SDL-1.2-20111107-win64\bin\SDL.dll).
7. Now go to back to the libtcod directory and go into the makefiles directory (in my case it is C:\Libtcod\libtcod\makefiles). Make copies of the makefile-mingw and makefile-samples-mingw files and name them makefile-mingw-64 and makefile-samples-mingw-64 respectively.
8. Editing makefile-mingw-64, you need to change the following lines:
#9: From "SDL_DIR=dependencies/SDL-1.2.15" to "SDLDIR=dependencies/SDL-1.2.20"
#22: From "CC=mingw32-gcc" to "CC=x86_64-w64-mingw32-gcc"
#23: From "CPP=mingw32-g++" to "CPP=x86_64-w64-mingw32-g++"
This is to ensure that the proper 64-bit version of mingw that we installed in Step 1. is used to compile.
9. Editing makefile-samples-mingw-64, you need to change the following lines:
#6: From "SDLDIR=dependencies/SDL-1.2.15"
#8: From "CC=mingw32-gcc" to "CC=x86_64-w64-mingw32-gcc"
#9: From "CPP=mingw32-g++" to "CPP=x86_64-w64-mingw32-g++"
10. Now you can compile libtcod, and the samples. To do this, replace the makefiles targeted in the make commands given in "Compiling libtcod" with the new 64-bit makefiles:
"make -f makefiles/makefile-mingw" becomes "make -f makefiles/makefile-mingw-64"
and
"make -f makefiles/makefile-samples-mingw" becomes "make -f makefiles/makefile-samples-mingw-64"
Note that the call to the UPX executable packer may fail at the end of the build process. Ignore this, its not that important (IMHO).
11. You can now run the 64-bit samples app to make sure it runs ok. Which it should.
12. For informational purposes, here are my relevant Code::Blocks "Build Options" for compiling a 64-bit libtcod project successfully in C++11. Please remember to highlight the top-level build option on the left-hand side of the "Project Build Options" to apply these to both Debug and Release and any other build types you have defined":
Compiler Settings/Compiler Flags:
Checked: "Have G++ follow the C++11 ISO C++ Language Standard [-std=c++11]"
Compiler Settings/Other Options:
-Wno-c++0x-compat
-isystem "C:/Libtcod/libtcod/include" (this is set to avoid generating warnings for Libtcod files when building)
Linker Settings/Link Libraries:
Add ..\..\..\Libtcod\libtcod\lib\libtcod-mingw.a (in my case this is C:\Libtcod\libtcod\lib\libtcod-mingw.a, i.e. it refers to the rebuilt libtcod library)
Search Directories/Compiler:
..\..\..\Libtcod\libtcod\include (in my case this is C:\Libtcod\libtcod\include)
Pre/post build steps/Post-build steps:
cmd /c copy "C:\Libtcod\libtcod\lib\libtcod-mingw.a" $(TARGET_OUTPUT_DIR)
cmd /c copy "C:\Libtcod\libtcod\libtcod-mingw.dll" $(TARGET_OUTPUT_DIR)
cmd /c copy "C:\Libtcod\libtcod\SDL.dll" $(TARGET_OUTPUT_DIR)
(note the quotes around the paths. Although not needed in this case, Code::blocks doesn't handle spaces in paths very well (see Step 1)).
And success!
4
Development Process & non-technical / Re: Thoughts on Threading to allow Animation with Libtcod (C++/Libtcod)
« on: February 01, 2014, 05:52:51 PM »
Aye, though I must admit, I'm preinclined to try threading because its not something I've done before, and I've written roguelikes before with non-blocking input.
5
Development Process & non-technical / Re: Thoughts on Threading to allow Animation with Libtcod (C++/Libtcod)
« on: February 01, 2014, 05:11:25 AM »
Ta Quendus for your thoughts.
That said, I'm really not a fan of non-blocking input (it usually ends up having to install a state-machine in the game engine to handle all the possible status changes). Certainly agreed with your other remarks though.
That said, I'm really not a fan of non-blocking input (it usually ends up having to install a state-machine in the game engine to handle all the possible status changes). Certainly agreed with your other remarks though.
6
Development Process & non-technical / Thoughts on Threading to allow Animation with Libtcod (C++/Libtcod)
« on: January 31, 2014, 08:41:19 PM »
(cross-posted from libtcod forums (http://doryen.eptalys.net/forum/index.php?topic=1628.msg9184#msg9184), I'm interested in a wider view)
So here are a few thoughts on how to provide animation in a libtcod roguelike project, building on top of the data and structures used in the C++ tutorial (http://codeumbra.eu/series/complete-roguelike-tutorial-using-c-and-libtcod).
Feel free to criticise and give feedback. Note this is probably incredibly *unoptimised*.
The basic idea is to use threads (sorry! :p). A worker thread would be used to handle animation of certain tiles during any time that nothing is happening.
I've split off any direct access to the TCODConsole::root into a singleton class called Console which is essentially just a wrapper around method calls to TCODConsole::root (and also allows me to work with std::strings in my code, and it handles the conversion to c_str() where possible). All calls to this need to be mutexed.
The update (i.e. AI/respond to player input)/render (draw on screen) methods in the Engine/GUI classes (which contain calls to change the screen) would be critical sectioned, and hence the animate thread would wait until such time as these were completed and flushed().
So, we will need a new class, let's call it Animate.
We can then add a Animate* pointer to the Tile struct and to the Actor class.
An animation object basically contains a vector of Frame structs, as well as a interval (int, in milliseconds, with a reasonable minimum granularity such as 0.1 seconds or so), screen x and y positions, and a Frame* NextFrame pointer. A Frame struct is a POD-object which consists merely of a char, a foreground TCODColor and a background TCODColor (note all these can be NULL/not set).
Essentially, this represents a situation where every interval, at the x any y position on screen, the glyph, background and foreground colours will change. (If the values are the same as previous, then no change in that value should occur).
So to animate a tile, one creates an appropriate Animate object and attaches it to the Tile (or Actor!), presumably at map creation.
So. The main thread maintains a vector of Animate* pointers. Every time the FOV is recalculated, this vector is populated (repopulated - again, room for optimisation here) with any Animate* belonging to tiles/actors currently in view. This needs to be critical sectioned/mutex off of course.
That's all the main thread does.
Meanwhile, the worker thread, every 0.1 seconds, or whatever we've decided the mininum granularity is, comes along, and starts at the top of this vector of Animate*. It checks if an animation is due (a simple mod on current time would work here?), and if so, updates the screen with the contents of the *NextFrame struct (and increases/wraps around the *NextFrame pointer to the "next" Frame*. One the entire list is processed it *flushes* the root console.
Note that the worker thread does NOT make any changes to *any* data other than the screen.
I'd probably implement this in Boost, to allow cross-platformness (is that a verb?).
So. Thoughts?
So here are a few thoughts on how to provide animation in a libtcod roguelike project, building on top of the data and structures used in the C++ tutorial (http://codeumbra.eu/series/complete-roguelike-tutorial-using-c-and-libtcod).
Feel free to criticise and give feedback. Note this is probably incredibly *unoptimised*.
The basic idea is to use threads (sorry! :p). A worker thread would be used to handle animation of certain tiles during any time that nothing is happening.
I've split off any direct access to the TCODConsole::root into a singleton class called Console which is essentially just a wrapper around method calls to TCODConsole::root (and also allows me to work with std::strings in my code, and it handles the conversion to c_str() where possible). All calls to this need to be mutexed.
The update (i.e. AI/respond to player input)/render (draw on screen) methods in the Engine/GUI classes (which contain calls to change the screen) would be critical sectioned, and hence the animate thread would wait until such time as these were completed and flushed().
So, we will need a new class, let's call it Animate.
We can then add a Animate* pointer to the Tile struct and to the Actor class.
An animation object basically contains a vector of Frame structs, as well as a interval (int, in milliseconds, with a reasonable minimum granularity such as 0.1 seconds or so), screen x and y positions, and a Frame* NextFrame pointer. A Frame struct is a POD-object which consists merely of a char, a foreground TCODColor and a background TCODColor (note all these can be NULL/not set).
Essentially, this represents a situation where every interval, at the x any y position on screen, the glyph, background and foreground colours will change. (If the values are the same as previous, then no change in that value should occur).
So to animate a tile, one creates an appropriate Animate object and attaches it to the Tile (or Actor!), presumably at map creation.
So. The main thread maintains a vector of Animate* pointers. Every time the FOV is recalculated, this vector is populated (repopulated - again, room for optimisation here) with any Animate* belonging to tiles/actors currently in view. This needs to be critical sectioned/mutex off of course.
That's all the main thread does.
Meanwhile, the worker thread, every 0.1 seconds, or whatever we've decided the mininum granularity is, comes along, and starts at the top of this vector of Animate*. It checks if an animation is due (a simple mod on current time would work here?), and if so, updates the screen with the contents of the *NextFrame struct (and increases/wraps around the *NextFrame pointer to the "next" Frame*. One the entire list is processed it *flushes* the root console.
Note that the worker thread does NOT make any changes to *any* data other than the screen.
I'd probably implement this in Boost, to allow cross-platformness (is that a verb?).
So. Thoughts?
7
Challenges / Re: Early 7DRL Declaration
« on: March 05, 2013, 07:58:45 PM »
Going to take part, going to write an occult-themed roguelike using Libtcod and C++
8
Early Dev / Re: Coming Soon: DAEMON
« on: October 18, 2011, 01:30:19 AM »
This is an early screenshot of the Spirit Details page from DAEMON. Ignore the details for now, they're still being worked on in terms of creating the algorithms for the details of the various powers of the spirits.
But each spirit controlled by the character has a power (a castable effect, like a spell in other roguelikes), and this has four parameters:
Proc: the % chance of this power being triggered each turn. This use does not modify the recharge time so powers can be both passive (proc-based) and active (on-use). Can be modified by environmental factors, target availability, items and so on. Also thinking of allowing the random proc effect to be suppressed under certain circumstances.
Effect: for damaging powers, the damage dealt. For non-damaging powers, the extent.
Duration: the duration of the power for non-instant powers in turns, for instant-powers, the length of a HoT/DoT effect applied.
Recharge: the time to recharge the on-use version of the power.
All these figures are/will be modified by factors such as the Spirit Power Level/Sphere/Current Tolerance and Character Spirit/Mind/Summoning Skill and so on. Also I want enviromental and transient effects to play a role too.
But each spirit controlled by the character has a power (a castable effect, like a spell in other roguelikes), and this has four parameters:
Proc: the % chance of this power being triggered each turn. This use does not modify the recharge time so powers can be both passive (proc-based) and active (on-use). Can be modified by environmental factors, target availability, items and so on. Also thinking of allowing the random proc effect to be suppressed under certain circumstances.
Effect: for damaging powers, the damage dealt. For non-damaging powers, the extent.
Duration: the duration of the power for non-instant powers in turns, for instant-powers, the length of a HoT/DoT effect applied.
Recharge: the time to recharge the on-use version of the power.
All these figures are/will be modified by factors such as the Spirit Power Level/Sphere/Current Tolerance and Character Spirit/Mind/Summoning Skill and so on. Also I want enviromental and transient effects to play a role too.
9
Early Dev / Re: Coming Soon: DAEMON
« on: October 12, 2011, 12:28:03 AM »
(cross-posted from http://kharne-rl.blogspot.com/2011/10/magic-in-daemon-part-2.html)
In DAEMON, each spirit you summon will have its own unique seal. A "genuine" seal from the Ars Goetia is given below:
I've written code to procedurally generate similar-looking seals, given names and colours which as passed in as parameters:
Rendered on screen using Libtcod's functions the above seal appears as (actual size):
What's the point of all this? None actually, from a strictly game-play point of view, but I think it increases the atmosphere quite a lot.
In DAEMON, each spirit you summon will have its own unique seal. A "genuine" seal from the Ars Goetia is given below:
I've written code to procedurally generate similar-looking seals, given names and colours which as passed in as parameters:
Rendered on screen using Libtcod's functions the above seal appears as (actual size):
What's the point of all this? None actually, from a strictly game-play point of view, but I think it increases the atmosphere quite a lot.
10
Early Dev / Re: Coming Soon: DAEMON
« on: October 10, 2011, 11:21:49 PM »
(cross-posted from http://kharne-rl.blogspot.com/2011/10/magic-in-daemon-part-1.html)
I thought I'd write a little bit more about the Magic system in Daemon. Its very heavily (well, more like ripped-straight-off from) two real-world occult systems: the medieval grimoire Ars Goetia (also known as the Lesser Key of Solomon), and the Kabbalah (Tree of Life) of the Western Mystery Tradition.
The Real "Tree of Life"
I intend gameplay to metaphorically simulate the path of the Goetic (one who summons spirits) ascending the Sephiroth (the Spheres of Tree of Life, embodying everything "good") whilst battling the evil forces of the inverse of the Sephiroth, the Qliphoth (which embody "evil") as one descends dungeon levels. Thus the spirits the Character can summon to assist him/her have thematic powers appropriate to the corresponding Qliphoth, foes will also be based upon said qliphoths, and the Sephiroth themselves will influence both the environment and also other powers that the Character may have.
For example, the dungeon levels corresponding to Geburah/Golachab (named Golachag in the game) will have enemies themed with destruction/burnings and ruins (in real-world occult lore, the qliphoth Golachab means "Burners with Fire" whereas the sephira Geburah embodies Strength), but the level itself will perhaps filled with martial armouries, great demonic captains or the remains of a dead god of war and so on.
The fluff in the game for Golachag states that:
"Spirits of Golachag are those who burn to do destruction - even onto themselves. They are known for inspiring in mortals unbridled radicalism and tyranny that brooks no opposition, and executes all its opponents.When manifested their bodies are forever consumed with an unburning liquid fire."
Summoning and using Spirits will cost the Character corruption and degeneration points, which will however, in return make summoning and using spirits easier. There will be ways to reduce both, although I've not finished designing these, but I suspect they will operate much like piety in Crawl does, although aligned upon Kabbalistic premises.
For example, in the screenshot above, it is possible to attempt to summon one of ten ranks of spirits, from the least, Soldier, to the greatest, King (as per the Ars Goetia). The more powerful a spirit summoned, the greater the powers available to the Character, but the more risks are involved.
Characters can summon and control three spirits at a time, and have access to the powers of the spirits (for example, in the above sphere, Neremoth (Fear), spirits will be able to frighten enemies, reducing their effectiveness or even preventing them from attacking altogether for a short period of time).
However, accessing their powers will reduce the spirit's life-force - represented by a hunger level. If the hunger level gets too low, then bad things (tm) could happen. I am still designing the consequences of what happens if this occurs. Perhaps the spirit could break free and attack the Character?
I'm also intending for environmental effects to play a big part in the game, akin to Unangband for example. These could make summoned spirits more or less effective, or easier to summon, and so on.
My aim is to make magic, and in fact, entire game-play a much more two-edged sword than in a lot of other roguelikes, simulating some of the character progression in RPGs such as Kult (which is another influence).
I thought I'd write a little bit more about the Magic system in Daemon. Its very heavily (well, more like ripped-straight-off from) two real-world occult systems: the medieval grimoire Ars Goetia (also known as the Lesser Key of Solomon), and the Kabbalah (Tree of Life) of the Western Mystery Tradition.
The Real "Tree of Life"
I intend gameplay to metaphorically simulate the path of the Goetic (one who summons spirits) ascending the Sephiroth (the Spheres of Tree of Life, embodying everything "good") whilst battling the evil forces of the inverse of the Sephiroth, the Qliphoth (which embody "evil") as one descends dungeon levels. Thus the spirits the Character can summon to assist him/her have thematic powers appropriate to the corresponding Qliphoth, foes will also be based upon said qliphoths, and the Sephiroth themselves will influence both the environment and also other powers that the Character may have.
For example, the dungeon levels corresponding to Geburah/Golachab (named Golachag in the game) will have enemies themed with destruction/burnings and ruins (in real-world occult lore, the qliphoth Golachab means "Burners with Fire" whereas the sephira Geburah embodies Strength), but the level itself will perhaps filled with martial armouries, great demonic captains or the remains of a dead god of war and so on.
The fluff in the game for Golachag states that:
"Spirits of Golachag are those who burn to do destruction - even onto themselves. They are known for inspiring in mortals unbridled radicalism and tyranny that brooks no opposition, and executes all its opponents.When manifested their bodies are forever consumed with an unburning liquid fire."
Summoning and using Spirits will cost the Character corruption and degeneration points, which will however, in return make summoning and using spirits easier. There will be ways to reduce both, although I've not finished designing these, but I suspect they will operate much like piety in Crawl does, although aligned upon Kabbalistic premises.
For example, in the screenshot above, it is possible to attempt to summon one of ten ranks of spirits, from the least, Soldier, to the greatest, King (as per the Ars Goetia). The more powerful a spirit summoned, the greater the powers available to the Character, but the more risks are involved.
Characters can summon and control three spirits at a time, and have access to the powers of the spirits (for example, in the above sphere, Neremoth (Fear), spirits will be able to frighten enemies, reducing their effectiveness or even preventing them from attacking altogether for a short period of time).
However, accessing their powers will reduce the spirit's life-force - represented by a hunger level. If the hunger level gets too low, then bad things (tm) could happen. I am still designing the consequences of what happens if this occurs. Perhaps the spirit could break free and attack the Character?
I'm also intending for environmental effects to play a big part in the game, akin to Unangband for example. These could make summoned spirits more or less effective, or easier to summon, and so on.
My aim is to make magic, and in fact, entire game-play a much more two-edged sword than in a lot of other roguelikes, simulating some of the character progression in RPGs such as Kult (which is another influence).
11
Early Dev / Re: Coming Soon: DAEMON
« on: October 10, 2011, 12:40:50 AM »
Writing a routine to print a paragraph of text to the console (or rather Libtcod's simulated true-colour console) in a series of x-character sized chunks whilst not breaking up words over a Carriage Return is actually not a trivial task. For a game like my roguelike, where there will be lots of lore and hence the need for lots of text displayed on the screen at various points in the game, this sort of thing is essential.
For example, consider this paragraph of textual fluff:
"Spirits of Neremoth are responsible for frightening sounds in strange places. They are commonly known as Whisperers or Night Spectres. Their colours are of a stagnant watery blue, and their forms are like hideous women, almost skeletons united to the bodies of serpents and fishes"
If I want to display this in an area of screen say 30 characters wide, then I need to keep taking chunks of that size, trimming back to the last space, display the line of text, remove the printed text from the beginning of the paragraph, and repeat until there is either no more text left to display or the remaining text is less than 30 characters.
That's the theory. I've found the code needed to perform this task to be slightly more complicated.
Here's the code anyway (in *C#*):
// Display multiline text
public void PrintText(string textToPrint, int xPos, int yPos, int width, TCODColor fgColour, TCODColor bgColour)
{
string fullText = textToPrint;
string workingChunk = string.Empty;
string lineText = string.Empty;
int lastSpace = 0;
// Now break down the text into lines and print them
do
{
// Remove leading spaces or else our removals every iteration
// will get "out of sync"
fullText = fullText.TrimStart();
// Take an appropriately-sized chunk
workingChunk = fullText.Length > width ?
fullText.Substring(0, width) : fullText;
// Work out the position of the last space
lastSpace = workingChunk.LastIndexOf(' ');
// If we can't find a space just break anyway
lineText = lastSpace > -1 ? workingChunk.Substring(0,
lastSpace) : workingChunk;
// Print this text
Print(lineText, xPos, yPos, fgColour, bgColour);
// Increment the y-position
yPos++;
// And delete the text we've just printed from the beginning of
// the string
fullText = (fullText.Remove(0, lineText.Length));
// Repeat until all the text is printed
}
while (fullText.Length > 0);
}
(ignore the call to the print method, its simply a wrapper for printing a sequence of chars to the console)
Improvements I can think of: returning the number of lines used, so that perhaps a wrapper function can display an optional frame around it. Any other improvements or enhancements that you can see?
For example, consider this paragraph of textual fluff:
"Spirits of Neremoth are responsible for frightening sounds in strange places. They are commonly known as Whisperers or Night Spectres. Their colours are of a stagnant watery blue, and their forms are like hideous women, almost skeletons united to the bodies of serpents and fishes"
If I want to display this in an area of screen say 30 characters wide, then I need to keep taking chunks of that size, trimming back to the last space, display the line of text, remove the printed text from the beginning of the paragraph, and repeat until there is either no more text left to display or the remaining text is less than 30 characters.
That's the theory. I've found the code needed to perform this task to be slightly more complicated.
Here's the code anyway (in *C#*):
// Display multiline text
public void PrintText(string textToPrint, int xPos, int yPos, int width, TCODColor fgColour, TCODColor bgColour)
{
string fullText = textToPrint;
string workingChunk = string.Empty;
string lineText = string.Empty;
int lastSpace = 0;
// Now break down the text into lines and print them
do
{
// Remove leading spaces or else our removals every iteration
// will get "out of sync"
fullText = fullText.TrimStart();
// Take an appropriately-sized chunk
workingChunk = fullText.Length > width ?
fullText.Substring(0, width) : fullText;
// Work out the position of the last space
lastSpace = workingChunk.LastIndexOf(' ');
// If we can't find a space just break anyway
lineText = lastSpace > -1 ? workingChunk.Substring(0,
lastSpace) : workingChunk;
// Print this text
Print(lineText, xPos, yPos, fgColour, bgColour);
// Increment the y-position
yPos++;
// And delete the text we've just printed from the beginning of
// the string
fullText = (fullText.Remove(0, lineText.Length));
// Repeat until all the text is printed
}
while (fullText.Length > 0);
}
(ignore the call to the print method, its simply a wrapper for printing a sequence of chars to the console)
Improvements I can think of: returning the number of lines used, so that perhaps a wrapper function can display an optional frame around it. Any other improvements or enhancements that you can see?
12
Early Dev / Re: Coming Soon: DAEMON
« on: October 09, 2011, 01:41:14 PM »Whoa!!!
I'm so going to play this!!
Just wait a minute, Tiphereth qlippoth = sanity??? What?
Also, the pentacle behind the qlippothic tree makes the screen a bit confusing (lines over lines)
Oh right, should really be Insanity. spirits of that sphere will allow you to cause insanities in your enemies. The actual qlippoth is Thagirion, "Those Who Bellow Grief and Tears", and I struggled a bit to map that to a implementable power. So I ended up with insanity.
Warning: Qabollix now follows:
Also, the first version will have ten dungeon levels, and each level will be themed to a sephiroth and its corresponding qlippoth. For example, the level corresponding to Geburah/Golachab will have enemies themed with destruction/burnings and ruins (Golachab means "Burners with Fire" whereas Geburah embodies Strength, but the level, perhaps filled with martial armouries, great demonic captains or the remains of a dead god of war and so on.
I forgot to mention the aim of the game will be to destroy the big bad, KHARNE (heh), who took over the world, and cut it off from the rest of the Macroverse, and defeated the pantheon of gods etc. To do this, think of it as a goetic ascending the Tree of Life.
Obviously, given the nature of the final qlippoth, there will be surprises in store.
(the final power, akin to Thamiel, is the ability to swap bodies, which I've never seen done in a Roguelike and which I think could be incredibly fun)
I've changed names slightly of the qlippoth and will be randomly generating actual spirit names to avoid doing any harm to any real spirits. :p
It will be
13
Early Dev / Coming Soon: DAEMON
« on: October 08, 2011, 09:49:08 PM »
I'm currently coding an occult-themed roguelike called Daemon using C# and the libtcod.NET library. Its inspired by the medieval grimoire Ars Goetia and by the Qliphoth (the reverse of the Qabbalistic Tree of Life).
I'm aiming to get a first version out (under the GPL) by the end of the month or so. It will be a complete game with save/load and a win condition, as I've largely used the framework I wrote for my 7DRL, Stygia.
Here's some screenies to whet your appetite:
Higher-resolution pictures available from http://kharne-rl.blogspot.com/2011/10/daemon.html
I'll also be releasing another Alpha version (primarily a bug-fix) of Kharne soon. Even though I can't stand coding in Delphi anymore :p
Best,
P.
I'm aiming to get a first version out (under the GPL) by the end of the month or so. It will be a complete game with save/load and a win condition, as I've largely used the framework I wrote for my 7DRL, Stygia.
Here's some screenies to whet your appetite:
Higher-resolution pictures available from http://kharne-rl.blogspot.com/2011/10/daemon.html
I'll also be releasing another Alpha version (primarily a bug-fix) of Kharne soon. Even though I can't stand coding in Delphi anymore :p
Best,
P.
14
Early Dev / Re: Kharne v0.0.6a now available.
« on: July 15, 2011, 10:49:20 PM »
(note: I've moved to a new numbering system for Alpha releases - this is effectively 0.06b in the old system; the change was made because I don't feel right giving an incomplete game a proper version number - the Roguelike world is filled with too many v0.01s and v0.001s and so on as is).
A new version of Kharne (Alpha 23) is now available at http://kharne-rl.blogspot.com/2011/07/kharne-alpha-23-now-available.html (source also available as a download, and browsable online, and released under the MPL).
This is mainly a bugfix version superseding the previous version, although I've made a few other additional changes:
* Moved to a new Versioning System.
* Status Conditions are now displayed at the bottom of the main display.
* The '@' symbol is coloured according to the current health of the Player Character.
* Added four more types of potions to cover Elemental Resistances, which add 40% to their respective resistances.
* Trying to drink a potion or reading a scroll whilst not being able to will now exit the inventory properly.
* Potions of Healing and Extra-Healing now cure poisons.
* Potions of Extra-Healing cure the Paralysis, Blinded, Confusion and Drained conditions.
* A message is generated whenever a level containing a Unique is entered.
* Wearing Heavy or Medium armour reduces stealth.
* Thieves now learn Stealth skills quicker.
* Warriors now learn Defense & Heavy Armour skills quicker.
* Stealth rolls are modified by the distance to Monsters.
I intend this to be the last version before magic, end-game/win conditions and the monster overhaul are implemented.
Comments, bug reports and queries most welcome of course.
A new version of Kharne (Alpha 23) is now available at http://kharne-rl.blogspot.com/2011/07/kharne-alpha-23-now-available.html (source also available as a download, and browsable online, and released under the MPL).
This is mainly a bugfix version superseding the previous version, although I've made a few other additional changes:
* Moved to a new Versioning System.
* Status Conditions are now displayed at the bottom of the main display.
* The '@' symbol is coloured according to the current health of the Player Character.
* Added four more types of potions to cover Elemental Resistances, which add 40% to their respective resistances.
* Trying to drink a potion or reading a scroll whilst not being able to will now exit the inventory properly.
* Potions of Healing and Extra-Healing now cure poisons.
* Potions of Extra-Healing cure the Paralysis, Blinded, Confusion and Drained conditions.
* A message is generated whenever a level containing a Unique is entered.
* Wearing Heavy or Medium armour reduces stealth.
* Thieves now learn Stealth skills quicker.
* Warriors now learn Defense & Heavy Armour skills quicker.
* Stealth rolls are modified by the distance to Monsters.
I intend this to be the last version before magic, end-game/win conditions and the monster overhaul are implemented.
Comments, bug reports and queries most welcome of course.
15
Early Dev / Re: Rogue Project 2
« on: July 09, 2011, 01:21:30 AM »http://lordsofdarkhall.weebly.com/rogue-project-2.html
Another version of my rogue project is up. Work stalled a bit, but has picked up a lot lately. Engine feels pretty solid, and now that I have the skill framework and hotkey system done (just drop the skill code in and its done) it's time to start adding the content and begin balancing.
If you're interested, you can give it a test drive at the link above. You still can't die yet, and pressing \ on the overworld unlocks a few skills to play with. Pressing \ on the submap generates a random, possibly magic item for you to futz around with.
Probably the last 'alpha' code I will generate, at least for a while. Now that the engine is 'done' (with the exception of the town/buy/sell stuff), I am going to actually start adding the 'content' and the town building code. My goal is something like a sort of roguelike Oblivion.
If you have the time, I would love some criticism/feedback, especially on performance of things like auto-explore on your system. I have manually coded the load/save dialog boxes because of the common 'comdlg32.ocx missing' people kept getting when I used what was supposed to be part of every Windows install.
Thank you for your time; hope everyone is having a nice summer (or winter for those of you down south)!
Brigand
Excellent stuff, glad you're still keeping involved with this. I'll give you some feedback after the weekend.
Best,
P.