Hi guys, okay with you? my English is weak and I'm using Google Translate, I am Brazilian and I'm enjoying / overseeing the work of you a long time, but never got to play, I install when I click to run it says it stopped responding, I'll post a log of my problem, thank you for your attention and keep at it.
CPU: Intel Pentium 4 3.00GHz
Graphics Card: GeForce FX5200
OS: Windows Vista
exception.log:
System.Reflection.TargetInvocationException: Uma exceção foi acionada pelo destino de uma chamada. ---> System.InvalidProgramException: Unsupported GPU. See graphics.log for details.
em OpenRA.Renderer.Glsl.GraphicsDevice..ctor(Int32 width, Int32 height, WindowMode window, Boolean vsync)
--- Fim do rastreamento de pilha de exceções internas ---
em System.RuntimeMethodHandle._InvokeConstructor(Object[] args, SignatureStruct& signature, IntPtr declaringType)
em System.RuntimeMethodHandle.InvokeConstructor(Object[] args, SignatureStruct signature, RuntimeTypeHandle declaringType)
em System.Reflection.RuntimeConstructorInfo.Invoke(BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
em OpenRA.Graphics.Renderer.CreateDevice(Assembly rendererDll, Int32 width, Int32 height, WindowMode window, Boolean vsync)
em OpenRA.Graphics.Renderer.Initialize(WindowMode windowMode)
em OpenRA.Game.Initialize(Arguments args)
em OpenRA.Program.Run(String[] args)
em OpenRA.Program.Main(String[] args)
exception.log the file indicated that I looked at the file and showed it graphics.log
Unsupported GPU: Missing extensions.Available extensions:GL_WIN_swap_hint GL_EXT_bgra GL_EXT_paletted_texture
Stopped working 20110320
Error prevents the game from start
Patches welcome.FreakNigh wrote: ↑The GPU requirements are too steep, a low requirement solution needs to be provided. The low requirement solution doesn't have to be well maintained / supported but it needs to be there.
Exactly how much of opengl etc is used? What kind of effects are done? If you aren't doing much more then transparency then you could go back to sdl's software renderer which should take advantage of hardware acceleration and be just as fast as opengl. At that point you'll have perfect support for everyone, no more gpu driver issues.
I'd rather pay / donate $10 and have everyone else do the same then be forced to labor myself for a patch to give to everyone for free. The point being, I'd rather just pay $10 and see everyone do the same.
The problem is time and manpower, not technical feasibility and giving us money won't fix anything. I have a full time job, as does chrisf. pchote/Sleipnir is doing full time study for his doctorate. You can either be patient or fix it yourself.FreakNigh wrote: ↑I'd rather pay / donate $10 and have everyone else do the same then be forced to labor myself for a patch to give to everyone for free. The point being, I'd rather just pay $10 and see everyone do the same.
Although beedee put it more bluntly than I would have, he is absolutely correct. Our current development team consists of myself and chrisf doing game code, and beedee doing (mostly) our web site / backend services. We simply don't have the time to justify spending a week building and testing a new renderer from scratch when we could be finishing one of the other big features that are sitting half finished in the git repository (order palette, automatic map downloading, ingame ui overhaul) or fixing N smaller bugs.
Half of our current problem is that the Intel graphics drivers lie about what capabilities they support, and then crash when we try to actually use these capabilities. Many of these cards work fine with the Cg renderer which can be enabled with a simple settings flag. Having the game automatically detect bogus intel drivers and switch to the Cg renderer by default is relatively simple, near the top of my todo list, and will hopefully make it into the next release.
Half of our current problem is that the Intel graphics drivers lie about what capabilities they support, and then crash when we try to actually use these capabilities. Many of these cards work fine with the Cg renderer which can be enabled with a simple settings flag. Having the game automatically detect bogus intel drivers and switch to the Cg renderer by default is relatively simple, near the top of my todo list, and will hopefully make it into the next release.
In the way you both worded your situation, yes money would fix something. It would change the priorities so people could turn the game on to play these new important features. I will say the developers do appear to be pretty quick though. But if your time and persuasion is "not for sale" and this project is really just a "we build this for ourselves but we give out the source" then I'll be waiting...
Also this is an open source project, which means the throw away line "code the whole game yourself" is expected. However it'd be a nice idea if you replace that throw away line with another throw away like "THANKS, we're working on it...". Open source honestly only means hackers can have a field day and you might see it ported, as far as development - never. So if that throw away is used to more less throw away the whole project then for your own sake and everyone elses it'd be preferred actually that you close the source.
Also this is an open source project, which means the throw away line "code the whole game yourself" is expected. However it'd be a nice idea if you replace that throw away line with another throw away like "THANKS, we're working on it...". Open source honestly only means hackers can have a field day and you might see it ported, as far as development - never. So if that throw away is used to more less throw away the whole project then for your own sake and everyone elses it'd be preferred actually that you close the source.
Ok, let's have a quick technical discussion about the bowels of the renderer.
Currently used OpenGL bits -- VBO/IBO, 2D RGBA textures, scissor, GLSL shader objects or arbfp1/arbvp1 shaders depending on GL/Cg renderer choice.
The shaders are used to do all the old-school palette effects, including unit recolor, on a per-triangle basis without breaking batches. They are also used to unpack multiplexed textures -- we store a full sheet of 8bit paletted art in EACH color channel of an RGBA texture, again for batching reasons.
We also leave as much geometry as possible in GPU memory, for performance. This includes everything static.
There are future plans to add full-screen postprocessing, distortion effects, etc, which will add a requirement for FBOs -- although there's no reason why we couldn't make this an optional 'fast machines only' feature if it causes compat/perf problems.
Now an alternative renderer:
It is possible to build a low-tech renderer using SDL/ddraw/handrolled-software-rendering. This is on my list of things to do. However, it's pretty far *down* my list of things to do, because no-one is going to get much benefit from it. We support recent GPUs from all the big players -- any nv/ati > ~2004 is perfectly adequate, and intel x3k1/x3k5/x4k/x4k5 all work -- machines with something weaker than this frankly don't have the CPU power to run the game properly anyway. Moving more work to the CPU is not going to improve this. But we'll see. If you're willing to work on this, I'm quite happy to give whatever guidance you need.
Currently used OpenGL bits -- VBO/IBO, 2D RGBA textures, scissor, GLSL shader objects or arbfp1/arbvp1 shaders depending on GL/Cg renderer choice.
The shaders are used to do all the old-school palette effects, including unit recolor, on a per-triangle basis without breaking batches. They are also used to unpack multiplexed textures -- we store a full sheet of 8bit paletted art in EACH color channel of an RGBA texture, again for batching reasons.
We also leave as much geometry as possible in GPU memory, for performance. This includes everything static.
There are future plans to add full-screen postprocessing, distortion effects, etc, which will add a requirement for FBOs -- although there's no reason why we couldn't make this an optional 'fast machines only' feature if it causes compat/perf problems.
Now an alternative renderer:
It is possible to build a low-tech renderer using SDL/ddraw/handrolled-software-rendering. This is on my list of things to do. However, it's pretty far *down* my list of things to do, because no-one is going to get much benefit from it. We support recent GPUs from all the big players -- any nv/ati > ~2004 is perfectly adequate, and intel x3k1/x3k5/x4k/x4k5 all work -- machines with something weaker than this frankly don't have the CPU power to run the game properly anyway. Moving more work to the CPU is not going to improve this. But we'll see. If you're willing to work on this, I'm quite happy to give whatever guidance you need.
Ok well of course fancier things will be more complicated with software rendering. However you can do palette swapping with standard SDL. To have fast blitting you simply make sure the image is in the same format as the screen and then don't edit the image and it will stay in hardware memory for fast blitting. So long as you are using the "software" renderer in SDL right it will utilize the hardware and be just as fast as opengl, so long as you are sticking manly to the basics in 2D rendering.
It'd be a thought if you weren't planning on doing anything fancy as it shoots the compatibility up to 100% clean. Of course a rendering engine overhaul is a big deal after the project is mainly done so.
It'd be a thought if you weren't planning on doing anything fancy as it shoots the compatibility up to 100% clean. Of course a rendering engine overhaul is a big deal after the project is mainly done so.