MacOS PPC CroMag Rally game port

https://github.com/jorio/CroMagRally

Should be playable even with modest PPC hardware.

Any one could check if this is doable?

There are very few car games fof OS4.

I give it a go : it use SDL2 + OpenGL (so GL4ES). Also it use some external library called Pomme: https://github.com/jorio/Pomme/ which is "A cross-platform implementation of the Macintosh Toolbox C API".

I were able to build that Pomme with no changes, and whole croMagRally too, but in game itself i had to ifndef one function to get locales (seems not implemented in our SDL2), and, it have Win32 specific functions like GetPreferencesFolder() and SysBeep(). Second one of course harmless, and for first one i just return the correct path.

So at this stage game compiles for new clib2, links fine (sdl2 + gl4es) , and when i run it it cry about patches/preferences/etc. So , fixed it in Files.cpp by return progdir: , and then, next run show up the window, then immediately close it, and in the shell i have "Uncaught exception: No ADF magic".

Checking the source code i find it there:



Not sure what did it mean, but it can be endian issues again ..

@kas1e have you build with define TARGET_RT_BIGENDIAN ?

https://github.com/jorio/Pomme/blob/b9 ... es/bigendianstreams.h#L51

@beworld
Nope !:) Rebuils with this define enabled, and it pass this error, window created, but then "can create GL context" or something, i need to check this one later.

@kas1e

Can you share your makefile and changes to compile.. I think it is a good example of SDL2 OpenGL OpenGLX project.

@Sinan



And on linking in links.txt add -athread=native and all that stuff.

Also in files.cpp:



Also headers/platform/Windows/PommeWindow.cpp will be like this:

@kas1e

Hi, can you "printf()" f.Read<UInt64> and see if it matches "0x0005160700020000ULL"

...
0x0005160700020000ULL != f.Read<UInt64>
...

@Javier
Sorry you too late :) See answer #4 to beworld : this flag deal with.

Now i have issues with GL context creation by some reassons, need to understand wtf.

@beworld
On MorphOS GL-Context creates fine ?

@kas1e i just test it

and i can say no problem with context !! i see game... but i have message when i start game : "Skeleton file has wrong version"

I continue to check why



Check maybe here for you : https://github.com/jorio/CroMagRally/b ... 82f2/Source/Main.cpp#L160

Any change for MiniGL? /

@beworld

Something strange happens: i create test case based on game's initialisation (see SDL2 thread), and for minigl no error thrown when do check on GAME_ASSERT(glGetError() == GL_NO_ERROR); , but for gl4es are. So seems or my SDL2 hacks for gl4es , or gl4es itself to blame there.. dunno, need to debug

@ultrt007

At least i tried to build it with minigl, and it builds, binary runs, and show just pink screen with noise in background, so not sure how far minigl version can go, but at least it compiles for sure, so chances for minigl version are high too

@kas1e maybe you can test (same as Vita) that : https://github.com/Rinnegatamante/CroM ... ce/3D/OGL_Support.c#L1176

i see game menu in my side... but seem have bigendian problem

i see that suspect :
https://github.com/jorio/Pomme/blob/ma ... tilities/structpack.h#L52 and https://github.com/jorio/Pomme/blob/ma ... tilities/structpack.h#L33

@Capehill
That the full output from glSnoop when i run test case from SDL2 thread:



I see there :

Shell Process 'test': W3DN_Submit: errCode 0x0
Shell Process 'test': W3DN_Submit: <- errCode 0 (W3DNEC_SUCCESS). Submit ID 24097
Shell Process 'test': OGLES2_glGetError: <- error 0x502 (GL_INVALID_OPERATION)
Shell Process 'test': OGLES2_aglDestroyContext: context 0x615fa2b8


But dunno wtf ..

@Beworld
Strange stuff : if i download from github this game as zip arhive from web, then in file OGL_Support.c i do not have any _vita_ changes. But if i download it from shell via "git clone", then i do have that function. It's like from the web older (or newer?) version of code downloads and it different between web-download and "git clone" one. Strange!

But anyway, if i download via "git clone", then when i compiling i do have that error:



So maybe that why you have errors about skeleton anims ? Do you have same warning/error on your side ?

Currently i fixed it by define the same as for _vita_ :

#define MAX_SPECIAL_DATA_BYTES (8 * 8) // Code is not 32bit compatible

but not sure if that correct for us or not

@beworld

I just commented out error gl checking, and game starts for me too:




It did show me menu, i can operate in, but when i choose the level to start, i do have the same as you : fat warning about wrong skeleton version #, and then exit.

ps. i also have some sound noice by default, but that was easy fixed by change in extern/Pomme/src/SoundMixer/cmixer.cpp :




ps2. Btw, if i didn't do anything, just waiting in menu, then it try probabaly to show some intro/et, and says "ParseBG3DFile: FSRead failed" and also exit. So i assume another Endian issue there.

ps3. Once deal with that game, he do have 3 other good games of the same SDl2/OGl + his Pomme lib use, will be cool to port them all and commit back to the author all aos4/mos changes.

@kas1e yes, i see the sound problem here, i put AUDIO_S16SYS but same , music is ok but sound not really....

@beworld
Just in case created bug-report on his tickets:

https://github.com/jorio/CroMagRally/issues/10

Maybe will be of any help as well

@kas1e

Quote:

My guess is that #version should be "310 es" rather due to uniform location.

@Capehill
Quote:

Right, tried to build this shader as it , and glsnalvalidator fail. Once i replace 120 on 310 es, then it works. I do checked gl4es sources, and found where this shader creates:

https://github.com/ptitSeb/gl4es/blob/master/src/glx/hardext.c#L29

its inside of testGLSL(), which among others things do that:



So code do that : create 3 test shaders, and check if they works, and depends on what happens return what is supported. But when on of them fail, we do have GL_ERROR and so it looks like opengl ERROR for app..

Just not sure it's issue with gl4es or ogles2 ?

In meantime created ticket on gl4es page: https://github.com/ptitSeb/gl4es/issues/394

Maybe we should after all those shaders check somehow made GL_ERROR be empty or something ? Or this shader for 120 should be rewritten to works on 120 as seems just shader wrong ?


EDIT:

Fixed in gl4es by this commit : https://github.com/ptitSeb/gl4es/commi ... 8ab18410932ccd2f96b198f3b

PtitSeb says that shader for 120 looks like this because there is 1 unofficial PowerVR extension that seems to allow that, but he haven't really used it, while the test is in place, so he add reseting of GL_ERROR to gl4es itself , and now all ok for both untouched game's code and test case.