FreeGameDev

qreeves {l Wrote}:I have decided that the Red Eclipse first person shooter should continue to use the Cube 2 Engine.

I understand and respect your decision, cheers :)

qreeves {l Wrote}:We can still make strides by polishing what we have, and imagining new possibilities; we will not fall behind but instead be appreciated by those who most need we have to offer - and that is a pick-up-and-play kickass game!

Agreed! Let's get rolling ;)

ZeroKnight {l Wrote}:

qreeves {l Wrote}:I have decided that the Red Eclipse first person shooter should continue to use the Cube 2 Engine.

I understand and respect your decision, cheers

qreeves {l Wrote}:We can still make strides by polishing what we have, and imagining new possibilities; we will not fall behind but instead be appreciated by those who most need we have to offer - and that is a pick-up-and-play kickass game!

Agreed! Let's get rolling

+1 As much as I would have loved to see RE in action with Tesseract it's not a big deal and would only provide better visuals. We have kick-ass gameplay and can continue to focus on that

I could just support quin in all his decisions, but I have to say, i was fairly entheusastic about the proposed change towards tesseract, and while i understand the reasoning behind this decision, I heavily disagree. The RE community is represented in this poll. The result is quite obvious. The popularity spike is something i see unrelated to the low-requirements, it just happened that one individual liked the game and shared it to his tons of subscribers (1mil).

What is important to see is that this popularity is non-permanent, let's not drive into the illusion that RE was completly discovered, indeed, from my many times playing recently I noticed now a decrease in playerbase, no longer in the high 50 players, but sometimes just about 5 players online total, very timeoriented, in the European evening about 30 players.
These, who are permanent, who play much, who have the most impact, the ones that power the community, THEY have voted here. I find it quite strange to make such a poll if the result is completly disregarded and overwritten. Out of this poll, it is very obvious that a majority wants better graphics, a step forward. The new vsauce players, that impact on playerbase is fairly small, and therefor you should not assume that they share your opinion, and even if they would, this small playerbase should not receive more attention than the large crowd that has followed and supported RE.
I feel myself tricked and would love a longer explanation on the matter... the current feels like a stupid poll that is completly ignored. I dont see any good reason to continue this engine other than lazyness, because as visible in this poll, the players wanting no change are a minority.

Let's also not forget the coverage Tesseract got in the media, the following popularity boost. RE could benefit from that.

A reliable player since svn wanting a change, <blaze> restcoser.

Infinite +1's to restcoser. That's pretty much the case against the popularity argument.

That said, I respect and stand by Quinton's decision... until Tesseract is in a more ready state, at least (and that will be a long time from now, even with the current pace of development).

Ok i am semi-neutral to the tesseract idea now, but because tesseract is based off cube 2 wouldnt it hypothetically be possible to work on both engines in paralell with a bit of modding to tesseract giving the user the choice. Or would it be a majorly increased workload by having to do the same work again but differently?

Jamestonjes {l Wrote}:Ok i am semi-neutral to the tesseract idea now, but because tesseract is based off cube 2 wouldnt it hypothetically be possible to work on both engines in paralell with a bit of modding to tesseract giving the user the choice. Or would it be a majorly increased workload by having to do the same work again but differently?

Either you get dynamic lighting, or you get static lighting, there is NO compromise by "giving the user the option". Either you sacrifice performance for quality, or you sacrifice file size for pre-computed lightmaps, it's as simple as that.

Editing:

To make shadowmapped point lights, just make light entities as normal. Optionally you can control the shadowing properties of the light using attribute 5: 0 = shadows, 1 = no shadows, 2 = static shadows - world and mapmodels only (no playermodels or pickups). Shadowmaps are cached from frame to frame if no dynamic entities such as playermodels are rendered into them, so static lights (2) will generally be much faster than normal lights (0) during gameplay and should be used where possible. Unshadowed lights (1) are even faster as they further reduce shading costs, so they should also be used where possible.

-Tesseract README.

Judging by this, we can optimize the maps. All of the lights on Tesseract (which were imported from Sauerbraten of course) use the first type, so no wonder people are having issues with running maps like Complex.

stroEkris {l Wrote}:

Editing:

To make shadowmapped point lights, just make light entities as normal. Optionally you can control the shadowing properties of the light using attribute 5: 0 = shadows, 1 = no shadows, 2 = static shadows - world and mapmodels only (no playermodels or pickups). Shadowmaps are cached from frame to frame if no dynamic entities such as playermodels are rendered into them, so static lights (2) will generally be much faster than normal lights (0) during gameplay and should be used where possible. Unshadowed lights (1) are even faster as they further reduce shading costs, so they should also be used where possible.

-Tesseract README.

Judging by this, we can optimize the maps. All of the lights on Tesseract (which were imported from Sauerbraten of course) use the first type, so no wonder people are having issues with running maps like Complex.

You can optimise to some extend, but the difference largely depends on the kind of map you're trying to improve. Don't let this fool you into thinking you'll get dramatic framerate increases, the fact remains that you won't ever see more than 500 fps on a blank map without a beefy machine.

the fact remains that you won't ever see more than 500 fps on a blank map

No, I'll get 200 fps and that is OK with me. I have a beefy machine btw.

How about we agree to re-evaluate this question once Tesseract is officially released and deemed stable by it's creator?

Julius {l Wrote}:How about we agree to re-evaluate this question once Tesseract is officially released and deemed stable by it's creator?

+9,000

Dratz-_C {l Wrote}:... I think we may want in the near future to ask for and facilitate a resolution to the problem of large visible surface area divided among a maximum number of shading descriptors. ...

Where some folks want to help "Tesseract" become robust and useful in and of itself and for "Red Eclipse," I recommend including this item in the agenda when in communication with Lee Salzman, also known as Eihrul, and his relevant, close colleagues.
Cheers

I agree about the waiting until its deemed stable by the developer. And just for interest sake on max in complex i get about 30-40 FPS on average (HD7750 pentium g860 4GB ddr3 1333 Windows 7 32bit) my friend on a gt 220 got about 20 on the default settings on average (IDK what cpu he has or how much ram or if there was software running in the background)

Jamestonjes {l Wrote}:I agree about the waiting until its deemed stable by the developer. And just for interest sake on max in complex i get about 30-40 FPS on average (HD7750 pentium g860 4GB ddr3 1333 Windows 7 32bit) my friend on a gt 220 got about 20 on the default settings on average (IDK what cpu he has or how much ram or if there was software running in the background)

What the heck! I put it on the highest settings and it still runs at 150 FPS (on default settings it's 200 FPS -- I cap it to that in the driver). That's on Linux Mint 14 KDE Edition, with an Intel Core i3 3220 and an NVIDIA GTX 550 Ti. It is noticeably about 30 FPS slower in editing mode and there is a 10 FPS drop in normal play after you leave editing mode. All this is on Complex.

Maybe Tesseract just sucks under Windows. Over here it's pretty great.

That actually sound more like crappy AMD OpenGL drivers...

I sincerely apologise if the topic was misleading. While I do work with the community on many things, ultimately I have to make the executive decision, even if it is an unpopular one. I believe that Red Eclipse benefits from the stability of the Cube 2 engine, it is now tried and true - in no small part because of our use of it, and my ongoing development with it. If it isn't broken, we should not be attempting to fix it. We are a public game now, and should aim for stability and refined user experience.

That being said, I still have other plans for Tesseract involving Red Eclipse, just not for our first person shooter.

We are a popular game now... do you really believe that? 3 players online of me writing this. 3 Players, which cant be called popular in any way. It is probably stupid to repeat the points I already stated, but a refined user experience for me involves good graphics. About the stability... I didn't have a single chrash or error in hours of me using it.

It is of course clear to me that me writing this has no point anymore, other than to manage my frustration. The game that I love... being stuck serving older systems to get the most stabilty. Great things can be built, but true masterpieces require a certain risk... why not fork it, test it, and look what comes out of it, if you fear the risk? Or do you fear the work rather of rewriting code to fit to the RE engine?
If your currently stated reason, to improve user experience and stability for users is your real concern, I can't understand you.

It is a lot of work too, work I couldn't possibly do myself due to my limited understanding of the low-level areas in the source code. It may end up being that, down the line somewhere, we can possibly look at supporting both, but for now I can't really focus on anything other than the immediate future. While writing this, I am sitting in a park at night by the soft glow of my laptop, being powered by my car, if that puts things in perspective for you.

Yes, thanks for that reply, that seems like a much better reason for me... I can indeed understand the tremendous amount of work needed for that, and it might be just too much right now, I agree.

"yay I can keep on playing RE"

While I voted for Tesseract, the mantra I and many professional game designers follow is:

It doesn't matter how it looks as long as it plays well.

So staying on Cube 2 is ok for me, but why do we have to decide in the first place? Why can't we have both? Let's look a little deeper.

So from what I've heard, Tesseract replaced the static lighting from Cube 2 with dynamic lighting. Replaced, not added. Why? Is there any technical limitation that prevents us from having both approaches in the engine? There is none.

Again, let's observe what we have:

• Static lighting
• Partially dynamic lighting (current Tesseract)
• Fully dynamic (hypothetical)

Static lighting requires baking precomputed lightmaps for all the lights into the map, partially dynamic lighting precomputes only some lights and fully dynamic computes everything in real time. Now, if the client chooses partially or fully dynamic, they don't need to have static lightmaps in the RAM. This can be easily solved by separating different lightmaps into separate chunks and loading only chunks corresponding to the current settings. Source engine does that. It has LDR and HDR lighting, those are computed separately into different chunks of BSP file and only one is loaded at runtime. Very simple.

Again, what is the problem? The problem is that for some reason Eihrul decided to remove static lighting from the engine.

Solution? There are several ones:

• Convince Eihrul to return static lighting to Tesseract.
• Fork Tesseract and add static lighting by ourselves.

None of those solutions are unrealistic. There are no technical problems, the only real problems are laziness and lack of time.

What I am told in this regard: The problem is the difference in pixel pipelines, which is more trouble than it is worth to support concurrently (basically, quadruple whatever effort we have to put in now); coupled together with the fact that texture coordinates are done differently too. I'd be weary of making accusatory remarks, eihrul is a volunteer like anyone else, and he (like me) is only going to do what interests him; alienation is only going to make him disinterested in helping us any further.

FaTony {l Wrote}:There are no technical problems, the only real problems are laziness and lack of time.

Besides what quin already said, I strongly suspect that it is rather the wish to avoid bloat-ware that becomes slow and unmaintainable at some point, which motivated this clear cut between regular cube2 and tesseract. Having lean and fast code has been always one of the main philosophies of the developers behind those engines.