It would be cool to have a countdown clock for the kickstarter

Guessing game!

  1. Get rid of the most substantial bugs in the .NET-based editor thing
  2. Start on a lot of missing editor components
  3. For some reason there’s been claims that they need a generic particle system to render stars. Pfft. Okay. I’ll just go cook toast in my microwave.
  4. List item

Keith doesn’t want to list what is taking so long because he wants the Space Wales to be a surprise!!!

For anyone who thinks I’m being serious; I’m just kidding :stuck_out_tongue:

The list of “what has to be done” is changing every day ( and don’t be under the assumption that it’s only shrinking, unfortunately every once in a while it grows, thanks to numerous bugs :wink: ) so it wouldn’t be wise to post anything.

We’re working very hard to launch the KS asap and we realize people are getting impatient… in fact we do, too. But there’s only so much time in a day, we’re a small team ( and only two people working full time at the moment: Keith and myself ), and there’s still tons of things to do.

To give an example, we’ve recently done a few rounds of optimizations to the engine. I implemented hardware instancing, which allows to render duplicated objects ( which share the same geometry and properties ) at once in a single draw call, instead of N times. One of our benchmark scenes ( which was cpu-overhead limited ) went up from 35 fps ( just a couple months ago ) to 250 fps after this round of optimizations.

Right after GDC we’ll probably do a couple of dev journals updates with more details and some new pics :slight_smile:


35 to 250 fps is very impressive.

Keep up the great work!

I love reading all these little updates.

Some people wanted a list, so here is one based on keith’s post and adding some of my own.

1- Wrap up technical things(bugs, necessary features for the video, camera angles, etc).
2- Keep answering the same old “How long for the Kickstarter?” twits, posts, letters, bat-signals, etc.
3- Put the finishing touches on a couple of art assets.
4- Finish the website.
5- Write the pledge video script.
6- Finish the video music.
7- Record the live action video.
8- Re-record the live action video because its never right the first time.
9- Record the parts in-engine.
10- Re-record it because that rare bug decided to show up on half the shots.
11- Finish editing the videos.
12- Finalize the pledge tiers along with their associated rewards
13- Create enough content to release during the Kickstarter.

Not necessarily in that order. And not a complete list.

Oh, and @INovaeFlavien, since stars are back and working, what is next? Asteroids?


Planetary rings are next, which includes asteroids. Once that’s done we will release our final video before the launch of our Kickstarter. After that it will be full steam ahead on everything in your list and maybe one or two other things ;).


Well, that isn’t so long of a list.

“3- Put the finishing touches on a couple of art assets”

This one is quite misleading, there is way more work than just “finishing touches”. My own list for this one item is quite extensive and time consuming.

1 Like

Just checking, you are talking about what absolutely needs to be done before a Kickstarter can be launched?

Well, I wont argue that shinies aren’t important.

1 Like

Yes, it’s needed. There would not be much of crowd funding a video without the art we’re working on atm. I’d hate to take a hatchet to everything to be a few weeks sooner on the launch.


:smiley: haha


I’m interested in how this is situated with your material system. Has material mapping (per-texel materials; rather than multiple meshes) simplified this?

To me, hardware instancing doesn’t sound like much of an extensive optimization; more like (possibly) pushing some amendments to the engine’s architecture – and if it’s worth anything, these amendments should have came easily, right? I understand there’s numerous possible reasons why it would have been harder than it sounds, but I think they’d be more paradigmatically frustrating than monotonous, prolongued tuning.

Meh. Sorry to bother. Who cares… Keep working. Honestly… whatever.

Nice! :thumbsup:

Fact: In programming, when you know exactly what you want to do and how it can be done, you’re done. Writing code is easier than writing English once you know what you want to say.

If figuring out how to implement hardware instancing, or even thinking of the fact that it might be a good idea to do so, was easy? Everyone would be doing it.


Only because you must have been out sick that day.


I won’t deny that.

If figuring out how to implement hardware instancing, or even thinking of the fact that it might be a good idea to do so, was easy? Everyone would be doing it.

Do you even know what hardware instancing means? Yeah. I was geniunely interested in how the engine may have bended the simplicity behind a day’s worth of work. I was interested in the complexity, I wasn’t criticizing it. Alright. Cool it.

Note: Everyone is doing it.

Flavien’s answers could range from “DX11 + OpenGL implementations” to “architectural mending.” They’d be interesting answers, and that’s why I prompted about it.

Also, we don’t even know how substantial this was. It was an example of progress without regarding temporal magnitude for the specific instance itself. It may as well have taken him a day or two. Nevertheless, I was interested. -_-

Well, that’s the problem with making most your posts about how the thread it’s on is a waste of pixels and should never have existed because you don’t agree with it… sort of puts the rest of your posts in an unfavourable context, doesn’t it?

And while it’s been a few years since I worked with any graphics beyond the complexity of swing I believe hardware instancing probably refers to a feature that’s been around since dx9 and geforce 6000 series. Not actually sure OpenGL supports it… though obviously, if it was the CPU benchmark that got improved, I’m probably thinking of something else.