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

Login with username, password and session length

 
Advanced search

1364651 Posts in 63841 Topics- by 55726 Members - Latest Member: LeArchi

August 21, 2019, 07:51: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 26760 times)
nihilocrat
Level 10
*****


Full of stars.


View Profile WWW
« Reply #40 on: March 28, 2009, 10:35:50 AM »

We have a few different ideas now... Jeff Lindsay has a pretty crazy one that might just work...

Awesomesauce!
Logged

Kornel Kisielewicz
The Black Knight
Level 1
*

Madman for hire


View Profile WWW
« Reply #41 on: April 07, 2009, 02:19:41 AM »

...and homegrown data structures.
Um, for heavens sake, why would anyone want THAT? O.o

Anyway, I'm all thumbs up for that, and can provide some code, once you guys agree on a common structure and coding conventions. BTW, be wary of the forever-in-design-perfect-engine tendency Wink.
Logged

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


Full of stars.


View Profile WWW
« Reply #42 on: April 27, 2009, 08:27:29 AM »

I think it might be the other thread, but the rationale was that for the time being avoiding STL would also avoid porting issues that would come from it. I haven't really met any such problems with it, but I assume Alec knows what he's talking about.

I assume it's prudent to just use some existing open-source 2D rendering code and implement it within the object/component model. As I stated before, I see graphics as a generally "solved" problem in the open source world and would much rather see an engine that can handle the nongraphical "Model" side of things.
« Last Edit: April 27, 2009, 08:31:57 AM by nihilocrat » Logged

Rob Lach
Level 10
*****



View Profile WWW
« Reply #43 on: April 28, 2009, 07:38:58 AM »

Just read through this thread. Great ideas all around.

I am very much for a component system especially considering how quickly one is able to prototype new systems with games previously created, but in the case of an open source project, having small pieces people could work on without bothering anyone until they are done is a godsend. Things like that ensure that a project will continue to be developed over time mainly because it is so extensible.

An example is the Foobar2000 music player, which is pretty much the audiophiles music player of choice mainly because people can develop and drop in their own components, and although the core is closed and I believe developed by only one person, a majority of the features come from third-party developers.

I like where this project is going.
Logged

arckie
Level 0
*



View Profile
« Reply #44 on: May 01, 2009, 06:42:28 PM »

...and homegrown data structures.
Um, for heavens sake, why would anyone want THAT? O.o

Check out the discussion somewhere like http://www.gamedev.net/community/forums/topic.asp?topic_id=424168

For someone working on their own little project, or on tools development, the STL would be fine though! Smiley
Logged
Will Vale
Level 4
****



View Profile WWW
« Reply #45 on: May 02, 2009, 02:45:14 AM »

One argument I have against STL which doesn't seem to come up much is that there's too much of it. It's OK to say "only use the good bits" or "only use the fast bits" but it's very easy to end up using things you probably shouldn't. I guess you could also pull out what you want stuff from the STL or Boost, but I've found that to be a chore when I've tried it because there are always lots of dependencies. Plus some STL classes offer a kitchen sink interface, as opposed to a more focused, less committee-designed one - std::string is a key offender here - making it harder to get the good bits without the bad.

STL (and to a lesser extent Boost) have a smell of the kind of code you write when you do a big design up front as opposed to focusing on what you need now and growing/refactoring over time when another need is demonstrated. There are some great core ideas in there, but they tend to get diluted by the desire to be everything to everyone.

If you have your own toolkit, you can just provide the bits that work efficiently and well, and let people use those without worrying about opening Pandora's box. If a coder needs something more than you offer, they can write it. And if it gets used in several places you can bring it back into the toolkit.

Caveat: All this applies mainly to high performance console games - don't take it as dogma for smaller indie games, where STL can be a big productivity win. Just be in mind what it costs you, especially if you plan to be multiplatform.

Cheers,

Will
Logged
Alec
Level 10
*****



View Profile WWW
« Reply #46 on: May 02, 2009, 03:59:49 PM »

STL's fine. For portability, I'd like to wrap structures though.
Logged

Rob Lach
Level 10
*****



View Profile WWW
« Reply #47 on: May 05, 2009, 10:02:22 AM »

STL's fine. For portability, I'd like to wrap structures though.

STL is more than good enough for something like this. Any optimization past something like STL is more than usually game specific.

I also agree with wrapping the structures.
Logged

Kornel Kisielewicz
The Black Knight
Level 1
*

Madman for hire


View Profile WWW
« Reply #48 on: May 08, 2009, 04:32:41 AM »

Sooo... any movement on this project? ;-)

* a public trac-like site?
* a read-only svn repo?
* a collaboration wiki?
Logged

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


This is how being from "da hood" is like, right?


View Profile
« Reply #49 on: May 08, 2009, 09:05:24 AM »

In other news, it's been ages since I last saw you here Kornel. Tongue

I'm also curious on the standing of this project. But I bet Alec is a very, very busy man already, with two whole games in development.
Logged

Feel free to disregard the above.
Games: Minus / Action Escape Kitty
jackf
Level 0
**



View Profile
« Reply #50 on: May 08, 2009, 09:28:15 PM »

Are you considering GameObjects to be individual entities, or can there be multiple GameObjects that create a yet larger unit, each with their own components?

This project intrigues me because I did the same sort of thing in C under the idea that every part (floor, enemies, player) of the game world would be of a datatype, and complication beyond rectangles would be obtained by adding "children". Without classes as I was inter-object communication was very difficult (Head object was hit, child Gun object should fire back).

If you can get this off the ground it seems like it would be fun, albiet similar to a lot of other game-making utilities.
Logged
Kornel Kisielewicz
The Black Knight
Level 1
*

Madman for hire


View Profile WWW
« Reply #51 on: May 11, 2009, 08:00:53 AM »

In other news, it's been ages since I last saw you here Kornel. Tongue
I usually just lurk, and it's only recently that I got back to indie-coding Smiley

I'm also curious on the standing of this project. But I bet Alec is a very, very busy man already, with two whole games in development.
That's why I suggested to set up some collaboration environment.
Logged

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


0xDEADC0DE


View Profile WWW
« Reply #52 on: May 12, 2009, 01:48:18 AM »

STL is evil D:

....and slow.

But it's okay for small things!
Logged

<Powergloved_Andy> I once fapped to Dora the Explorer
Klaim
Level 10
*****



View Profile WWW
« Reply #53 on: May 12, 2009, 02:18:58 AM »

It's not at all, I made full NDS games with heavy use of STL. Sure you have to understand how it works and sometimes how it is implemented for your target platform/compiler, but the performances are more about how you use it than the STL itself.

In the end, STL only provide very basic structures. That's the usage that is important.
Logged

Kornel Kisielewicz
The Black Knight
Level 1
*

Madman for hire


View Profile WWW
« Reply #54 on: May 12, 2009, 03:32:34 AM »

It is funny when people say "STL is slow" and then implement their own structures that turn out slower... I've done measures and stress tests of vector vs. new[] and map vs. a quite good non-STL implementation targeted at speed, and iterators vs. direct access on both GCC (4.3 FWIW) and MSVC (2008) on three different architectures on two OS'es, using cycle-based measuring and the differences were constantly marginal or non-existant.

True, if you carefully tune the structures to the target architecture (hell of a job), and throw away run-time checks, you'll get a performance boost. But the game is not worth the reward, unless it's optimizing specific parts of code on the latest stage of development. Also, availability of a good STL implementation on a newborn platform with it's own compiler not always meets our expectations, but usually it's just a matter of time.

People who say STL is slow, are either begginers who don't know how to use it properly, or who brainlessly keep repeating what they hear, or absolute experts. The scary majority however is the former...
Logged

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


View Profile WWW
« Reply #55 on: May 12, 2009, 05:26:26 AM »

Quote
STL is evil D:

....and slow.

But it's okay for small things!

I would be interested to see what container types you would implement or use in your own structures.
Logged

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



View Profile WWW
« Reply #56 on: May 12, 2009, 02:33:34 PM »

The one I would recommend (and use myself) is an iterable random access container (i.e. like a vector) with some differences:

* No automatic growing of the container when it runs out of space.

* Specify capacity as construction parameter.

* Add a set_capacity() method to change this.

* erase() is non-order-preserving and copies the end element into the vacated slot.

* clear_memory() provided to remove the allocation of the vector without having to use the non-obvious swap trick.

Obviously you could implement this in terms of std::vector and it wouldn't be a whole lot of work. You could also look at EASTL for some good commentary on this topic.

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2271.html

Cheers,

Will




Logged
Kornel Kisielewicz
The Black Knight
Level 1
*

Madman for hire


View Profile WWW
« Reply #57 on: May 12, 2009, 03:20:55 PM »

The one I would recommend (and use myself) is an iterable random access container (i.e. like a vector) with some differences:
How about boost::array (or std::tr1::array for that matter...)?
Logged

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



View Profile WWW
« Reply #58 on: May 12, 2009, 04:58:44 PM »

boost::array and tr1::array are an adaptation of compile-time-constant size native arrays to STL standards. Fine and all, but nothing like what I was describing.  Sad

Logged
Kornel Kisielewicz
The Black Knight
Level 1
*

Madman for hire


View Profile WWW
« Reply #59 on: May 13, 2009, 12:29:32 AM »

Yeah, I noted that after I posted. Still, you can use a vector because:

* "No automatic growing of the container when it runs out of space." <- you can check that yourself. Range checking would be done anyway to allow safe usage, so it isn't such a big performance hit.
* "Specify capacity as construction parameter." <- AFAIR you can do that with a vector.
* "Add a set_capacity() method to change this." <- reserve/resize depending on need for pre-clearing
* "erase() is non-order-preserving and copies the end element into the vacated slot." <- I don't exactly understand what you want here.
* "clear_memory() provided to remove the allocation of the vector without having to use the non-obvious swap trick." <- also exists, and once you know the trick it's not a problem.

Also, you might look at using new-allocated arrays with the boost constructs -- you can iterate over an array like over a container. Also, it's still always better to build up on stl/boost than reinvent the wheel Wink.
Logged

At your service,
Kornel Kisielewicz (@epyoncf)
ChaosForge -- DoomRL and AliensRL
Jupiter Hell -- DoomRL spiritual successor!
Pages: 1 2 [3] 4
Print
Jump to:  

Theme orange-lt created by panic