chrisf

It seems someone got it working....

Ok I will try this weekend and report back.

When I get some free time this weekend I will try again. So basically every dds file needs to be resized and the game should accept it?

My main concern is when I compile from source and mess with anything at all it doesn't work... My main concern is when I compile from source and mess with anything at all it doesn't work...

Is there anything that can do this on the fly at driver level? Or am I Barking up the wrong tree?

I can't get past the menus at all now, experience either a segfault or some other bug. Probably worth me contacting the driver developer to see if he can shed any light on the issue. Reviving this topic, does anyone know of a way to shrink texture sizes on the fly? It seems textures are the issue here and otherwise it should run okay. I know on Android you can do this in GLTools but I don't know of an alternative for raspbian.

I complied the latest GIT successfully and to my amazement... you can actually get into the map! It's not without problems though... this is with the GPU memory set to 160mb (shared with 1GB of system ram). After a few minutes it freezes and hard locks the system. You can see it getting slower and slower... I should probably run some metrics. Interestingly textures work so I don't know if it's getting passed uncompressed from the game or if the driver is decompressing them. This is actually my third attempt at running the game or so. The first time, as it was streaming the textures in, it actually loaded them all, but as higher quality versions started to appear, the game messed up as it does here. Is it possible to have a "low quality" setting which locks it to the muddy looking versions for testing? Next tasks: Proper profiling of RAM usage (GPU and System) Poring through logs etc to find out where the display driver is messing up (if it is) Filing bug reports (once I have useful feedback)

You were right. It's now past that stage. Running make now, also only on 1 core. Very slow as you can imagine so we'll see if it works. I still expect it will behave the same as the old alpha so I'm probably going to re encode the textures as low resolution versions so we can see if the game crashing is a memory problem.

This is what I get when trying to compile 0 A.D from Git... works great on Ubuntu on the desktop PC. Looking around the web suggests SpiderMonkey is a pain to compile on arm. Can't try using make until this part gets sorted. Will let you know.

Here's the important business from the Terminal: ERROR: CRenderer::EndFrame: GL errors 1285 occurred WARNING: Fancy Effects framebuffer object incomplete: 0x8CDD GL_OUT_OF_MEMORY OpenGL error(s) occurred: 0505 GL_INVALID_VALUE OpenGL error(s) occurred: 0501 Draw call returned Invalid argument. Expect corruption. Segmentation fault I've currently got 64mb VRAM set so I'll increase this and see if it helps. I remember it also not working at 224mb though... Also left a post over at the Xonotic forums for DivVerent who created S2TC (the free encoder/decoder for S3TC) as he might be able to help me come up with some on-the-fly decoding solution for the S3TC textures 0 A.D uses. EDIT1: Here's the link: http://forums.xonotic.org/showthread.php?tid=6080 The game crashes with any VRAM amount set. I think it's not just a texture problem because on the OpenMW forum they found that their game DOES run but with pink shapes: https://forum.openmw.org/viewtopic.php?f=8&t=2850&start=10 I'm going to do some more research over the next few days and see if it's bugs in the driver, handling shaders, etc. Does anyone have a low resolution texture pack for 0.A.D I could try?

Would the easiest thing right now simply to be to implement uncompressed textures and different texture quality modes? I'm sure there's a way to force ETC on the VideoCore IV. I'm going to fire the Pi3 back up again later tonight and copy the error messages in here. Does anyone else have experience of compiling 0A.D for the Raspberry Pi? I'd like to test with Alpha 19. Also, when the game crashes where does it store crashlogs? Kind regards.

I'd like to know how React OS fares with OpenGL Acceleration. I'm not aware of what GPU drivers it works with. Older cards like GeForce 2 seem to be working so it's finding something new enough to be compatible with the game.

Okay, I got hold of a Raspberry Pi 3. There's now an experimental Gallium VC4 driver for the Broadcom VideoCore4 graphics chip in this device. OpenArena runs perfectly as you might expect as it is a common test case and complete. Anyway, there was 0.A.D in the Raspbian repository, albeit an old version, so I thought why not give this a go? It runs! At least through the menus, when you try to load a map it complains in the terminal about GL errors (this is with all effects disabled and quick and ugly water selected and closes. Not bad though eh? The open source driver that I'm using here supports desktop OpenGL 2.1 according to glxinfo as well as OpenGL ES. However I believe the hardware does not support S3TC and only supports... EGL? Whatever the compression Android uses is. Just thought I'd leave this here for someone to enjoy. Kind regards.