Segfault during font loading with `TCOD_sys_check_magic_number`. about libtcod HOT 22 CLOSED

It works!!!

from libtcod.

Seems to be the relevant code here, assuming 1.15.0:

The traceback implies that rwops->read fails, then the rwops->close(rwops) afterwards crashes. I don't think this should be possible according to the SDL docs.

This code is a mess, but it looks correct and I haven't had anyone else have an issue like this until now.

Knowing SDL_GetError() after the error of rwops->read would be nice. Can you step through the code with GDB to verify that it crashes here? Which version of SDL are you using?

from libtcod.

The top item in the traceback being 0x0000000000000000 is also a strong indication that rwops->close or one of the other callbacks was NULL when it was called.

from libtcod.

SDL_GetError says "Error writing to datastream"

I strongly suspect that threads is what causes this problem. I've eleminated all threads in my project, but they still exist in tcod.

Are there any way to build tcod without threads (just to check the idea at least)?

Do you need the code I am trying to build? I can give you a link and build instructions... This should be easy for debian-based linuxes at least...

cmake reports SDL 1.2.15 while finding it.

This confuses me a bit now... because tcod needs sdl2 as far as I understand... using wrong call might bring strange problems too...

from libtcod.

Error writing to datastream

Wow, that should really be an error about reading. Any chance you've somehow mixed up the SDL 1 and 2 headers? Maybe by including them both?

from libtcod.

Threads can be disabled with CMake by setting CMAKE_DISABLE_FIND_PACKAGE_Threads=1 or LIBTCOD_THREADS=OFF. They're also disabled by default if you're using Vcpkg. However, I don't think threads are affecting this part of the code.

from libtcod.

CMake reporting SDL 1.2.15 sounds really bad if it's a later version of libtcod, but I'd expect compile and linking errors if SDL2 was missing. I wouldn't expect it to compile then crash at runtime.

from libtcod.

If you were to get a RWOps struct from SDL1, then call the read function on it from the SDL2 headers, then this would mistakenly call the write function since SDL2 shifted all the struct attributes downward. This could be the steps to reproduce the "Error writing to datastream" error.

I recommend that you uninstall SDL1 before continuing.

from libtcod.

I am working on it now.

but I'd expect compile and linking errors if SDL2 was missing. I wouldn't expect it to compile then crash at runtime.

Dynamic linking is tricky thing. libtcod links sdl2, project I build links sdl1. project's dynamic linking overrides functions from libctod's bynamic linking... You just can't have sdl and sdl2 linked to the same project in the same time...

from libtcod.

This would take a while.... project's code have some SDL related code too (I hope not much). I will have to port it.

But I think your guess it right, and we are on the right way. So, thank you in advance...

from libtcod.

@HexDecimal while porting, I came to the point where I need current SDL_Window. Need it to do
SDL_ConvertSurfaceFormat(temp, SDL_GetWindowPixelFormat(window), 0) instead of SDL_DisplayFormat(temp)

I've found it in libtcod_int.h, but it seems to be in readonly section or something

/usr/bin/ld: CMakeFiles/goblin-camp.dir/Goblin_Camp/src/tileRenderer/sdl/SDLTilesetRenderer.cpp.o: warning: relocation against `window' in read-only section `.text'
/usr/bin/ld: CMakeFiles/goblin-camp.dir/Goblin_Camp/src/tileRenderer/sdl/SDLTilesetRenderer.cpp.o: in function `SDLTilesetRenderer::SDLTilesetRenderer(int, int, TCODConsole*)':
SDLTilesetRenderer.cpp:(.text+0x308): undefined reference to `window'
/usr/bin/ld: warning: creating DT_TEXTREL in a PIE

Are there global SDL_Window var for the whole ctod-based program? How do I access it?

from libtcod.

One of the few things actually documented is how to port over to new versions of libtcod.

Are there global SDL_Window var for the whole ctod-based program? How do I access it?

Explained more or less in the Window manipulation section. If you're not using contexts yet you can get the internal variables using TCOD_sys_get_internal_context.

TCOD_console_init_root(80, 25, "Window title", false, TCOD_RENDERER_OPENGL2);  // Deprecated.
TCOD_Context* context = TCOD_sys_get_internal_context();
SDL_Window* sdl_window = context->get_sdl_window();

from libtcod.

I managed to pass this milestone... Thought older libctods (including 1.16.0 .. 1.18.0) does not have TCOD_sys_get_internal_context... For now I hacked it into it.
Now I have some parser issue. But I will try to explore it myself first

from libtcod.

The libtcod parser must have broke a long time ago. I have to deal with that every time I try to revive one of the older main libtcod projects. I don't really touch the parser since string handing in C is a huge pain, it wasn't blocking any projects yet, and I'd rather just move everything to JSON or TOML.

If you made to 1.6.7 then you can jump to the most recent versions of libtcod. I kept things more stable than the previous maintainers.

from libtcod.

So your suggestion is to move it all to json? Or there might be simple ways to make parser work?

from libtcod.

Fixing libtcod should be possible if I actually looked at it, and it should be easier now since I've gotten more familiar with libtcod and C in general. The issues I remember with the parser were things along the lines of libtcod thinking that color is a name rather than a type. At the time I didn't make issues as I encountered problems so by now I've forgotten about them.

Libtcod has a lot of poorly made tools when far better tools exist outside of the library. The zip tool makes files that are platform dependent, the parser is more complicated and less powerful than more generic libraries, there's a set of threading and timing functions which SDL easily replicates.

from libtcod.

It reports an error
error in /usr/local/share/games/goblin-camp/lib/gcamp_core/items.dat line 452 : Parser::parseEntity : identifier expected

I prepare the code, so you can chek it out and try, and give you a link

from libtcod.

I found the commit with my old workarounds libtcod/thecave@6db78c3. You'd have stuff like color=#000000 or char='@' and the parser would think color and char were types and not identifiers, and this is old code so it was showing a clear regression here.

from libtcod.

OMG!

I even had this solution before: https://gitlab.com/dhyannataraj/goblin-camp/-/commit/758f9ccf908d72f98711cd864f73f9b21716a4e0 (It is another effort to run that old code)

But I never understand the purpose of this commit...

Thanks!

from libtcod.

And Last question (I hope) in this coding cicle.

I need 2x size tileset (resizing treminal.png will do the trick). Where should I start? (I tried to update my current terminal.png, but it did not change anything that time)

from libtcod.

tile_size = (screen_size / console_size) Changing the tile size without changing the console or screen resolution would've just scaled the tiles back to the original size. So you should simply double the resolution of the screen and maybe enable integer_scaling if you're using contexts. If you're not using the latest version of libtcod yet then you might want to hint SDL to use the 'nearest' filter.

from libtcod.

Closing this since the main topic was resolved. You can use the discussions tab if you have more general questions.

from libtcod.