Tried to port another game to our os, and it crashes for me in some function, which is called read_level() , and, looks like quite possible endian issues.. Have anyone clue ? There is:
} while ((lcode != lvlCode || acode != areaCode) &&
!feof(file) && lvlCode < 80);
for (i=0;i<lvlWidth/SPR_SIZE;i++)
for (j=0;j<lvlHeight/SPR_SIZE;j++)
for (k=0;k<3;k++)
tiles[i][j][k] = tilebackup[i][j][k];
if (bkgtemp < 1 || bkgtemp > BKG_MAX - 1) bkgtemp = 1;
if (musictemp < 0 || musictemp > MUSIC_MAX - 1) musictemp = 0;
clear_selection();
switch_music(musictemp, 0);
switch_background(bkgtemp);
fclose(file);
} else {
loaderror = 1;
if (lvlCode < 80 || creatormode)
set_up_input("The file was not found",1,-1,-1);
else set_up_input("Make the level first!",1,-1,-1);
}
}
Crashes exactly on the fread(&tilebackup[i][j][k], sizeof(int), 1, file); line, and all that probably because of [i][j][k] and way how it reads and later uses and where endianes can make differences ?
Int4, char 1, yep :) "thing" is structure "Thing", in my case there it was 184 :)
So i converted all stuff which come till fread to "thing" which is declared as "Thing things[THINGMAX]" " . Did you mean i need to byteswap all the items in that structure which are bigger than 1 byte ? There is:
typedef struct thing {
float x, y, vx, vy, stickx, sticky, startx, starty;
int speed, jump, jumpdelay, teledelay;
int width, height;
int dir;
int timer, status;
int link, islinked;
float anim;
int telething, ontele;
int dead;
int collide[4];
int colltarget[4];
int type, subtype;
int pickup, icy, gravmod, floating, solid, deathtouch, crashspeed;
int nomove, nohmove, novmove, infront, inback, animate;
} Thing;
There is also Floats and few arrays :(
I of course can byteswap each elemnt just like: things->speed = SDL_SwapLE32(things->speed); and so on, and skip arrays (if they ok to be not byteswapped), and for floats find SDL_SwapFloatLE (yeah!)
Or maybe i can somehow in the .h point out that all strcuts should be endian aware, like maybe pragma packs or how it was..
And that crap worry me as well: fread(&tilebackup[i][j][k], sizeof(int), 1, file); tilebackup are int tilebackup[LVLMAX][LVLMAX][3]; which in my case int[500][500][3].
Is tht endian problem don't affect arrays, just makes them stored reverse, but still no problems and have no needs to convert ? I mean last string there.
Edited by kas1e on 2018/1/17 21:16:37 Edited by kas1e on 2018/1/17 21:31:44 Edited by kas1e on 2018/1/17 21:48:20 Edited by kas1e on 2018/1/17 21:49:46 Edited by kas1e on 2018/1/17 22:03:49
The endianness difference will cause every multi-byte field (all the ints, floats, etc) in that structure to be stored backwards, that is, all the bytes are stored in the opposite order. The contents of each byte are unaffected.
So, if the structure contains these values:
int speed = 0x12345678;
int jump = 0x90abcdef;
...then they will be stored (little endian) like this:
speed: Rel addr 0: 78 56 34 12
jump: Rel addr 4: ef cd ab 90
Strings are usually OK, as both big- and little-endian store strings starting from the lowest address (This also causes problems when you try to cast string data as a multi-byte integer).
One way to fix it is to read the data as big-endian, then go through and reverse each multi-byte field afterwards. Another is to read all the data with your own version of sscanf(), reversing each field byte by byte.
@capehill,tony I have another idea: maybe easy route to convert just all data files from which fread happens to big endian order and keep game's code as it ?
edit: but that probably unpossible, as there can be all kind of types, some of which need to swap, some of which don't , as well as it all shifts, so we can't just convert whole data file like "its all ints" ..
Tried to make replacement function, but fail. Will back to SDL_Swap32LE() again .. Its just too much of freads there , and they all of different use. For example simple ones are fine to replace are:
There is current version of that mess if anyone in interst to see, changes i do done via #if SDL_BYTEORDER == SDL_BIG_ENDIAN. You can see how lots of fread and fwrites here, but i firstly want to replace only freads().
@capehill Yeah, code looks like C, but assembler way :) probably you comment swaps in function which read saves, and they write by fwrite() when its all runs on our cpu, so already converted for fread.
Didnt you release it by any reassons ? I may try to compile latest version (1.2.1) and put on os4depot, if you didnt back in past of course :)
@Capehil Oh i see now, it still was messy so you probably just give up with it. There some parts just missed, and in menu, and in game itself. But i will use your work as reference if you doesn't mind, just want to make it work as it works on win32 :)
@Capehill Done with :) You was very close, just 2 issues was in your attempt: you just overlook one definition in that Thing structure (int status), so it wasn't byteswapped. And, there was about 7-8 floats, so pure SDL_Swap32LE did't go, and once i use SDL_SwapFloat32LE from SDL2 for them, it all start to works correctly, yeah!
There is:
Menu:
(press open in new tab for fullscreen)
In game:
(press open in new tab for fullscreen)
And ready port with all fancy things like icons and crap: Beret_os4
@All If someone have time, plz give it a test. It through will take a little of your time to unerstand contol (check options and read helpers), but once you done, game is fun enough.
@mufa Damn, that because when i made archive, i just use "a -r", without "-e" (pack empty directories), and lha just skip packing empty folder "saves", so game's code didn't find it, and can't create save files, and because of that also can't open a menu in the game.
In other words, just create in root of beret "saves" directory and all should be fine, i.e. saving will works, and you will have a tasty menu in the game as well when press "esc". (btw, alt+enter to switch to window mode).
I reupload new fixed archive in same location: Beret fixed
If you doesn't mind check if all is ok afer unpacking now. Thanks for testing!
@all After a while of playing in Beret, i find it VERY worth of time we spend on porting !
Its really good stuff, remind me some modern "bolder-dash" + "incridebly machine" combo. Levels are very well polished, mathematic and physic in control very nice too. Checking the forums and thread about game, its one of good games for all times for some of them.
But that not all ! Game itself have inside custom level editor, which is unlockable. I.e. you can't just open it right away, you should complite the game first (get 120 midalions). But for those who can't, there is cheatcode : in the "map title", type "evilevilevil", and editor will opens.
And that not all, once you do so (i.e. open level editor), you can play other's ppls levels and maps. There was lots of level and maps, and the best ones are there: http://www.moddb.com/games/beret/addons
Through, usage of them are not easy enough (you unpacking any of addons to your "rooms" directory, then once you run game, with unlocked level editor, you can go to that level editor, and play levels like they only designed). Yeah, kind of suck, but author didn't make it all be structured better when he works on, and now probably will not.
For example i grabs few screebshots from different addons:
I haven't had a chance to try your version yet but my old binary is quite slow on Sam440. It seems to draw lots alphablended stuff so if it uses actually SDL_BlitSurface, compositing might help.