Barony test thread

@Kas1e

X1000 A-Eon beta test set up:

LIBGL: Initialising gl4es
LIBGL: v1.1.1 built on Dec 20 2018 17:02:06
LIBGL: Using GLES 2.0 backend
LIBGL: Using Warp3DNova.library v1 revision 61
LIBGL: Warning, your Warp3DNovaBase.library is too old, minimum is v1.62, please update!
LIBGL: Using OGLES2.library v1 revision 22
LIBGL: OGLES2 Library and Interface open successfuly
LIBGL: Targeting OpenGL 2.0
LIBGL: Forcing NPOT support by disabling MIPMAP support for NPOT textures
LIBGL: Current folder is:RAM Disk:Barony
[19-26-31] Data path is PROGDIR:
[19-26-31] Output path is PROGDIR:.barony
LIBGL: Hardware test on current Context...
LIBGL: Hardware Limited NPOT detected and used
LIBGL: FBO are in core, and so used
LIBGL: PointSprite are in core, and so used
LIBGL: CubeMap are in core, and so used
LIBGL: BlendColor is in core, and so used
LIBGL: Blend Substract is in core, and so used
LIBGL: Blend Function and Equation Separation is in core, and so used
LIBGL: Texture Mirrored Repeat is in core, and so used
LIBGL: Extension GL_OES_element_index_uint detected and used
LIBGL: Extension GL_EXT_texture_format_BGRA8888 detected and used
LIBGL: Extension GL_OES_texture_float detected and used
LIBGL: high precision float in fragment shader available and used
LIBGL: Extension GL_EXT_frag_depth detected and used
LIBGL: Max vertex attrib: 16
LIBGL: Max texture size: 16384
LIBGL: Max Varying Vector: 32
LIBGL: Texture Units: 8(8), Max lights: 8, Max planes: 6
LIBGL: Extension GL_EXT_texture_filter_anisotropic detected and used
LIBGL: Max Anisotropic filtering: 16
LIBGL: Hardware vendor is A-EON Technology Ltd. Written by Daniel 'Daytonta675x' Müßener @ GoldenCode.eu
LIBGL: OGLES2 Library and Interface closed

@TiredOfLive
Cool, so all fine ? Music, sounds, gameplay, etc ?

@ddni
Yeah, seems works, but you need datafiles

@kas1e

I have dat files. Runs ok, a bit slow as you said.
Game quits dirty... Odyssey hard system crash when run after playing Barony.

@ddni
On x1000 shouldnt be slow. Are you on sfs ? If so, try from ngfs.

As for dirty exit, its probably odyssey, not barony :) Try after reboot, etc. Be sure all datafiles correct and dirs of size i show, or there can be memory leaks if no all data files correct

@K-L
Try plz binary from post 114, that one: https://www.sendspace.com/file/887my2

If all ok on your side as well, i will update os4depot's archive

@kas1e

Yeah game runs now, music and sound all ok.
Mouse on main menu is a bit slow but game play is fine.
DSI error on end of game.

Cheers

@kas1e

I'ts ok but when I lose the game and wanted to ga bakc to main menu, game crashed.

log.txt:

[23-54-22] You die...
[23-54-22] deleting savegame in 'PROGDIR:.barony/savegames/savegame0.dat'...
[23-54-22] deleting savegame in 'PROGDIR:.barony/savegames/savegame0_npcs.dat'...
[23-54-34] LoadMap PROGDIR:/maps/mainmenu1.lmp


CrashLog:

Crash log for task "Barony.exe"
Generated by GrimReaper 53.19
Crash occured in module Barony.exe at address 0x7CA76C30
Type of crash: DSI (Data Storage Interrupt) exception
Alert number: 0x80000003

Register dump:
GPR (General Purpose Registers):
0: 7CA7DD90 45A389D0 AEDA5BF9 45A3F680 00000001 00000001 00000100 00000000
8: 455B1DD0 00000001 00000000 59D84098 00000000 4B4AB820 61BC88F0 59D54000
16: 7CAD2650 00000000 45F56010 45D9B1F0 02B30000 02B30000 00000000 00000007
24: 6FF8C180 00000002 46842888 00000000 00000001 53680000 53680000 3D801E00


FPR (Floating Point Registers, NaN = Not a Number):
0: nan 0.25 0 0
4: 1 -0 -0 -1
8: 9 0.271934 7.63286e-10 0.259624
12: 0.25 -1 0 0
16: 0 0 0 0
20: 0 0 0 0
24: 0 0 0 0
28: 0 0 0 0

FPSCR (Floating Point Status and Control Register): 0xAA004100


SPRs (Special Purpose Registers):
Machine State (msr) : 0x0200B030
Condition (cr) : 0x2EF5BDA0
Instruction Pointer (ip) : 0x7CA76C30
Xtended Exception (xer) : 0x02027504
Count (ctr) : 0x00000000
Link (lr) : 0x00000000
DSI Status (dsisr) : 0x02046428
Data Address (dar) : 0x00000000



680x0 emulated registers:
DATA: 94D9C700 00000000 00000000 00000000 00000000 00000000 00000000 00000000
ADDR: 6FFB8000 95059000 00000000 00000000 00000000 00000000 00000000 45A39170
FPU0: 0 0 0 0
FPU4: 0 0 0 0



Symbol info:
Instruction pointer 0x7CA76C30 belongs to module "Barony.exe" (PowerPC)
Symbol: _Z14OPENAL_SetLoopP12OPENAL_SOUNDc + 0x10 in section 1 offset 0x0000BC0C

Stack trace:
Barony.exe:_Z14OPENAL_SetLoopP12OPENAL_SOUNDc()+0x10 (section 1 @ 0xBC0C)
Barony.exe:_Z9playmusicP13OPENAL_BUFFERbbb()+0x14c (section 1 @ 0x12D84)
Barony.exe:main()+0xe1c (section 1 @ 0x68448)
native kernel module newlib.library.kmod+0x000020a4
native kernel module newlib.library.kmod+0x00002d0c
native kernel module newlib.library.kmod+0x00002ee8
Barony.exe:_start()+0x170 (section 1 @ 0x1920)
native kernel module dos.library.kmod+0x000255c8
native kernel module kernel+0x000420ac
native kernel module kernel+0x000420f4

PPC disassembly:
7ca76c28: 7d292110 subfe r9,r9,r4
7ca76c2c: 99230308 stb r9,776(r3)
*7ca76c30: 892a0004 lbz r9,4(r10)
7ca76c34: 2f890000 cmpwi cr7,r9,0
7ca76c38: 4cbe0020 bnelr+ cr7

System information:

CPU
Model: P.A. Semi PWRficient PA6T-1682M VB1
CPU speed: 1800 MHz
FSB speed: 900 MHz
Extensions: altivec

Machine
Machine name: AmigaOne X1000
Memory: 2097152 KB
Extensions: bus.pci bus.pcie

A1X5000
Amiga OS 4.1FEupd1 :))))))


Just gonna crash, then I update the thread!

Maybe there is a problem here: SFS/00 vs SFS/02?

@Spectre660 use SFS/00
@amig_os use SFS/02

@amig_os
What problem you mean ? For Spectre all works with binary from post 114

@khayoz
You need to use binary from post 114

@k-l
Seems again 0x0000000 and loosed IDOS..

@tireoflive
DSI same like for K-l with 0x0000000 ?

@Spectre
Can you confirm crash K-L have ?

@K-L
Try plz this one:
https://www.sendspace.com/file/v3pi77

There i again open dos library / IDOS and close in the playmusic() routine. All of which suck, as why it didn't works on public ones are strange, but whatever if it make it works.

Check plz

@kas1e

Great work ! Everything is working correctly now ! Thank you !

@kas1e

If I understand it correctly, the IDOS symbol should be provided by the C lib startup code. A "helloworld" example shows symbol here as "S" and pointer is non-zero. With GCC4.

Barony seems to use CMake so I couldn't see the makefile that produces the binary.

Assuming pointer is non-zero right in the main() function, I don't know how it could be NULL later unless some cleanup code (?) is ran or heap corruption? Strange.

@Capehill
Cmake used for build objects, but final linking line are my own, which i do at end manually. I am not at home, but will show the line later.

Strange thing that all fine in all beta setups (and on x1000, and on x5000, and on sam460).

I at moment have a guess that it maybe related to newer gcc and native threading. If you check adtools repo, few days ago there was some fix in native threading , but dunno if it at all related.

But why problems only on public oses and not on betas.. Maybe elf.library related

And its only from barony's code, which is c++11 / threads

And dunno if in main() IDOS is not null (didnt checked that), i think it can be null as well. Because any call to dos are 0x0000000, once first function called. But #include <proto/dos.h> is here, so wtf..

@kas1e

That last update on post 151 did the trick for me, no more errors.

Cheers

@TiredOFLive, K-L
Aha thanks for confirm, so will do os4upload soon with fixed version.

@Capehill

My linking line are:




There dos calls happens to be from libphysfs.a and libopenal.a (in both cases , their code have #include <proto/dos.h>). So when it firstly start to crash at physfs, we realise that just pure adding of any DOS call inside of initApp() from init.cpp file of barony , even when added #include <proto/dos.h> , fail as well.

I tried to compile simple test cases with any dos call from, but exactly 1:1 the same compiling and linking lines : all works fine, but then, those simple test cases have no needs for all those linker libs of course (which may cause issues).

@Capehill
We also trying to made workaround you mention for SFS/newlib to avoid micropauses , but that didn't help at all. See there:
https://github.com/ptitSeb/Barony/commits/master

Last 3 commits about adding and then removing of that (as it didn't help).

@kas1e

That SFS workaround was added sometime in the last decade so maybe it's not relevant anymore, today.

@all
Reuploaded new version on os4depot, so far changes are:

-- get rid of double "PROGDIR:PROGDIR:" and "PROGDIR:/" constructs (last one cause crashes on SFS). So Barony now works on SFS, but NGFS still _VERY_ recomended, as SFS produce lags in game (you may notice some micro pauses)

-- added workaround to make it works on non-beta OS => on latest public versions IDOS pointer looses in the deep of c++11/native threads from Barony's code somehow, so we open dos.library/IDOS interface again to make physfs and openal works. For next update of OS all will works even as it was, but one more time open dos.library/IDOS make no harm anyway.

-- stack cookie was 100.000, just in case made it 1.000.000 to avoid any possible problems

-- added amigaos4 readme with all necessary information (so everything is more clear how install it all and co).

@All
And thanks all for tests, of course :) If there will be anything else wrong, let us know. Thanks !