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.


Messages - Cfyz

Pages: 1 ... 11 12 [13]
181
Right now it is impossible to compile it on Mac. The library creates a UI window on its own via OS API calls and that requires platform-specific code. Such code is isolated by implementing a subclass of the BearLibTerminal::Window, e. g. X11Window or WinApiWindow. However, after that the rest will require just a few simple tweaks. Mac is very close to Linux but interacting with OS requires Objective-C and right now I have zero experience with that. I do plan to port it to Mac, just can't say when =(

As a relatively quick hack I can try to make 'generic' window implementation via SDL. This will obviously introduce a library dependency, but can help with portability as the rest of the code is mostly platform-agnostic.

By the way, I lowered compiler requirement to GCC 4.6.3, which comes with much more distros than 4.8. Trying to support even lower versions will require rewriting a lot so I stop here for now. As for MSVC, VS2013 is pretty good, I'll make library code support it shortly. And actually Windows is more lenient here as one can use VS2013 to compile a binary that will run on any sensible Windows version, i. e. from XP to 8. In Linux 64-bit version can't link statically to libstdc++ thus for library to run on different distros, it have to use the lowest possible version of libstdc++.

Also, about compiling SampleOmni with VS2013. I've found a rather shameful mistake in sample code. In WindowsGlyphList.cpp the list of ranges was initialized from references to temporaries rather than actual objects, fixed now. Well, working okay with some particular compiler also falls under UB =)

182
Off-topic (Locked) / Re: War never changes
« on: March 06, 2014, 10:47:26 PM »
Ukraine is a bit closer to Russia than someone might think. There is neither visa nor usual international passport required and customs are nearly nonexistant. For some people it way easier to come to east Ukraine or Crimea (e. g. for vacation) than to distant regions of Russia. By the way, the area of current Ukraine is practically the motherland of Russian nation (see Kievan Rus'), all that Syberia came far later.

And the excess of land does not help, the infrastructure outside of big cities is paper-thin Т_Т.

About Finland I can only wonder where that came from. It is nice and, as far as my expirience goes, very hospitable country, but at the same time is is unmistakenly foreign country. It's a completely different situation from brother nation of Ukraine. Thus nope, Krice, no russain women to you.

183
Off-topic (Locked) / Re: War never changes
« on: March 04, 2014, 10:33:05 PM »
This video shows how Crimean self-defence tries to keep control of their airport base. The base was taken under control by order from deputy prime minister of Crimean Autonomy (Rustam Temirgaliev). By now Ukrainian people are allowed to the base.

At 0:55 you can hear Ukrainian "soldier" screaming "America with us!" (wut, really?). And just before, "ha, shoot, shoot, we're on TV". As far as I can see this was a fairly clumsy provocation. After several warning shots and a lot of talking those 50 or so Ukrainians were allowed on the base. The way situation unfolded indicated quite clearly that was a minor internal confusion. Too bad we'll likely to see a lot of similar situations, all the while Russian, Crimean and Ukrainian forces looking almost indistinguishable.

By the way, that only concerned military structures. As far as I can see (wow there is so much propaganda from both sides =_= and unfortunately I do not know anyone from there to ask) civilian airport is functioning as usual.

I find relatively funny how this one was blown out of proportion. Think what USA troops would do if some random people tried to show off and provoke right at the military base entrance, whether it was taken over legally or not.

184
Off-topic (Locked) / Re: War never changes
« on: March 04, 2014, 08:50:22 PM »
Quote from: miki151
Yep, so why don't Poland now invade western Ukraine to keep our minority safe from the still possible civil war ...
Safe from who? There are mobs going out screaming "if you are true ukrainian you have to kill russian in you!" while waving fascist flags. The most extreme ones trying to threaten to "purge Crimea of russian filth". They go in crowds with weapons and generally look ready to riot. And the Ukrainian military is mostly disfunctional.

Things got to the point that Crimea is claiming independence from Ukraine. Almost all of their military forces have sworn loyality to the "people of Crimea", not the Ukrainian government. Neither to the Russian, obviously, since that would likely freaked the world out =)

I highly doubt all of that was orchestrated by EU but currently pro-European part presents far greater danger to the Ukraine as a country.

Quote from: miki151
The pact allows them to station, and not take over airports, military installations, block roads, etc.
For now, nothing like that happened and lets hope nothing will. The "massive invasion" for the most part was actually a long scheduled military excercises. The main force has already been recalled. The lesser part is pure strategy. As you said, the pact allows to station some troops. Given the unstable situation, Russia just stenghtened those troops to be prepared for the worst situation.

Quote from: rot13
Technically there's no invasion yet, as Russia and Ukraine have a pact which allows certain amount of russian troops to station in Crimea.
Actually, there is more. The still legitimate president of Ukraine, Yanukovich, himself officially asked for assistance in restoring the law and order. Personally I'm not very fond of this idea as it can easily get out of hand. Thankfully our goverment decided to wait and see how the things turn out. And given Yanukovich general incompetence I doubt he and his request will remain legitimate for long as there is a referendum scheduled to 30th of March.

185
Off-topic (Locked) / Re: War never changes
« on: March 03, 2014, 10:52:36 PM »
Quote from: Krice
because some countries want war more than others. Russia, Somalia and other underdeveloped countries.
Believe me, the country which took full onslaught of both World Wars despite having no real desire in participating in them is unlikely to want a war. Even Somalia is just lawless, so more like simple wild nature than a dedicated crowd of fanatics.

Quote from: Krice
Let them kill each other rather than hurt civilized world with whatever they do. We should know better and be wiser than them.
Which is a form of self-satisfaction based on fairly simple demagogy method: substituting "I am better than the worst people of %nation%" to "I am better than people of %nation%". Sorry to disappoint but this works only until you are dragged into some shit without asking your subjective opinion about yours neighbourhood developmentness (which is, as it turns out, is totally irrelevant).

On another note, because people may be unaware of actual state of Russia and other slavic nations around: self-identification-wise Ukraine is half russians (and Crimea is even more so). There are tons of people with family ties. But the other half consider themselves european and the fact that they live within one border always was a cause for some tension -- people of seemingly one country are actually two different nations and want to live differenly. So (at least for now) there is no any "intervention" from Russia, we just trying to keep our own people safe in case of still possible civil war.

186
Off-topic (Locked) / Re: War never changes
« on: March 03, 2014, 10:34:35 AM »
Quote from: Krice
We really should not do anything other than let russians kill each other.
"We should let %nationality% people die" is not funny at all. Substitute yours in that placeholder, hm?

Quote from: koiwai
People don't want a war -- Putin does, he is a bored megalomaniac.
As a Russia resident I can say Putin is one cunning and calculative bastard (KGB past must help a lot). He always stops just before the situation goes to the extreme and always leaves some visibility of freedom, not that it helps people much though. I'm fairly sure he won't let anything major happen, in only just to ensure his safety.

187
Updated the library to version 0.9.8: http://foo.wyrd.name/en:bearlibterminal#download

koiwai, I fixed the project a bit and now it should compile fine on 64-bit systems. Also I've changed CMake project structure for easier incorporation into another project's source tree. Now entire library source with all its dependencies is under ./Terminal directory (so the root CMakeLists.txt and this directory is all you need) and ./Samples is now optional. If you remove samples directory before CMake generation, it won't complain about that and will build just the library.

Quote from: Quendus
it would be nice for code completion if the api functions and constants were in a namespace
Well, the problem is that C++ header is also header for C which do not have namespaces. Where it is not a case (e. g. C# or Ruby) API functions are indeed grouped under some namespace. Also I'm not sure what you mean by "code completion", as IDEs auto-complete current variant just fine (checked MSVS and Eclipse).

Quote from: Quendus
I used cmake to generate a VS2013 project for SampleOmni. It compiles and it can find the BearLibTerminal.dll file, but it crashes when main() starts. Maybe I configured it wrong.
Whoa. I have not had my hands on VS2013 yet and given how different GCC and MSVC are I expected it to fail right from the start =) Looks like they did a good job fixing C++11 support. I will make library compileable by MSVC later, but for now you should either build it with MinGW or just use a prebuilt binary. Not that I discourage you from experimenting =)

If it crashes in terminal_open, it might not be MSVC's fault, as there was a mistake in calling convention of OpenGL extension function. Whether it will crash or not somehow depended on compiler optimization options and usually it was ok. Fixed now.

Quote from: Quendus
I'll resist the temptation to put Cyrillic monsters in my 7DRL!
Angry ё (like e but with eyes open), spider Ж, butterfly Ф, paired monsters Я and R. Well, there is not much actually, I think Greek is better material as it is generally more familiar (think math). My favourite one is Ω, which is, of course, a wind spirit (see fūjin).

Quote from: Quendus
I've made a simple example of smooth movement using exponential decay.
Nice one. I think I'll include it into samples though most likely edit it beyond any recognition >_<. And I have some comments about the code If you don't mind...

It might be a matter of preference but I thing constructing configuration string that way is rather cryptic. There is a printf-like version of set:
Code: [Select]
terminal_setf("window: size=%dx%d, cellsize=%dx%d, title='%s'", TERM_WIDTH, TERM_HEIGHT, CHAR_WIDTH, CHAR_HEIGHT, TITLE_STR.c_str());
Quote
// what do I do if I want to use argc, argv?
Well, then you just do not use TERMINAL_TAKE_CARE_OF_WINMAIN macro and declare main yourself. It's just a bit of sugar to get rid of all those HINSTANCE and Windows.h include as most of the time graphical applications do not take command-line arguments anyway.

188
Quote from: Z
Is there any relation to Bear who was a long time rgrd regular
No =) "bear" here is a reference to the "BeaRLibrary" collection of roguelike-oriented libraries from the russian rlgclub.ru forum (like, russia = bears >_<). There are at least separate BearLibMG (map generation) and BearLibPF (pathfinding) libraries, though I have no connection to them.

189
Quote from: Quendus
The mouse input sample behaves strangely for me. When I scroll nothing happens, but if I then click, rhe scroll state updates. Would it be possible for the scroll wheel to emit an event (with the change in the scroll state) instead?
It can emit an event. In the demo there is a list of input mask flags at the top-left corner, you can select "mouse scroll" there. By default only key presses and releases produce the events but mouse movement (cell or pixel-level) and mouse wheel scrolls may be included there as well. The configuration string would be
Code: [Select]
terminal_set("input.events=keypress+keyrelease+mousescroll");and the event itself is TK_MOUSE_SCROLL.

190
Quote from: koiwai
I tried to compile the source code on my 64bit Linux, and it failed at libfreetype2. (Unless I did something wrong with cmake)
It's unlikely to be your fault, the 64bit builds are just not tested yet. The code should be okay though, it mostly build configuration problem. I'll try to fix this soon.

However, do note that code relies on C++11 features, which essentially requires GCC 4.8+. I'll probably try to make it more compiler-friendly, as lower GCC versions had pretty good C++11 support and MSVC is improved greatly with VS2013 release, but for now it is not supposed to be a part of a project source. Instead, if there is no suitable build yet, compile it separately and include the binary in the project.

Quote from: koiwai
Maybe, I can use my native library to build BeaR on a 64bit system?
You should be, by replacing include_directories and target_link_libraries in the ./Terminal/CMakeLists.txt file. The intention behind including a copy of freetype2 code is to make sure the game will rasterize TrueType identically down to the pixels on every platform. It is important when mixing TrueType main font with bitmap tilesets.

Quote from: koiwai
Is the library designed to be simply copied in your project directory, and distributed together with the source code of the game (if I make my code open source)?
Not sure I understood you here. The library binary is supposed to be distributed along with an application, but mostly because I do not imagine it in installer form =). The location of sources is up to you.

Quote from: koiwai
I did not find anything specific about the license, but it's good to have one.
Quote from: Quendus
If it's a permissive license I may use it instead of NotEye for this year's 7DRL.
The library is licensed under MIT. It is stated so in every source file, headers and bindings included =). Shoud have mentioned that on the site too, probably.

191
With mixed feelings of pride and uncertainty I present you a project I've been working on for some time. This is a library aimed to simplify the interface part of a roguelike development. Something along the lines of libtcod but focused primarily on output, maybe ncurses will be a closer example.

(Yup, I am no native English speaker so please bear with me =_=.)

The library is available from http://foo.wyrd.name/en:bearlibterminal. The documentation is also there, though somewhat incomplete. However, the rest will follow in time and the library itself is practically done, so I believe there is no point to delay its "international" release any longer.

This library provides you with a window and allows for easy tile and tileset manipulation while keeping pretense that the scene is mainly text or pseudographics. Quick example:
Code: ("c") [Select]
#include "BearLibTerminal.h"

int main()
{
    terminal_open();
    terminal_set("window: size=32x8");
    terminal_set("font: UbuntuMono-R.ttf, size=12");
    terminal_print("Hello, ωōrlд!"); // UTF-8
    terminal_refresh();
    terminal_read();
    terminal_close();
    return 0;
}



The library is not for C/C++ only. As it is a dynamic-link library, it also has bindings for C#, Pascal, Lua and Ruby, which should make it suitable for rapid prototyping. It also runs on Windows and Linux.

There is a showcase named "SampleOmni" included in the download archive. You may be surprised at how much can be squeezed from the measely 20 functions of the library API.

Well, I hope it helps someone =)

192
Programming / Re: Handling a large number of actors
« on: December 09, 2013, 11:33:25 AM »
Quote from: Thales
Also, since this is a turn-based game, the game spends most of its time doing nothing, and checking the player's input.
I think you might utilize this. Most of the actors who do not actually interact with the player (for a simple example, all those outside of player's FOV) may be calculated in advance while waiting for the player's input, from closest to player to farthest. The main idea is to calculate as much as possible during the time game has nothing else to do.

This will increase game engine/logic complexity. There must be some way to check if precalculated move conflicts with actual state. Game data must support some level of parallelism. However, this approach can make an impression of all the actors being handled.

193
Programming / Re: Basic game programming concepts
« on: September 25, 2013, 04:36:05 PM »
I think george was right to call your question paradoxical. You ask about general concepts like storing game objects information and not implementation details. Yet those are exactly what implementation details of some specific game are. For example, game may have or may not have any tiles -- this will influence inner logic tremendously, both data- and algorithm-wise. There may be or may not be any doors to open and close. Whether there will be a new dungeon to load when leaving the screen is also up to you. There are multitude of options. So you cannot just wave this point aside as something 'oh i just meant similar idea-wise'. All these design choices together are the game itself.

That's why your question looks like "any tutorial on concepts about everything?".

Try to write several mock-ups. For example, trivial ping-pong game and simplest one-screen one-level rogue-like. You'll see there are almost no similarities. You can't expect any tutorial on the subject this broad.

194
Programming / Re: Porting to other platforms - how to test?
« on: September 14, 2013, 08:11:12 PM »
1. Most likely won't work as good as you expect. Every platform has some aspects no programming language will be able to abstract. Like console output not behaving uniformly, input methods being completely different or specific installation procedures. Without some libraries (like SDL) or frameworks (like Marmalade) support for several platforms is difficult.

2. Will not work. You'll have to debug a lot and reports like "ITS NOT WORKING!!" won't help you any.

3. You'll have to learn platforms' mechanics to some extent. At the very least you should be able to build your app for the platform in question and run it to reproduce bugs. Buying HW isn't strictly necessary as there are VMs and emulators.

4. For desktop platforms VM is usually enough. Lately they even become capable of some graphics acceleration which probably will be enough for a roguelike.

5. I say, depends on the project. If it is your first game without clear future, just select one most interesting platform and concentrate on that. In case of success, there will always be Wine and better understanding what and where exactly you need to port.

Pages: 1 ... 11 12 [13]