Got collision working seamlessly on my survival game, it was painless (for once). Need to get a character sprite because currently you are a gem. Now I just need to make it so it can make more things than air non-solid and I should be sweet.
What are you guys opinions on having "devlog" like threads in the programming forum?
I want to make a Entity system for simple games, I was planning to have a World which holds all the objects derived from Entity, but only the game has the World object. How can a entity find other entities in similar existing engines? Is world static? Does every Entity have a World reference?
The world usually keeps an array of its entities.
For dynamic games, this is a dynamically resizable array of course. A linked list is the most common one, since you can easily remove items from it, though it is slow to iterate over it.
I'd suggest using a mix of different container types and having a bunch of pools, each one having pointers to entities with similar characteristics, and an array containing pointers to these pools. Then you can search quite fast if you know what entity-type you are searching for and you can decide what container-type to use for each pool:
You might have a bunch of entities that always exist, such as the player, for which you can use a stack-allocated array. Then you can stuff the indestructible entities of a map in one heap-allocated and never resizing - at least not till the next map - array. Particles might have a circular array (like [url=http://www.boost.org/doc/libs/1_41_0/libs/circular_buffer/doc/circular_buffer.html#description]this[/url]) and entities with quite unknown life-time live in a normal linked list.
Make sure not to allocate big chunks of memory in one go, since this will be quite slow. Try to keep the pools of limited size and allocate new pools if one is full. Also preallocate more memory than needed to keep the allocation of memory while you play the game to a minimum.
[QUOTE=iPope;18438749]Got collision working seamlessly on my survival game, it was painless (for once). Need to get a character sprite because currently you are a gem. Now I just need to make it so it can make more things than air non-solid and I should be sweet.
What are you guys opinions on having "devlog" like threads in the programming forum?[/QUOTE]
twitter/blogs for that
[QUOTE=iPope;18438749]What are you guys opinions on having "devlog" like threads in the programming forum?[/QUOTE]
Millions of threads with uncompleted projects in D:
I think this thread is fine for logging your development to other fpers, otherwise, as has been said, I'd go with a blog.
[QUOTE=ZeekyHBomb;18439106]The world usually keeps an array of its entities.
For dynamic games, this is a dynamically resizable array of course. A linked list is the most common one, since you can easily remove items from it, though it is slow to iterate over it.
I'd suggest using a mix of different container types and having a bunch of pools, each one having pointers to entities with similar characteristics, and an array containing pointers to these pools. Then you can search quite fast if you know what entity-type you are searching for and you can decide what container-type to use for each pool:
You might have a bunch of entities that always exist, such as the player, for which you can use a stack-allocated array. Then you can stuff the indestructible entities of a map in one heap-allocated and never resizing - at least not till the next map - array. Particles might have a circular array (like [url=http://www.boost.org/doc/libs/1_41_0/libs/circular_buffer/doc/circular_buffer.html#description]this[/url]) and entities with quite unknown life-time live in a normal linked list.
Make sure not to allocate big chunks of memory in one go, since this will be quite slow. Try to keep the pools of limited size and allocate new pools if one is full. Also preallocate more memory than needed to keep the allocation of memory while you play the game to a minimum.[/QUOTE]
Thanks for this extensive explanation, but that wasn't exactly what I wanted to know. I'm making this for small 2D games (actually just prototypes, I never finish proper projects anyway and it's more fun too), so performance isn't a huge issue, I'll use a single linked list for all my entities. My actual problem is a design problem. I have the game class which has a reference to an object of the world class which has all the entities. I would like to have the game logic for every entity defined in the entity itself, but my problem with that is that I can't access other entities from an entity, so stuff like collisions are impossible.
I don't like the idea of passing a World reference to every entity when I'm creating them. It seems like a bad design choice. If I (or you) can't come up with something better I'll have to do it this way though.
[QUOTE=iPope;18438749]Got collision working seamlessly on my survival game, it was painless (for once). Need to get a character sprite because currently you are a gem. Now I just need to make it so it can make more things than air non-solid and I should be sweet.
What are you guys opinions on having "devlog" like threads in the programming forum?[/QUOTE]
Definitely twitter, if not that, then something like [url]http://www.tumblr.com/[/url] (Which I would recommend).
So, garry, and GWEN updates? I wanna port it to Ogre.
[QUOTE=Robber;18439436]Thanks for this extensive explanation, but that wasn't exactly what I wanted to know. I'm making this for small 2D games (actually just prototypes, I never finish proper projects anyway and it's more fun too), so performance isn't a huge issue, I'll use a single linked list for all my entities. My actual problem is a design problem. I have the game class which has a reference to an object of the world class which has all the entities. I would like to have the game logic for every entity defined in the entity itself, but my problem with that is that I can't access other entities from an entity, so stuff like collisions are impossible.
I don't like the idea of passing a World reference to every entity when I'm creating them. It seems like a bad design choice. If I (or you) can't come up with something better I'll have to do it this way though.[/QUOTE]
Well, for collision you can just let the game-class check each entity of the world for collisions, and if two collide call their onCollision-functions.
But for other types of interaction you need another method. I haven't shed much thought on this yet, but for a start I'd make some MessageSystem-class owned by the game- or world-class. You still need to pass a reference to that to every entity, but at least the world-instance is not exposed. An alternative to passing the reference around would be using global-obtainable singletons.
[QUOTE=ZeekyHBomb;18439957]Well, for collision you can just let the game-class check each entity of the world for collisions, and if two collide call their onCollision-functions.
But for other types of interaction you need another method. I haven't shed much thought on this yet, but for a start I'd make some MessageSystem-class owned by the game- or world-class. You still need to pass a reference to that to every entity, but at least the world-instance is not exposed. An alternative to passing the reference around would be using global-obtainable singletons.[/QUOTE]
I already thought about using singletons, the disadvantage is that I can only have one world, but I don't think I'll actually need more than one anyway. Thanks :smile:
Just give each entity a pointer to it's containing world, what's the issue?
[QUOTE=nullsquared;18441000]Just give each entity a pointer to it's containing world, what's the issue?[/QUOTE]
This, that way if you ever have several different worlds you can pass any of them to the entities with ease.
Also it is just better to remove as much reliance as possible making your code more easily changeable.
Thanks for all your input. I still have to decide between singleton and passing pointers, but I think I will go with the latter. Anyway, I've got to go now, I have a test tomorrow.
Don't go with singletons. They're fun for a while then everything goes to the shit.
[QUOTE=blankthemuffin;18441500]Don't go with singletons. They're fun for a while then everything goes to the shit.[/QUOTE]
What? Care to explain?
[QUOTE=efeX;18441597]What? Care to explain?[/QUOTE]
[url]http://en.wikipedia.org/wiki/Singleton_pattern[/url]
Well it's just my experience with them really, they can be used effectively.
Last time I used them, which I admit was a long time ago, I was writing an engine type thing in C#/XNA. I was using singletons for the various managers and for a while everything was nice, then I started to get inter-dependencies. For examle, pretty much everything required the Console system to be up and running so that they could log messages, register console commands, etc. You might think this would be simple and lead to nothing more than that particular singleton being instantiated first. However due to my flawed design and its interaction with XNA, various parts of the console system needed to be loaded after other parts of the system. At which point everything started going to the shit and I had to hack around to get things to load in the right order.
I suppose the lesson you could take from this is singletons can look like a silver bullet, but like every approach they have their issues, and at least in my case they tend to make things seem easier than they are. So go with whatever, but be certain you have a well designed system before you start if you want to go down the singleton route.
So, * is pointer, which says like "This stuff is at 0xWhatnot" and *** is pointer pointing to a pointer pointing to a pointer.
:psyboom:
[QUOTE='-[ Fizzadar ]-;18441663'][url]http://en.wikipedia.org/wiki/Singleton_pattern[/url][/QUOTE]
I know what a singleton is. I was asking for clarification why he said that.
[QUOTE=efeX;18442424]I know what a singleton is. I was asking for clarification why he said that.[/QUOTE]
Oh, haha xD
Yay for path tracing!
[img]http://img697.imageshack.us/img697/6272/pathtracerday12.png[/img]
... time to implement something more efficient :sigh:
1.7 fps?
[QUOTE=efeX;18446116]1.7 fps?[/QUOTE]
That's actually 1.7 FPS [i]per-render[/i], you need to accumulate thousands of renders for the final image to look good.
(BTW, path tracing is essentially ray tracing that simulates light travel by brute force)
[editline]09:24PM[/editline]
[QUOTE=windwakr;18446175]You'd be better off faking it.[/QUOTE]
There's no such thing as "faking" it. This is path tracing. The opposite is photon tracing, which traces from the light to the eye, rather than from the eye to the light. Both are extremely inefficient. What's better is photon mapping and other such techniques.
[editline]09:25PM[/editline]
The beauty of path tracing lies in its simplicity: if you have a basic ray tracer up and running, turning it into a path tracer takes no more than 5-10 minutes.
[QUOTE=nullsquared;18446291]That's actually 1.7 FPS [i]per-render[/i], you need to accumulate thousands of renders for the final image to look good.
(BTW, path tracing is essentially ray tracing that simulates light travel by brute force)
[/QUOTE]
Oh, okay. So that's not the normal FPS counter that people use?
[QUOTE=nullsquared;18446291]That's actually 1.7 FPS [i]per-render[/i], you need to accumulate thousands of renders for the final image to look good.
(BTW, path tracing is essentially ray tracing that simulates light travel by brute force)
[editline]09:24PM[/editline]
There's no such thing as "faking" it. This is path tracing. The opposite is photon tracing, which traces from the light to the eye, rather than from the eye to the light. Both are extremely inefficient. What's better is photon mapping and other such techniques.
[editline]09:25PM[/editline]
The beauty of path tracing lies in its simplicity: if you have a basic ray tracer up and running, turning it into a path tracer takes no more than 5-10 minutes.[/QUOTE]
So it's like [url=http://www.maxwellrender.com/]Maxwell[/url]?
I created a voxel ray tracer earlier today, I hope to have screens up soon, but I'm having problems as my math sucks. I'm not even into Trig yet so I'm using slope to replace angles and then looping and adding this slope to the line one unit at a time and then checking if there's a voxel in that area of the grid. It doesn't actually use a grid for the ray part, but the voxels are in a grid and the coordinates of the rays are used to find if there are any voxels on the grid in the same location. If so it returns the color of the voxel, and draws it to the screen. I still need to do lighting, which should be as simple as casting another ray towards each light source, and then if it doesn't hit then it turns the pixel's color slight darker. Just with a 100x100x100 grid of Voxel types (containing 4 unsigned bytes of data), and 100 rays (nearly 10 integers) it's terribly slow and locks up often. It's probably because I'm an idiot as far as math goes. :(
[QUOTE=Ortzinator;18446485]So it's like [url=http://www.maxwellrender.com/]Maxwell[/url]?[/QUOTE]
In a way, yes, though I'm quite sure Maxwell uses more advanced techniques such as photon mapping, etc.
[editline]10:08PM[/editline]
[QUOTE=windwakr;18446405]
Could you please explain to me exactly what the difference is between normal raytracing and path-tracing?[/QUOTE]
Normal ray tracing intersects with the scene and then does direct lighting on the intersection as is done with rasterization (N dot L for diffuse, N dot H for specular, stuff like that).
Path tracing starts at the screen, intersects with the scene, gathers colour information, and then generates a random path to bounce off the intersection into another direction, and does the same thing over and over until some predefined maximum. This process needs to be repeated [i]many[/i] times over and over with different random bounces to calculate "real" light. The problem is that many (most) of these random rays don't contribute anything useful.
Photon tracing is the same idea, except the rays start at the light, intersect with the scene, then hit the "eye plane", which is transformed what you see on the screen. The problem is similar as with path tracing - many (most) of the rays never hit the "eye plane", meaning they're not visible.
Photon mapping and other techniques are rather different, even though they all aim for realistic lighting.
[QUOTE=Chandler;18439794]Definitely twitter, if not that, then something like [url]http://www.tumblr.com/[/url] (Which I would recommend).[/QUOTE]
Back when I was using Github, you could set it up to automatically tweet all of your commits. :v:
[QUOTE=windwakr;18447109]
BTW: Have you seen this: [url]http://code.google.com/p/tokaspt/[/url]
I found it while looking around google for path-tracing. It's fucking sweet, I'm playing around with it right now.
It generates 20 "frames per second", but it uses CUDA.[/QUOTE]
Hey, that's really cool!
Working on an installer... so far all that's done is a MySQL connection test, whoop. Once installer's done I'll probably tag 0.1 in the repo
[media]http://i49.tinypic.com/9vbfwm.png[/media]
[b]EDIT:[/b] Cool, I get boxes for each time I post something about bugspray, I feel loved [img]http://www.facepunch.com/fp/rating/heart.png[/img] [i]More boxes[/i]
Sorry, you need to Log In to post a reply to this thread.
