Egoboo is a working cool 3D dungeon crawling game in the spirit of NetHack for Windows, Linux and Mac.
or do you see any naming conflicts here
@Zefz and make a new pr for that for that something working maybe gets into master at some point
@/all so ladies and gentlemen we have a cmake build system running for idlib (https://github.com/primordialmachine/idlib) on travis and appveyor; for now, the most important part is to transfer these techniques to whole egoboo. This came unexpected, hence there are several important steps to take:
- first of all math part is (extremely) simplified and plug-in based (which was what is was working on actually) as GCC as well as Visual C++ support now the required language features.
- The math part is moved to Idlib.
- Afterwards the "game" project is merged into Egolib in order to avoid linking issues (lots of code motion).
@/all You may have observed that there was a license switch in Idlib; shortly, Idlib will be too valuable to waste it exclusively on a trainwreck like Egoboo alone, I do think there is an acceptable option: It receives its proper (L)GPL license and an option for commercial licensing; I do think i support commercial usage but whoever wants to make money can also pay for it. Only free software - like Egoboo - is supposed to be built on other free software. I do not like freeloaders so to say.
@/all yet commercial usage has a nice backflow of features and ideas if it ever happens and they can pay for the servers^^
For the cmake build system of Egoboo, the primary problem are the dependencies (on Windows/Cygwin); on Linux it actually works fine already
@/all as cmake supports cross-platform downloading and unpacking (yes even tar.bz2 works on windows (at least here)) the dependencies impose no thread to this effort - even PhysFS (the worst as it is only packaged on some Linux systems and certainly not packaged on Cygwin) can be handled then
positive effect is most likely that the "external" repository/submodule will be gone
@/all also a change as it does not seem to be possible to grant free access to things without people causing a desaster: Egoboo/Idlib/... changes will be strictly speaking pull request based and i will merge them only after careful examination :(
there are four linker errors left e.g. "map_generate_tile_twist_data"
i can not find a definition of this function however, which is weird
that baby is nice; again, you define your own functor
id::semantic_cast<Vector2f>(getPosition(), id::zero<Point2f>())
the semantic cast for the case in which you want to define some point of origin
id::semantic_cast<Vector2f>(getPosition(), Point2f(1,1))
can be used for implementing any cast you'd ever need
auto t = id::euclidean_norm(v);
if (t.length == id:zero<float>()) { /* v was zero, t.vector contains v*/ }
else { /*t.vector contains the normalized vector*/ }
egoboo/egoboo#361
so far 2200 lines of code removed
so as Egoboo has "some" text rendering issues (including the still to be fixed console) and i require an actually usable console to check wether the "camera system" still works when i change something about these dreaded "facing" angles, there it comes: the inevitable "document" class: the idea and some of the code was taken from an engine that is a bit dated (lighfeather) and i was working on the GUI back then - the GUI back there actually had text support for formatted multi-line text and it was using this approach. In PR #361 the document class still resides in Egolib, this will change of course, as soon as it passes all the unit tests
the fundamental issue documents aid to solve is text rendering - more precisely the costly operation of preparing text for rendering; they raise appropriate events when parts of a long text change. For example, if you replace a part of the string then you will receive the original string, the string with the part replaced, and the range of characters affected. Themselves, they do not deal with rendering (separation of concerns). Receiving such events makes it easier to re-prepare the text for rendering after changes. For example if an event is received that says a number of characters l starting at index i were changed, it becomes quite trivial to update a graphical representations of specific text lines (i and l make it trivial to find the affected lines and update)
lightfeather, the engine i was talking about, is not really competitive these days, however, it's gui system was and (taking a look at CEGUI and others) most likely still is competitive
certain languages (C#, Java) use in their GUI toolkits quite exhaustively what these documents are: there, they are called models
c does not stand for C or C++ but rather compiler
so now the task is to be able to check the game state and acquire a pointer to the current game state and we can implement cheats; by cheats i mean cheats for development e.g.
grog() which grogs the player
this project will be built with CMake as well
@/all make Egolib actually use the image class (to get rid of all the C-like functions) and then move the image class into Idlib-Game-Engine. This will also require that Idlib-Game-Engine properly links with SDL.
the pixel format descriptors queries will be changed to allow for runtime inputs instead of compile-time inputs, for the reason that the input (i.e. a pixel format enumeration value) to a pixel format descriptor query might not be available at compile-time (e.g. load pixel format enumeration values from files)
doesn't matter if a module is select or not, i think the problem is the "Press an icon ..." label