Egoboo is a working cool 3D dungeon crawling game in the spirit of NetHack for Windows, Linux and Mac.
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
Reason: Egoboo has too many problems that prevent it from being released to players. These problems are distributed over code and data. That is, they are distributed over the whole software.
Comparing to real games/real game tools, Egoboo is in its infancy.
Resolutions: More developers which want and are able to (technically and theoretically) on these problems.
Interim Solution: I have technical means to provide pre-built packages for Windows.
However, what is the purpose ofnon-developers playing an unfinished software.
However, what is the purpose ofnon-developers playing an unfinished software.
@/all and Idlib compiles and passes existing unit tests for Apple; now the same (including SDL and PhysFS) for Idlib: Game Engine
@/all Idlib is put under the zlib license and received a project page https://primordialmachine.com/idlib/
travis-ci/travis-ci#7304
...
...
so there are two more functions required for the file system: get the home/user directory and
copy_file; i am a bit concerned about OS X as i do not have a native environment there though; i suppose, along with Idlib, we can have a non-unit test binary that is executed after the unit tests spitting out some useful system information
this is btw the last non-portable mess in egolib ... once this is done, Idlib: Game Engine SDL integration can start
@/all the "ways" the Egoboo processs discovers its data is changed. The old way is that a heuristic in the code tries to find it. The new way will rely on the fact that there is - on any reasonable system - a configuration directory. When Egoboo is installed, the path to the data is encoded there in configuration file(s). This is a more modern and reliable and cross-platform way to deal with data discovery.