next »

[Will Vale]

I agree that a vector offers some of these features, as I said in my previous post:

Obviously you could implement this in terms of std::vector

The point I'm trying to make is that std::vector also offers features which make it easy to write slow or badly-behaved code, and doesn't always make the efficient way obvious. If you make heavy use of std::vector without being aware of these issues, you can have endemic performance or fragmentation problems which are not amenable to end-of-cycle hotspot optimisation.

NB: The specific point about erase was that you can efficiently erase an element from a sequence by copying the last element into the vacated space. This gives a constant-time erase and maintains contiguousness without maintaining order - often what you want.

NB: I'd be really wary of saying things like "once you know the trick..." - if a library feature is accessible only through a 'trick' rather than a helpfully-named interface, it suggests there is room for improvement in the library.

Anyway, I don't want to get drawn into a detail-heavy STL debate here. I was originally responding to Snakey's question about which containers you would implement by describing the one I think is especially important. I think we'll have to agree to disagree about whether this is worthwhile effort - in my line of work it definitely is, your experience is obviously different

Cheers,

Will

[Kornel Kisielewicz]

The point I'm trying to make is that std::vector also offers features which make it easy to write slow or badly-behaved code, and doesn't always make the efficient way obvious. If you make heavy use of std::vector without being aware of these issues, you can have endemic performance or fragmentation problems which are not amenable to end-of-cycle hotspot optimisation.

This statement is true in case of any non-trivial piece of code. That's the problems of todays programmers -- they'd rather write their own, than use tested and good implementations -- afterwards a new programmer takes over, and has an even worse problem -- using someone elses non-standard code, that probably suffers more than standard library. Standards exist to prevent such situations.

NB: The specific point about erase was that you can efficiently erase an element from a sequence by copying the last element into the vacated space. This gives a constant-time erase and maintains contiguousness without maintaining order - often what you want.

Err, that would rather be a set than a vector... and tell me, how such a structure would be "helpfully-named"

NB: I'd be really wary of saying things like "once you know the trick..." - if a library feature is accessible only through a 'trick' rather than a helpfully-named interface, it suggests there is room for improvement in the library.

Nothing's perfect -- find me a better library . And even if you do, will it be easier to teach a newcomer to the project about it, and will he write better code, compared to the situation where you'd be using STL, and the newcomer knew STL well?

Anyway, I don't want to get drawn into a detail-heavy STL debate here. I was originally responding to Snakey's question about which containers you would implement by describing the one I think is especially important. I think we'll have to agree to disagree about whether this is worthwhile effort - in my line of work it definitely is, your experience is obviously different

I follow the principles of fast and error-free code development, keeping it as readable to the average programmer as possible. Too many times I've seen the wheel reinvented, and too many times it was reinvented into a square...

But agreed, this is a pointless discussion, not to mention derailing the topic.

BTW, in terms of STL pitfals, who'd know that std::list size has linear complexity .

[Snakey]

In the case of STL's portability, I think that it is difficult to say what exactly is required. It depends where this engine wants to operate. Because there is no requirements document, I almost get the feeling that people want the engine to exist on platforms that are simply not feasible or worth thinking about.

For example, we can support the personal computer well enough since everyone has access to that (Windows, Linux and Macintosh). However, is it worth considering XBox360, Wii or Playstation 3?

I can certainly understand the appeal of an indie engine supporting everything on the planet, but considering that this project isn't likely to be paid work, work which would require considerable time, experience and money.

So, without a basic requirements document, it's pretty hard to argue the use of things such as STL ... either for or against its usage.

As for my stance on STL and its usage, I certainly have been using it a lot and I don't tend to run into performance problems. However, it is plausible that I haven't spend enough time developing critical performance engines.

Having worked with Unreal Engine 3 on the C++ level, sometimes it's frustrating dealing with memory problems and typically unsafe practises. However, I suppose for the sake of performance you sometimes have to assume the programmer on the other end isn't a complete idiot and thus protect him/her from everything.

If this project is to not turn like Tixel, then perhaps some early requirements documentation is needed? Just so that we all can agree on a set of requirements for the engine without devolving the project into rantings about trivial things?

[Will Vale]

I agree with all of that

As for platforms/requirements, this was in Alec's original post in the main thread:

Key Platforms to Support

• PC
• Mac
• Linux
• XBox360
• Wii
• iPhone
• PS3

Not very formal, but the mention of Wii and iPhone does make it seem like paying some broad attention to performance is a good idea.

[Snakey]

Hmm, that's a little concerning as I'd really just target the pc to start off with .. but it's a start I suppose.

[Alec]

The engine would just start on the PC for the initial version. Other versions would be added based on interest / external support.

[Ivan]

A good thing to keep in mind if you wanna go for multiple platforms is how things like shaders get handled. They are a fairly peculiar engine feature because on some platforms they are tied very closely to internal engine function (skinning,particles, etc.) and on some platforms they are not supported at all.

[Massena]

Reviving this topic for the good of mankind.

I would just like to profess my agreement with what venerable Alec is going for. Also, to link to this eye-opening, and very informative article (which was linked in the other thread about this project) prototype modeling. If I'm not mistaken, it's quite similar to what you have in your pseudocode.

Also, I think that it is best that we let one person alone code the very core of the engine. It strikes me as very important that the filling of this engine cake be very purist in terms of the programming philosophy chosen. Later, when writing the limbs of our man-engine, or the frosting of the engine cake, deviations from the base philosophy are A-OK in my book.

Keep being awesome Alec. 

[TakeV]

I must confess my interest in this project.

Has there been an SVN or some other code base set up to review? I don't think I'd be able to work on the core engine, though I would be quite willing and eager to create a few components for this project.

I believe Google has a reliable code repository for such things, if one needs to be set up. The link is here, I believe.

[Alec]

Hrm...

I've been wiped out from working on like 4 projects simultaneously lately... :\

I guess I see two paths for Monocle...

A. start fresh, build a new engine from scratch. put together a "board" of 2-3 core people and go to town.

B. put the aquaria base engine on an svn repo. rape it for usable spare parts, then build monocle using those bits. possible fork the engine into bitblotgameengine (old aquaria engine) vs. monocle (shiny new engine?)

In any case, the "board" is going to be pretty critical. We'll need some folks who have good C++ and engine design/development experience, and who share the same goals.

I'd still like to do this as the engine for Verge HD. Where the fuck is Kyle Puvler.

[Will Vale]

Having done 1) a couple of times on professional projects, I'd go for 2) unless you're really worried about the Aquaria codebase. Is there an engine-game split in Aquaria or are the waters muddied?

IMHO it's much better to incrementally improve existing systems - or indeed add new ones - within the scope of an existing engine *especially* if it's possible to use Aquaria as a test case to ensure the changes are non-breaking. I guess that's not quite what your 2) was - the difference being whether you work in place, or pull code out into a new 'clean' repository. Both are probably better than starting from scratch.

[TakeV]

Hrm...

I've been wiped out from working on like 4 projects simultaneously lately... :\

I guess I see two paths for Monocle...

A. start fresh, build a new engine from scratch. put together a "board" of 2-3 core people and go to town.

B. put the aquaria base engine on an svn repo. rape it for usable spare parts, then build monocle using those bits. possible fork the engine into bitblotgameengine (old aquaria engine) vs. monocle (shiny new engine?)

In any case, the "board" is going to be pretty critical. We'll need some folks who have good C++ and engine design/development experience, and who share the same goals.

I'd still like to do this as the engine for Verge HD. Where the fuck is Kyle Puvler.

Oh my, don't over-extend yourself.

Anyway, I think I'd be in favor of option B. Better to reuse what is already made, I think, and it would save on effort. Unless the Aquaria engine isn't really using a similar architecture to what was proposed, in which case it might be easier to start from scratch.

Not going to volunteer to be on the board though. However, I would be happy to contribute in any other way, be it coding components, documentation, or perhaps writing tutorials. The later two are important, I think. I've seen so many good engines that would be useful, if only it was clear how to use them. :\

Reiteration: Yes to uploading Aquaria, unless you have a problem with doing so or it is not practical to use the code from it, I can contribute however you'd like, including documentation, coding components, and tutorials, and please take it easy and do not burn yourself out.

[Alec]

Yeah, Aquaria has a split between reusable engine and game code, but the engine itself is kind of hacky in places. I would definitely want to rewrite it at some point if it was going to be used for another game.

[TakeV]

Hmm, so, should the code be first uploaded, or should the board be formed, first?

[Snakey]

The board needs to be formed first, and from there the board needs to design the engine. Design in the way of specifications, requirements and code style documents need to be setup. We need to emphasize code style, otherwise you get weird components written by third parties and they operate and work completely differently making it hard in general to fit in. Code style isn't so much using tabs or spaces argument but rather how classes are organised, what standard practises are used for writing code systems and so forth. This becomes very important since we're dealing with C++.

Lastly, for this engine to be of any real use in my opinion, we need to consider tools. We have to appreciate that not everyone is going to want to compile it and set it up themselves, and most users probably won't even bother to modify the engine. If there are no decent tools for the engine, it'll be just like every other freeware engine out there. That is, a bunch of a cool tech that's completely unbearable to use.

My 2 cents for the day.

[Alec]

The board needs to be formed first, and from there the board needs to design the engine. Design in the way of specifications, requirements and code style documents need to be setup. We need to emphasize code style, otherwise you get weird components written by third parties and they operate and work completely differently making it hard in general to fit in. Code style isn't so much using tabs or spaces argument but rather how classes are organised, what standard practises are used for writing code systems and so forth. This becomes very important since we're dealing with C++.

Lastly, for this engine to be of any real use in my opinion, we need to consider tools. We have to appreciate that not everyone is going to want to compile it and set it up themselves, and most users probably won't even bother to modify the engine. If there are no decent tools for the engine, it'll be just like every other freeware engine out there. That is, a bunch of a cool tech that's completely unbearable to use.

My 2 cents for the day.

^ Agree!