Need some help to finalize AmigaOS4 port of AssaultCube

[kas1e]

Hi all.

Few days ago i start to work on port of AssaultCube to the AmigaOS4, and i have a good progress with port already:



And there is video in action:


My amigaos4 machine are: PPC-based cpu on 1ghz + 1gb of ram + radeon9250.

The only problem for now, that is sometime crashes on different level loading (but that i think not the real problem for now), and the most important one: It crashes heavy when trying to render Meshes, so, i should comment out one string for make game works, but without meshes it of course looks empty and wrong. Check some more examples of how it looks like right now:



It is because that i comment line 870 in the src/vertmodel.h:
loopv(meshes) meshes[i]->render(as, cur, doai ? &prev : NULL, ai_t);

Crash happens exactly on that line (its some kind of segfault , if compare with unix world).

For first i catch that bug, when i try to run fresh compiled ac_client binary with packages from SVN, it trying to write to shadow.dat , and then crashes on that line.

Second time i catch that crash when i just grab win32-data-files from last release, run ac_client binary, and when it comes to MainLoop (i see that output in shell), it crashes.

So i comment out that string, and it start to works with win32 data files, but of course without meshes is nothing.

I use yesterday SVN build if it make sense.

The only changes which i do in the code:

------
change all __APPLE__ on __amigaos4__ in src/console.cpp

and comment out these strings:
// extern void mac_pasteconsole(char *commandbuf);
// mac_pasteconsole(dst);
In the same src/console.cpp file.

(so it all about console)

---
change in src/log.cpp all APPLE on amigaos4
---
change all UNUSED on UNUSEDA in src/tristrip.h because with UNUSED have heavy warnings, which imho because UNUSED are recerved by aos4 sdk.
---

That all changes i do ..

If some of developers can help me , i will be realy appricated for it. Should to add that i am not so "programmer", so someone brave enough to help me are very-very welcome :)

Thanks for time.

[flowtron]

Uhm, changing __APPLE__ to __amigaos4__ seems like a bad idea, you should instead use something like:

[SELECT ALL] Code:

ORIGINAL:
#ifdef __APPLE__
CHANGED:
#if defined(amigaos4) || defined(__APPLE__)

Other than that I have no advice since I stopped seeing Amigas sometime in the mid-90's .. I just got my jaw dropped when I found the AmigaOS entry on wikipedia telling me they're still actively developing on the OS. Somewhere I've still got AMOS lying around, it's a BASIC-dialect geared towards game-production .. it was a sweet thing to toy with back in the day.

The writing of the shadow.dat files should go to the game-home-directory - what are you passing as "--home=" argument to your binary? Is it writeable by the user?!
Regarding the meshes you might tryout some debugging with something like gdb - if available on Amiga (probably a built-in for the SDK!) - so you can set a break-point at the line you mentioned and inspect the values of the variables in use there - maybe not all __APPLE__ segments are meant to be used for AMIGA - another reason to use the approach I suggested above, it'd make it easy to flip on/off single segments.

[kas1e]

@flowtron
Thanks for answer :)

Well, related to __APPLE__ stuff, there is not many parts in code about, there is:

1. client.cpp / sendintro(). I think its only about connections ? code looks like this:

void sendintro()
{
packetbuf p(MAXTRANS, ENET_PACKET_FLAG_RELIABLE);
putint(p, SV_CONNECT);
putint(p, AC_VERSION);
putint(p, (isbigendian() ? 0x80 : 0 )|(adler((unsigned char *)guns, sizeof(guns)) % 31 << 8)|
#ifdef WIN32
0x40 |
#endif
#ifdef __APPLE__
0x20 |
#endif
#ifdef _DEBUG
0x08 |
#endif
#ifdef __GNUC__
0x04 |
#endif
0);
sendstring(player1->name, p);
sendstring(genpwdhash(player1->name, clientpassword, sessionid), p);
const char *lang = getalias("LANG");
sendstring(!lang || strlen(lang) != 2 ? "" : lang, p);
putint(p, connectrole);
clientpassword[0] = '\0';
connectrole = CR_DEFAULT;
putint(p, player1->nextprimweap->type);
loopi(2) putint(p, player1->skin(i));
sendpackettoserv(1, p.finalize());
}

As on aos4 we have GCC as default compiler ,so its eat __GNUC__ , and should be everything ok here ?

2. console.h

There is only one difference, and its related to SDL:

#ifdef __APPLE__
#define MOD_KEYS (KMOD_LMETA|KMOD_RMETA)
#else
#define MOD_KEYS (KMOD_LCTRL|KMOD_RCTRL)
#endif

I not change it as well, because its imho some kind of fix for apple ?

3. main.cpp

There is defines on for setfullscreen(), in screenres () and in setresdata(), which all realted to setting of screenmodes (with which i have no problems. all works fine without any changes here).

So, for now i leave all of this like that.

4. openal.cpp

There is one more fix for apple stuff, we have not problem on os4 with it, so, i leave it without any changes.

5. Platform.h

That only about includes, so, if it already compiles fine , then no problems here as well.

6. serverbrowser.cpp

There is again some apple only specific fix, which i also not touch.

The only change which i do related to __APPLE__ , its in :

console.cpp and log.cpp

But for sure they boch should be not related to meshes in any case, its just about how handle console which user spawn for all those commands and alt (imho) ? So, it shouldnt be a problems here ..

The writing of the shadow.dat files should go to the game-home-directory - what are you passing as "--home=" argument to your binary? Is it writeable by the user?!

When i compile it , i not set any "--home=" values , just in hope that it will get "current directory", nope ? On aos4 we have PROGDIR: (which mean the same as ./ for linux, i.e. current directory), and we use all the time that for HOME stuff.

It is possible, that it crashes because trying to write to some /somethink_which_we_not_have for svn data, and crashes in meshes, because i use win32 data (which have something different, or platform specific, or endian specific inside ? )

another reason to use the approach I suggested above, it'd make it easy to flip on/off single segments.

Can you explain a little more about that ?

Maybe assault cube have some kind of "turn full debug info on", which will say me about everyhitnkg, about all the values, what expected and what founds and so on ?

[tempest]

You pass --home to AC as a command line argument when you start it. Like

[SELECT ALL] Code:

bin_unix/native_client --home=/some/path

(I have no idea if your binary is in bin_unix since you're not using a UNIX system...)
Now, that /some/path has to be something you have write permissions for. I have no idea where configuration files are typically stored on Amiga, on Linux it would be ~/.assaultcube_v1.1

[kas1e]

You pass --home to AC as a command line argument when you start it. Like

[SELECT ALL] Code:

bin_unix/native_client --home=/some/path

(I have no idea if your binary is in bin_unix since you're not using a UNIX system...)
Now, that /some/path has to be something you have write permissions for. I have no idea where configuration files are typically stored on Amiga, on Linux it would be ~/.assaultcube_v1.1

I running binary just from the main root directory (not in any subdirs). I also test win32 version, and if i just copy from bin_win32 binary to root directory, and run it without any params - it works. What make me think, that all grabs from the current path.

All in all, it works like that, just meshes loading crashes. I don't think that only for meshes there is some home values, which programmed only for meshes, but not for all the textures/sounds and alt (which works fine).

[tempest]

I don't think that only for meshes there is some home values, which programmed only for meshes, but not for all the textures/sounds and alt (which works fine).

Of course not. Do configuration files work? (I.e. if you change some game settings ,are those changes still there when you restart AC?)

[kas1e]

Of course not. Do configuration files work? (I.e. if you change some game settings ,are those changes still there when you restart AC?)

Yep. For example i just run ac (with commented that string which load meshes), then settings/videoquality/ set from LOW to GOOD, then exit, restart, go to settings, and GOOD settings is here.

Still it not save full-screen / win mode (i.e. if i for example change to win mode, then apply, then quit, the run again, and it runs still in full-screen, but i think that is because win/fullscren modes handles by all those "-t" keys, so its ok i assume for that, other settings saves fine, what mean that all is ok there as well imho).

I think that crash can be because of something with our OpenGL realisation (pretty possible), because its very-very sensetive to bugs. If something a little wrong, then it will crashes (even if it will works on win32, or linux for example).

I also trying to port Cube1, and it works fine, all works ok with meshes and alt , there is youtube clip:



For now i trying to understand , what that line just mean, in human language:
loopv(meshes) meshes[i]->render(as, cur, doai ? &prev : NULL, ai_t);

Its call some loopv() function, which happenes for all the meshes, and for every mesh its do render of something ? What mean all these "doai ? & prev: NULL" ? Should to say, that NULL are scare me a bit, because usually some heavy bugs happenes when NULL should be not NULL but 0 instead or kind .. Or when you trying to remove something by some weird way..

Can you point me, where i can put debug printfs/delays, to found, where exactly crash is happenes ? I for now not so good understand the whole code, and trying to found where that "loopv" fucntion are declated and what it expected to do.

[tempest]

I think that bug is caused by shadow rendering. Try switching "Dynamic Shadows" to "Blob" or "Off" in the menu (Settings->Video settings->Advanced video settings).

In order to find the cause of the bug, you should use a debugger (preferably GDB, i think that's available for Amiga?). You'll have to compile with the -g option. To do this, change the line

[SELECT ALL] Code:

CXXFLAGS= -O3 -fomit-frame-pointer

at the top of source/src/Makefile to

[SELECT ALL] Code:

CXXFLAGS= -O3 -fomit-frame-pointer -g

, then recompile and run it in GDB.

[kas1e]

@tempest

think that bug is caused by shadow rendering. Try switching "Dynamic Shadows" to "Blob" or "Off" in the menu (Settings->Video settings->Advanced video settings).

Can i manually change that settings in config files ? (because game crashes without loading a menu, when that rendering line is here). I also trying all the time for now win32 data. But you can be right here: if it crashes on shadow when i trying to generate textures, then very possible that game crashes on the same shadow loading when i use win32 data..

But just for point : i use win32 data for now, that "shadow" crash was only when i try to generate data from SVN.


Anyway, ill do it like that for now : build with commented line , set dynamic shadow to OFF (before was BLOB btw), then uncoment line, build, running, and the same crash :(

In order to find the cause of the bug, you should use a debugger (preferably GDB, i think that's available for Amiga?). You'll have to compile with the -g option. To do this, change the line

Yep, already do it for now, and have:

Program received signal SIGBUS, Bus error.
0x00000000 in ?? ()

Btw, maybe it will help us, but that what i have in shell :

9/0.WORK:ac> ac_client
current locale: C
init: sdl
init: net
init: world
init: video: sdl
init: video: mode
init: video: misc
init: gl
Renderer: MiniGL/Warp3D ATI Radeon (radeon r200) (The MiniGL Team)
Driver: 1.3
init: console
init: sound
Audio devices:
Sound: AHI Software / OpenAL Soft (OpenAL Community)
Driver: 1.1 ALSOFT 1.7.411
init: cfg
Could not set gamma (card/driver doesn't support it?)
sdl: Gamma ramp manipulation not supported
init: models
init: docs
missing "]"
init: localconnect
read map packages/maps/official/ac_iceroad.cgz rev 8 (569 milliseconds)
ac_iceroad by Ruthless & Undead
loaded textures (1935 milliseconds)
loaded mapmodels (266 milliseconds)
loaded mapsounds (462 milliseconds)
game mode is "TDM"
init: mainloopdl

All looks fine imho .. Loads and alt..

[tempest]

Does a backtrace reveal anything? (type 'bt' in GDB)

[kas1e]

Does a backtrace reveal anything? (type 'bt' in GDB)

GDB for us works a bit buggy (i contacted with authors of GDB port, they say that i should not belive to amigaos4 port of GDB, because its suck in current state).

But, as i know "bt" in GDB, mean "stack trace" ? If so, then we have in amigaos4 some kind of little-easy inbuild debugger, which generate stack trace info for every crash. And for the AC crash, it generate such stack trace:

ac_client:_ZN9vertmodel4part6renderEiifiP6dynent()+0x2C0 (section 7 @ 0x82e8c)
ac_client:_ZN3md36renderEiifiRK3vecffP6dynentP11modelattachf()+0x6F4 (section 7 @ 0x8434c)
ac_client:_Z11rendermodelPKciifRK3vecfffiP9playerentP11modelattachf()+0x304 (section 7 @ 0x75fd4)
ac_client:_ZN6weapon14renderhudmodelEii()+0x174 (section 7 @ 0xd1ef4)
ac_client:_Z10drawhudguniifi()+0xBC (section 7 @ 0x65524)
ac_client:_Z12gl_drawframeiiff()+0x764 (section 7 @ 0x69928)
ac_client:main()+0xE78 (section 7 @ 0x46e30)

That mean that from main calls gl_drawfram, from gl_drawfram cals drawhudguninif, and so on, and in end crash happenes on the latest (at top) line.

Then, by usage of "addr2line" program, i found, that:

15/0.MOS_WORK:ac> addr2line -e ac_client --section=.text 0x82e8c
vertmodel.h:870

And that line 870 in vertmodel, is that loopv (render meshes blablabla). Of course pretty possible, that bug only happenes here, but all the problems coming early, maybe in drawhudguniifi() or kind.

The other time, i got such stack trace on the same crash (when i turn everything off/0 in advanced-video options):

ac_client_with_line:_ZN9vertmodel4part6renderEiifiP6dynent()+0x2C0 (section 7 @ 0x82e8c)
ac_client_with_line:_ZN3md36renderEiifiRK3vecffP6dynentP11modelattachf()+0x358 (section 7 @ 0x83fb0)
ac_client_with_line:_Z11rendermodelPKciifRK3vecfffiP9playerentP11modelattachf()+0x304 (section 7 @ 0x75fd4)
ac_client_with_line:_Z15rendermapmodelsv()+0x1F8 (section 7 @ 0x3dc54)
ac_client_with_line:_Z11drawminimapii()+0x6A0 (section 7 @ 0x68f24)
ac_client_with_line:_Z12gl_drawframeiiff()+0xA8 (section 7 @ 0x6926c)
ac_client_with_line:main()+0xE78 (section 7 @ 0x46e30)

At this time bug again the same , but from other call (from rendermapmodelssv).

Pretty possible that its start to happenes in rendermodel-modelattach stuff. I check that address (0x75fd4):

15/0.MOS_WORK:ac> addr2line -e ac_client --section=.text 0x75fd4
rendermodel.cpp:451

Which are mean "m->endrender();".

Also for now i catch some more info, which can be interesting i think. I trying to run ac, and have in shell:

blablabl

init: localconnect
read map packages/maps/official/ac_douze.cgz rev 17 (173 milliseconds)
Douze (AC-Version) by makkE - layout by stanze
loaded textures (697 milliseconds)
loaded mapmodels (0 milliseconds)
loaded mapsounds (1441 milliseconds)
game mode is "TDM"
init: mainlooptwa

For first what is strange a bit for me, its 0 milliseconds for the loaded mapmodels.

And next interesting moment, that game before crash, show me the screen, which looks pretty fine:



And then imediately crash. Just by some luck i switch on the other screen while it loads, and because of "inactive" ac_screen, i can capture the screenshot. But then, when i make it active everything crashes with such stack trace which i show.

Another time, when i switch everything off in advanced video options, it loads one time, and i can move, run, but when i press fire, imidiately crash with the same stacktrace points.

That make me think, that : loading happens fine. Because if i see gun/hands, then all is loaded in memory already, and game are can load all of this correctly. But then a crash: maybe because of "redraw", maybe because of "rerendering the scene", but , crash happenes only when that line 870 in vertmodel.h are here => what also make me think, that there is something exactly related to handler of all that hands/guns/stuff maybe ?

Anyway, thank you already for all that help. I know its annoing to fix all that problems (which in end, very possible will be because of our opengl realisation) but for sure game can works here, just need to found what cause the problem..

---

Do some more depper "comment out" testings, and found, that game works as well (but without models/hands/guns), when i only commented these lines in rendermodel.cpp:

line 227:
m->render(b.anim, b.varseed, b.speed, b.basetime, b.o, b.yaw, b.pitch, b.d, a, b.scale);

and line 443:
m->render(anim, varseed, speed, basetime, o, yaw, pitch, d, a, scale);

So looks like bugs happenes here (and only later, they causes by line 870 in vertmodel.h in the loopv(render-meshes) function).

I think we can play with settings for that functions to found where is problem ? Like for example set "scale" to 0 all the time, and all the other possible values to static ones (one by one), to found in which one all the problems.

[tempest]

Sadly, the stacktrace seems to be mostly useless here (don't know why it won't go any further). You'll have to debug it manually. I find that the best way to do this is to put a few conoutf()'s into the suspicious functions, like this:

[SELECT ALL] Code:

void bla()
{
    conoutf("entered function bla");
    ...function code...
    conoutf("reached point 1 in bla");
    ...function code...
    conoutf("reached point 2 in bla");
    ...function code...
    conoutf("finished function bla");
}

Eventually, you should be able to see where it crashed. A horrible procedure, I know, but still faster than commenting out single lines.

[kas1e]

Yep, i think about the same too for now, as about better/faster way. So, i found that "m" its just "struct model" which have inside:

virtual void render(int anim, int varseed, float speed, int basetime, const vec &o, float yaw, float pitch, dynent *d, modelattach *a = NULL, float scale = 1.0f) = 0;

So trying to found that "render" fucntion for now, and found that "void render" handles in many files, but i assume "our one", is in md2.h or in md3.h ? Or somethere else ? (sorry, not so good with programming, and a bit looses in that sources for now).

EDIT: trying to comment our render fucntion in the md2.h only - crashes. in the md3.h only - crashes. But if i comment out these functions in the boch md2.h and in md3.h - then no crashes / but no meshes of course.

I think that i need to put all that print/pause stuff to boch (md2 and md3 includes), inside of that render fucntions ? I will try for first comment out fully render in md3, and printf/pause all the stuff in md2 (i think problem will be the same in boch as well)

---

added printfs to the void render of md2.h fucntion, and , it works for a while, i see tons
of prints, all going well , and on some moment it crashes there:

conoutf("if anim scale blabla, + redner !");
if(anim&ANIM_MIRROR || scale!=1) matrixstack[0].scale(scale, anim&ANIM_MIRROR ? -scale : scale, scale);
conoutf("end of scale");
parts[0]->render(anim, varseed, speed, basetime, d);
conoutf("end of anim scale blablab and render");

In the shell after tons of working loops, i have :

if anim scale blabla, + redner !
end of scale

Should to say, it happenes exactly when everything should showns on screen. I can hear first sound when game starts, and then that crash. Some times it even show me that first screen, but when i "shoot", then crash is happenes.

For now all the ways bring me back to vertmodel.h, to the "struct mesh", which have inside also render() functions which looks like this:

void render(animstate &as, anpos &cur, anpos *prev, float ai_t)
{
if(!(as.anim&ANIM_NOSKIN))
{
GLuint id = tex < 0 ? -tex : skin->id;
if(tex > 0) id = lookuptexture(tex)->id;
if(id != lasttex)
{
glBindTexture(GL_TEXTURE_2D, id);
lasttex = id;
}
if(enablealphablend) { glDisable(GL_BLEND); enablealphablend = false; }
if(skin->bpp == 32 && owner->model->alphatest > 0)
{
if(!enablealphatest) { glEnable(GL_ALPHA_TEST); enablealphatest = true; }
if(lastalphatest != owner->model->alphatest)
{
glAlphaFunc(GL_GREATER, owner->model->alphatest);
lastalphatest = owner->model->alphatest;
}
}
else if(enablealphatest) { glDisable(GL_ALPHA_TEST); enablealphatest = false; }
if(!enabledepthmask) { glDepthMask(GL_TRUE); enabledepthmask = true; }
}

I think is the "very first and very main" render of all the meshes ?

[kas1e]

Trying to spend few hours on that latest render() stuff from "struct mesh" of vermodel.h file, and if i comment out all that part of code (whic i show above, these lines from redner() ) - no crashes, but no meshes. If i start to comment line by line, its sometime crashes on loading, sometime loads fine some level, but then crashes when i press "fire" first time.

Trying to put printfs after every lines, and it crashes in strange places. Have that:

conoutf("before if skin->bppt");
if(skin->bpp == 32 && owner->model->alphatest > 0)
{
conoutf("before if enablealphatest");
if(!enablealphatest) { glEnable(GL_ALPHA_TEST); enablealphatest = true; }
conoutf("before is lastalphatest");
if(lastalphatest != owner->model->alphatest)
{
conoutf("before glalphafunc");
glAlphaFunc(GL_GREATER, owner->model->alphatest);
conoutf("before owner->model->alphatest");
lastalphatest = owner->model->alphatest;
}
}
else if(enablealphatest) {
conoutf("after skin, before enablealphatest=false");
glDisable(GL_ALPHA_TEST); enablealphatest = false;
}
conoutf("before if enabledepthmask");
if(!enabledepthmask) { glDepthMask(GL_TRUE); enabledepthmask = true; }
conoutf("after if enabledepthmask");
}

And have in shell, that crash happens after many workins loops, and then last what i see:

conoutf("before if skin->bppt");

I trying to comment the whole part of that "if" loop, but still the same crashes..

Maybe meshes have different format in compare with other textures ? Maybe all that alpha-stuff can be buggy a bit ? Maybe someone can create a replacement withou all that ifs/etc, just somethink stoopid/static/hardcore, by which we can detect what is works, and what is not and why ? Or maybe some printfs with some details which will show some values which we can compare/check/etc ?

Its all of course in hope, that this render() from struct mesh are the main one.

[tempest]

I think is the "very first and very main" render of all the meshes ?

Yes. That function contains the OpenGL functionality, everything before is just setup stuff.

I have some bad feeling that this will be a basically unfixable bug somewhere between AC, OpenGL, graphics driver and graphics card (probably the latter because of the SIGBUS)

[kas1e]

I have some bad feeling that this will be a basically unfixable bug somewhere between AC, OpenGL, graphics driver and graphics card (probably the latter because of the SIGBUS)

Yep, very possible, but imho we can somehow understand why it happenes ? (i have contact with our minigl author, so if we can found if the problem in our opengl, he will fix it).

All in all we imho can also commented everything and only loads meshes as some "basic" stuff, without any options, etc ?

[tempest]

You should first ask that developer if he is sure that vertex arrays and display lists work flawlessly.

All in all we imho can also commented everything and only loads meshes as some "basic" stuff, without any options, etc ?

Not really, no. The engine relies heavily on said features, not only to render models, but especially to rotate and animate them.

Honestly, I don't know enough about neither OpenGL nor AC's rendering functions to be of much use.

[kas1e]

You should first ask that developer if he is sure that vertex arrays and display lists work flawlessly.

The example of that all of this works (should works): its many ports of opengl games/apps/demos which we already have, like:
battle for wesnoth, super tux kart, tux kart, cube 1, teewords, i have no tomatoes, gish, lugaru and many others, which works fine on our opengl.

Not really, no. The engine relies heavily on said features, not only to render models, but especially to rotate and animate them.

Honestly, I don't know enough about neither OpenGL nor AC's rendering functions to be of much use.

That what i recieved for now from our opengl author:

I think that they're too quick to blame MiniGL.

Given how it fails the moment that you use any variable in that
function, I'd say that you might have bad pointers/bad objects. Do
"skin," "owner," and "owner->model" all point to valid objects? Comment
out ALL OpenGL function calls in the render function, and see what
happens. If it still crashes, then the problem lies within Assault cube.

One possible test would be to print out details of all objects that this
function is accessing to the console or using DebugPrintF. Print the
value of the pointer to the object, and then try to print out the
contents of various fields. Do this within the render function as this
is where you're having trouble.

I trying to comment all the opengl functions, inside the render(), and its not crashes => looks like still opengl problems.

Imho for now, only what we can do : its that printf the values of the pointer to objects, and then print out their content..

Did you know maybe emails of any other active AC developers, who can help me with that ? (because i do not know what values and where should be, what expected from objects, and what should be inside of the objects arrays).

[ärkefiende]

Yeah Lugaru :D

well, you may try #assaultcube @ Quakenet to get in contact with some

[kas1e]

@arkefiende

Yeah Lugaru :D

Check some screenshots of os4 version here :)

@all
Btw ! I think iam almost closed for now ! By some unluck i missed that Render() function much bigger than i post here (just miss that there was no closed braket, but all was looks like function are ends), and for now, i found exactly line where crash is happenes:

At the very end of Render() function:

           loopi(numdyndraws)
            {
                const drawcall &d = dyndraws[i];
                if(hasDRE && !builddlist) {}//glDrawRangeElements_(d.type, d.minvert, d.maxvert, d.count, GL_UNSIGNED_SHORT, &dynidx[d.start]);
                else {glDrawElements(d.type, d.count, GL_UNSIGNED_SHORT, &dynidx[d.start]);};
            }

The crash happens exactly on the glDrawRangeElements_

Which are in protos.h:

// GL_EXT_draw_range_elements
extern PFNGLDRAWRANGEELEMENTSEXTPROC glDrawRangeElements_;

And in rendergl.cpp (where is Render() function):
PFNGLDRAWRANGEELEMENTSEXTPROC glDrawRangeElements_ = NULL;

Which in <gl/glext.h> defined as :

typedef void (APIENTRYP PFNGLDRAWRANGEELEMENTSEXTPROC) (GLenum mode, GLuint start, GLuint end, GLsizei count, GLenum type, const GLvoid *indices);

Maybe have any ideas there ? For sure it looks like something wrong with that extension, or maybe need some additions. Without that line, i can see now hands/guns, but when i fire , guns are clears (and i not see them), and, when i connect to some servers, some textures heavy blinking, i see no bots / other players. I think its all because of that line exactly.

If anyone have any ideas: they highly welcome. Or maybe anyone can write a other replacement for that glDrawRangeElements_, which will not relis on all tha extensions, just maybe something like void glDrawRangeElements_ ( blablab );

[tempest]

If it still crashes, then the problem lies within Assault cube.

Did you tell him that the error is a SIGBUS?

Other than that, you could ask eihrul if you see him around - he's the OpenGL guru here.

EDIT: Just to make this clear, I'm not an AC developer.

[kas1e]

Did you tell him that the error is a SIGBUS?

SIGBUS its just say GDB, which works wrong for us. So there is in general no SIGBUS, but some kind of heavy error anyway.

Other than that, you could ask eihrul if you see him around - he's the OpenGL guru here.

Thanks.

I have good progress: I add to our opengl glDrawRangeElementsEXT fucntion, and replaced by this in render() glDrawRangeElemtes_ (which in general do the same as i understand). And now, game starts, all renders, and for now i even trying to kick some asses on some servers. There is video:



Still, there is some strange errors:

1. I cant kill any bot. I.e. i can fire, but its like nothing happens to them.
(but i can for example kill bots by knife).

2. Pistolet just not works. I.e. i press "2", have pistolet, trying to fire, and nothing. Like its empty, but its not.

[tempest]

That's cool. However, I really wonder why you seem to be hitting the air in front of you all the time. No idea what's going on there...

[kas1e]

That's cool. However, I really wonder why you seem to be hitting the air in front of you all the time. No idea what's going on there...

Did you mean when i do fire ? Yep. Looks strange for me too. Maybe by exactly the same problem, pistolet not works too. I think about that:

1. maybe latest SVN code have some bugs, maybe for me will be better to use latest public branch code.

2. maybe somethere in code, i use some glSomethingEXT , which in reality not present in our MiniGL (only dummy includes), and while it not give a crash, by some strange reassons, it can give us such problems.

3. Also very possible, that somethere are little/big endian issues. As i see, AC officially now have PPC binaryes , only x86, so very possible that there is something ..

4. Something wrong somethere with type defines, like for example its INT, but should be UINT, or CHAR, but should be unsigned char, and while on x86 its works as expected, on ppc (maybe) it give something wrong. Because all that "fire in air", and not working postolet, make me think about a little, but still mistakes with all that types,etc

What you think ?

[kas1e]

@tempest
I found from where come problems with "cant kill bots" and "fire in the air" , it come from rendergl.cpp, in that piece of code:

void readdepth(int w, int h, vec &pos)
{

glReadPixels(w/2, h/2, 1, 1, GL_DEPTH_COMPONENT, GL_FLOAT, &cursordepth);

vec screen(0, 0, depthcorrect(cursordepth)*2 - 1);
vec4 world;
invmvpmatrix.transform(screen, world);
pos = vec(world.x, world.y, world.z).div(world.w);
}

For that piece of code, i have in shell all the time while play in game:

MISSING ARGB PACK SUPPORT FOR GL_DEPTH_COMPONENT/GL_FLOAT

Dunno what it mean in human words, but as far as i understands, it fucks on the z-buffer depth reading. There is what author write before that fucntion in comments:

// find out the 3d target of the crosshair in the world easily and very acurately.
// sadly many very old cards and drivers appear to fuck up on glReadPixels() and give false
// coordinates, making shooting and such impossible.
// also hits map entities which is unwanted.
// could be replaced by a more acurate version of monster.cpp los() if needed

So looks like it very well known problem. I trying to found that "mosnter.cpp" file with los() fucntion, but have no luck. For sure it can be changed somehow, but there need some opengl guru ..

[tempest]

I can't believe it. They seriously rely on an OpenGL depth test to find the world target? Now that explains something.

I'm working on replacing that with a sane method, might take a few hours though.

[tempest]

EDIT: Got it. The new method checks for mapmodels too. Still, I'm not sure if this fix is a gameplay-relevant change (you can e.g. shoot through parts of fences), so better ask a dev before you play online with that.

Again, just comment the current content of the readdepth() function and put this in there:

[SELECT ALL] Code:

float yaw = camera1->yaw-90, pitch = -camera1->pitch;
    vec from = camera1->o, dir, surface;

    float sin_yaw = sinf(yaw*RAD);
    float cos_yaw = cosf(yaw*RAD);

    float sin_pitch = sinf(pitch*RAD);
    float cos_pitch = cosf(pitch*RAD);

    dir.x = cos_pitch * cos_yaw;
    dir.y = cos_pitch * sin_yaw;
    dir.z = -sin_pitch;
    
    vec ray = dir;
    float dist = raycube(from, ray, surface);
    if(dist < 0) dist = 1000.0f;                // if skymap was hit, dist is always -1 ...
    pos = vec(dir).mul(dist).add(from);

    loopv(ents)
    {
        entity &e = ents[i];
        if(e.type != MAPMODEL) continue;
        if(from.dist(vec(e.x, e.y, e.z)) < dist && intersect(&e, from, pos))
            dist = from.dist(vec(e.x, e.y, e.z));
    }

    pos = dir.mul(dist).add(from);  // once again, now with correct dist

[kas1e]

@Tempest
You rokz hard ! It works ! I kick some asses for now in multiplayer + no more "fire in the air" ! Thankt a lot !

Maybe you can also help me with the same replacement, but for Cube1 ? There is how function looks like for cube1:

// find out the 3d target of the crosshair in the world easily and very acurately.
// sadly many very old cards and drivers appear to fuck up on glReadPixels() and give false
// coordinates, making shooting and such impossible.
// also hits map entities which is unwanted.
// could be replaced by a more acurate version of monster.cpp los() if needed

void readdepth(int w, int h)
{
glReadPixels(w/2, h/2, 1, 1, GL_DEPTH_COMPONENT, GL_FLOAT, &cursordepth);
double worldx = 0, worldy = 0, worldz = 0;
gluUnProject(w/2, h/2, depthcorrect(cursordepth), mm, pm, viewport, &worldx, &worldz, &worldy);
worldpos.x = (float)worldx;
worldpos.y = (float)worldy;
worldpos.z = (float)worldz;
vec r = { (float)mm[0], (float)mm[4], (float)mm[8] };
vec u = { (float)mm[1], (float)mm[5], (float)mm[9] };
setorient(r, u);
};

and setorient() its:

vec right, up;
void setorient(vec &r, vec &u) { right = r; up = u; };

We have released cube1 for os4 already, but because of the same choords bug we cant "fire" normally. If you can help here in the same way, it will be just uber-cool.

Btw, related to assault cube, i still have problems with "pistols". And with default one (1 gun), and with pistol-pack with 1 gun per hand. I.e. i see it in hands, i can choice it by pressing "2" key, but when i press mouse button for fire, nothing happens. I.e. like just empty or kind (but it is not). Did automat and postol handles different by code in term of GL calls or kind ?

[kas1e]

@Tempest
A bit offtopic: still trying to fix the same problem in Cube1, and found that monsters.cpp with los() function are present here, and that how it looks like:

bool los(float lx, float ly, float lz, float bx, float by, float bz, vec &v) // height-correct line of sight for monster shooting/seeing
{
if(OUTBORD((int)lx, (int)ly) || OUTBORD((int)bx, (int)by)) return false;
float dx = bx-lx;
float dy = by-ly;
int steps = (int)(sqrt(dx*dx+dy*dy)/0.9);
if(!steps) return false;
float x = lx;
float y = ly;
int i = 0;
for(;;)
{
sqr *s = S(fast_f2nat(x), fast_f2nat(y));
if(SOLID(s)) break;
float floor = s->floor;
if(s->type==FHF) floor -= s->vdelta/4.0f;
float ceil = s->ceil;
if(s->type==CHF) ceil += s->vdelta/4.0f;
float rz = lz-((lz-bz)*(i/(float)steps));
if(rz<floor || rz>ceil) break;
v.x = x;
v.y = y;
v.z = rz;
x += dx/(float)steps;
y += dy/(float)steps;
i++;
};
return i>=steps;
};

And example of usage:

bool enemylos(dynent *m, vec &v)
{
v = m->o;
return los(m->o.x, m->o.y, m->o.z, m->enemy->o.x, m->enemy->o.y, m->enemy->o.z, v);
};

Still, functions are bool, return only one value, and as input want many of them. As author say that is can be replaced, so there is something pretty easy should be for anyone who know all that mathematic stuff.

In end i trying to do something like you do for assaulc cube:

readdepth(....)
{
.. code from los() ...

setorient(r, u); // that is need it for later usage
}

Maybe you can help there as well ?