Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
Michael Heilmann
@michaelheilmann
you can't just rename some file in some subproject in some folder just to resolve a linker error somewhere way above
...
idlib/parsing_expressions/header.in"
this include is plain right wrong
these are freaking files internal to the library and are not meant to be used by some kind of unit-test project
Michael Heilmann
@michaelheilmann
-#include "egolib/Tests/Math/MathTestUtilities.hpp" the include schemas are there for a reason
Michael Heilmann
@michaelheilmann
@Zefz linker error due to cyclic dependencies; you need to move everything from game into egolib i think i told you already
JohanJansen
@Zefz
The name collision is a technical limitation of cmake's file globbing feature (one of the reasons they recommend adding and managing all files manually instead of auto globbing everything)
Michael Heilmann
@michaelheilmann
@Zefz never had this problem; the paths are unique
Michael Heilmann
@michaelheilmann
@Zefz seriously just move the code as i started out on master please
Michael Heilmann
@michaelheilmann
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
JohanJansen
@Zefz
@michaelheilmann
Fine, I don't need this. The only reason I can find time to contribute to Egoboo is when it is fun. This is not. I leave it to you to not merge #359 or even delete the PR if it so bad. Good luck with future development.
Michael Heilmann
@michaelheilmann
@Zefz In the light of your current contribution and your current development practices - I am not sure if that is a bad thing. Good luck to you as well.
Michael Heilmann
@michaelheilmann
@/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).
Michael Heilmann
@michaelheilmann
@/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
Michael Heilmann
@michaelheilmann
@/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 :(
Michael Heilmann
@michaelheilmann
@/all shouldn't be a surprise that SDL fucked up its CMake system
Michael Heilmann
@michaelheilmann
@/all i think i will just upload prebuild binaries, i am fed-up with this clusterfuck SDL project; these subprojects like SDL mixer do not even provide CMake build files
Michael Heilmann
@michaelheilmann
all right egoboo was built successfully using cmake visual studio and cygwin
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
Michael Heilmann
@michaelheilmann
id::semantic_cast<Vector2f>(getPosition())
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*/ }
Michael Heilmann
@michaelheilmann
id::pi_over<float,4>()
egoboo/egoboo#361
so far 2200 lines of code removed
Michael Heilmann
@michaelheilmann
as you see there are only 3 types of commits; one for the CI (as this is changing until CMake works), one for math, and one for the rest, i keep it that way until the PR is ready
Michael Heilmann
@michaelheilmann
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
Michael Heilmann
@michaelheilmann
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
Michael Heilmann
@michaelheilmann
for the updated reference to idlib: id::c contains now code, that was distributed all around idlib, that pertains to the various "languages" Egoboo uses.
c does not stand for C or C++ but rather compiler
Michael Heilmann
@michaelheilmann
ok we have a working console now, Console::get().ExecuteCommand.subscribe([](std::string command) { ... })
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
Michael Heilmann
@michaelheilmann
roughly 6000 LoC remove
Michael Heilmann
@michaelheilmann
now, we are going to remove most of the technical code from egolib moving it into "engine"
this project will be built with CMake as well
Michael Heilmann
@michaelheilmann
the most important difference to idlib is: this will has to compile with SDL support