amigaos4 port
kas1e opened this issue · 119 comments
Howdy ! Its me :)
So, to make amigaos4 version possible need to add those changes:
- src/backtrace.c
replace all #ifndef _WIN32 (in 1 place) and #ifndef WIN32 (in 5 places) , on #if !defined(_WIN32) && !defined(__amigaos4__)
- src/main.h
at top change as for Pandora to use float instead of double:
#ifdef __amigaos4__
#undef Double
#define Double float
#endif
and get rid of "#error KO":
#ifdef NEON
#include <arm_neon.h>
#else
#ifndef __amigaos4__
#error KO
#endif
#endif
- src/time_util.h
line 72 : #if 1 change on #if 0 for amigaos4
line 103: #if 1 change on #if 0 for amigaos4
- src/term.c
replace all #ifndef _WIN32 on #if !defined(_WIN32) && !defined(__amigaos4__)
- src/main.c
at moment comment out execve():
#ifndef __amigaos4__
#ifdef _WIN32
execve(executable, (const char *const *) args, 0);
#else
execve(executable, (char *const *) args, 0);
#endif
#endif
And that all. + changes in makefiles , but that can go for latter (i can create just makefile.os4 and makefile_os4.ramdisk).
Now, when i run game, i have as usuall for big-endian inverted colors. As well, as menu didn't draws (or just can't be seen) and character at left also can't be seen.
There is screenshot of menu:
http://kas1e.mikendezign.com/aos4/gl4es/games/gorynlich/gorynlich_1.jpg
Then, i check how it all loads, and find out that its load_image() from tex.c. And that one for sure have ENDIAN checks. So, for sake of tests, i comment out big-endian ifdefs in that functinos, and wtf , colors start to be right ! Check this out:
http://kas1e.mikendezign.com/aos4/gl4es/games/gorynlich/gorynlich_2.jpg
Through, menu not visibly still, and no character visibly at left bottom of screen.
And strange, why removing of endian ifdefs make colors be better , but not in other way :)
Music plays fine btw , etc. And clicking on any area where is menu for play game, in 90% of times cause
DYING: Died at util.c:myzalloc_():21
FATAL ERROR : No memory(1 384 241 048) , map_jigsaw.c:generate_level():3099
But that probabaly also same endian issues there .. But if it for real want 1.3gb to alloc, then that probably will fail for sure..
And some more things to add:
- in src/stb_image.c add
#include <string.h>, to avoid warnings about memset. That one probabaly can be added for all platforms, not amigaos4 ifdefed. - there is makefile for amigaos4:
http://kas1e.mikendezign.com/aos4/gl4es/games/gorynlich/Makefile.aos4
Interesting that there is that stb_image.c file at all, if i remember right, we have some issues with back in past (with prototype?) , or it was something else ..
Also what make me curious, we have in main makefile include of both Makefile.ramdisk.deps and Makefile.ramdisk, but none of them is used , so maybe we can just delete them ?
Oh, i found ! Its indeed want to alloc 1.3gb by default seems so ?
I just add the same change as you do on Pandor inside of map_jigsaw.h , i.e.:
#if defined(NEON) || defined(__amigaos4__)
#define JIGPIECE_MAX 10000
#else
#define JIGPIECE_MAX 20000
#endif
And levels can be starts more offten. Through one time when i die, i have the same error again, just this time it wasn't 1.3gb , but 692 mb. Which is probabaly also too much to allow for me, so maybe set it to 5000 will be the safe side ? Or even 1000 so to be 100% safe. If of course, it not cause some impact on something very important.
Also offten i have now another error when about to start a level (after i set it to 10000) :
DYING: Died at map_jigsaw.c:dieat():278
FATAL ERROR: Died at line 1982, col 0: expecting start of line
But when i was still able start level, it looks like this:
http://kas1e.mikendezign.com/aos4/gl4es/games/gorynlich/gorynlich_3.jpg
(that with commented out SDL_ENDIAN check in the load_image() from tex.c).
Seems everything renders more or less fine, just no Text (same as in menu), and probabaly some textures missing still (same as in menu, where i miss that character at left).
Ah, I had forgot to activate the "Watch" feature on this repo, and I hadn't been notified you openned a ticket.
Lot's of stuff here, interresting. I'll look deeper tomorrow.
(also, why the BigEndian was not needed: probably because the glTexture created with the data is also bigendian ready, so no need to swap bytes 2 times).
Tring to check in meantime why fonts didn't renders, so as i can see , src/ttf.c is handle it all, and maybe something with Endianes there. It didn't have any fread() or fwrite(), but it did have some structures there and there. For example "glyph" structure are full of "doubles" , "glyphtex" structure have one int32 (for texture exactly, so maybe that one need to be converted). Will check it more
Maybe the texture built with / for the glyph is inverted, and alpha end's up beeing empty? I have to check all this code, but I haven't yet.
Have some more news about : i just enable in config file ENABLE_GENERATE_TTF define (that used in the font.c and ttf.c files), and then, font start renders !
http://kas1e.mikendezign.com/aos4/gl4es/games/gorynlich/gorynlich_4.jpg
It is through seems on running always generate something a little, but fonts and lettrs now visibly. Dunno if it point out us on something related to the how to make it works without ENABLE_GENERATE_TTF define ? Probabaly it point out us only on the fact that fonts loads fine, etc, just didn't visibly. Like, fonts coming as data files are big-endian or something with alpha in them ..
Through, that didn't fix issue with non-drawing character in menu at left-bottom, and in the intro there is no background too (that probabaly same issue in both cases).
But what at moment is not that good, is FPS ! It just suck :)
On my windows machine, i have in menu : 300 fps, on amigaos4 have 150fps in meanu : ok, kind of expected. But in the game itself, when do "quick start", then on windows machine i have ~160 fps, but on amigaos4 just a 25-35 fps only ! Was expected to have at least 60, or 80, but 25-35 :(
I tried LIBGL_BATCH 40, but that make no differences (even make it a little slower)
There is screenshot from gamesplay when there is no enimies, almost nothing to render, and it's 36 fps :) :
http://kas1e.mikendezign.com/aos4/gl4es/games/gorynlich/gorynlich_5.jpg
I also think that something is wrong with 2d blitting in some functions (or just in general in aos4 driver, or, which unluckyly, gl4es ). Why i think is it , its because i notice already in few games, that some operations which is pure "Scrolling" are slow. I can't say when exactly, but at least in the Foobillard++ , when you press on gadget for drop-down menus, those menus moves pretty slow.
Same with Logo of Gorynlich in the menu : it scrolls not very smooth. Dunno what can be cause of it and how to debug it .. But that probabaly for the latter.
Mmm, now that have used ENABLE_GENERATE_TTF, I think you have generated new tga with font. So I guess the endianness is fixed. Do some git status to see if some tga have changed.
A note about FPS. I do have slow speed on the Pandora too. I checked to see if it was the Graphics, but it doesn't seems so. I think it's more CPU constraint. I'm unsure, but that was my quick analysis shown.
Mmm, now that have used ENABLE_GENERATE_TTF, I think you have generated new tga with font. So I guess the endianness is fixed. Do some git status to see if some tga have changed.
Yeah you are right. I didn't compare files through, i just rebuild gorynlich with disabled generation of ttf (but keep those font tgas which was generated), and then it runs fine and font there. So, it mean that tga files can be of different endian type ?
That probabaly mean, that i need somehow to convert other tga files to big-endian ones (like background in the intro , that characters at the left-bottom screen, etc). Strange through, that logo, and chest , and some other thigs draws as it , while all the data files are .tga..
It would be better to fix the reading. The function is ttf_read_tga from src/ttf.c I haven't seen what could go wrong in a quick look, but there must be something there.
Mmmm, in fact, I think line 686, the memcpy(f->glyphs, glyph_data, sizeof(f->glyphs)); : that f->glyphs needs to be byteswapped !
What i also noticed, is that in the every message in the "intro" , the last letter always missing. Maybe that cause of some memory issues (and as usuall visibly on amigaos4 better), and that the reassons why there is no background in intro, and in menu i didn't have those characters at left-bottom.
Interestingly, is that if i choice "play game", and start move up/down keys, i actually can see how characters appears to be visibly there when they scrolls to the right side, and then should shown on the left side with small scroll : but that didn't happens. I.e. i press let's say there "down", and can see how character scrolls to the right side, then, it should scrolls a bit from the left side and stop : but that didn't happens. I can't see scroll from the left side.
I also found that i can see last character "wizzard" be visibly. But that one appears like this: scrolls to the right side as should, and then i see no scrolling from the left, and then bum, character shows.
I probabaly vaguely explain it all, can made a video, but it all looks like that reading is fine of those "characters" tgas, just by some reassons they not visibly when should.
Mmmm, in fact, I think line 686, the memcpy(f->glyphs, glyph_data, sizeof(f->glyphs)); : that f->glyphs needs to be byteswapped !
Do you mean something like:
memcpy(f->glyphs, glyph_data, sizeof(f->glyphs));
#ifdef __BIG_ENDIAN__
int r;
for (r = 0; r < sizeof(f->glyphs) / 2; r++)
{
f->glyphs[r] = SDL_SwapLE16(f->glyphs[r]);
}
#endif
?
Yes, but no. glyph is a large stucture, full of double...
So it will be more like:
#ifdef __BIG_ENDIAN__
int r;
for (r = 0; r <= TTF_GLYPH_MAX; r++)
{
f->glyphs[r].width = SwapDouble(f->glyphs[r].width);
f->glyphs[r].height = SwapDouble(f->glyphs[r].height);
f->glyphs[r].minx = SwapDouble(f->glyphs[r].minx);
f->glyphs[r].maxx = SwapDouble(f->glyphs[r].maxx);
f->glyphs[r].miny = SwapDouble(f->glyphs[r].miny);
f->glyphs[r].maxy = SwapDouble(f->glyphs[r].maxy);
f->glyphs[r].advance = SwapDouble(f->glyphs[r].advance);
f->glyphs[r].texMinX = SwapDouble(f->glyphs[r].texMinX);
f->glyphs[r].texMaxX = SwapDouble(f->glyphs[r].texMaxX);
f->glyphs[r].texMinY = SwapDouble(f->glyphs[r].texMinY);
f->glyphs[r].texMaxY = SwapDouble(f->glyphs[r].texMaxY);
}
#endif
And before, you need to define SwapDouble, with:
static double SwapDouble(double a)
{
Uint64 r = SDL_SwapLE64(*(Uint64*)&a);
return *(double*)&r;
}
Oh, you mean to byteswap whole strucutre, yeah, that did the trick ! now text renders with fonts coming by default in data archive from repo.
Through last letter still missing in all the test in the intro, same as if i use auto-generated big-endian fonts.
I.e. on win32 firt phrase in intro:
"For millenia, the dwarfes of old"
on my build it
"For millenia, the dwarfes of ol" (last "d" missing). And the same for all other phrases in intro.
Is on pandora you have first phrase in intro with last "d" at end, or it missing as well ? It can be very well some buffers-issues in the game itself
Also at right-bottom we should have goblinhack@gmail.com, -- version 0.0.6, and i found that string in the wid_intro.c :
static void wid_version_make_visible (void *context)
{
widp w = wid_popup(
"%%fg=green$goblinhack@gmail.com, -- version 0.0.6",
"", /* title */
0.8f, 0.95f, /* x,y postition in percent */
0, /* title font */
vsmall_font, /* body font */
0, /* button font */
0); /* number args */
wid_set_no_shape(w);
wid_destroy_in(w, 60000);
}
But that "6" at end also didn't visibly. And for me it looks like goblinhack@gmail.com, -- version 0.0. on title screen (i.e. no 6). Is on Pandora it visibly ?
I don't remember. I'll have to check on the Pandora tonight if I have the same issue. Also, I'll try to build vanilla version of Gorynlich on linux to see how it behave (just in case my numerous changes broke something)
Yeah, thanks a bunch ! I also found that my cursor is "blue" instead of "yellow", but that easy probabaly to remove somewhere same SDL_ENDIAN check as it was for main titles before.
Yeah, removing all #if SDL_BYTEORDER == SDL_BIG_ENDIAN code in the src/tex.c , make not only colors be fine in title screen, but also make cursor be yellow instead of blue, as should be.
Btw, is levels always generated even if there is levels directory ? What i mean, is that once i do for example "Quick Start" it's in 90% of times saying:
00:00:33.851: Client: Level 1.1[0x200b9008] (client): created
00:00:33.955: Server: Level 1.1[0x1fb49008] (server): created
00:00:33.957: Server: Level 1.1[0x1fb49008] (server): Level generating
00:00:35.627: DYING: Died at map_jigsaw.c:dieat():278
00:00:35.628: FATAL ERROR: Died at line 1982, col 0: expecting start of line
00:00:35.630: ERROR: FATAL ERROR: Died at line 1982, col 0: expecting start of line
00:00:35.630: ERROR: FATAL ERROR: Died at line 1982, col 0: expecting start of line
00:00:35.729: Client: Level 1.1[0x200b9008] (client): destroy
00:00:35.730: Client: Level 1.1[0x200b9008] (client): destroyed
exit(1) error
LIBGL: OGLES2 Library and Interface closed
LIBGL: Shuting down
While "data/levels" have all of them already there.
Strange .. Maybe its the same effect of bug with missing characters at end ..
Yes, levels re always generated. If I remember correctly, the data/levels folder contain "blocks" of level, that are then used by the level generator to build actual levels.
On the Pandora, it doesn't die (not that I remember of), but I do need a quite large swapfile (like 1,3 GB of RAM used during level generation, or something like that).
On amigaos4 we have some sort of "extendent memory" , kind of it was in old DOS when they used chunky memory . I.e. by default i have free about 1.8gb (because of 31 bit addressing) , but can use some specific code to have more (probabaly need to write own malloc(), etc, but it will be fits pretty well in the game where he already have myalloc() ).. So in worse scenario, i can use that.
Just this error didn't looks like memory error, when its can't allocate, it usually says something like can't allocate and die in myalloc(). But once i replace in map_jigsaw.h JIGPIECE_MAX to 10000 (as it done for Pandora), i almost never meet with that malloc error, but instead with that one. And line 1982 in that map_jigsaw.c are:
dg->frag_alt[dir][c].c[JIGPIECE_WIDTH - 1 - y][x] = dg->frag_alt[dir-1][c].c[x][y];
Which didnt' looks like problem with malloc , but more like it can't find something which should find.. And comment at top of block from where that line, saying that it just for "Rotate 90 degrees".
There is, maybe, some bigendian issue with level "basic block" loading, leading to this error...
Yeah, i rechecked, and yes, when i have no memory, i just have something like this:
00:00:40.207: Client: Level 9.9[0x17c760c8] (client): level loaded
00:00:46.496: DYING: Died at util.c:myzalloc_():21
00:00:46.498: FATAL ERROR: No memory(121900776), wid_editor.c:wid_editor():4051
00:00:46.499: ERROR: FATAL ERROR: No memory(121900776), wid_editor.c:wid_editor():4051
So its probably indeed something with endianes there, as lots of [] [] and stuff used. Through, when it level loads (that happens sometime still), all other parts looks correct : enemies, move, main character, fonts, textures, etc ,etc.
And i just tried to comment out that block about "Rotate 90 degres" , and now it start bring again not-enough-memory errors :)
So probabaly in terms of that bug i need firstly implement extendent memory support then..
stuff like that: https://github.com/ptitSeb/gorynlich/blob/master/src/map_jigsaw.c#L3118 probably need some byte reordering... To be checked later.
Interesting why he (author) choice that unusuall way to do things, i mean, i never ever thinking about malloc 1.6gb, or 2gb at one push. And, what is more funny, is not the kind of game which need that much. Visually it dind't looks that impressive, mostly like some oldshcool game from amiga era. Strange why and for what all those resourses wastes..
edit: it seems that "Read jigpiece header" may have issue. At least, "expecting start of line" words i found right at top of part about reading jigpiece header. Or maybe memory can't allocated, and so he fail only there .. But from another side i can see that memory checked, and if can't be allocated there should be error about.
Oh, and actually what is interesting : is not always generate levels ! It seems it use generated ones, just dunno why sometime are, sometime not.
For example, now was succefull running, and it didn't eat much memory, and that what i have in output:
00:00:20.322:
00:00:20.324: Welcome to the Gorynlich console!
00:00:20.326:
00:00:20.328: Press <tab> to complete commands.
00:00:20.329: Press ? to show command options.
00:00:31.642: Client: Level 1.3[0x4b1ca008] (client): created
00:00:31.985: Server: Level 1.3[0x4ac49008] (server): created
00:00:31.988: Server: Level 1.3[0x4ac49008] (server): Level Work:games/gorynlich/data/levels/1.3: loading
00:00:32.447: Server: Level 1.3[0x4ac49008] (server): Reset players at start of level
00:00:32.449: Server: Level 1.3[0x4ac49008] (server): level loaded
00:00:32.451: Server: Level 1.3[0x4ac49008] (server): Allocate trigger, white
00:00:32.453: Server: Level 1.3[0x4ac49008] (server): No action trigger exists, activate trigger, white
00:00:32.456: Server: Level 1.3[0x4ac49008] (server): Activate trigger, white
00:01:08.025: Client: Level 1.3[0x4b1ca008] (client): destroy
00:01:08.027: Client: Level 1.3[0x4b1ca008] (client): destroyed
00:01:09.831: Server: Level 1.3[0x4ac49008] (server): destroy things and players
00:01:09.860: Server: Level 1.3[0x4ac49008] (server): destroy
00:01:09.861: Server: Level 1.3[0x4ac49008] (server): destroyed
Exited
LIBGL: OGLES2 Library and Interface closed
LIBGL: Shuting down
See, it load the stuff, not generate !
Probabaly it possible somehow hardcore setup to only load levels, and never generate (that will be more than enough imho). Also it looks like they already generated, just by some reassons regeneration starts again ..
At least that how i see it now
..
Gorynlich use fixed pipeline only, no shaders.
I'll try to check all this generation / level loading stuff.
Thanks !
Yeah, i just rechecked : there is just few shaders created (very simple ones) by gl4es, so to have just 2d working. Also i made a profile of it and at least in the intro and menu, it use only glDrawArrays() for drawing
So. I'm back home and done a quick test on the Pandora.
-
I also have the missing last letter issue ?!
I'll investigate on what is happening ! -
On the Pandora, I can use GLES 1.1 or GLES 2.0 backend. Gorynlich seems significantly faster with GLES 1.1 backend. I have to investigate also to see if it's normal or not.
I built my version of gorynlich on a linux and ran it without gl4es: same missing last character... So at least it's not gl4es.
I'll now try with original version of Gorynlich.
And I built the original, and the error is there too! So it's not my port either!
And I found the issue of the last character missing and just pushed a fix
And I pushed all the AmigaOS4 changes also.
Yeah, it is !
Now, there is video how it looks like on my side:
https://youtu.be/DC50C_sXsxY
There you can see those issues :
- no background images in intro
- no character at left-bottom in the main menu
- when press "play game" and do switch between menus, the only visibly right-scroll of characters, without left one, and in end no characters shown, except only wizzard one.
Can you check how it all on Pandora in that terms ?
I built my version of gorynlich on a linux and ran it without gl4es
Btw, how in terms of fps when you build it over linux with and without gl4es on the same machine ?
Gorynlich seems significantly faster with GLES 1.1 backend.
How it in terms of fps ? I.e. for example in menu, and in any level. Like GLES2 give 15 fps, and GLES1 50 or something ?
I built my version of gorynlich on a linux and ran it without gl4es
Btw, how in terms of fps when you build it over linux with and without gl4es on the same machine ?
Gorynlich seems significantly faster with GLES 1.1 backend.
How it in terms of fps ? I.e. for example in menu, and in any level. Like GLES2 give 15 fps, and GLES1 50 or something ?
I haven't done any measurement of speed yet. Let's have something that work first, and I woul dlike to try reduce the memory needed also before.
Yeah, it is !
Now, there is video how it looks like on my side:
https://youtu.be/DC50C_sXsxYThere you can see those issues :
- no background images in intro
- no character at left-bottom in the main menu
- when press "play game" and do switch between menus, the only visibly right-scroll of characters, without left one, and in end no characters shown, except only wizzard one.
Can you check how it all on Pandora in that terms ?
Everything works as it should. No problem on the Pandora.
Everything works as it should. No problem on the Pandora.
Interesting that for all of them used the same texture loading function.. With missing background in intro it can be probably something with transparency, but strange effect of those "no left-scroll visibly"
I watch closer in intro, and i can see, that for a second, image appears to be visibly, and then black. Every new portion of intro (with new intro's background) always show a image for a second, and then black screen.
So imgae is loaded and then a black something is put on top? Maybe an issue with some fade-out effect? I'll check later.
It looks like it even didn't reach full alpha of 1 , its like fade in effect starts, and reach maybe half of it (or , it may reach till final, just disappear fast), but what i can notice, is that around 50% of fade in effect happens for half of second, and then all black. Will check maybe fade in effect have something in terms of alpha change
Btw, found in meantime, that game do not free resources correctly even if you just run it (till menu) and then exit from menu without actuall running of game. I checked sdl.c , and it did have :
SDL_GL_DeleteContext(context);
SDL_DestroyWindow(window);
So all fine (And i checked via printf that this part is working) and its not that usuall missing part because of which we have non-freed resources, but something else in the code of game itself.
It didn't free big part of the memory (about 130 mb!) , and didn't free about 6 mb of gfx data. Its just when you only run it , and exit from menu right away. I assume, that this non-freed memory can be also issue when we start actual game (like, those 130 mb which can't be freed , can't be used for allocation for the levels).
Can you open a new ticket about the Texture not appearing on amigaos4 port?
I'll have some test for you to make to try figuring out what's wrong, but this issue is already long, I would prefer to do that on a new fresh thread.
Yeah, created, thanks !
Now .. what next , reducing memory usage ? But probabaly its will be not very possible to reduce it 2-3 times ?
From my side i found another bug yesterday, when implemt amigaos4-restart code : when restarting, game didn't close ourself, don't free resources, etc ,etc , it just like rerun another copy, with eating the same gygabytes. Probabaly there need to add cleaning of resources before: like, just full exit from game, and then only call the execute of binary.
Also its still unclear, why sometime levels generated, but sometime just loaded.
Btw, Daniel fix both issues with glScissor(), but if you doesn't mind keep that workaround in gl4es till that fixed version released to public
Yeah no problem, it can stay there, it's behind a ifdef anyway.
Hey folks, thanks for breathing life into this project! you might want to look at zorbash - I switched to working on that this year, it's a very work in progress - but is based on the same code - though I'm trying to move more to c++. I only mention this, if you are looking at bugs, you might want to look there and for comparison. The code is mostly quite different - but some of the common functions will look familiar. I also changed the widget code completely, to be more of a ascii like grid interface, for more of a retro console feel. Anyway, thanks for working on this!
Oh yeah, and none of my stuff uses shaders - I never quite got around to understanding them 8) also for performance, the lighting is usually the culprit - maybe #define MAX_LIGHT_RAYS 360 could be tweaked a bit lower. I seem to recall ENABLE_LARGE_TEXT_OUTLINE was expensive too... As for memory, I can't recall the main culprits.
Howdy :) The main problem there is that its need a lot of memory just to start a level : from 500mb to 1.2 gb just for one level. That currently is only one stop-factor from release for amigaos4 (for Pandora ptitseb use SwapFile for), but i just can't release a port for amigaos4 , where the 2d game want ~1gb of memory , they will cry at me and says that old games take just 1-2 mb, and taking 1gb for just a level generation is too much. And you can't explain them anything about how progressive is it, and how hard levels is , they will keep repeat the same :)
So there we need somehow to reduce maximum memory usage. At least to 300-400mb for any level, that can fit in amigaos4 easy.
I had something in progress to reduce memory footprint (using c++ would also help there, by using std::vector instead of fixed sized array), but it's buggy for now. Hopefully, I'll find that bug soon.
Thanks for the hint for MAX_LIGHT_RAYS, I'll try to experiment later, see if I can fine tune all that.
And I'll give zorbash a try later.
you could try lowering MAP_THINGS_PER_CELL - the risk is that if a lot of explostions happened in the same location it might run out of thing slots at that location. And changing this to a std::vector
typedef struct {
uint8_t count;
uint32_t id[MAP_THINGS_PER_CELL];
} thing_map_cell;
might help - or to a list, or something that isn't 4*128 bytes per map cell!
another hacky idea might be to change double to float in thing.h to save space
JIGPIECE_MAX might also be lowerable a bit, maybe 10000
and I bet MAP_MAX could be changed to 128
you could also lower MAP_WIDTH and HEIGHT - I always felt the levels were too large anyway, as long as they are a multiple of JIGPIECE_WIDTH it should be ok - tho that would mean all of the previously saved levels would fail... I mean if you want to create new levels, then that would be one way to lower the map size and save memory
hth
@ptitSeb
Btw, about high-memory usage, maybe together with lowering all the things goblihack point out us, maybe it possible to use GPU's memory more somehow, so to offload system's memory usage ?
Nope, the memory here is used to construct the level. There is nothing graphical here. I know how to reduce the memory, but for now, I'm focussed on another project, box86, were I've started writing a DynaRec and because it's quite complex, I need to stay focus on that one.
Sorry, I'll go back to that later, but not right now.
Aha got it , no problems of course :) Thanks !
Yo ptitSeb! :) Haven't you tired with box86 ?:) Just asking, maybe you have some interest to go back to that one about reducing memory usage in gorynlich :)
Ha ha... Nope, not tired yet of Box86 ;)
But yeah, I'll try to finish that optimization on gorynlich soon.
@kas1e : I have finaly update the jigsaw maze generator. I think memory consumption will be much lower now!
Oh, good news ! Will try now and report back, thanks! Is it enough now for you do not have a swap file on pandora? (i remember there were needs for 1gb of swap file ?)
I don't know. I always have a 4Gb swap active... And I haven't try to unmount it.
Tried to at least change only those 2 files you touch today, and when tried to do a "quick start", have in console that:
Client: Level 1.5[0x5096c008] (client): created
Client: Level 1.5[0x5096c008] (server): created
Client: Level 1.5[0x5096c008] (server): Level generating
Dying: Died at map_jigsaw.c:dieat():331
FATAL ERROR: Died at line 1982, col 0: expecting start of line
ERROR: FATAL ERROR: Died at line 1982, col 0: expecting start of line
ERROR: FATAL ERROR: Died at line 1982, col 0: expecting start of line
Client: Level 1.5[0x5096c008] (client): destroy
Client: Level 1.5[0x5096c008] (client): destroyed
exit(1) error
Strange error... But I have it even before too. Dunno if it related to memory allocation, or maybe it just some endian related issues?
It's not all the time. It's not very often so difficult to debug on my side. You have it all the time now? How is the memory consumption?
You do have that one too sometime?
Currently, I have it all the time. But probably need to rebuild everything from scratch, maybe there were some tries left of my older tests. But I am sure that error was there at the beginning.
As for memory consumption the only time I can see how much memory it wants it when starting to generate a level, and I can be wrong but it seems now want less memory for sure.
I probably need to rebuild everything from scratch firstly, just to be sure.
Rebuild all the latest sources from scratch, and yeah, the issue still there when I just choose "quick start". Same when I choose "start level". Error always the same.
Through one time, when I hit "quick start", the game actually starts, and take the only 100mb for a level (strange). That was for level 1.3. Then quite from level, start another one: and this time it takes 400mb. Then again quit from level to menu and can see, that memory for sure did not feed when we come back to the menu. So when I tried to start another time, I then hit "no memory" error.
It also seems not freed memory when it exits with that "fatal error: died at line 1982".
When I reboot and tried again, than usual "fatal error: died at line 1982" back :) Weird!
And what is that "line 1982 are".. I mean which file. Because in map_jigsaw.c line 1982 seems empty?
So, I think I have found the issue for the "died at line 1982" error (FYI, the line 1982 is from data/map/jigsaw.map :p )
Bur for the "memory leak", I don't know. I ran a valgrind test on the Pandora: start a game, ganarate a map, quit game... The "leak" was less than 100kb of memory... Nothing like the MB you mentionned.
So, nothing on my side.
Just a note: there is some use of realloc(...)... Is that ok on AmigaOS?
Oh yes, that 1982 bug seems gone!
I.e. when I reboot and run a game, it always starts the levels and does not matter if it "quick start" or "start a game". It does not matter what level, all seems fits now.
But the issue with the memory not freed still there, and I mean not on exit from a game, but when you just exit from generated level back to the menu. I.e. you start a level, then hit "q" and exit to the menu: at this time, all the memory taken by the generation of the level not freed. And when you about to start again another level, it will have a "no memory" error, as too much was taken by the first attempt.
It, of course, can be AmigaOS issue (and probably is it), but just strange even if it realloc/calloc issues, when we exit from the level to the menu, all the generated data should be freed IMHO?
Another interesting issue I found which maybe be related to gl4es: when I run a game, start a level, exit from level, trying to start again (with non freed memory) and have "no memory", then, after that, running of the game always will have a black window (i.e. nothing renders) while whole logic works. Probably when game dies with no memory it tries to write to .gl4es.psa something which causes that effect. Once i delete .gl4es.psa all render again.
About memory: the same issue happens when you for example die and want to replay a level, it then again dies with "no memory" (but then strange, because why it wants to allocate anything, as it already allocated and generated)...
Found that it does not matter how I exit from the game, create .gl4es.psa on the next run always make the game be "all black color", and I need to delete .gl4es.psa.
I found also that if I just change in map_jigsaw.h 10000 on 3000 (so lower a lot), then everything seems to fits into whole 650-700mb of memory for all the time. I.e. I run game, and can as long as I wish to start/exit levels, etc. They all generated/regenerates, but memory always hit 930mb and never less and seems never more. So that ok too.
So for example, I had when system boots: 230 MB ram filled.
When running binary and game start "clorping": 533 MB used.
When the menu show ups: 614 Mb used.
Then play a game with a quick start: 800mb used (but that sometimes more, dunno on what based)
Quit to the menu: nothing changed or freed, the same 800mb used
Then Quick Start: 917 Mb used.
Then quit to the menu : nothing changed or freed, same 917 Mb used.
Then again play a game (this time another one): 917 Mb used
Quit to the menu : 917 Mb used
Start a new game (another level again): 917 Mb used
In other words, in the worst case, I can just for amigaos4 release use smaller #define JIGPIECE_MAX 3000 to deal with memory allocation errors. But something still with memory on exit: when I exit from a game after that, I had 280 Mb filled, and not 230 as I have when start I game (so 50 Mb lost). Maybe something with the latest gl4es? Because as I understand, realloc issues may have an impact in the game itself, while we in, but memory shouldn't be eaten when we exit (right ?)
Also maybe if convert all .tga to something like .jpg, maybe that will reduce memory a lot as well? Has less memory be filled till the menu, also help to have more free memory when the time to generate levels?
And strangely while in the menu I have about 350 fps, in the game itself I have just about 16-25 fps. I think we also need to enable for AmigaOS4 build #define Double float too to speed things up (as currently it only enables for __ARM_NEON__ , maybe it will add some more fps as well. If I remember right, back in time when we first time test the things, you find out that with gles1 driver we had much higher FPS?
Black screen? I don't get it. The .gl4es.psa generated at the end of the game is "corrupted"? I don't have this on the Pandora, maybe you should speak with Daniel about this issue.
Memory, I'll try something, I have seen some protential things that could save some more memory, I have to try.
tga to jpg will probably save nothing, the texture is loaded in graphic memory, so it will be uncrompressed anyway...
About the Speed, yeah, main menu is smooth, because nothing happens there. In game, I have pretty slow speed too. I haven't been able to really pinpoint something that is superslow and needs optimization. I have done a few things here and there, but nothing spectacular. If you find something that is slow, tell me.
Interesting that when we actually play a game, CPU loading never reaches 100%, it always about 85% on me, not more (usually when things want to use resources, CPU busy on 100%)
I don't what to say. I also have pretty low speed, but I don't know were is the bottleneck. If you find it, tell me, and I'll see how to remove it.
About the memory, I have done a last changed that should, again, lower memory. It seems to stay under 512MB for me now (not sure, as the swap is still there, but I haven't logged any swap in maze generation now).
Tested, memory for sure lowered more! Thanks!
Btw, I found that when you exit from the game, it also leaks GPU memory. Not the usual VRAM memory (which is leaked too), but GPU only one where textures uploads. When I start the game, I have 0% of GPU memory-filled, then, when game started, it eats 152 Mb of GPU memory. Now, I didn't go to the level, just exit from the menu right away, and 6MB of GPU memory is leaked.
I, of course, need to check first on the same gl4es / ogles2 other games, if there is such leak or not, just to be sure it is gorynlich (or amigaos4 again because of realloc or something:) )
As for speed, you do have 2-3 times faster speed with gles1, that correct? (just to be sure). But that CPU loading didn't hit 100% may point out on something .. I may try to ask other devs about.
So do those tests in terms of at least GPU memory leaks on exit:
Fricking shark with currently gl4es and with older gl4es which I use before (to see if there something about gl4es): and there on exit I didn't have any GPU memory leak on exit, all back to 0%.
Then tried the latest Gorynlich with older gl4es which I use before, and with last one: with both cases it enough to just run game, wait till menu, and exit from the menu, and we have 6mb of GPU memory leaked on exit. That always reproducible, and the more time you run/exit game, the more +6 leaked Mb you had.
Those tests (IMHO) show us that it's Gorynlich code leak on exit. I can think about missing SDL_ related close calls (and on Pandora garbage collector do clean things), but that probably can't explain GPU leaks? Will check.
Checked sources (sdl.c ) , and there we have that kind of block:
void sdl_fini (void)
{
if (HEADLESS) {
return;
}
FINI_LOG("%s", __FUNCTION__);
SDL_ShowCursor(0);
SDL_ShowCursor(1);
if (sdl_init_video) {
sdl_init_video = 0;
SDL_VideoQuit();
}
#ifdef ENABLE_SDL_WINDOW /* { */
SDL_GL_DeleteContext(context);
SDL_DestroyWindow(window);
#endif /* } */
SDL_Quit();
}
And it is for sure compiles and tested that we surely inside of that last ifdef, so SDL_GL_DeleteContext and SDL_DestroyWindow surely compile. Will check if they called on an exit at all (maybe whole sdl_fini() didn't called ? ). Surely it can be just forgotten free of GPU memory somewhere, just in the hope it will be something like missing call to sdl_fini :)
I checked the code and the free are there. But maybe it was not called, because the game assume globals varibles are initialized to 0 by default (it's true on x86, but not true on ARM or AmigaOS).So I pushed some fixes, maybe it's better now?
Thanks for trying, but nope :( Still the same 6mb of GPU memory-filled after exit. Does it seem that it just missing somewhere in the code maybe? I can see that in the whole when we start till menu, it takes 152mb of GPU memory, and on exit almost all freed, but 6 Mb not. So probably forgotten free of textures somewhere, will try to check, maybe can find out something
This function below should be freeing the GL memory from tex_fini called from exit.
You could also try to enable ENABLE_LEAKCHECK in main.h to see if it catches anything.
You could also try lowering MAX_LIGHT_RAYS to see if that makes it faster.
static void tex_destroy (tex *t)
{
SDL_FreeSurface(t->surface);
GLuint gl_surface_binding;
gl_surface_binding = t->gl_surface_binding;
if (!HEADLESS) {
glDeleteTextures(1, &gl_surface_binding);
}
oldptr(t->surface);
}
@goblinhack
Thanks for suggestions! Reducing MAX_LIGHT_RAYS from 360 to 120 seems didn't change anything (not visually, not in terms of speed). I even tried 30, and nothing. So something else blocks speed. I have just about 18-25 fps maximum. I remember ptitSeb says that on glesv1 hardware it all much faster (in 2 times or something), so maybe issue amount of draw calls or some calls which is heavy for emulation by shaders?
As for memory leak, you probably mean config.h, yeah, enable it here and just run game, wait when menu showups, and quit. And nothing new printed anywhere, but GPU memory each run/quite take +6MB more.
@ptitSeb
Can you check if on Pandora after exit not all GPU memory is taken by a game is freed?
Yeah it was a bit/lot slow - in my new game Zorbash I redesigned the whole display loop
as it was just slow... You could try tweaking this
-#define TILES_SCREEN_WIDTH_PAD TILES_SCREEN_WIDTH
-#define TILES_SCREEN_HEIGHT_PAD TILES_SCREEN_HEIGHT
+#define TILES_SCREEN_WIDTH_PAD 2
+#define TILES_SCREEN_HEIGHT_PAD 2
the other thing would be to run it at a lower resolution - as the frame buffer fill for
lighting was a big hit I recall.
Also you could probably just bulk replace double for float as fcos looks to be expensive
static inline double fasin (double rad)
{
const uint16_t index = (uint16_t)(rad / RAD_STEP);
extern double FASIN[RAD_MAX];
return (FASIN[index & (RAD_MAX-1)]);
}
static inline double fcos (double rad)
{
const uint16_t index = (uint16_t)(rad / RAD_STEP);
extern double FCOS[RAD_MAX];
return (FCOS[index & (RAD_MAX-1)]);
}
@goblinkhack
Also you could probably just bulk replace double for float as fcos looks to be expensive
Yeah, ptitSeb already doing that for Pandora:
#ifdef __ARM_NEON__
#define NEON 1
#undef Double
#define Double float
#endif
And i doing same for amigaos4:
#ifdef __amigaos4__
#undef Double
#define Double float
#endif
And then main.c had something like:
Double FSIN[RAD_MAX];
Double FASIN[RAD_MAX];
Double FCOS[RAD_MAX];
So if I understand right, ptitSeb changes that at the beginning.
I tried also to replace TILES_SCREEN_WIDTH_PAD and TILES_SCREEN_HEIGHT_PAD as you say, and that definitely improve fps! Now I even can see sometimes 35-36 fps. Which of course not superior, but at least now it more or less playable.
Maybe have any idea what else can be changed, so to reach 60 fps in end ?:)
Also, do you remember is there ability to generate the same 1:1 level (for testing purposes), because I can't see for sure that FPS changes and how much, because of levels always different, and fps always different, I can only count on the maximum fps I can see when to start 2-3 levels.
Try playing with this option to set the seed
/*
* -seed
*/
if (!strcasecmp(argv[i], "--seed") ||
!strcasecmp(argv[i], "-seed")) {
opt_seed = atoi(argv[i + 1]);
i++;
continue;
}
seed is used here
rc = generate_level(level, jigsaw_map, opt_seed);
so might work
is there a way to use any lower resolution? that would decrease the amount of pixle
filling that the light algorithm does with all the draw array calls
You could also try disabling all lights except the player's - add a check in wid_light_add
and if not is_player then return.
Or you could tweak this code
if (thing_is_player_or_owned_by_player(t)) {
max_light_rays = MAX_LIGHT_RAYS;
} else {
if (strength >= 10) {
max_light_rays = MAX_LIGHT_RAYS;
} else if (strength > 5) {
max_light_rays = MAX_LIGHT_RAYS / 2;
} else if (strength > 2) {
max_light_rays = MAX_LIGHT_RAYS / 8;
} else {
max_light_rays = MAX_LIGHT_RAYS / 16;
}
}
so that the else case is really low (non player lights) and leave the player light rays higher
lastly I seem to recall ENABLE_LARGE_TEXT_OUTLINE was slow - try disabling thst
making the map smaller would help a lot - but that would involve redesigning all the levels - so I never did that - but in hindsight 64x64 would have been more than enough!
Thanks, I will try those hints as well!
Btw, is it only me on my setup, or, restarting (when changes settings from the menu) are not working? For me, I have new copy of game with new settings started, but old one is not closed. Music plays, main picture shown, just without menu.
All I do is only replace execve() in a void restart (void) of main.c, on Execute() of AmigaOS, and it actually executes with new settings, just old one didn't close/stops/etc.
is there a way to use any lower resolution? that would decrease the amount of pixel
filling that the light algorithm does with all the draw array calls
From the tests I do, at least on AmigaOS4 it not very much important with Gorynlich if I use 800x600, or 1920x1080 fullscreen: fps in-game always the same.
@Ptiseb
On Pandora, you can change the settings and then "restart" game from menu? It's like, destroying is never called.
Are you still around?
Just about to release amigaos4 port of Gorynlich, and find out that I always crash when code calling the thing_reached_teleport(), right at the beginning of a function, and it comes from the thing_collision.c . line 552 which is
thing_reached_teleport(me, it);
I.e. once I start to play at any level, once the time comes to "things_teleport" I crash there.
Have any idea maybe what to check, etc?
Thanks!
I'm guessing maybe 't" is freed after the collision check below? any more info with gdb?
If only we have working gdb :) We have some sort of dump-info when a crash happens, it just shows the register's state, stack trace, etc, and can bring some light on, but not as good as gdb of course. That how it looks like:
kernel 54.34 (5.2.2021) AmigaOne X5000 release
Machine model: 9 (AmigaOne X5000/20)
Dump of context at 0xEFDB9BA0
Trap type: DSI exception
DSISR: 00800000 DAR: 61978260
Page: 0xEFAEDE40 (Virtual: 0x61978000, Physical: 0x00000000, Flags: 0x 800)
Machine State (raw): 0x0002F030
Machine State (verbose): [Critical Ints on] [ExtInt on] [User] [IAT on] [DAT on]
Instruction pointer: 0x7EE8D820
Crashed process: gorynlich (0x66DDB320)
DSI verbose error description: Access to address 0x61978260 not allowed by page protection in user state (protection violation)
Access was a store operation
Exception Syndrome Register: 0x00800000
0: FFFEDF30 6198A330 00000002 475CC708 477492B0 01826C00 00001B9A 5158DD82
8: 606554C2 5AB00000 00000001 000000F0 6198A330 5ABBF63C 00000000 6028AE10
16: 5AAF8624 475CC708 60743E10 5AAF863C 602BAE10 00000001 000078F0 0037EF00
24: 60641608 5AAF8398 00000001 5AAF8384 00000001 0000004A 477492B0 5AAD65A4
CR: 35553335 XER: A000007E CTR: 01C1569C LR: 7EE76CBC
Stack trace:
(0x6198A330) [thing_teleport.c:15] gorynlich:thing_reached_teleport()+0x10 (section 1 @ 0xBC81C)
(0x6198A3D0) [thing_collision.c:552] gorynlich:thing_handle_collisions()+0xe80 (section 1 @ 0xA5CB8)
(0x6198A470) [sdl.c:1517] gorynlich:sdl_loop()+0x740 (section 1 @ 0x613FC)
(0x6198ACB0) [main.c:869] gorynlich:main()+0xb58 (section 1 @ 0x2E9EC)
(0x6198AD10) native kernel module newlib.library.kmod+0x00002614
(0x6198AD60) native kernel module newlib.library.kmod+0x00003340
(0x6198AF10) native kernel module newlib.library.kmod+0x00003864
(0x6198AF40) gorynlich:_start()+0x1e0 (section 1 @ 0x1B3C)
(0x6198AF90) native kernel module dos.library.kmod+0x0002a490
(0x6198AFC0) native kernel module kernel+0x0005c6c8
(0x6198AFD0) native kernel module kernel+0x0005c740
Disassembly of crash site:
7EE8D810: 3C00FFFE lis r0,-2
7EE8D814: 7C2C0B78 mr r12,r1
7EE8D818: 6000DF30 ori r0,r0,57136
7EE8D81C: 3D205AB0 lis r9,23216
>7EE8D820: 7C21016E stwux r1,r1,r0
7EE8D824: 7C0802A6 mflr r0
7EE8D828: 92ACFFC4 stw r21,-60(r12)
7EE8D82C: 7C751B78 mr r21,r3
7EE8D830: 92ECFFCC stw r23,-52(r12)
7EE8D834: 3869BDA0 subi r3,r9,16992
Stack pointer (0x6198A330) is inside bounds
you could try to turn on this
Added that together with verify(t) and verify(teleport).
And then, when I start level, I have quite a bit of "ERROR: null pointer", but no crashes, the game starts as before. Then, once the time comes for teleport thing, I again crash on the same place in the code, at the beginning of the void thing_reached_teleport (thingp t, thingp teleport), stack trace even point out on the {. After crash happens, if I choose to ignore that crash, I have in the console:
"ERROR: **NULL POINTER* 0x0 thing.h:():1280
but that error can be because of a previous crash of course ..
can you send the stack trace?
Of course, its on the previous post :) There is relevant part:
Stack trace:
(0x6198A330) [thing_teleport.c:15] gorynlich:thing_reached_teleport()+0x10 (section 1 @ 0xBC81C)
(0x6198A3D0) [thing_collision.c:552] gorynlich:thing_handle_collisions()+0xe80 (section 1 @ 0xA5CB8)
(0x6198A470) [sdl.c:1517] gorynlich:sdl_loop()+0x740 (section 1 @ 0x613FC)
(0x6198ACB0) [main.c:869] gorynlich:main()+0xb58 (section 1 @ 0x2E9EC)
does it crash now on the verify()s perhaps?
is 1280 this?
Yeah, line 1280 is verify(t);
Will try to add more debug today
Commenting out verify(t); on line 1280, didn't fix a crash. It instead starts to say that we have BAD POINTER in things_tp():904.
But crash happens early, before those output lines arise, much early. Just when we call [thing_collision.c:552] gorynlich:thing_handle_collisions() it then crash.
I may try to rebuild the game via GCC 10.0.1 instead of 8.4.0, maybe it will give us some more clue.
@goblinhack
Thanks for the help :) Firstly tried this path without ENABLE_PTRCHECK - nope, nothing on the console. It the same crashes, with the same crash log, and nothing in the console before or after a crash happens.
Next, I tried this patch with enabled ENABLE_PTRCHECK, this time as always when I start level I have lots of "NULL POINTER" errors, and when it calls thing_reached_teleport() it crashes. After the crash happens, I have lots of bad_pointer errors, but they all happen after the crash. So can be just a side-effect. But the log looks like this:
00:00:27.350: ERROR: null pointer
00:00:27.350: ERROR: null pointer
00:00:27.358: ERROR: null pointer
00:00:27.358: ERROR: null pointer
00:00:27.365: ERROR: null pointer
00:00:27.365: ERROR: null pointer
00:00:30.689: Server: Level 0.0[0x47836008] (server): Reset players at start of level
00:00:30.691: Server: Level 0.0[0x47836008] (server): level loaded
00:00:30.693: Server: Level 0.0[0x47836008] (server): Allocate trigger, white
00:00:30.696: Server: Level 0.0[0x47836008] (server): No action trigger exists, activate trigger, white
00:00:30.698: Server: Level 0.0[0x47836008] (server): Activate trigger, white
00:00:31.197: Client: Level 1.2[0x43265008] (client): created
00:00:51.233: ERROR: **BAD POINTER** 0x5adb0000 :():1288
00:00:51.233: ERROR: **BAD POINTER** 0x5adb0000 :():1288
00:00:51.259: DYING: Died at ptrcheck.c:ptrcheck_verify_pointer():449
00:00:51.261: FATAL ERROR: Fatal error
00:00:51.263: ERROR: FATAL ERROR: Fatal error
00:00:51.263: ERROR: FATAL ERROR: Fatal error
00:00:51.741: Client: Level 1.2[0x43265008] (client): destroy
00:00:51.750: Client: Level 1.2[0x43265008] (client): destroyed
00:00:51.771: Server: Level 0.0[0x47836008] (server): destroy things and players
00:00:52.049: Server: Level 0.0[0x47836008] (server): destroy
00:00:52.051: Server: Level 0.0[0x47836008] (server): destroyed
exit(1) error
LIBGL: Shuting down
and 1288 line, is our verify(t);.
It all looks like that "things_is_dead" is not the one we have issues with. It just after we crash, things continue to be bad for this part, but the original issue a bit early: when thing_reach_teleport. I.e. when we call thing_reached_teleport(me, it); from the things_collision.c
@goblinhack
Intersting that if i do in the things_collision.c just that:
if (thing_is_teleport(it)) {
LOG("thing reached teleport bliad !!!\n");
//thing_reached_teleport(me, it);
return;
}
I.e. comment outcall to thing_reached_Teleport(), but instead put LOG, then I never crashes, but I also never see a LOG printf ! Wtf :)
this macro should be expanding and giving you info but I see "()" for FUNCTION above
Maybe that because you have in patch "char *" for function, while it asks to be "cost chat *"?
a long shot - you did a make clean when turning on ENABLE_PTRCHECK?
Yes, tried again with the full clean rebuild with adding ERR("null pointer %s:%s():%u", file, func, line); parts into the ptrcheck.c as well, and there is the full log:
00:00:32.565: Server: Level 0.0[0x4d410008] (server): Activate trigger, white
00:00:33.081: Client: Level 1.2[0x4272d008] (client): created
00:00:52.080: Client: Level 1.2[0x4272d008] (client): destroy
00:00:52.082: Client: Level 1.2[0x4272d008] (client): destroyed
00:00:53.888: Server: Level 0.0[0x4d410008] (server): destroy things and players
00:00:54.162: Server: Level 0.0[0x4d410008] (server): destroy
00:00:54.166: Server: Level 0.0[0x4d410008] (server): destroyed
00:00:57.315: Server: Level 0.0[0x4272d008] (server): created
00:00:57.316: Server: Level 0.0[0x4272d008] (server): Level generating
00:00:57.324: ERROR: null pointer dungeon_resize_jigpiece:map_jigsaw.c():302
00:00:57.324: ERROR: null pointer dungeon_resize_jigpiece:map_jigsaw.c():302
00:00:57.342: ERROR: null pointer dungeon_resize_frag:map_jigsaw.c():313
00:00:57.342: ERROR: null pointer dungeon_resize_frag:map_jigsaw.c():313
00:00:57.358: ERROR: null pointer dungeon_resize_frag:map_jigsaw.c():313
00:00:57.358: ERROR: null pointer dungeon_resize_frag:map_jigsaw.c():313
00:00:57.374: ERROR: null pointer dungeon_resize_frag:map_jigsaw.c():313
00:00:57.374: ERROR: null pointer dungeon_resize_frag:map_jigsaw.c():313
00:00:57.389: ERROR: null pointer dungeon_resize_frag:map_jigsaw.c():313
00:00:57.389: ERROR: null pointer dungeon_resize_frag:map_jigsaw.c():313
00:00:57.405: ERROR: null pointer dungeon_resize_frag:map_jigsaw.c():313
00:00:57.405: ERROR: null pointer dungeon_resize_frag:map_jigsaw.c():313
00:00:57.420: ERROR: null pointer dungeon_resize_frag:map_jigsaw.c():313
00:00:57.420: ERROR: null pointer dungeon_resize_frag:map_jigsaw.c():313
00:00:57.436: ERROR: null pointer dungeon_resize_frag:map_jigsaw.c():313
00:00:57.436: ERROR: null pointer dungeon_resize_frag:map_jigsaw.c():313
00:00:57.451: ERROR: null pointer dungeon_resize_frag:map_jigsaw.c():313
00:00:57.451: ERROR: null pointer dungeon_resize_frag:map_jigsaw.c():313
00:00:57.467: ERROR: null pointer dungeon_resize_frag_alt:map_jigsaw.c():325
00:00:57.467: ERROR: null pointer dungeon_resize_frag_alt:map_jigsaw.c():325
00:00:57.484: ERROR: null pointer dungeon_resize_frag_alt:map_jigsaw.c():325
00:00:57.484: ERROR: null pointer dungeon_resize_frag_alt:map_jigsaw.c():325
00:00:57.500: ERROR: null pointer dungeon_resize_frag_alt:map_jigsaw.c():325
00:00:57.500: ERROR: null pointer dungeon_resize_frag_alt:map_jigsaw.c():325
00:00:57.517: ERROR: null pointer dungeon_resize_frag_alt:map_jigsaw.c():325
00:00:57.517: ERROR: null pointer dungeon_resize_frag_alt:map_jigsaw.c():325
00:00:57.533: ERROR: null pointer dungeon_resize_frag_alt:map_jigsaw.c():325
00:00:57.533: ERROR: null pointer dungeon_resize_frag_alt:map_jigsaw.c():325
00:00:57.563: ERROR: null pointer dungeon_resize_frag_alt:map_jigsaw.c():325
00:00:57.563: ERROR: null pointer dungeon_resize_frag_alt:map_jigsaw.c():325
00:00:57.579: ERROR: null pointer dungeon_resize_frag_alt:map_jigsaw.c():325
00:00:57.579: ERROR: null pointer dungeon_resize_frag_alt:map_jigsaw.c():325
00:00:57.596: ERROR: null pointer dungeon_resize_frag_alt:map_jigsaw.c():325
00:00:57.596: ERROR: null pointer dungeon_resize_frag_alt:map_jigsaw.c():325
00:00:57.633: ERROR: null pointer dungeon_resize_trigger_fragment:map_jigsaw.c():337
00:00:57.633: ERROR: null pointer dungeon_resize_trigger_fragment:map_jigsaw.c():337
00:00:57.652: ERROR: null pointer dungeon_resize_trigger_fragment:map_jigsaw.c():337
00:00:57.652: ERROR: null pointer dungeon_resize_trigger_fragment:map_jigsaw.c():337
00:00:57.672: ERROR: null pointer dungeon_resize_trigger_fragment:map_jigsaw.c():337
00:00:57.672: ERROR: null pointer dungeon_resize_trigger_fragment:map_jigsaw.c():337
00:00:57.693: ERROR: null pointer dungeon_resize_trigger_fragment:map_jigsaw.c():337
00:00:57.693: ERROR: null pointer dungeon_resize_trigger_fragment:map_jigsaw.c():337
00:00:57.713: ERROR: null pointer dungeon_resize_trigger_fragment:map_jigsaw.c():337
00:00:57.713: ERROR: null pointer dungeon_resize_trigger_fragment:map_jigsaw.c():337
00:00:57.732: ERROR: null pointer dungeon_resize_trigger_fragment:map_jigsaw.c():337
00:00:57.732: ERROR: null pointer dungeon_resize_trigger_fragment:map_jigsaw.c():337
00:00:57.751: ERROR: null pointer dungeon_resize_trigger_fragment:map_jigsaw.c():337
00:00:57.751: ERROR: null pointer dungeon_resize_trigger_fragment:map_jigsaw.c():337
00:00:57.771: ERROR: null pointer dungeon_resize_trigger_fragment:map_jigsaw.c():337
00:00:57.771: ERROR: null pointer dungeon_resize_trigger_fragment:map_jigsaw.c():337
00:00:57.790: ERROR: null pointer dungeon_resize_trigger:map_jigsaw.c():349
00:00:57.790: ERROR: null pointer dungeon_resize_trigger:map_jigsaw.c():349
00:00:57.807: ERROR: null pointer dungeon_resize_trigger:map_jigsaw.c():349
00:00:57.807: ERROR: null pointer dungeon_resize_trigger:map_jigsaw.c():349
00:00:57.823: ERROR: null pointer dungeon_resize_trigger:map_jigsaw.c():349
00:00:57.823: ERROR: null pointer dungeon_resize_trigger:map_jigsaw.c():349
00:00:57.840: ERROR: null pointer dungeon_resize_trigger:map_jigsaw.c():349
00:00:57.840: ERROR: null pointer dungeon_resize_trigger:map_jigsaw.c():349
00:00:57.856: ERROR: null pointer dungeon_resize_trigger:map_jigsaw.c():349
00:00:57.856: ERROR: null pointer dungeon_resize_trigger:map_jigsaw.c():349
00:00:57.872: ERROR: null pointer dungeon_resize_trigger:map_jigsaw.c():349
00:00:57.872: ERROR: null pointer dungeon_resize_trigger:map_jigsaw.c():349
00:00:57.889: ERROR: null pointer dungeon_resize_trigger:map_jigsaw.c():349
00:00:57.889: ERROR: null pointer dungeon_resize_trigger:map_jigsaw.c():349
00:00:57.905: ERROR: null pointer dungeon_resize_trigger:map_jigsaw.c():349
00:00:57.905: ERROR: null pointer dungeon_resize_trigger:map_jigsaw.c():349
00:00:57.922: ERROR: null pointer dungeon_resize_action1:map_jigsaw.c():361
00:00:57.922: ERROR: null pointer dungeon_resize_action1:map_jigsaw.c():361
00:00:57.938: ERROR: null pointer dungeon_resize_action1:map_jigsaw.c():361
00:00:57.938: ERROR: null pointer dungeon_resize_action1:map_jigsaw.c():361
00:00:57.954: ERROR: null pointer dungeon_resize_action1:map_jigsaw.c():361
00:00:57.954: ERROR: null pointer dungeon_resize_action1:map_jigsaw.c():361
00:00:57.971: ERROR: null pointer dungeon_resize_action1:map_jigsaw.c():361
00:00:57.971: ERROR: null pointer dungeon_resize_action1:map_jigsaw.c():361
00:00:57.987: ERROR: null pointer dungeon_resize_action1:map_jigsaw.c():361
00:00:57.987: ERROR: null pointer dungeon_resize_action1:map_jigsaw.c():361
00:00:58.003: ERROR: null pointer dungeon_resize_action1:map_jigsaw.c():361
00:00:58.003: ERROR: null pointer dungeon_resize_action1:map_jigsaw.c():361
00:00:58.020: ERROR: null pointer dungeon_resize_action1:map_jigsaw.c():361
00:00:58.020: ERROR: null pointer dungeon_resize_action1:map_jigsaw.c():361
00:00:58.036: ERROR: null pointer dungeon_resize_action1:map_jigsaw.c():361
00:00:58.036: ERROR: null pointer dungeon_resize_action1:map_jigsaw.c():361
00:00:58.053: ERROR: null pointer dungeon_resize_action2:map_jigsaw.c():373
00:00:58.053: ERROR: null pointer dungeon_resize_action2:map_jigsaw.c():373
00:00:58.069: ERROR: null pointer dungeon_resize_action2:map_jigsaw.c():373
00:00:58.069: ERROR: null pointer dungeon_resize_action2:map_jigsaw.c():373
00:00:58.086: ERROR: null pointer dungeon_resize_action2:map_jigsaw.c():373
00:00:58.086: ERROR: null pointer dungeon_resize_action2:map_jigsaw.c():373
00:00:58.102: ERROR: null pointer dungeon_resize_action2:map_jigsaw.c():373
00:00:58.102: ERROR: null pointer dungeon_resize_action2:map_jigsaw.c():373
00:00:58.118: ERROR: null pointer dungeon_resize_action2:map_jigsaw.c():373
00:00:58.118: ERROR: null pointer dungeon_resize_action2:map_jigsaw.c():373
00:00:58.135: ERROR: null pointer dungeon_resize_action2:map_jigsaw.c():373
00:00:58.135: ERROR: null pointer dungeon_resize_action2:map_jigsaw.c():373
00:00:58.151: ERROR: null pointer dungeon_resize_action2:map_jigsaw.c():373
00:00:58.151: ERROR: null pointer dungeon_resize_action2:map_jigsaw.c():373
00:00:58.167: ERROR: null pointer dungeon_resize_action2:map_jigsaw.c():373
00:00:58.167: ERROR: null pointer dungeon_resize_action2:map_jigsaw.c():373
00:00:58.184: ERROR: null pointer dungeon_resize_action3:map_jigsaw.c():385
00:00:58.184: ERROR: null pointer dungeon_resize_action3:map_jigsaw.c():385
00:00:58.200: ERROR: null pointer dungeon_resize_action3:map_jigsaw.c():385
00:00:58.200: ERROR: null pointer dungeon_resize_action3:map_jigsaw.c():385
00:00:58.217: ERROR: null pointer dungeon_resize_action3:map_jigsaw.c():385
00:00:58.217: ERROR: null pointer dungeon_resize_action3:map_jigsaw.c():385
00:00:58.234: ERROR: null pointer dungeon_resize_action3:map_jigsaw.c():385
00:00:58.234: ERROR: null pointer dungeon_resize_action3:map_jigsaw.c():385
00:00:58.250: ERROR: null pointer dungeon_resize_action3:map_jigsaw.c():385
00:00:58.250: ERROR: null pointer dungeon_resize_action3:map_jigsaw.c():385
00:00:58.267: ERROR: null pointer dungeon_resize_action3:map_jigsaw.c():385
00:00:58.267: ERROR: null pointer dungeon_resize_action3:map_jigsaw.c():385
00:00:58.283: ERROR: null pointer dungeon_resize_action3:map_jigsaw.c():385
00:00:58.283: ERROR: null pointer dungeon_resize_action3:map_jigsaw.c():385
00:00:58.299: ERROR: null pointer dungeon_resize_action3:map_jigsaw.c():385
00:00:58.299: ERROR: null pointer dungeon_resize_action3:map_jigsaw.c():385
00:00:59.998: Server: Level 0.0[0x4272d008] (server): Reset players at start of level
00:01:00.000: Server: Level 0.0[0x4272d008] (server): level loaded
00:01:00.002: Server: Level 0.0[0x4272d008] (server): Allocate trigger, white
00:01:00.005: Server: Level 0.0[0x4272d008] (server): No action trigger exists, activate trigger, white
00:01:00.007: Server: Level 0.0[0x4272d008] (server): Activate trigger, white
00:01:00.716: Client: Level 1.3[0x4d410008] (client): created
00:01:09.747: ERROR: **BAD POINTER** 0x5abf0000 :():1288
00:01:09.747: ERROR: **BAD POINTER** 0x5abf0000 :():1288
00:01:09.782: DYING: Died at ptrcheck.c:ptrcheck_verify_pointer():449
00:01:09.784: FATAL ERROR: Fatal error
00:01:09.786: ERROR: FATAL ERROR: Fatal error
00:01:09.786: ERROR: FATAL ERROR: Fatal error
00:01:10.181: Client: Level 1.3[0x4d410008] (client): destroy
00:01:10.183: Client: Level 1.3[0x4d410008] (client): destroyed
00:01:10.205: Server: Level 0.0[0x4272d008] (server): destroy things and players
00:01:10.529: Server: Level 0.0[0x4272d008] (server): destroy
00:01:10.532: Server: Level 0.0[0x4272d008] (server): destroyed
exit(1) error
LIBGL: Shuting down
See, at first it bring lots of null pointers from map_jigsaw.c , then when we had teleport call we then crash with bad_pointer.
As I see from the code, all those null-pointers when the level starts come from myrealloc calls. Maybe because of them we crash on teleport_thing later?
Yeah, will check.
Anyway, what I think that maybe for the first amigaos4 release just comment out calling to thing_reached_teleport(me, it); and be done with it? Or it will break the game's functionality a lot?