This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Messages - Builderboy
Pages: 1 ... 10 11 [12] 13 14 ... 375
166
« on: September 28, 2012, 12:01:09 am »
Binder, the Garbage Collector only runs if you have objects which are no longer being used. I can create any amount of objects I want, as long as I keep references to them until I want them to be erased. Additionally, when the level changes the area I request the GC to do all it can to collect objects, which helps keep the load off during the actual level.
Oh and the game should work on the gallery, that was an outdated post saying it did not work. Additionally many people have been playing it recently so there might be something wrong on your end Munchor. You have the latest version of java downloaded? What is your internet speed like?
167
« on: September 27, 2012, 04:48:48 pm »
I'm not saying that the camera will not be moving, I am saying that as long as the camera is inside of a single cube, the cubes being drawn will be sorted in the same order regardless of the angle or the location of the camera inside the cube.
168
« on: September 27, 2012, 04:42:10 pm »
Unless the camera is also moving as it is rotating, the distance from each block to the camera should not be changing. Since we sort blocks based on how far they are from the camera, and since the distances are not changing, shouldn't the sorted order also not change?
169
« on: September 27, 2012, 03:33:57 pm »
Seems interesting. Could you give an exemple ? Because of my poor English skills, I'm not sure that I've got it very well...
Mmm it's a bit hard to explain, but think of it this way. Every single frame you are sorting the blocks according to distance, and every single frame you arrive at the exact same order. Every single frame you always render the farthest blocks first, followed by closer blocks, and finally centering on the camera. Instead of re-sorting the blocks every frame, you could just generate a sorted list when the game starts, that way you never have to sort again.
I can't really see how well that would work when you rotate the camera though.
Well I suppose you would have to be considering all blocks around you equally, and then throw them out if they are outside of the camera view. Since the sorting of blocks should be independent of camera angle anyway.
170
« on: September 27, 2012, 02:55:24 pm »
Seems interesting. Could you give an exemple ? Because of my poor English skills, I'm not sure that I've got it very well...
Mmm it's a bit hard to explain, but think of it this way. Every single frame you are sorting the blocks according to distance, and every single frame you arrive at the exact same order. Every single frame you always render the farthest blocks first, followed by closer blocks, and finally centering on the camera. Instead of re-sorting the blocks every frame, you could just generate a sorted list when the game starts, that way you never have to sort again.
171
« on: September 27, 2012, 01:34:39 pm »
Here are a couple ideas that could help with the speeding up of the way you sort things:
First off, it is important to note that whenever the camera is within a voxel, the voxels that are rendered are sorted relative to the distance they are to that voxel. Consequently no matter what voxel the camera is in, the order of the rendered voxels is always the same relative to the center camera voxel. What this means is that you can presort a large number of voxel positions into an array based on how far they are from a center voxel, and simply use those positions relative to the camera to render.
This works, but it can take up a large amount of memory. If that is a problem, there is another solution that I discovered when working on my Castle Storm game, which uses a similar rendering method. The way it would work is by drawing the voxels (still relative to the camera position) in shells, and it is painfully difficult to explain, so if you are interested, I can whip up some sort of gif or example and we can talk from there.
Now, this would speed up the sorting of cubes, but it would not actually speed up the drawing, which is probably another main bottleneck. First off, since you are only rendering cubes, you can always discard the faces that are facing away from you. This is a rendering trick you can use on convex objects, that any faces that are facing away from you cannot actually be seen. Additionally, you can use a simply dot product to detect whether or not a face is facing away from you, so it is super speedy and results in half of your faces being discarded! Another method would be to look at the cubes surrounding a cube to be rendered. When you go to render a cube, you can look at neighboring cubes to see if they are solid, if not, you do not have to render the connecting face! This should result in significant speedups hopefully, since using these methods would drastically cut down on the number of polygons you need to render in any given frame.
172
« on: September 27, 2012, 02:27:34 am »
I have a question of my own, how exactly are you 'sorting' the cubes to draw? Are you actually putting their distances in a list and sorting them?
173
« on: September 18, 2012, 11:39:29 pm »
Mmm I supose I could see that. Either way though it looks great ^^
174
« on: September 18, 2012, 11:28:08 pm »
Aww i liked the particle effects you posted on Cemetech better :[
175
« on: September 16, 2012, 12:22:56 am »
I haven't and I am le sad :[ Have you?
176
« on: September 15, 2012, 09:09:22 pm »
Well, it's not in a list, so I'd say it's more of a second tilemap. It is still technically a grid of cells that evolve in the simulation based on a certain set of rules, so I still think it is classified as a cellular automaton^^
177
« on: September 14, 2012, 10:19:06 pm »
It reminds me a little bit of Minecraft water And it looks super epic as well! The physics of this game look like it's going to make the gameplay fantabulous, can't wait for more updates
178
« on: September 10, 2012, 10:27:41 am »
Check the first post
179
« on: September 09, 2012, 06:29:07 pm »
It really depends on what the final gameplay will look like. If there are some super intensive things going on, 15mgz might be worth it. We shall have to see Leafy could you give us a little bit more info on what the gameplay is actually going to consist of?
180
« on: September 08, 2012, 06:49:48 pm »
So this is not a big update, but a major change in the direction that this game is going in. As some of you may know, I have been working at a company called Leap Motion, and while there, I have learned a whole bunch of stuff, which includes OpenGL. With my newfound knowledge, I have taken it upon myself to completely rewrite the graphics engine in OpenGL using the Lightweight Java Game Library, which is the same graphics library that Minecraft uses! I am also moving away from Greenfoot and into Eclipse. While I was at Leap Motion, I grew used to Visual Studio and all the awesome features it gave, and Greenfoot is just too lacking for me anymore. I will also probably be upgrading the scripting engine a bit, but that is a bit less of a change Anyways, I have already started work porting it over, and already the results are looking awesome! Below is a screenshot of the beginning of the new lighting engine. All lights will be dynamic (be able to move around) have different color abilities (impossible with the old engine), and cast soft shadows across everything!
Pages: 1 ... 10 11 [12] 13 14 ... 375
|