Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length

 
Advanced search

1364511 Posts in 63831 Topics- by 55716 Members - Latest Member: ProStorGames

August 19, 2019, 03:47:44 PM

Need hosting? Check out Digital Ocean
(more details in this thread)
TIGSource ForumsJobsCollaborationsMonocle Engine: Pseudocode Sketches
Pages: 1 2 3 [4]
Print
Author Topic: Monocle Engine: Pseudocode Sketches  (Read 26759 times)
Will Vale
Level 4
****



View Profile WWW
« Reply #60 on: May 13, 2009, 03:08:12 AM »

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

Quote
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 Smiley

Cheers,

Will

Logged
Kornel Kisielewicz
The Black Knight
Level 1
*

Madman for hire


View Profile WWW
« Reply #61 on: May 13, 2009, 04:00:54 AM »

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" Tongue

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 Wink. 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 Smiley
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 Wink.
Logged

At your service,
Kornel Kisielewicz (@epyoncf)
ChaosForge -- DoomRL and AliensRL
Jupiter Hell -- DoomRL spiritual successor!
Snakey
Level 2
**


View Profile WWW
« Reply #62 on: May 13, 2009, 07:45:51 PM »

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?
Logged

I like turtles.
Will Vale
Level 4
****



View Profile WWW
« Reply #63 on: May 13, 2009, 07:50:50 PM »

I agree with all of that Smiley

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

Quote
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.
Logged
Snakey
Level 2
**


View Profile WWW
« Reply #64 on: May 13, 2009, 07:55:10 PM »

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.
Logged

I like turtles.
Alec
Level 10
*****



View Profile WWW
« Reply #65 on: May 13, 2009, 11:31:00 PM »

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

Ivan
Owl Country
Level 10
*


alright, let's see what we can see


View Profile
« Reply #66 on: May 14, 2009, 09:08:04 AM »

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.
Logged

http://polycode.org/ - Free, cross-platform, open-source engine.
Massena
Level 4
****


Satisfied.


View Profile
« Reply #67 on: July 14, 2009, 03:21:48 PM »

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.  Beer!
Logged

TakeV
Level 0
**


View Profile
« Reply #68 on: July 29, 2009, 11:10:16 PM »

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. Smiley

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



View Profile WWW
« Reply #69 on: August 03, 2009, 02:55:26 PM »

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.
Logged

Will Vale
Level 4
****



View Profile WWW
« Reply #70 on: August 03, 2009, 03:49:40 PM »

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.

Logged
TakeV
Level 0
**


View Profile
« Reply #71 on: August 03, 2009, 08:09:28 PM »

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. Sad

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. Smiley
Logged
Alec
Level 10
*****



View Profile WWW
« Reply #72 on: August 03, 2009, 09:12:01 PM »

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.
Logged

TakeV
Level 0
**


View Profile
« Reply #73 on: August 08, 2009, 12:48:41 AM »

Hmm, so, should the code be first uploaded, or should the board be formed, first?
Logged
Snakey
Level 2
**


View Profile WWW
« Reply #74 on: September 26, 2009, 05:41:53 PM »

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.
Logged

I like turtles.
Alec
Level 10
*****



View Profile WWW
« Reply #75 on: September 27, 2009, 09:18:20 AM »

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! Smiley
Logged

Pages: 1 2 3 [4]
Print
Jump to:  

Theme orange-lt created by panic