-
-
Notifications
You must be signed in to change notification settings - Fork 60
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Adapting new code to the old functions that didn't use "context" (ImGui integration) #97
Comments
The reason you're having such a hard time backporting this to the old API is because it's impossible with the old API. While the new contexts have an unofficial way to separate the rendering process from a screen update which is required for ImGUI the older rendering system had no method of doing this at all. The good news is that even if you're not officially using the new API, the new contexts are still being used under the hood. You should be able to access the internal context used by the old API via |
An example would be helpful because while it compiles, the linker gives an error: This is where we began discussing the whole thing, if more information might be useful: |
If I had to guess. GCC is enforcing visibility rules for I can add a public function to return the context this way. How are you compiling libtcod right now? |
This time I used vcpkg under msys2/mingw64. Using these instructions: And then: |
|
Well, I need examples. I cannot figure this stuff on my own without a lot more detail. I said many times I'm not an expert. |
Sorry for that. I think you can replace the context specific functions with older API functions like this: bool renderer_accumulate_context(TCOD_Console* console) {
int window_width;
int window_height;
SDL_GL_GetDrawableSize(TCOD_sys_get_sdl_window(), &window_width,
&window_height);
glViewport(0, 0, window_width, window_height);
glClearColor((float)DEFAULT_VIEWPORT.clear_color.r / 255.0f,
(float)DEFAULT_VIEWPORT.clear_color.g / 255.0f,
(float)DEFAULT_VIEWPORT.clear_color.b / 255.0f,
(float)DEFAULT_VIEWPORT.clear_color.a / 255.0f);
glClear(GL_COLOR_BUFFER_BIT);
int err = TCOD_sys_accumulate_console(console);
if (err != TCOD_E_OK) {
fprintf(stderr, "Accumulate error: %s\n", TCOD_get_error());
return false;
}
return true;
}
void renderer_present() {
SDL_GL_SwapWindow(TCOD_sys_get_sdl_window());
} |
Yes, that makes sense... But I still have problems with the syntax because with the old code I don't create a console manually. All I use is |
Contexts don't like to given the root console. You can make a console with the same size as the root console, blit to it then pass the pointer to the new console into the function. It should be something like this: TCODConsole clone(TCODConsole::root->getWidth(), TCODConsole::root->getHeight());
TCODConsole::blit(TCODConsole::root, 0, 0, 0, 0, &clone, 0, 0);
renderer_accumulate_context(clone.get_data()); If you want something like a root console with contexts then it's recommended to make your own global console variable. |
That said. |
So yes, I was getting a weird problem because once again there are different APIs, it seems. I set up Your example works, but I had to include Now I have more problems because of course this function doesn't use the timings that are built in with "flush", so the program goes as fast as it can and uses up all CPU it can get... But I guess I'll try to figure out the rest. I really need to break down all of the flush command to preserve all it did. (is there anything else that the "flush" does beside timings? Event related or something? Maybe more things depend on that to work, and will stop working if I use that custom function?) |
There's an unreleased tcod::Timer class being developed which will handle timing without relying on the old API. Until then you'll have to use SDL_Delay and SDL_GetTicks yourself to handle timing. The simplest way to conserve resource usage would be to enable VSync. For the old API you can force it on by setting the environment variable |
Since you're using MinGW you probably only need to know about setenv. setenv("TCOD_VSYNC", "1", 0); // Before calling TCODConsole::initRoot. |
My hope was to look up again the code of "flush" and take from there the part about timings? Wouldn't it work? The problem with vsync is that the faster the refresh, the faster the "movement" in the roguelike. I prefer keep a fixed screen update to have things consistent. How deep goes the rabbit hole if I tried to update the code? Right now I use: It's a big png, but the big deal is that I use multiple "fonts" of varied grids, created by assembiling two or four basic cells. So libtcod encodes a standard 8x8 font, but then I use
Is there support to all of this under the new API? Can I create a The fact that the documentation is sparse and lacking example isn't helping, but the problem is I'd need examples to convert the old code across all these changes, and I don't think this sort of documentation/tutorial exists. I wonder if I should just stay on the old version of the library since I'm just adding more and more overhead to all of this. |
The timing code for the old API is here: libtcod/src/libtcod/sys_sdl_c.c Lines 319 to 350 in f263e29
Where TCOD_sys_sleep_milli is just SDL_Delay and TCOD_sys_elapsed_milli is just SDL_GetTicks .You can find min_frame_length in TCOD_sys_set_fps :libtcod/src/libtcod/sys_sdl_c.c Lines 1224 to 1229 in f263e29
Not if your code uses delta time, then VSync just makes sure you don't render a frame which won't be seen by the player.
Pretty deep I assume. I've just now started to really get into refactoring the C++ API so functions are being developed right now to fit your needs rather than them already existing for me to explain them. It makes things harder if you're not using libtcod from the develop branch like in this template. If you were you could mess around with the new
Please use the Private Use Areas for custom glyphs.
Column-major tilesets were deprecated and the new API doesn't support them. This won't be a problem if you've already been manually mapping them, and it's easy to remap all the
Whatever you're doing in C++ can be recreated with the C API, which will be more forward compatible with how new API is being developed. While you can reassign the codepoints afterwards. The idea of
One doesn't exist, and making inline code examples is something I've just figured out how to do with the new documentation generator. Right now I'm trying to update the samples with the new API. I should be able to make examples for you if you have anything specific you want to know, |
I missed this edit until now. It's not really just "flush" that does a lot special stuff, but the giant global singleton hidden behind "initializing the root console". The new context system removes the singleton and disables anything depending on it. The functions which would break were cataloged in the Python-tcod docs here in the note, which should give you an idea of which C/C++ functions will also break. |
I found someone on the reddit roguelike that was able to integrate ImGui with libtcod, that was one of the things I was really hoping someone would solve, since I have very low technical skills and couldn't realistically figure it out on my own.
Now the problem is that all his code is made for the new version of libtcod, and it all relies on "context" passed as argument to a bunch of functions.
I have no "context" in my code, and due to my lack of skill, custom fonts and everything, I don't want (and cannot) rewrite the whole thing from scratch.
I'm trying to figure out some solution.
What we're trying to do is separate the
accumulate_context
andrenderer_present
in order to plug the ImGui own stuff so that it can be drawn on top before the screen is updated.Problem is, again, that all my code is set up with
TCODConsole::flush();
whereas his code is all aboutTCOD_context_present
that is always dependent on a "context" passed as an argument, that I instead don't have in my code.I've tried on my own despite the lack of skill to look up the code and see if I could manually split that flush command. But I got completely lost. The reference seems to start in
console_.cpp
and it seems to redirect to aTCOD_console_flush
which seems to be defined insideconsole_etc.c
, here AGAIN it is redirected to aTCOD_console_flush_ex
. But inside this function another one is calledTCOD_context_present
... that once again uses a "context" of an internal type, defined mysteriously.So even the standard, old "flush" function seems to be dependent on a "context", but this context isn't the one explicitly built in the user program with the standard initializations, but seems to be internally defined in some obscure way.
I'm completely stuck here, and probably all I wrote is already all wrong guesswork.
The code I'm trying to use is this:
In between these two functions there's ImGui render code, but that part works. I need some way to REPLACE my
TCODConsole::flush();
with those two functions I've pasted here. Problem is: I have no goddamned CONTEXT anywhere.I need to pass this thing a context, but there's no context in the old library code. Is there a way to pass some sort of fast conversion that grabs my current stuff and creates a context on the fly I can use? How the hell can the flush function USE A CONTEXT if a context is nowhere to be found in the old code?
Sorry for the frustration, but I spent already many, MANY hours trying to figure this out, and the new library standards redoing all the core functions wasn't something that helped...
The text was updated successfully, but these errors were encountered: