Spring for low-end and buggy GFX
Moderator: Moderators
Re: Spring for low-end and buggy GFX
@Tim, it is very feasible/easy/nice if proper separation would be here, but to get there is.. either never gonna happen, or take 5 years or so.
Re: Spring for low-end and buggy GFX
Meaning you can make a lua call to just stop rendering the worldview, and arse in your own lua to draw it instead? :0Map Rendering, Unit Rendering, just any rendering can be done in Lua.
Re: Spring for low-end and buggy GFX
yes...Anarchid wrote:Meaning you can make a lua call to just stop rendering the worldview, and arse in your own lua to draw it instead? :0
Spring.SetDrawGround (false) Spring.SetDrawSky (false) Spring.SetUnitNoDraw ( ),...and then use gl to draw whatever you want.
But dont know how that helps when the old/crappy drivers/whatever computers crash before the game is fully loaded and can never call those Lua commands?
Re: Spring for low-end and buggy GFX
Maybe someone could try to do that separation thing then. Sounds like between Lua capabilities and separation lies everything OP intends, and more to boot. Or is it *that* ominously impossible to achieve? I have no idea myself here, but i'd certainly like spring to work on low-end, at least if for the AI stuff and whatnot.
(and if it runs on core 2 with 10 fps with everything shutdown - and i mean everything, with terrain rendered as mesh and all currently available settings to minimum and on minimal reso - due to crappy card/crappy drivers, and still having to go through all the extra rendering load, that makes am disappoint kinda)
(and if it runs on core 2 with 10 fps with everything shutdown - and i mean everything, with terrain rendered as mesh and all currently available settings to minimum and on minimal reso - due to crappy card/crappy drivers, and still having to go through all the extra rendering load, that makes am disappoint kinda)
Re: Spring for low-end and buggy GFX
Awesome, I'll try those in Pre-game and see what happens.knorke wrote:Spring.SetDrawGround (false) Spring.SetDrawSky (false) Spring.SetUnitNoDraw ( )
jK wrote:You can't ruin Spring cause you don't got git access.
O'rly? Scared much?
Re: Spring for low-end and buggy GFX
I'm on a 6 year old laptop with a nvidia Quadro NVS120M (essentially a GeForce 7400 Mobile with better OpenGl). I'd be willing to do a bit of testing if needed.
Re: Spring for low-end and buggy GFX
!RAISES HAND!SpliFF wrote: My opinions were attacked first. I'm defending them.
I *was* supportive bro...
Re: Spring for low-end and buggy GFX
I'd be happy if one Spring dev was concerned with maintaining low end hardware compatibility, and with ATI support.
I'm concerned when I see so many devs and mod makers considering upgrading the only answer, because I know the reality isn't like that. There are kids who play on their parent's PC, adults who'd like to play on their notebook while commuting, people who'd like to play when not a home, like at work, at friends, at relative.
Eh, even myself, I'm pretty much a nerd, spending all free time on computer, playing, modding or talking about PC video games, and yet my main gaming PC is 5 years old (have money, but cba to spend days rebuilding and reinstalling).
So I'm a bit sad to see SpliFF getting so agressively put down.
That said, I don't know enough about SpliFF skills or Spring internal to really know if it's justified.
I'm concerned when I see so many devs and mod makers considering upgrading the only answer, because I know the reality isn't like that. There are kids who play on their parent's PC, adults who'd like to play on their notebook while commuting, people who'd like to play when not a home, like at work, at friends, at relative.
Eh, even myself, I'm pretty much a nerd, spending all free time on computer, playing, modding or talking about PC video games, and yet my main gaming PC is 5 years old (have money, but cba to spend days rebuilding and reinstalling).
So I'm a bit sad to see SpliFF getting so agressively put down.
That said, I don't know enough about SpliFF skills or Spring internal to really know if it's justified.
Re: Spring for low-end and buggy GFX
there is more then one dev that is concerned about low end hardware, and i would not mind if there was more focus on that even, but more ATI related work... thats just asking for too much.
it is a reality that ATI is shit, and many have ATI, but that does not mean that we have to pay for that. the only ones that should pay for it. is ATI. the best thing to do would be... if we could somehow direct all the anger from the end users (gamers) directly to ATI. that would be partly feasible for crashes, but very hard for glitches already. we could add something like the MT Lua warning for ATI users, maybe in form of a loading screen, that only shows for ATI users, like. every 5th game ro so, and a small load-screen overlay the other 4 times.
it is a reality that ATI is shit, and many have ATI, but that does not mean that we have to pay for that. the only ones that should pay for it. is ATI. the best thing to do would be... if we could somehow direct all the anger from the end users (gamers) directly to ATI. that would be partly feasible for crashes, but very hard for glitches already. we could add something like the MT Lua warning for ATI users, maybe in form of a loading screen, that only shows for ATI users, like. every 5th game ro so, and a small load-screen overlay the other 4 times.
Re: Spring for low-end and buggy GFX
Just a quick update to say I'm much closer now to finding the source of the radeon/KMS bug.
It's taken me a couple of days because I've literally had to go through the rendering system line by line to establish where the error is happening and see what I could safely disable without breaking other things (remembering it isn't an actual "crash" so I can't just use a backtrace). I added a new log subsystem (Shaders), a couple of config vars (ie, Shaders = 0) and about 60 new log lines at various points in the SpringApp, Game, WorldDrawer, Shader and Texture rendering pathways and finally discovered that the kernel message coincides with the SDL_GL_SwapBuffers() call at the bottom of SpringApp::Update().
First thing I tried after that was disabling "Page Flipping" in the X11 config but that didn't fix it.
However it was apparent the SwapBuffers call wasn't the problem in itself because it's used throughout the pre-game load screens without triggering the error. That means something else in the render pipeline was doing something to the buffer that the radeon driver doesn't like.
So I went through CGame::Draw() and disabled absolutely every rendering-related call, then added them back one by one and I now know for certain that the problem is triggered by something in the function mouse->DrawCursor()
I'm going to look into that now but if anyone knows anything that might be relevant feel free to point it out. I know the mods I'm using for testing both have custom cursors so that's what I'll be looking at first. I'll also see if using a hardware cursor works as a workaround.
UPDATE: Yes, HardwareCursor = 1 in .springrc appears to stop the kernel messages and allows Spring to progress beyond "Finalizing..."
UPDATE 2: Scratch that. Hardware Cursors only fixed my hacked build. There must be other parts of the rendering system that trigger the same bug.
It's taken me a couple of days because I've literally had to go through the rendering system line by line to establish where the error is happening and see what I could safely disable without breaking other things (remembering it isn't an actual "crash" so I can't just use a backtrace). I added a new log subsystem (Shaders), a couple of config vars (ie, Shaders = 0) and about 60 new log lines at various points in the SpringApp, Game, WorldDrawer, Shader and Texture rendering pathways and finally discovered that the kernel message coincides with the SDL_GL_SwapBuffers() call at the bottom of SpringApp::Update().
First thing I tried after that was disabling "Page Flipping" in the X11 config but that didn't fix it.
However it was apparent the SwapBuffers call wasn't the problem in itself because it's used throughout the pre-game load screens without triggering the error. That means something else in the render pipeline was doing something to the buffer that the radeon driver doesn't like.
So I went through CGame::Draw() and disabled absolutely every rendering-related call, then added them back one by one and I now know for certain that the problem is triggered by something in the function mouse->DrawCursor()
I'm going to look into that now but if anyone knows anything that might be relevant feel free to point it out. I know the mods I'm using for testing both have custom cursors so that's what I'll be looking at first. I'll also see if using a hardware cursor works as a workaround.
UPDATE: Yes, HardwareCursor = 1 in .springrc appears to stop the kernel messages and allows Spring to progress beyond "Finalizing..."
UPDATE 2: Scratch that. Hardware Cursors only fixed my hacked build. There must be other parts of the rendering system that trigger the same bug.
Re: Spring for low-end and buggy GFX
I think this is a laudable effort, and I'm glad you're making it, SpliFF.
-
varikonniemi
- Posts: 451
- Joined: 03 Jul 2011, 11:54
Re: Spring for low-end and buggy GFX
Yes we all know ATI sucks. I bought an 6870 some months ago and sold it some days ago primarily because of the horrible state of ATI linux and openGL support.
spliff you are doing great work.
spliff you are doing great work.
Re: Spring for low-end and buggy GFX
With jKs help I've found that adding LoadingMT = 0 to ~/.springrc resolves the radeon CS parser errors. Likely suspect is some side-effect of the "offscreen context" code used to create textures in secondary threads (threaded loading also happens in non-MT spring executable).
In the process of debugging this I've found several areas of the code that could be given low gfx fallbacks so I'll continue the work to make a low end version of Spring. It will take some time to do this cleanly though because the rendering code is spread around a lot of files.
In the process of debugging this I've found several areas of the code that could be given low gfx fallbacks so I'll continue the work to make a low end version of Spring. It will take some time to do this cleanly though because the rendering code is spread around a lot of files.